Skip to content

Category: OpenFlow 1.3

MPLS Traffic Engineering – Review

I wanted to review the basics of MPLS and Traffic Engineering (TE) so I went to my favorite networking blog and searched for RSVP and found the following articles:

Although the articles were incredible and clearly explained the technologies, it also clearly demonstrated how complex ‘legacy’ MPLS technologies are. UPDATE: I recently found about PacketDesign and got very excited by the material they put out there. Their white paper on MPLS-TE is one of the best pieces I’ve seen on the subject!  I urge you to check it out.

This article is divided into 4 sections: First, I mention reasons for MPLS forwarding. Second, I go through some of the motivations behind Traffic Engineering technologies. Then, I briefly explain Segment Routing, and I conclude with a tutorial on how ONOS can achieve TE using an SR SDN application on top of OpenFlow.

Why MPLS at all?

To reduce network state.
Today, The full Internet routing table includes +600.000 routes. Routing this by itself is already complicated. Now what if you took different paths for different Classes of Service (CoS), you could easily reach 2M routes. With MPLS, you basically can aggregate several network prefixes into labels, reducing the state drastically. The articles I mentioned at the beginning go through some of those numbers. A Segment Routing (SR) architecture can reduce this number even further to the order of the number of network devices. ps: SR can also be achieved with IPV6 encapsulation.

Why Traffic Engineering?

To save money!! $$$$

Diptanshu Singh explains this subject wonderfully, so I urge you to check his article if you need a more detailed explanation.

For instance, say the Comcast network in your neighborhood has 1 Gbps of VOIP and 4 Gbps of data traffic demand. It’s overprovisioned by 50%, so its 10G links suffice at the moment. Now, suppose its traffic increases 20% next year, sustaining this strategy would require an immediate upgrade of the infrastructure.

A Diffserv strategy would change resource allocation rates: One could instead allocate a 2x overprovision rate for VOIP and a 1.2x overprovision for data. Resulting in 2.4+6 Gbps total of bandwidth ( 1G*120%*2, voice data plus 20% increase times 2x overprovision rate) Next year, you would have 2.8+7.2 Gbps of data, still smaller than 10G.  With this approach, Comcast can delay its backbone upgrade for 2 years and can still adhere to the SLA’s required for sensitive traffic.

With the first rule, your expansion rate is dictated by generic traffic growth because you must keep network utilization low. On the second case, your expansion rate is mandated by critical traffic growth and networking equipment life-cycle (at your convenience). Critical traffic is 5x smaller than best-effort, thus your expansion rate would be 5x lower if you don’t care about best-effort traffic.

Now you have the opportunity to reduce your expansion budget by a factor of 5 and invest that money on engineering power. I’m sure that’s what Google saw 10 years ago when it started heavily investing in its networking technology. Bad Vendors will often say ‘you don’t need QoS or Traffic Engineering’, the problem can be solved with more bandwidth. That’s a convenient message if you sell bandwidth.

Why Segment Routing?

I wanted to compare legacy technologies (RSVP, LDP) with SR, but I realized that is pointless. To me, the only reason you would use legacy is for backward compatibility with existent equipment. Don’t get me wrong, RSVP will get the job done. Also, you may not be able to afford replacing it with SR or maybe your RSVP infrastructure works perfectly and you already have proper processes in place.

That all said, SR is just simpler and better. To learn more about RSVP check for yourself: http://packetpushers.net/rsvp-te-protocol-deep-dive/. If you know nothing about SR check http://www.segment-routing.net/.

In summary, SR is a network architecture that allows the network to keep no flow-state. Rather than only forwarding packets based on IP destination address, they are forwarded based on the segment address. The network maintains shortest path forwarding state information to each segment and backup paths to implement fast reroute. Fast reroute by itself is worth money, SR TILFA allows for sub 50ms failure recovery.

Additionally, The architecture allows you to enforce loose source routing. For example, say, IGP OSPF will give a 40ms path, to steer your VoIP traffic through a node 104, you would just change your routing at the edge of the network to include that segment before the end destination.

 SR

Tutorial

I already wrote a tutorial on this 2 years ago. I’m just going to highlight the main points.

Screen Shot 2015-08-13 at 4.46.02 PM.png

In this configuration, you have a cluster of 3 ONOS SDN controllers controlling a leaf-spine fabric. The entry-nodes, do a route lookup and encapsulate the packets with the MPLS label correspondent to the exit-node. The packet is then forwarded using shortest path based on the MPLS label. That’s basic IP forwarding. The cool thing here is the ability to programmatically set forwarding tunnels.

