Author: Prof. Rudra Dutta of NCSU Computer Science
I have been using GENI in some form in my teaching for the last three years –
very tentatively to start with, but more extensively over time. Fall, 2014
was my most ambitious use so far.
The course I was teaching was Internet Protocols – a graduate level course on
networking that assumes at least one previous general networking course.
I assume basic working knowledge of networking, TCP/IP, socket programming,
and general knowledge of common Internet functionality such as HTTP, DNS etc.
After a quick refresher of some of this topic, the course dives into details of
the forwarding engine, QoS issues in forwarding, programming kernel modules
with netfilter, some content about routing, SDN, etc. The first half of the
course largely individual and group assignments on these topics, and the
second half is one large group project. Groups are assigned by myself for both
assignments and project – not self-assigned.
In this instance, I used GENI in two different ways – first, specific
questions out of some of the homework assignments were required to be done on
GENI, and later, GENI was specified as one of the three platforms that students
could use for the project. More detailed information about the administration,
including the specific assignments, is available for those interested from
http://dutta.csc.ncsu.edu/csc573_fall14/index.html. I exclusively guided the
students into using ExoGENI substrates, because experience from previous
semesters indicated that it was the most nearly consistent in providing
slice behaviors. (Some other substrates would have varying slice and
stitching behavior, when trying with the same RSPEC multiple times – this was
confusing to students.) We also used a methodology of designing/reserving
through Flukes and accessing separately by ssh, because it went well with the
rest of ExoGENI, and again presented a unique way to negotiate the
authentication/authorization issues for the students.
Before assigning the first homework, I had briefly covered GENI operations in
class. The first assignment actually had them create GENI IDs, request joining
the ncsu_teaching project, and they ended up simply being able to reserve a
slice with a simple four-node tandem network, then setting up routing tables at
each node to get a simple ping through. Later homework assignments were more
complex, until the final one asked them to create a seven-node topology and use
both OpenFlow and kernel module programming to build and investigate the
behavior of a firewall.
There were a total of 86 students, who were eventually
grouped into 22 project teams; however, the class started with a somewhat
larger number of students who attempted the early assignments. There were the
usual initial problems; students complained of resources not being available,
access never working, very sluggish access, and other similar issues. Upon
investigation most of these could be resolved to misunderstandings about ssh
key files, lack of appreciation of how much extra bandwidth it requires to
push through a GUI through two sets of networking connections (many of the
students had no suitable self-owned computing to access GENI from, and were
using servers from VCL, the NCSU computing cloud, to do so), not realizing that
management interfaces were visible to them and trying to use them for their
slice usage, etc. There were also some actual GENI issues – over this period
ExoGENI went through some ExoSM problems, which caused them to advocate that
anybody not using cross-rack stitching should use specific SMs rather than
ExoSM (contrary to what the webpages typically said), and also changed the
format of the Flukes .properties file, which the TA had to scramble to get
communicated to all students. By far the problem that had the biggest impact
on the students was that resources were not always available when needed –
students would wait for hours and days without requests being provisioned.
We cannot be sure but believe that these represent real resource crunches, not
an artifact or mistake of some kind.
When time came to propose project ideas, I was somewhat surprised (after all
the complaints) that 12 out of the 22 teams picked GENI as their platform
outright, and another 7 listed it as one of the two platforms they were going
to use (3 of these eventually ended up working on GENI). While the teams had
varied success in their projects, I was glad to see that they had all
negotiated GENI well. Some of the projects were quite impressive. Most of
them would have been possible to execute in my department’s networking lab,
but it would not have been possible to support the same number and variety of
Each of the teams that used GENI as their project platform wrote up a short
assessment of the role of GENI in their project. A few of these are appended.
Most of them speak of pros as well as cons, but on the whole they confirm that
the availability of GENI enriched this course, and produced learning benefit
that would not have been unattainable without it.
1. Were able to allocate resources as needed on-demand, with different specifications.
2. Allowed us to work remotely as per our convenience.
3. We could create a topology in Flukes with the start-up script created for the different nodes.
This allowed us to create new slices with the nodes already configured with some basic tools like tshark, Open vSwitch installed on the nodes required.
1. There is no way to modify a slice once created. This necessitated creation of new slices even for slight change in requirements. (For instance the bandwidth of links could not be modified after slice creation).
2. The environment wasn’t very predictable in its behavior.
Even if a reservation was successful, the nodes would not initialize to a successful state sometimes.
Also, it was difficult to reserve slices on some racks sometimes.
* Real network simulation – Slices and nodes being provisioned in a real
* network gave more real network statistics than if instances contained in a
* controlled environment like NetLabs or VCL Managed infrastructure – GENI
* allowed us to save a topology and recreate it instantly. This saved us a lot
* of time than if we were to create virtual hosts manually everytime.
* Large topology issues: long waiting time for the devices to change from
* ticketed to active in ‘response manifest’ for topologies with more than 10
* devices. Main problem faced was “resources not available” while reserving
* the slice. This was seen across multiple controllers
Our team found GENI extremely beneficial throughout the development process due
to the amazing simplicity it offers in creating new topologies. We found it
quite quick and simple to create a new customized topology any time we needed
to test a specific part of our project that previous topologies were not
capable of conducting. Using GENI also enabled each team member to individually
work on their respective assignments in small isolated topologies without
interfering with another teammate’s work. Finally, GENI’s advantage over
physical networks is that it provides a great level of flexibility throughout
the development process and the demo day (e.g. we could work on our project and
demo it anywhere on campus as long as we have our lap tops with us). However,
we recognize that working on the actual physical network has a great advantage
of providing hands-on experience with the network equipment. In our opinion,
the lack of this hands-on experience is the only drawback of using GENI.
1. Remote access to save time connecting wires and cables.
It was easier to simulate a typical network topology and work on it virtually
than actual physical connections. Our project involved testcases to be run
on 2-3 different network topologies. So, creating a slice for each topology was
less time consuming than connecting workstations in Netlabs.
2. The ability to obtain a slice and store the various node configurations and
to be able to retrieve those configurations with ease and continue working. All
the nodes required quagga to be installed on it, also there were frequent change
to the code as per requirements, which had to be incorporated by recompiling
the application module. Doing this on virtual nodes simultaneously by running
bash scripts was easy.
3. Ease of testing in a simulated environment aping actual large scale networks.
4. GENI allowed us to create multiple topologies and hence all team members were
able to simultaneously work on test-cases individually on their own topologies.
This saved us a lot of time.
1. Running test-cases like interface shutdown on the interfaces which needed to
be performed using the “ifdown” was not possible on GENI and reported an error
saying the interface did not exist.
2. Running kernel modules to get device statistics from the linux data structure
net_device was not functional for the virtual interfaces. It worked only for
– Configuration of nodes was simple.
– The fact that we could access the nodes from anywhere turned out to be very advantageous because our class schedules, exams, and other assignments left us with limited time to work on the project together — it would have been difficult to work on NetLabs.
– Configuring OVS for the controller was easy. We were told that some changes were to be done in Floodlight in order for it to listen to external switches. We’d have had to this in VCL, but in GENI, it turned out to be easy.
– If any command, or programming error caused the configuration of the eth0 interface to get corrupted, we would have had to create a new slice and start over, because we’d have lost connectivity to the node. This would have been easily correctable in NetLabs. This did not occur specifically in the project, but it did happen to us once during a group homework assignment on GENI.
– There was one instance when we lost connectivity to the nodes, for about 10-15 minutes. We assumed it was because of some kind of maintenance.
GENI platform was very useful for our project. The best thing about it is the easy remote access to the nodes. It was also easy for modifying the kernel codes and building the modules. When initial modifications were tried, multiple crashes happened in the nodes which could be easily recovered.
Each team member could create his own set-up and work in parallel in GENI. As we required multiple AQM’s to be inserted in nodes, we created multiple slices (one for each), this helped us save time avoiding regular initial set-ups.
Only disadvantage of GENI is that some times it gets slow and sometimes slice building would take time.
Platform : GENI
We used GENI because our Demo topology required 7 Linux server nodes & GENI
provided the ease of recreation of the topology in case of failures while doing
integration Testing and fixing and debugging issues found during end to end
Testing. Project needed compilation of 2 kernel modules and an executable user
file. So, it was easy on GENI when we had to make changes to the modules and
user executable file and insert the modules. Also the teams previous experience
and familiarity with GENI due to past home-works was a motivation to use GENI.
Some risks and challenges we faced while using GENI were availability of exact
kernel version that is needed for the code to work in the way required thus
resulting is us not getting a slice in GENI. Whenever kernel module that hung
meant reloading the image on a GENI node. We did not face that problem many
times, whenever we got into such situation we made the changes and then
everything was first tested on our local Virtual machines, where we only had to
reboot the virtual machine.There was also a risk of cutting of SSH access to
our topology because of a firewall rule that blocks packets from undefined
SourceIP to undefined DestIP as access the Eth0 interface IP gets denied by
that rule, resulting in us not able to access to those nodes.
The use of GENI helped us test our project on several complex topologies. We did not have to go through the trouble of creating several VCL images in order to test a
Although GENI helped us test with several nodes, we faced a perennial problem of getting failed resources or disconnected links.
Also, an extended reservation for a slice did not guarantee the existence of the slice till the last date of reservation.
Use of different controllers or racks did not help much.
Experience with GENI :
The GENI platform made working on our kernel based project a good experience. The slices were mostly easily available, other than the time when
there was possibly ‘big demand’. Getting the required image on a node was also straightforward with GENI. For our project we wished to utilize the
GENI DESKTOP for monitoring throughput, while sending traffic through the nodes. This is an interesting feature supported by GENI through FLACK.
On the whole, GENI offered a supportive learning environment for the project.
We used GENI as a platform for our project. The major advantage of using GENI was it allows to create our own topology which makes testing our project easier
because we needed different set of topology. But getting the desired topology with more than 4 switches, controller and hosts was difficult.
Sometimes, one of the switch will become inactive (FAILED state) which causes to get the complete topology again or contact GENI folks to resolve it.
Advantages of GENI:
Using GENI platform gave us access to wide range of resources to experiment like we had many kinds of servers, different kinds of operating systems to try our module on. We could also freely upload different utility softwares on the linux boxes, configure them as switch, router etc as and when needed.
GENI gave us flexibility to access the network from anywhere which would not be possible in Physical labs with same ease.
Disadvantages of GENI:
Once a network was created, if we needed to make any change to the topology for example changing IP address, we had to again create the entire network and ask for new resources.
Since, we had to implement kernel modules which meant always compiling and inserting modules into the kernel, in order to run and test them, we had the risk of the kernel crashing and the node requiring a restart every time this happened. Since we had created the network in GENI, we did not have the privileges to restart the node in case its kernel crashed. Hence, the only solution was to recreate the network, put in the request and wait for it the nodes to get commissioned(which would fail most of the time). Once, that was over we had to update the forwarding and routing tables so packets could be sent successfully. This entire setting up and configuration would lead to a lot of extra time spent in case a crash occurred. So, we had to resort to first implementing and testing the kernel modules in VMs on our machines where we could quickly restart the machines.
Advantages of using GENI:
1. Initially we were playing around with Click module and few times got our configurations wrong. With GENI, it was easy to just create new slice.
2. Using GENI, we were able to work as per our convenience.
3. Different members were able to work on multiple slices independently to try out different parts of the project. Like me and Nikhil were trying out Click configurations on my slice while Aditya was trying out different traffic generators on his slice. So you could say we were able to work in parallel.
Disadvantages of using GENI:
1. Our data and configurations need to be redone on a new slice each time. But compared to the perks this was a small overhead. Also be redoing them each time we memorized the steps and CLIs.
2. Bandwidth of ethernet links on GENI is limited. For our project, actual ethernet bandwidth application could have been tried.
Advantages of using GENI:
1. Ability to access devices remotely, unlike Netlabs. Thus, the team could easily work from home.
2. VCL is apt only to create standalone hosts. In our project, we required 8 nodes, thus GENI provided an easy interface to create networked VMs.
3. Easy to provision nodes with specific images. Anytime we used to face issue with nodes in the network, we would easily delete the slice and reserve a new one.
Disadvantages of using GENI:
1. Unable to always reserve resources. We had a few instances when we were not able to reserve the required topology dur to resource constraints on the controller/orchestrator.
2. Connectivity issues. SSH was not available a couple of times, though it was rare.
We have used GENI for our project based on OpenFlow,
and it has been a handy tool because of the range of
features available in it.
The single most important feature that I liked in GENI over VCL
is the admin privileges. Our project requires root access and
it easily available for us to get it in GENI. With root access
we were able to install various third party softwares and if
something went wrong it is easy to create another slice and
delete the old one, there is no real damage to any physical system.
It would be better if the number of orca controllers and the
resources available in each of them are increased as we faced some
delay in creation of slices from RCI, UCD controllers.
Moreover, if options such as, adding new nodes to an existing
slice etc, if available, would have saved a lot of time in
performing redundant work.
GENI provided us a platform to check the concepts taught in class and how they were implemented in real-world topologies, like adding ARP tables, Route tables and monitoring network traffic. Ability to create topologies rather than connecting systems manually and opportunity to test latest protocols like OpenFlow over these topologies is great. Our project needed us to load and unload kernel modules repeatedly and the root user permissions that GENI provided us made it really easy to do some necessary in kernel too. Comparing it to a case where kernel modules are loaded in local systems and they got hung, just the ability obtain a new node to perform testing on losing one made it very comfortable to implement kernel modules.
During high demand, it was difficult to obtain slice to perform experiments. GENI’s UI can be made more use-friendly. After slice is submitted and all nodes become active, hovering mouse over interfaces/nodes can show a simple pop-up note giving details about node’s IP address and interface’s details. Whenever a user logs in, it opens a new terminal window, handling multiple windows can be cumbersome if there are many nodes, it will be better if there is an option to open them in new tabs.