Two months ago, TERENA Networking Conference 2012 took place in Reykjavik, Iceland. DANA team has been there presenting achievements in the projects we are involved, contacting NREN’s and industry key people and attending very interesting workshops and lectures.
DANA presence could be noticed in both a project booth and a couple of presentation slots we where allocated. One of them was performed jointly with GEANT.
While next posts may go deeper in other events, this post is focused on the OpenNaaS demonstration at TNC, outlining OpenNaaS key features and evaluating the overall experience of OpenNaaS being presented in this year’s TNC.
OpenNaaS, as introduced in a previous blog post, is an open-source tool creating a NaaS reusable stack for on-demand, commonly user-triggered, provisioning of network resources. Born from Mantychore FP7 project, it is being developed in the OpenNaaS community.
As already mentioned, OpenNaaS has been presented in TNC 2012. Concretely, it has been demonstrated in a private workshop and during one of GEANT‘s demo slots, following an invitation to show-cast AutoBAHN based applications. It has also been demonstrated live to interested individuals arriving at the booth Mantychore consortium had at the conference. This has been a good opportunity to explain OpenNaaS with more detail as well as establish contact and share visions with NREN’s community and industry key people.
The demo itself was conducted by Pau Minoves (i2CAT) and Dave Wilson (HEAnet) and consisted in using OpenNaaS to create a functional IP network (using the NaaS paradigm) on top of the testbed deployed in Mantychore FP7 project.
This testbed, summarized above, consists of:
- 3 routers in different locations. All of them connected to internet, connected to AutoBAHN managed ports but not directly connected to each others:
- myre: Juniper MX240 running JUNOS 11.2R1.10 and located in HEAnet GD5 (Dublin)
- gsn-cpe1: Juniper MX80 running JUNOS 11.2R3.3 and located in HEAnet Parkwest
- uni-c: Juniper MX80 running JUNOS and located in UNI-C (Copenhagen)
- an AutoBAHN Inter Domain Manager (HEAnet IDM),
- a server running OpenNaaS v0.10 and,
- for demonstration purposes only, a web cam connected to one of the routers and zanzil server hosting a webpage with an animation.
- On first step, resources are registered into OpenNaaS using a resource descriptor, together with a protocol context. Resource descriptor is used to describe a resource, assigning it a known type and a name, and also to specify which capabilities OpenNaaS should load for it. On the other hand, protocol context is used for communicating with the real resource. This step loads resource information into OpenNaaS, populating each resource model.
- Then, sub-interfaces are created and configured in routers by specifying a VLAN id in each. This is done by calling router’s chassis capability, the one responsible of interface/sub-interface management.
- On third step, a logical router is created in each router, and created sub-interfaces are transferred to them. For the demo scenario, only a single logical router is given internet access, the rest will be accessible through this one.
- After that, a network is created and logical routers are added to it. This network is treated as another resource in OpenNaaS. What’s the benefit? Control of this resource may be transferred to final users, who can then interact with it’s capabilities.
- An IP address scheme is used to add IP addresses to interfaces in this network. At this point, interfaces are well configured, but there is no physical connectivity between logical routers.
- In order to provide physical connectivity, AutoBAHN BoD service is invoked. OpenNaaS requests a connection between required autobahn managed interfaces and waits for Autobahn resolution.
- Once each router in the network can reach the others, it’s time to activate OSPF in the network so routing tables are populated and routes established. OSPF is launched using OSPF capability in the network, using the network as a single resource. At it’s time, network OSPF capability will look for OSPF capability in it’s components (logical routers) and invoke their methods.
- Finally, a GRE tunnel is established in order for other equipment to join the network. GRE tunnel is established between a logical router (using OpenNaaS to configure it), and zanzil server (manually configured).
In order to demonstrate successful configuration of the scenario, anyone could visit the web cam and an http server in zanzil, located at the other side of the GRE tunnel, as the setup was done with public addressing.
We are proud of having all these features ready for TNC and being able to show them in live demonstrations. We are also happy for the audience response. In fact, we are gladly surprised for the good assistance in OpenNaaS presentation workshop as well as for the feedback we received in it. Presentations at the booth gave us, also, a good opportunity to explain OpenNaaS with further detail and to establish contact and share visions with NREN‘s community and industry key people. We expect OpenNaaS to take advantage from these contacts and evolve taking into account envisioned business needs and received feedback. Thanks everyone for participating!
Finally, I’d like also to thank all the people making it possible. It’s been really a hard work to develop, deploy and coordinate all efforts to arrive here, and we made it. We’re now going further. So, many thanks and cheers!!