OpenFlow Starter Tutorial Lab #3

OpenFlow Starter Tutorial Lab #3

OpenFlow Starter Tutorial Lab #3 : Move individual flows

Figure 1. OpenFlow starter tutorial Lab #3 topology. Add an entry to the wrong port and watch it break.

Let’s clear all of our flows and get everything pinging the gateway again.

Add our three earlier entries from Lab1

TCPdump Analysis

Start tcpdump on the host you will send Host3’s traffic to. In my case I am starting tcpdump on Host1 where I am going to send Host3’s traffic to.

The filter “host <ip>”says only capture traffic to or from that host. We should never see unicast traffic from one host to another under proper condictions on a packet switched network.

Instantiate Bad Flows

Now lets push a mac to a bad port and watch it break. This will overwrite ‘static-flow3’. This will break Host 3.

Figure 2. TCPdump output when I push host 3’s forwarding datapath to host 1.

As soon as you added the “wrong-port” static flow you began getting ICMP replies from the gateway until that times out. This has many more security type implications. Why not have your action be forward to two ports instead of just one. The 2nd port could be an IDS monitoring traffic and instead of trying to process the firehose of traffic in a typical port mirror you can get as granular you want and watch only particular matching traffic as defined by the tuple matching in the header fields  (src_mac,dst_ip,VID etc.). No you can use a fraction of the hardware and only process what is important to your use case. Load balancing is another obvious one. Policy routing that may be scalable if managed programmatically by northbound API’s.

Figure 3. The API is the end game IMO

Conclusion

Thats it hope this maybe demystifies a bit of OpenFlow for you. I still have lots to learn as it is never-ending cycle, but going through a couple of labs seems to help nail some of this down and show that with complexity or more accuraltely abstraction, will bring more simplicity to the operators(some day so very very very far away theoretically). This lab setup can scale out to a wide range of different scenarios then just the couple little guys here. Would love to hear what others are doing.

From an end user perspective, it is the same ideas we have had in best matching of prefixes all along but we are adding more ways to match and fields to match upon. The API is what is going to be very important in my opinion and will open up the value over the next coulple of years as the northbound apps begin to surface. Sorry there is not any commentary on the videos, swamped but I think its fairly straightforward. I only added the video in case someone gets stuck. Feel free to contact with assistance or jump on irc.freenode.net on #openflow.

Miscellaneous API Calls

Find all flows

List all static

Clear all flows

---

Additional OpenFlow and SDN Links and Resources

http://openvswitch.org/ Martin Casado’s group have put an amazing vSwitch out there. I doubt there will be many vSwitches that are not munging his work in some form or fashion over the next few years.

http://floodlight.openflowhub.org/ Thanks to Nick Bastin for answering my question on the #openflow channel. He is a great asset to the community.

http://www.noxrepo.org/ Another nice OpenFlow Controller is POX a Python based platform agnostic project the Murphy McCauley is doing a great job with. As soon as I dig into the API I am going to do a similar tutorial with that. I need the API docs if anyone has them hook me up.

I am typically always /nick networkstatic on irc.freenode.net in #openvswitch #openflow #openstack and #packetpushers if anyone has any questions.

---

Check out the rest of the tutorials in this series:

• Getting Started OpenFlow OpenvSwitch Tutorial Lab – Setup
• OpenFlow Starter Tutorial Lab #1
• OpenFlow Starter Tutorial Lab #2
• OpenFlow Starter Tutorial Lab #3

---

Thanks for stopping by.