Let’s say you want all Netflix traffic to go through spine s105, thus making sure all Web and Voice traffic has 3 spines worth of bandwidth and thus lower delays, you could establish a tunnel in the following way:

A tunnel is defined as a set of LABELS, defining the path taken by a flow. The following command instantiates a tunnel called FASTPATH through the routers 101, 105, and 102 in that order.

onos> srtunnel-add FASTPATH 101,105,102

Then, a policy can be applied to a subset of traffic, for example,  policy1 = tcp_port=80 >> fwd( TUNNEL_1)

onos> srpolicy-add p1 1000 10.1.1.1/24 80 10.0.2.2/24 80 TCP TUNNEL_FLOW FASTPATH

This tunnels can be used to reinforce TE policies and guarantee SLAs and improve network utilization.

Conclusion

A Segment Routing network combined with a centralized controller for path computation can enable advanced Real-Time traffic engineering capabilities. In this way, Segment Routing is a perfect match for SDN.

The SDN applications have already been developed and made available in open-source projects like ONOS. The Segment Routing app mentioned has evolved to TRELLIS which is the networking fabric that supports the Cord project. I urge you to check their work.

Please reach out to me if you have any questions regarding how one could move forward and implement this.

 

Leave a Comment

Easiest way to develop on ONOS

I just started interning at the ON.LAB. We are developing the ONOS controller and other things.

The learning curve for ONOS is a bit of a challenge compared to its python competitors. But it has several features that a carrier-grade controller need and make the effort worth. To me, the two most important things are:

  • The Flow-objective abstraction
  • High-availability mechanisms

I’ll talk more about them in another posts.

Today I’ll show you the easiest way to setup your development environment.

cd ~   
git clone https://gerrit.onosproject.org/onos   
. ~/onos/tools/dev/bash_profile   
onos-setup-ubuntu-devenv   
cd onos
mci   

This will take a while to finish… While you are waiting check this another post with a series of very explicative videos about ONOS.

After it done do.

ok clean

That’s it the controller is on.

For detailed information check the ONOS from Scratch tutorial

I hope this was helpful

Leave a Comment

Troubleshooting Ofdissector: a Wireshark plugin to analyze OpenFlow 1.3

In this last post, I explained how to install the last version of the OFDissector.

I still had one other problem after installing it.

Whenever I run wireshark as a root user I had this following error:

Lua: Error during loading: [string "/usr/share/wireshark/init.lua"]:45: dofile has been disabled

What happens is that whenever something tries to run LUA code with root permissions, that script is blocked.

What you gotta do to fix that: you have to not run wireshark with root permissions. To do that you might want to still be able to capture traffic from all interfaces, then you should do what is described here:

sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap

After that you should be able to run Wireshark without any problems.

Thanks

Leave a Comment

Ofdissector: A way to analyze OpenFlow packets in Wireshark at Ubuntu 12.04

As you start messing around in the Software-Defined Networking area you might want to analyze OpenFlow packets in Wireshark. This post is a installation tutorial of ofdissector, a plugin to analyze OpenFlow 1.3 packets in Wireshark.

The guys from CPqD have developed a plugin called ofdissector that is capable of doing that. In this post I am going to report the troubleshooting I had to do to make it work. The main problem was to make Wireshark to be able of analyzing OF 1.3. The original installation guide is linked here.

What worked?

I started by following this tutorial and finally came up with this successful installation script :

cd  $HOME/
git clone git://github.com/mininet/mininet
mininet/util/install.sh -n3f
sudo -s
apt-get install scons
git clone https://github.com/CPqD/ofdissector    
cd ofdissector/src
export WIRESHARK=/usr/include/wireshark
scons install

Troubleshooting:

The first problem I had was not being able to install ofdissector correctly. Adding the sudo -s command made things better I don’t know why exactly. But before I was having the following error:

scons: Reading SConscript files ...
### ERROR: You need to set the WIRESHARK environment variable to the
location of your wireshark include directory.
### ERROR: (such that epan/packet.h is a valid include path)

The seconde problem I had was conflicting installations of different versions of ofdissector. I installed both versions. You can avoid the problem by not installing the oldversion of ofdissector, using the following line of code instead of the wrong one:

##This is Right!!!
mininet/util/install.sh -n3f
##This is WRONG!!
mininet/util/install.sh -n3fxw
## the w option will install the wireshark plugin for OF1.0

Anyway, if you install both and fall into this problem:

 Err Duplicate protocol name "OpenFlow Protocol"! This might be caused by an inappropriate plugin or a development error.

The only thing you have to do is to remove the old openflow plugin and reinstall the new ofdissector by doing this:

