Managing networks with OpenFlow

Level 1: There and Back Again

Imagine two hosts connected by a switch (Figure 4). Initially, I won't define a controller and set flow entries manually. To check whether the connection has been established, host 1 uses the CLI in Mininet to ping host 2 (Listing 1). I ping host 2 from host 1:

mininet h1 ping -c 4 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.From 10.0.0.1 icmp_seq=1 Destination Host Unreachable[...]
Figure 4: OpenFlow controllers often serve as a platform for networking applications.

Listing 1

Creating a Network in Mininet

 

The attempt fails because the switch initially does not forward packets without flow entries and without a controller. The absence of a controller and flow entries is revealed using the dpctl command, a utility shipped with OpenFlow that provides access to a switch's flow table:

~$ dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0x6929ef28): flags=none type=1(flow)

dpctl then sets a flow entry that forwards the incoming packets arriving at port 1 of the switch to port 2:

~$ dpctl add-flowtcp:127.0.0.1:6634 in_port=1,actions=output:2

Again, nothing: The second ping fails because, although the switch forwards packets to host 2, host 2 is not responding.

If you now use dpctl to create another flow entry that forwards from port 2 to port 1, the results are positive: The two hosts communicate freely through the switch, as long as the idle timeout does not interfere (Listing 2).

Listing 2

A Working Flow Table

 

Level 2: Where is Arp?

Scenario 2 uses a network structure identical to Scenario 1, but it sends the initial command to ensure that Open vSwitch enters the game as a built-in controller:

sudo mn --topo single,2 --switch ovsk --controller ovsc

The connection test with ping is immediately successful; the flow table shows three flow entries (Listing 3).

Listing 3

Reading Flow Tables

 

In addition to the Arp reply, two ICMP requests and replies appear in Listing 3; these requests originate from the flow entry generated by the ping. What happened to the Arp request, which usually comes as a broadcast over the network? If you sniff the control channel, which connects the switch and the controller, using tcpdump or Wireshark, you can determine that the controller has the Arp requests forwarded directly, which does not require a flow entry.

If you use Wireshark with the OpenFlow dissector, which is part of the Mininet image, you can see and analyze the OpenFlow controller's entire communication. Figure 5 shows an example of the handshake between the controller and the switch: The switch uses the Features Reply to signal to the controller which OpenFlow actions it supports.

Figure 5: With Wireshark, you can easily sniff communications between controllers and switches.

Level 3: Tree-Like

In the third and final scenario, Mininet generates a network with a tree topology (Figure 6), in which three hosts each are connected to switches S2 through S4. Mininet then plugs the three switches into an aggregation switch (S1). This topology is typical for networks in companies or data centers. This time, the admin defines a remote controller, assigns an IP address, and sets an OpenFlow standard controller port.

Figure 6: Floodlight recognizes the tree structure of the test network and automatically maps it graphically.
sudo mn --topo tree,depth=2,fanout=3 --mac --switch ovsk--controller=remote,ip=<Controller-IP>,port=6633

The admin can select any computer on the local network and launch a controller (e.g., Floodlight) in the basic configuration:

java -jar floodlight.jar

If Mininet is online, Floodlight detects both the connections to the switches as well as the topology from the console output. Now, you can enter

http://<Controller_IP>:8080/ui/index.html

to launch the Floodlight web user interface and view the switches and hosts that have been detected – the Topology tab presents a graphical display. The graph in Figure 6 might be more functional than pretty, but it is sufficient for an overview.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Mininet

    Mininet lets you test new controller features for your software-defined network in a sandbox before releasing them onto your production network.

  • SDN Up Close

    Globalization, rapidly increasing numbers of devices, virtualization, the cloud, and "bring your own device" make classically organized IP networks difficult to plan and manage. Instead of quarreling, some admins address these problems with a radically new approach: Software-defined networking.

  • OpenDaylight

    Several well-known companies are collaborating on the foundations of future SDN products under the umbrella of the OpenDaylight open source project.

  • Software-Defined Networks

    Even as the tech world works to figure out just what to do with the potential of cloud computing and big data, along comes a new bit of technology fueled by open source software: software-defined networks.

  • Open Networking Foundation Formed

    “Stronger definition of network behavior in software is a growing trend, and open interfaces are going to lead to faster innovation,” said Nick McKeown, ONF Board member and professor at Stanford University.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News