A sandbox ready for testing is available, please check the osm9-hackfest9 Slack channel for passwords.
- OSM Instance at: hackfest@172.21.248.19 (~/osm-packages/magma is synced with this repo), which has a PNF and the required "sgi" network already shared.
@@ -28,11 +19,11 @@ There is a "build_infra.sh" with some examples of what needs to be prepared.
1. If you just cloned the repo, make sure you run `git submodule update --init` under the osm-packages folder.
1. Upload the packages to OSM, the "build_slice.sh" file contain some useful commands, from building to launching.
1. Make sure you got the images for AGW and srsLTE emulator available at ETSI VIM or at the hackfest@172.21.248.19 home directory.
1. Make sure you got the images for AGW and srsLTE emulator available [here](http://osm-download.etsi.org/ftp/osm-7.0-seven/OSM9-hackfest/images/).
## Launching the Slice
1. Edit the params.yaml and set an address for your Magma Orc8r-proxy service, which AGW will connect to. Same IP address should go to 'proxyserviceloadBalancerIP' and 'orch_ip', and should belong to your K8 Cluster MetalLB pool. Make sure you assign an IP address not being used in the target cluster (if using the ETSI K8sCluster at 172.21.248.18, an IP address between 172.21.250.150 and.199 should be available)
1. Edit the params.yaml and set an address for your Magma Orc8r-proxy service, which AGW will connect to. Same IP address should go to 'proxyserviceloadBalancerIP' and 'orch_ip', and should belong to your K8 Cluster MetalLB pool. Make sure you assign an IP address not being used in the target cluster.
1. In the same file, set a name and ID for the first AGW, in parameters agw_id and agw_name (they need to be different each time you launch a new slice)
@@ -40,7 +31,7 @@ There is a "build_infra.sh" with some examples of what needs to be prepared.
## Verifying the services
1. Visit the Orc8r dashboard at the KNF's nginx-proxy svc IP, with https and credentials admin@magma.test / password1234, then check that your AGW has been registered successfully under the list of Gateways in this path: https://<orc8r-nginx-proxy-ip>/nms/osmnet/gateways) (after proxy charms are finished)
2. Via this same dashboard, add check that a test subscriber has been added as Day-1 primitive, with these parameters:
2. Via this same dashboard, check that a test subscriber has been added (as Day-1 primitive), with these parameters:
- IMSI: 722070000000008
- KEY: c8eba87c1074edd06885cb0486718341
- OPC: 17b6c0157895bcaa1efc1cef55033f5f
...
...
@@ -59,13 +50,7 @@ There is a "build_infra.sh" with some examples of what needs to be prepared.
After UE is attached (at emulator machine), the "tun_srsue" will appear, and a default route should be added automatically to it (script at the image), pointing to the GTP tunnel endpoint:
Finally, a Day-2 primitive must be executed against the PNF (VyOS) to allow traffic from the specific Magma SGI IP address, for example, if it's 192.168.239.10:
With this, the UE machine will have access to Internet through the AGW and then the VyOS PNF.
This works because the VyOS Router is pre-configured to deny all traffic unless explicitely added to a MAGMA_AGW group:
Make sure the PNF (VyOS Router) is pre-configured to deny all traffic unless explicitely added to a MAGMA_AGW group:
```
set firewall group network-group MAGMA_AGW network 192.168.239.10 # this rule is added by the primitive
...
...
@@ -77,6 +62,11 @@ set firewall name MAGMA_FW rule 10 source group network-group MAGMA_AGW
set interfaces ethernet eth1 firewall in name MAGMA_FW
```
With this, a Day-2 primitive can be executed against the PNF to allow traffic from the specific Magma SGI IP address, for example, if it's 192.168.239.10:
With this, the UE machine will have access to Internet through the AGW and then the VyOS PNF.
## Additional tests
...
...
@@ -113,11 +103,11 @@ A second slice, reusing the same Orc8r, can be launched at different VIM, so tha
### Metrics collection
VIM-level metrics are being collected by default, they can be observed at the Grafana dashboard (possible bug at the ns_id variable, under review)
VIM-level metrics are being collected by default, they can be observed at the Grafana dashboard.
### Auto-scaling
Magma AGW VDU is configured for autoscaling when CPU exceeds a threshold. After scaling, services are not automatically balanced (possible add-on for future hackfests)
Magma AGW VDU is configured for autoscaling when CPU exceeds a threshold. After scaling, services are not automatically balanced (possible ennhancement for the future)