sudo -s
rm -f /usr/lib/wireshark/libwireshark1/plugins/openflow.so
cd $HOME/ofdissector/src
export WIRESHARK=/usr/include/wireshark
scons install

That’s it. Feel free to report issues with the installation script.

1 Comment

Learning Switch tutorial on Ryu + OVS 2.0 + OF 1.3

This tutorial aims to make you get in touch with some subtleties of the OpenFlow 1.3. The requirements for this tutorial are:

  • Mininet 2.1 (If you haven’t installed it yet, follow this link)
  • Ryu (If you haven’t installed it yet, follow this link)
  • OpenVSwitch 2.0 (If you haven’t installed it yet, follow this link)
  • Openflow 1.3 (If you haven’t installed it yet, follow this link)

So this tutorial will follow these steps:

  1. Test OVS 2.0 + RYU(OF1.0)
  2. Test MN user’s switch + MN controller. ( Verify it doesn’t work.)
  3. Test OVS 2.0 +MN controller. ( Verify it works)
  4. Test MN user’s switch + RYU (OF1.0). ( Verify it doesn’t work.)
  5. Test MN user’s switch + RYU (OF1.3). ( Verify works fine.)
  6. Test OVS 2.0 (OF1.0) + RYU (OF1.3)
  7. Test OVS 2.0 (OF1.3) + RYU (OF1.3)
  8. Conclude OVS 2.0 (OF1.0+1.3) + RYU (OF1.3) rules!

SO, in this tutorial we will test several scenarios. The initial problem we faced with OF1.3 was negotiation. Basically, if controller and switch don’t match versions they won’t talk, and won’t work.

I will give you the best solution in advance, then if you want to understand a lil better you can read the article to the end. The best solution is to enable OVS 2.0 switches to work with all versions of OF AND make sure RYU is running the right code.

Start ryu with OF13. (Note in line 20 of the code that Ryu imports OF13)

cd ryu
 PYTHONPATH=. ./bin/ryu-manager ryu/app/simple_switch_13.py

Start Mininet:

sudo mn --topo linear,4 --mac --switch ovsk --controller remote
h1 ping h4

Enable OpenFlow 1.3 in the switches. ( you need to open a new terminal with xterm s1 for that)

ovs-vsctl set bridge s1 protocols=OpenFlow10,OpenFlow13
ovs-vsctl set bridge s2 protocols=OpenFlow10,OpenFlow13
ovs-vsctl set bridge s3 protocols=OpenFlow10,OpenFlow13
ovs-vsctl set bridge s4 protocols=OpenFlow10,OpenFlow13

The article is not finished haha, I will finish it ASAP.

3 Comments

Setting up OpenVswitch 2.0 + Mininet 2.1+ Ubuntu 13.04

I’ve been struggling trying to set up the OVS 2.0 with Mininet 2.1 on Ubuntu 13.04 and after installing it, it would work fine but after rebooting the OS the OVS didn’t work I don’t know why yet.

So, What did I do to fix it? This:

After searching around the internet a found this article which didn’t work completely, but after I found this one with a few changes in the OVS-something syntax I thought it would work fine but it still didn’t.

I did this exactly to install:

sudo -s
apt-get update
apt-get install -y git automake autoconf gcc uml-utilities libtool build-essential git pkg-config linux-headers-`uname -r`
wget http://openvswitch.org/releases/openvswitch-2.0.1.tar.gz
tar zxvf openvswitch-2.0.1.tar.gz
cd openvswitch-2.0.1
./boot.sh
./configure --with-linux=/lib/modules/`uname -r`/build
make && make install
insmod datapath/linux/openvswitch.ko
mkdir -p /usr/local/etc/openvswitch
ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
ovsdb-server -v --remote=punix:/usr/local/var/run/openvswitch/db.sock \
--remote=db:Open_vSwitch,Open_vSwitch,manager_options \
--private-key=db:Open_vSwitch,SSL,private_key \
--certificate=db:Open_vSwitch,SSL,certificate \
--pidfile --detach --log-file
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach
ovs-vsctl show

So, finally I decided to do this everytime I perform a reboot:

sudo -s
cd openvswitch-2.0.1
ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
ovsdb-server -v --remote=punix:/usr/local/var/run/openvswitch/db.sock \
--remote=db:Open_vSwitch,Open_vSwitch,manager_options \
--private-key=db:Open_vSwitch,SSL,private_key \
--certificate=db:Open_vSwitch,SSL,certificate \
--pidfile --detach --log-file
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach
ovs-vsctl show

If this does not work for you, please report me your issue . I will do my best to help you!

Regards,

4 Comments