Friday 24 May 2013

OpenFlow webinar

Last night I did a webinar on OpenFlow with Stu Bailey - CTO of InfoBlox

It was my first webinar - it's an odd experience and actually far more nerve racking than standing in front of an audience because there is absolutely no audieence feedback.

The webinar was recorded so if you would like to watch it (it's about 50 mins long), it will be shortly available on the Erlang Solutions website. Watch the OpenFlow webinar.




Thursday 23 May 2013

OpenFlow Switch on Raspberry Pi Part 3: Configuration and getting it running

In part 1 I showed what hardware you need to turn your Raspberry Pi into an OpenFlow switch by  adding USB to Ethernet adaptors.

In part 2 I showed how to install Erlang and install the LINC OpenFlow switch

In this part we start with configuring the switch.

The first thing we need to do is identify what networking ports we have on our Pi.

We use the command ifconfig -a to find out what Ethernet ports we have

pi@raspberrypi ~ $ ifconfig -a

eth0      Link encap:Ethernet  HWaddr b8:27:eb:21:08:6a
          inet addr:192.168.1.19  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11559 (11.2 KiB)  TX bytes:11040 (10.7 KiB)

eth1      Link encap:Ethernet  HWaddr 00:e0:4c:53:44:58
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0  carrier:0  
          collisions:0  txqueuelen:1000                                                                               
           RX bytes:0 (0.0 B)  TX bytes:0 (0.0B)   

eth2      Link encap:Ethernet  HWaddr 00:e0:4c:53:44:58
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:0b:81:89:5e:bf
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


Port eth0 is the native Ethernet port on the Pi and the USB based Ethernet ports are showing up as eth1, eth2 and wlan0.  If you've added more or different ports for your hardware, your port numbers will differ.

We now need to edit the LINC config file so that it knows what ports it has access to.
If the version you have downloaded is higher than 1.0 you'll need to change the line below

pi@raspberrypi ~/LINC-Switch $ sudo vi rel/linc/releases/1.0/sys.config

We now need to edit the section of the file to declare the ports which form part of the switch

       {ports,
        [
         %% - regular hardware interface
         {port, 1, [{interface, "eth1"}]},
         {port, 2, [{interface, "eth2"}]},
         {port, 3, [{interface, "wlan0"}]},
         {port, 4, [{interface, "eth0"}]}
         %% - hardware interface with explicit type
         %% {port, 1, [{interface, "net0"}, {type, eth}]},
         %% - regular tap interface
         %% {port, 2, [{interface, "tap0"}]},
         %% - tap interface under MacOSX with dynamically assigned IP
         %% {port, 3, [{interface, "tap1"}, {ip, "10.0.0.1"}]},
         %% - tap interface with explicit type
         %% {port, 4, [{interface, "net1"}, {type, tap}]}
        ]},

Note that the last active port shouldn't have a comma after it

We can now start the OpenFlow switch for the first time

pi@raspberrypi ~/LINC-Switch $ sudo rel/linc/bin/linc console

Exec: /home/pi/LINC-Switch/rel/linc/erts-5.9.3.1/bin/erlexec -boot /home/pi/LINC-Switch/rel/linc/releases/1.0/linc -mode embedded -config /home/pi/LINC-Switch/rel/linc/releases/1.0/sys.config -args_file /home/pi/LINC-Switch/rel/linc/releases/1.0/vm.args -- console
Root: /home/pi/LINC-Switch/rel/linc
Erlang R15B03 (erts-5.9.3.1) [source] [async-threads:0] [kernel-poll:false]

21:18:47.473 [info] Application lager started on node linc@raspberrypi
21:18:47.483 [info] Application ssh started on node linc@raspberrypi
21:18:47.542 [info] Application enetconf started on node linc@raspberrypi
21:18:47.557 [info] Application linc started on node linc@raspberrypi
Eshell V5.9.3.1  (abort with ^G)
(linc@raspberrypi)1> 21:18:47.957 [info] Created port: {port,4,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{interface,"eth0"}]}
21:18:48.197 [info] Created port: {port,3,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"wlan0"}]}
21:18:48.435 [info] Created port: {port,2,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth2"}]}
21:18:48.704 [info] Created port: {port,1,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth1"}]}

(linc@raspberrypi)1>
You can see LINC has created the ports defined in the config file and ended with the Erlang prompt.

OK. Let's shutdown the switch. We use the Erlang command  init:stop().

(linc@raspberrypi)1> init:stop().
ok

In the next post we'll get an OpenFlow controller running and start talking to the switch.

Tuesday 21 May 2013

OpenFlow Switch on Raspberry Pi Part 2: Installing the OpenFlow switch on the hardware

In the first article I introduced the concept of building the worlds cheapest OpenFlow switch based on the Raspberry Pi. A 4 port switch was constructed from about £50 worth of hardware.

We are now going to install the open source software on the Pi to get ourselves a functioning switch.

The software we are going to use is one which I've been involved with for about 18 months which is the LINC OpenFlow switch.  This switch is written in Erlang and can be downloaded for free from flowforwarding.org

First we need to install Erlang on our Raspberry Pi.  I have assumed your Pi is running Raspbian - if not you'll need to download the image onto a new SD card.

First you need a command prompt on your Pi as we need to edit some files

pi@raspberrypi ~ $ sudo vi /etc/apt/sources.list

Insert into this file:

deb http://binaries.erlang-solutions.com/debian wheezy contrib

Then at the command prompt type

pi@raspberrypi ~ $ wget -O - http://binaries.erlang-solutions.com/debian/erlang_solutions.asc |sudo apt-key add -
pi@raspberrypi ~ $ sudo apt-get update
pi@raspberrypi ~ $ sudo apt-get install esl-erlang

Assuming there were no problems, you should now have Erlang installed on your Pi.

We now need to install LINC.

First we need to install a few more libraries

pi@raspberrypi ~ $ sudo apt-get install git-core bridge-utils libpcap0.8 libpcap-dev libcap2-bin uml-utilities

Now we need to clone the LINC switch

pi@raspberrypi ~ $ sudo git clone https://github.com/FlowForwarding/LINC-Switch/
pi@raspberrypi ~ $ cd LINC_Switch

Now we need to compile the switch software

pi@raspberrypi ~ $ sudo make

 We now have a LINC OpenFlow switch installed on our Raspberry Pi hardware.

In the next blog I will cover how to configure it and start it up

Cheapest OpenFlow switch in the world. Using the Raspberry Pi as an OpenFlow switch.

If you want to learn about OpenFlow, there is no better way than to experiment.

So how do you experiment when this stuff is new?

Simple. Copy Google and build your own network!

I am currently building my own OpenFlow switch so I can build my an OpenFlow lab and start experimenting. The goals for my DIY switch are that it has to be cheap, easy to build and useful.

Thankfully lots of other amazing people have done all the hard work for me.  You'll be able to build your own OpenFlow switch for about £50.

I'm using the Raspberry Pi which you can buy for around £30. The Raspberry Pi is a small ARM based computer running Linux. It has an HDMI port, composite video, Ethernet port and 2xUSB ports.

OK you might be thinking this isn't going to make much of a router when it only has 1x Ethernet port!

To solve that problem I'm using a USB hub and have bought some USB to Ethernet adapters for about £3 each and a WiFi dongle based on the RTL8188CUS chipset for about £8.

Assuming you have a USB mouse, USB keyboard, a monitor or TV with a HDMI port + HDMI cable and a USB hub then the cost for 3xEthernet + 1xWiFi switch/router will be £44.

Here's mine:


The Raspberry Pi recognised the USB to Ethernet adaptors and dongle straight-off so no messing around with drivers.

This isn't going to be fastest router/switch on the planet. Firstly running Ethernet over USB is slow anyway and these adaptors are USB 1.1 (what do you expect for £3) so they will max out at about 6Mbit/s anyway.
The Raspberry Pi is hardly a high spec computer either and in addition we will be running the switch software in user space.

[Post blog note.  These USB to Ethernet adaptors are pretty crap. The Chinese manufacturer has programmed them all with the same MAC address....It's not the end of the world - you can over-ride it with ifconfig but still bloody annoying. AlsoI'd recommend the RT5370 WiFi dongles over the RTL8188CUS - I had problems getting the RTL to work in Access Point mode.  See this blog post for more details on both of these points.]

The purpose of this switch is not speed. It's to learn.

In future articles I will explain how to  install the software on your Raspberry Pi, get your controller and start experimenting.

I'm also experimenting with the slightly more expensive RouterBoard 450GL. This is custom built low-end 5 port router for about £80.  This is a little more involved to hack and will be covered in later articles.

Selling OpenFlow technology

This post was first published on my sales blog "Selling High Tech" on the 19th April 2013.

Software Defined Network (SDN) and OpenFlow are the latest networking hot buzzwords in the word of high tech. I've just spent the last 2 days at the pinnacle of SDN by attending the ONF summit which has been an interesting experience. I've been on the bleeding edge of SDN as I've been involved in its development for the last 18 months and it is getting to the point where the hype is turning into reality and that means this new hot tech has to be sold.


Before I delve into the challenges of selling SDN I thought it would be interested to explain what it is, why everyone is getting excited and my personal perspective since in reality SDN is an old idea in the telecom world but very new in the networking world.

At the heart of OpenFlow is the idea to separate out control from data. In data networking, that means messages to control set-up, build routing tables etc are all carried in the same channel as the data for example these control messages are carried alongside the web page you're downloading.

Routers and networking switches have in-built intelligence and when configured correctly will make decisions about how your data gets from A to B.

Separating control from data happened in the telecom world around 40 years ago so the concept is far from new. In fact it happened several times in telecom. The very old systems used tones carried in the speech path for signalling purposes. The problem with this is that users could “hack” the telecom network to trigger the controls. This problem still exists to some extent and is called freaking. DTMF is a signalling (control) mechanism to signal to the network on your fixed line phone what number you want to dial – this control info is carried in the data (speech plane). Hackers manipulate PABX, voice-mail and other systems which use DTMF for control. Hacking the core telecom network in this way is not possible anymore. Mobile phones send call set-up signalling information separately from the voice since they use more up-to-date technology.

The other change in the telecom network which happened 30-40 years ago was in the core and was more fundamental and had a profound impact. Telecom circuit have a separate channel in which signalling information is carried. The fundamental change was not the physical separation of the signalling from the data which was already present but the centralisation of signalling. Digital telecom networks relied on the dialled digits to signal to the next switch how to route the call. The numbering plan was cleverly designed so the dialled digits described how to get the call from A to B. You can kind of think of it as source routed packets. However the problem was all this signalling channels were difficult to maintain (read labour intensive) since each switch needed to have part of the information about how to get from A to B. The transition to centralised signalling or STPs (Signal Transfer Points) was a fundamental change – it meant each switch simply needed enough signalling information to know how to handle queries and the STPs handle the details of the call set-up. It is this change which has a close parallel to what is happening in networking with SDN.

So why was the change to centralised signalling in telecom such a fundamental change? Up until that point, dialled digits were geographical – the call was set-up hop-by-hop, with each switch holding lots of configuration data. It meant things like freephone numbers were difficult if not impossible to establish. In the old model each node would need to know how to route free-phone numbers. With the centralised model it was possible to add new functionality (Service Creation Points) which sat above the STPs allowing number abstraction – suddenly numbers were not tied to geographical locations. This meant someone dialling an 800 number could be routed to a physical phone based on their originating location or based on the state of the destination eg busy. Because signalling was centralised, operator based controls became possible for example call blocking. These were not services for users – these were services to protect the network. If a telephone number was in high demand for example ticket booking or voting, call volumes could be throttled to stop excessive network load.

So let's jump forward to SDN. Separation of the control and data planes is actually giving routing information to a controller which is analogous to the STP. Controllers will be connected via northbound interfaces to systems allowing applications to control the network (analogous to SCPs) . The service abstraction was labelled under Intelligent Networking.

So one of the key problems with selling SDN is actually “what problem does it solve”. The messages for the past 2 days at the ONF conference have been about
  • Lower costs
  • Flexibility
  • Responsiveness

We may think of IP routing as being fresh and modern but the reality is it has progressed very little in the last 20 years. There have been lots of bolt on protocols attempting to overcome shortcomings. SDN concepts have been born out of frustration. Cloud services and virtualisation in the server space have enabled the time to create a new server to be reduced from days to minutes. Creating a new server is a low cost, almost labour free activity and yet the bottle neck is now the networking. The moment networking changes are needed there is no automation, it takes days to implementation the manual changes and because humans are involved, they are error prone. Companies like Google have therefore resorted to writing their own SDN since they want networking to be exactly like the server space. This covers the points of flexibility and responsiveness.

The other area which has been covered over the last couple of days is lower costs. The same networking vendors that have progressed things little in the last 20 years have kept prices high. There is nothing fundamental in SDN to make things cheaper – at least from a capital cost perspective. What is really happening is SDN is a disruption change allowing new players to emerge and it is shifting value from boxes to the higher layers. Networking boxes therefore become more commodity. It is this area where I have been involved for the last 18 months with the LINC OpenFlow switch which enables new low cost vendors to enter the networking space.

Returning to our telecom parallel, it is the STP (OpenFlow controllers) and SCP (OpenFlow applications) where new opportunities and players are emerging. The volume is in the switch/router layer whilst the value and therefore profit will be with the higher layers. Switches will be commodity with little opportunity to differentiate.

The fundamental change in telecom was not the cost element since in reality this was extra boxes to buy so actually higher cost. Operators moved to a centralised control model since costs were reduced from a support perspective. It was far easier to maintain since routing could be changed dynamically (least cost routing) and adds and changes made in a simple manner from a central location.

Throttling before, was complex configuration activity and therefore prone to human error but with a centralised control function it became possible to automate the activity.

Number translation and number abstraction was also a powerful and fundamental change. It meant numbers were no longer tied to a location. Call control became more flexible allowing dynamically change to call routing and call manipulation. This lead to virtualised PABX type service like Centrex. The operators had a powerful new tool to create new services in a simple way. For example private dial/numbering plans.

So fast forward to today. The sales messages for SDN and OpenFlow are about lower cost and flexibility (easier support and faster provision). The reality is OpenFlow will probably not lead to lower capital costs – at least not initially. If you already have a router network and it works then you won't save money by replacing it with OpenFlow since you will have new investment costs and scrappage costs for your existing network. Depending on how much service and network provisioning change is taking place in your network you may have reduced support and administration costs resulting from OpenFlow's flexibility – this becomes a simple business case. Are my support cost reduction gains worth the capital investment?

Contrasting with telecoms is useful. Load control and throttling is comparable to today's denial of service threats. Today if we have an attack, it can be quite a manual task to apply blocking rules across a large distributed network. Ironically building resilient fault tolerant networks actually creates more problems compared to a simple linear service chain. More meshing means more options for threats and attacks to find alternative routes.

OpenFlow's centralisation enables similar functionality to telecom's traffic management. Centralised blocking control means that policies such as block all traffic from this IP address or all traffic to this IP address can be simply created and applied on a network-wide basis. If you are in the firewall business you better watch out. OpenFlow is going to impact your business.

For example it now be possible to block queries to particular DNS lookups. Schools may restrict access to facebook.com during specific hours so that the lookup simply fails!

It's worth briefly considering IP v4's addressing. In reality it is hierarchical with the numbering having a geographical binding. This sub-net relates to a country and sub-net location. It is not so different from old world telecoms yet we like to fool ourselves that IP is a fresh new idea!

The decoupling of the control of the data forwarding plane in telecom allowed address abstraction – the numbers pretty much became irrelevant. We still needed “unique” numbers but they were no longer cast in-stone.

It is this decoupling in telecoms that spawned service innovation and flexibility. I believe that exactly the same will happen in IP and OpenFlow enables this control abstraction.

So let's look at telecom services and see what insights we can gain for the future of SDN. Firstly numbering abstraction. We probably won't have freephone equivalents since IP bearer costs are not exposed to the end user (yet) however being able to route traffic to an address (telephone number) and route traffic optimally is an interesting and potentially powerful feature. Consider Google. Currently there is coarse granularity traffic routing eg google.com, google.co.uk etc and there are data centre load balancing similar to ACD functionality in the telecom world. We now have IP addresses which the control plane can decide to route in different ways to today. We could for instance allow the network to handle routing to the nearest Google data centre without lots of special hacks such as DNS, or special routes to do the data centre assignment.

Virtual, overlapping or private address spaces suddenly are possible. The traffic can be routed based on the originator. The actual address becomes in many respects irrelevant.

OpenFlow is currently based around applying routes for persistent flows yet this doesn't have to be that way. Telecoms services allowed calls (flows) to change their route based on conditions (end-point was busy so forward to voice-mail) or actions such as “I'll forward your call onto xyz as they can help you”. Doing the same in the IP has some challenges since TCP assumes that endpoints remain constant and have state information but there's nothing stopping this model for UDP traffic sources or future protocols. It's probably easier to adopt redirection approaches for TCP.

It is not clear what SDN based applications and services will emerge yet it is clear that this base functionality will simplify the creation of innovative new services.

Telecom may seem old world but it has continued to move forward, particularly in the mobile space. Today's mobile networks are IP based with specialist boxes to overcome the limitations of IP eg GSNs for mobility functions. The latest generation is adopting a key element called a PCRF (Policy Control Function) which manages the service level and privileges at a user level. These parallel worlds can learn from each other!

So back to selling SDN. Today the message is one of flexibility and cost. It's hard to sell these application layer services when we don't yet know what they will be or the value they deliver. If the customer values on the fly network provisioning and dimensioning then there is real value which can be sold. It's feasible to randomly wire an OpenFlow network and it will sort it out. Today's legacy IP networks struggle. The types of customers that would value this dynamic network provisioning are cloud providers or companies with large constantly changing data centres.

Customers that place a high value on service availability and up-time would also value OpenFlow. Many IP boxes have found their way into the traffic path creating long serial service chains. When there are lots of boxes in a chain there is more chance of a service outage if one fails and more chance for unexpected interactions between boxes. Examples of these boxes are firewalls, load balancers, deep packet inspection. Generally these boxes are control functions.

It is rare that these types of boxes modify content in the payload. Usually they make a decision do I allows this or where should I send this. These are control functions. Occasionally there are boxes that modify payload for example content caches, content adaptation and maybe deliberate injection of jitter on VoIP calls! For the most part they are control functions so they can be moved into the control plane by OpenFlow. The end result is the data path becomes much shorter with fewer boxes which means higher reliability.

Today building fault tolerant IP networks is a challenge. Adding protection, redundancy and fail-over creates complexity. Complexity often leads to reduced availability so ironically the additional equipment built to provide resilience and higher availability can lead to reduced availability!

As the saying goes “every change has a consequence”. The consequence of simplifying the data path is the control layer potentially becomes more complex. The network has the potential for the network to become more fluid and dynamic. Particular services such as Video traffic, might request routing for low latency and therefore have a very different traffic path to web browsing. Sure the services get the best available performance for their needs but it creates a new problem for the operations staff when they want to trouble shoot an issue. Where was the traffic?

OpenFlow does allow traffic forwarding so the job of monitoring and troubleshooting can be assisted. Just like firewall vendors, if you're a probe vendors then watch out. OpenFlow is set to change your business!

OpenFlow + SDN

Software Defined Networking is the latest buzz hitting the world of networking.

Is SDN little more than hype or is there substance to what's happening?

My personal opinion is SDN has a future and it is delivering real change. Why? For several reasons

1/ The company behind the concept is Google. They couldnt buy OpenFlow technology. They were disappointed with the current generation of equipment so decided to invent SDN and build their own equipment.  They are using it today.

2/ The concepts behind OpenFlow are not new. In fact the telecom world embraced the concept of separating control from data more than 30 years ago. Without that concept things like mobile phones would not be possible.

At the moment it is not clear to me what services this concept of separating the data and control planes will enable but it intuitively feels like a more elegant way to build IP networks. I've been running projects to build data centres and networks since around 1998 and my observation is that IP networks have ended up complex and unwieldy.  Layers upon layers of boxes have been introduced to overcome shortcomings and deficiencies in protocols or connection models. Roughly every 3 years I used to insist that the designers simplify the network to make it supportable. Although I'm sure OpenFlow will introduce different layers of complexity and support problems in the control plane, it does at least appear to be creating simplicity and elegance in the data plane!

This blog will be a mix of commercial and technical posts. I'm expecting it to be articles sharing my thoughts about OpenFlow as my understanding and insights develop and details of my technical experiments.

I've been involved with OpenFlow (which is one of the most popular SDN technologies) for about 18 months now.

The first experiment I will be sharing is my attempts to build my own OpenFlow switch. It's based on a Raspberry Pi and you too will be able to build your own 4 port OpenFlow switch for about £50 so you can experiment and learn.