@@ -18,6 +18,7 @@ There is a "build_infra.sh" with some examples of what needs to be prepared.
### Packages preparation
1. If you just cloned the repo, make sure you run `git submodule update --init` under the osm-packages folder.
1. Take a look at the cloud-init files of the VDUs. They basically remove the default gateway obtained from DHCP and add static routes back to the management networks. Since they map to the ETSI VIM, they might need to be adjusted for your specific use case. The purpose of removing any default gateway acquired from the management interface, is to establish the data path to Internet through the AGW and PNF.
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 [here](http://osm-download.etsi.org/ftp/osm-7.0-seven/OSM9-hackfest/images/).
...
...
@@ -30,21 +31,22 @@ There is a "build_infra.sh" with some examples of what needs to be prepared.
## Verifying the services
### AG, eNodeB and Subscriber Registration through Day-1 primitives
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, check that a test subscriber has been added (as Day-1 primitive), with these parameters:
- IMSI: 722070000000008
- KEY: c8eba87c1074edd06885cb0486718341
- OPC: 17b6c0157895bcaa1efc1cef55033f5f
3. The emulator is ready to connect, Day-2 primitives are available for this:
### eNodeB register Day-2
3. Check that the eNodeB has registered to the AGW (as Day-1 primitive that uses juju-relations), by accesing the Magma AGW via SSH and running "tail -f /var/log/mme.log".
Otherwise, you can go to the Magma Orc8r dashboard and look for the "Connected EnodeB" metrics.
With this, the UE machine will have access to Internet through the AGW and then the VyOS PNF.
After the primitive is executed, the UE machine will have access to Internet through the AGW and then the VyOS PNF.
## Additional tests
...
...
@@ -89,29 +91,33 @@ Primitives are available to add/remove allowed URLs:
Additional slice instances can be launched (changing agw_id and agw_name), and we should see that just the AGW+emulator NS is launched, as the Orc8r NS is shared.
### Metrics collection
VIM-level metrics are being collected by default, they can be observed at the Grafana dashboard.
VNF-level metrics are collected through SNMP using a dedicated "execution environment" POD which includes the SNMP Exporter Prometheus module.
Its specifications can be found inside the "helm" folder in the VNF package. They can be found at Prometheus GUI (look for metrics starting with "if", from the IF-MIB) and added manually to Grafana.
### Placement
A second slice, reusing the same Orc8r, can be launched at different VIM, so that we see AGWs being launched at remotely VIMs. It would need management networks to be reachable between VIMs so the Orc8r's exposed address is reachable from the remote AGWs. The procedure is as follows:
1. [ If PLA not available in setup] Build the PLA image by cloning the repo and running `docker build . -f docker/Dockerfile -t osm_pla:dev`, then plug it into the OSM network. In docker swarm it would be with `docker run -d --name osm_pla --restart always --network netosm osm_pla:dev`
1. [ If PLA not available in setup] Make sure you add the Placement module to your OSM installation.
1. Prepare the second VIM by ensuring it has the PNF/PDU and the required images.
1. Edit the `pil_price_list.yaml` and `vnf_price_list.yaml` as desired, ensuring that it's "less expensive" to launch the VNFs at the second VIM. Examples are available at this repo.
1. Copy the files to the placement folder at PLA:
1. Copy the files to the placement folder at PLA. A sample using docker is below, which can be made with kubectl in a similar way.
1. Uncomment the placement-engine line and launch as usual! you should see the AGW/srsLTE/PNF subnet being instantiated in the second VIM.
### Metrics collection
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 ennhancement for the future)
Magma AGW VDU is configured for autoscaling when CPU exceeds a threshold. After scaling, services are not automatically balanced (possible enhancement for the future)
### SDN Assist
The MagmaAGW+srsLTE VNF has been designed so that there can be an SDN-Assisted data-plane in the internal S1 VLD. As long as the interfaces are declared as "SR-IOV" in the descriptor, instead of PARAVIRT/VIRTIO.
The MagmaAGWsrsLTE VNF has been designed so that there can be an SDN-Assisted data-plane in the internal S1 VLD. As long as the interfaces are declared as "SR-IOV" in the descriptor, instead of PARAVIRT/VIRTIO.
Even though it can be tested with any fabric for which there is an SDN Assist plugin in OSM, this documentation will refer to the case where an OpenFlow-based fabric is used to interconnect the servers, so that ONOS VPLS becomes the ideal plugin to use.
