GETTING STARTED BUILDING HANDS-ON SDN SKILLS

When your company trials #SDN solutions, do you want to be involved in the project? Do you want to hit the ground running, or just hear about? To be ready, you need more than knowledge of what the vendors are doing; you need some core hands-on skills. Today’s post explores some suggestions for first steps to build hands-on SDN skills, along with the why and wherefore.


BIG PICTURE OF SDN AND WHY TO START MIDDLE-DOWN

If you’ve been thinking about SDN for a while, then you’ve probably already figured out your first steps for learning. For the rest of you, let me define a few terms so the first steps make more sense.

The classic SDN definition begins with the separation of the control plane and data plane. A basic SDN architectural model uses three layers, with the controller in the center, and some components above (North) of the controller, and some below (South) of the controller. The controller, and the SDN applications above the controller, implements the control plane functions. The network – that is, networking devices connected by links – implements the data plane, forwarding messages between devices.

Figure 1: SDN Architecture – Control and Data Plane Perspective

The model shown here shows only the most basic parts of the architecture, but it does show enough to frame a conversation about where to start learning hands on skills. I believe most everyone who wants hands-on skills with SDN should begin in the lower half of this SDN model, implementing the data plane and the controller, and learning from that process.

Why? Network engineers should be able to quickly build skills with the lower half of the model. Networkers know protocols, so picking up another protocol (OpenFlow) shouldn’t be too hard. You know existing data plane and control plane concepts, so now you just have to learn about the SDN alternatives. Even if you know how to program, and want to write SDN apps one day, you will still need a controller and some switches to use when testing.

I’ve reduced some suggestions to four steps, which I’ll explain in a little more depth for the rest of this post:

1. Create a lab with both the data plane and a controller, using the Mininet simulator, and focus on learning Mininet options and commands.
2. Learn OpenFlow protocol using Wireshark while testing with Mininet.
3. Learn More OpenFlow using different start options with the POX controller.
4. Use different SDN controllers to compare features and learn controller architectures.

 

STEP 1: LEARN DATA PLANE AND CONTROLLER BASICS USING MININET

Mininet is a freely available open source tool that simulates OpenFlow switches and SDN controllers. You can run it on a VM on your own computer, simulate an SDN-based network, run a controller, learn what’s happening, experiment all you like.

Mininet comes with the ability to simulate switches (and routers), along with a couple of included SDN controllers. The default reference controller works well for just kicking the tires, but for learning, the included POX controller has some nice features as well (see suggested step 3).

Getting started can truly be as easy as following the steps in the Mininet Walkthrough page. Install Mininet, follow the walkthrough, and you’ll learn a lot. Make sure and experiment with:

• Creating different switch topologies
• Displaying the topologies
• Pinging and other test traffic between Mininet hosts
• Starting and using Wireshark (to be ready for other upcoming tasks)

2) LEARN OPENFLOW PROTOCOLS USING WIRESHARK AND MININET

The pre-installed Wireshark in the Mininet VM makes it easy to quickly see packet captures of the OpenFlow messages that flow between the controller and the networking devices in Mininet. So, rather than just reading the OpenFlow protocol document, you can see the protocol messages that relate to the specific Mininet network you built.


As for a suggested exercise, let me make a few suggestions:

1. Begin reading the OpenFlow 1.0 standards doc.
2. Pick one Mininet topology, start Wireshark, and start Mininet.
3. Read the OpenFlow messages you see in Wireshark before you send any test traffic.
4. Compare those messages to the OpenFlow standard, and think about what flows have been programmed into which switches.
5. Ping between hosts to generate traffic.
6. Read the OpenFlow messages found in Wireshark, noticing the messages created as a result of each ping, and again compare that to the OpenFlow standard.
7. Do not worry if you do not understand it all – digest what you can, and move on.

Note that for beginning your learning, OpenFlow 1.0 makes the most sense. First, 1.0 was the first version intended for widespread release in products. OpenFlow 1.3 appears to be the next release that is likely to see widespread implementation in products. (Mininet supports OpenFlow 1.0 and 1.3, by the way, and uses 1.0 by default). So the OpenFlow 1.0 doc is a good place to start.

For example, OpenFlow 1.0 defines a 12-tuple of field values that can be used to match a message to a flow in a switch’s flow table. Section 5.2.3 of the OpenFlow 1.0 standard details those fields. Figure 2 shows an example output from Wireshark for an OpenFlow FlowMod message that happens to direct a switch to program a flow with these criteria:

