NEMO:Virtual Networking PoC Demo
The PoC demo of NEMO project was shown on the Open Networking Summit 2015. The introduction Flash and Video of NEMO demo are now available for download. You can also get more details for NEMO and NEMO project. This document describes the NEMO demo in detail.
The demo shows how users can design their own network using NEMO, which is more abstract and simple. With NEMO, users can design and deploy any desired network without knowing the details of the underlying physical network. NEMO allows the users to define the network nodes, such as host, layer 2 group, firewall, load balancer, and the connections to connect these nodes. Further, flows and policies can be defined to achieve the flow-based traffic control functions in the user’s network, such as filtering, redirect, service chaining, etc. However, this demo only shows the network creation.
Once the network is designed with NEMO, the NEMO engine will resolve the NEMO statements, automatically map the network into the underlying physical network and configure all related physical devices through SDN control protocol. Then a state machine will be maintained by the NEMO engine for the user. With the logical abstraction of NEMO, the complexity of the underlying network is hidden, as well as the network resources are better managed and utilized.
Start the OpenDaylight and install odl-restconf, odl-dlux-all and odl-nemo-engine features in karaf.
Create a physical topology using mininet.
The figure below shows the created physical topology. As we see, it’s the typical fat tree topology in the data center.
To check the physical topology has been collected into the OpenDaylight, visit the OpenDaylight dlux UI, in which the physical topolgy and all Openflow switches created above should be shown just like the two figures below.
In the NEMO UI, which is represented as a tag in the dlux UI, there’s no tenant at the beginning.
Now, start a NEMO client, connect it to the NEMO engine and create a tenant with username “tenanta”, password “password” and user role “1” which denotes a virtual network user. Then enter NEMO script to create a virtual network for the new tenant.
Node h2,h4,h9,h12,h13,h15,h16 Type host Property location:(openflow:1:6, openflow:2:6, openflow:5:5, openflow:6:6, openflow:7:5, openflow:8:5, openflow:8:6); Node n1 Type l2 Contain h2,h4 Property ipv4prefix:18.104.22.168/24; Node n2 Type l2 Contain h9,h15 Property ipv4prefix:22.214.171.124/24; Node n3 Type l2 Contain h12,h13,h16 Property ipv4prefix:126.96.36.199/24; Connection c1 Type p2p End-Nodes n1,n2; Connection c2 Type p2p End-Nodes n1,n3;
The first statement of the NEMO script describes the location information of all tenanta’s hosts. The next three statements are to create three layer 2 groups or subnets with hosts they contain and their IPv4 prefix property. And the last two ones are to create two p2p connections to connect the first group with the other two.
Refresh the NEMO UI, tenanta’s virtual network topology and the corresponding NEMO script can be seen now.
To validate the NEMO script has been correctly resolved and successfully executed, test the communications between all tenanta’s hosts in mininet. As the test results show below, hosts in the same group or in two connected groups can communicate with each other, while hosts in the disconnected groups can’t.
As before, start another NEMO client to create another tenant, as well as use NEMO to create a virtual network for him.
Node h1,h3,h5,h8,h10 Type host Property location:(openflow:1:5, openflow:2:5, openflow:3:5, openflow:4:6, openflow:5:6); Node n1 Type l2 Contain h1,h3,h5 Property ipv4prefix:188.8.131.52/24; Node n2 Type l2 Contain h8,h10 Property ipv4prefix:184.108.40.206/24; Connection c1 Type p2p End-Nodes n1,n2;
And now, there are two tenants in the NEMO UI after refreshing it again.
Do the same as before to check the communications between hosts of the new tenant.