@@ -15,12 +15,18 @@ Request your own user to run advanced tests.
## Preparation
### Infrastructure preparation
This example requires a PNF, emulated with a VyOS router (image [here](http://osm-download.etsi.org/ftp/osm-6.0-six/7th-hackfest/images/vyos-1.1.7-cloudinit.qcow2.tgz)), connected to a shared management network (osm-ext in this example) and to a shared internal "sgi" network where the Slice will be placed.
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. Make sure you add a VIM that has a default management network, for example: `osm vim-create ... --config='{management_network_name: <vim mgmt-net name>}'`
1. Add the PDU with the yaml file (emulated by a VyOS VM in this environment). You can do it with `osm pdu-create --descriptor_file pdu.yaml` (editing at least the VIM ID first)
1. Add your K8s Cluster to the VIM.
### Packages preparation
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.
...
...
@@ -51,9 +57,7 @@ This example requires a PNF, emulated with a VyOS router (image [here](http://os
## Testing traffic
After UE is attached (at emulator machine), the "tun_srsue" will appear, and a default route should be added (pending to put as Day-2 primitive), pointing to the GTP tunnel endpoint:
`sudo route add -net 0.0.0.0/0 gw 192.168.128.1`
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:
...
...
@@ -70,20 +74,25 @@ A Web Proxy is available via a KNF with primitives, implemented with Squid throu
The UE's browser can be now configured to navigate with this proxy service.
TODO: add how to test this service and run primitives to allow URLs.
The UE's browser can be now configured to navigate using this proxy service. Configure it at the browser's preferences, using the K8sCluster exposed IP for this service, and port 3128 (for HTTP, HTTPs and FTP requests)
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 (Orc8r NS is shared)
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.
### Placement
A second slice, reusing the same Orc8r, can be launched at different VIM. The procedure is as follows:
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 --network netosm osm_pla:dev`
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.
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.
@@ -95,7 +104,7 @@ VIM-level metrics are being collected by default, they can be observed at the Gr
### Auto-scaling
Magma AGW VDU is configured for autoscaling when CPU exceeds a threshold. After scaling, services are not automatically balanced (WIP)
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)