• 11 fields should be considered wildcards (that is, they always match)
• 1 field (Ethernet Type) that should be 0x0806

In other words, the flow definition in this trace matches IPv4 ARP messages, which have Ethernet Type 0x0806.

Figure 2: Wireshark Trace of OpenFlow 1.0 Flow Definition to Match ARP

3) LEARN EVEN MORE OPENFLOW WITH POX CONTROLLER OPTIONS

The POX controller gives us some convenient ways to learn OpenFlow. First, the Mininet VM comes with POX already installed. POX can then be started with different parameters from the Linux command line, with those parameters making the controller program the flows with a different mindset.

Using different POX options lets you run controlled experiments in Mininet. First, you can use the same Mininet network topology over and over, and run the same traffic generation tests over and over (for example, repeat the same pings each time). However, with different POX parameters each time, the controller thinks differently, programs different flows, so the OpenFlow messages differ, and each Wireshark trace differs. So, just run the tests and investigate the differences.

For instance, one POX startup option tells the controller to make the switches act like hubs, while another tells the controller to program flows between specific pairs of hosts based on their MAC address. (Check the POX documentation wiki for the list of options.)



Here’s a suggested outline for a lab:

1. Start and capture your Wireshark trace for each pass. (You will know how to do this already if you work through the Mininet Walkthrough, as mentioned in Step 1.)
2. Start POX with the parameter from the next list, e.g., ./pox.py forwarding.l2_learning)
3. Start mininet, pointing to POX as a remote controller (e.g., sudo mn –controller=remote,ip=w.x.y.z –topo=linear,3 –mac)
4. Look at the Wireshark trace for any flows populated before you generate any test traffic
5. Ping from host H1 to each of the other hosts
6. Look at the Wireshark trace, take notes, and save
7. Stop Mininet and POX

Then repeat the steps, with a different POX option, and look for the different results. Here are a couple of recommended options for POX startup options for learning OpenFlow:

1. forwarding.hub
2. forwarding.l2-learning
3. forwarding.l2-multi

4) TRY A FEW OTHER SDN CONTROLLERS

Once you get comfortable with Mininet, I would suggest a next step of kicking the tires with a few different SDN controllers, particularly those with a graphical interface. The controllers that come installed with Mininet have some great features, but they do not have extensive GUI interfaces. Getting some SDN experience with some other controllers, particularly those with a graphical interface, can be a great next learning step.

This option works well in part because the controller can sit anywhere compared to the SDN switches, at least anywhere that’s reachable with IP. Literally, you could run the controller somewhere in the Internet, and Mininet on your Laptop, and as long as no firewalls blocked the TCP port used by the controller (default 6633), the controller could control the network. That’s not the preferred design, but it would work.

More normally, you could just install another controller on another Linux VM and use Mininet to create the network on the same Mininet VM as usual. You ignore the controller you have been using on the Mininet VM – instead, when you start Mininet, you point to the IP address of the other controller. Figure 3 shows the idea, with the usual Mininet VM on the top, and the new controller running in the VM on the bottom.

Figure 3: Using an External SDN Controller in Lab

Just as a for instance, here’s a sample of what you get from Cisco eXtensible Network Controller (XNC) with a Mininet network:

Figure 4: Sample Screen Shot from Cisco XNC

So, which controllers should you test? Well, for a home lab rather than a lab at work, it helps to have some free options. I’ve listed three controllers that you can get for free without ambiguity. Two of them are open source, and are likely to be freely available for their natural lives. The other one, the HP VAN controller, has a 60-day trial period, so you can legally use it, without your company having to be in the middle of a product evaluation. (I do not see other commercial SDN controllers with a clear trial download option, but please feel free to let me know.)

• Get HP’s Virtual Application Networks (VAN) controller : 60 day trial
• Get Floodlight Controller: Free (open source), but similar to Big Switch Networks’ Big Tap Controller)
• Get OpenDayLight: Free, (open source)

When you get time to dig into each controller, ask yourself a few questions:

1. What flows does the controller program into the switches to support ping and web traffic – even with no SDN apps running?
2. What settings exist (from available documentation) to change the controller’s behavior?
3. What features does the controller have for listing flows, displaying status, and troubleshooting the network?

What can you learn about the controller’s architecture based on what you see from the user interface?