One of the important points that I try to push is Transparancy i.e. The Open concept.  The word Open has been used so much lately that it is starting to lose meaning.  Some uses of Open seem forced, like Open Daylight.. Does that mean there is a closed Daylight project or did they just add Open to get good press coverage?

An interesting tidbit on all of the controller projects is how many of the same companies we see involved in them.  Cisco seems to lead, being involved in a lot of projects along with the ONF.  Many of the Open controller projects are backed by multiple multi-billion dollar corporations.  This of course brings a lot of thoughts into my brain about hedging bets.

I am still a fan of the truly open projects such as RouteFlow from CPqD, Vandervecken and the Cardigan project.  What is nice about these projects is that their support comes from contributions from the community.  NetDEF is a supporter of all of these projects, providing equipment, testing, feedback and non-monetary support.

As we move Router Analysis under the Network Device Education Foundation structure, we expect that there will be no change in the charter that Router Analysis has to bring unbiased information about networking products to the community for free.  NetDEF is a not-for-profit corporation with no paid officers.

Once Router Analysis is transferred, I will be giving up my President/Owner role (obviously) as all of the equipment will become property of NetDEF and the Router Analysis Project.  I will stay president of NetDEF.

The post RIPE66, OpenSource and OpenFlow/SDN appeared first on Router Analysis.

ONS 2013 as the name implies, is focused on Open Networking such as SDN, OpenFlow, Network Controllers, etc.

There have been a lot of great announcements such as:

Extreme Networks Announces OpenStack Quantum and OpenFlow support in their campus switches.

Extreme Networks, Inc., today announced that it will be present at the Open Networking Summit (ONS) event this week, April 15-17^th, in Santa Clara, highlighting Software Defined Networking (SDN) strategies, technology and multi-vendor interoperability demos with Big Switch Networks and NEC. Attendees can view and discuss solutions at Extreme Networks ONS booth # 304.

Dell Announces New Fabric Technologies

Dell Monday lifted the curtain on new fabric technologies for the data center, representing the latest in a series of networking vendors to bulk up their converged infrastructure and software-defined networking play.

Centec Boosts SDN Applications with N-Flow Technology

Centec Networks, a leading innovator of IP/Ethernet switching silicon and advanced turnkey system solutions, today announced N-Flow^TM technology in its third generation GreatBelt Series Switching Silicon at Open Networking  Summit 2013 (ONS 2013), to enable more advanced applications for Software-Defined Networking (SDN), in an attempt to widen the commercialization of the OpenFlow^TM protocol.

Brocade to Demonstrate Migration Strategies and Path Toward Software-Defined Networking at Open Networking Summit

Brocade today announced that it will be exhibiting and attending Open Networking Summit 2013, the premier conference aimed at the evolving Software-Defined Networking (SDN) landscape. As a leader in data center networking and an initial member of the Open Networking Foundation, Brocade believes that SDN holds the promise of starting a new network innovation cycle and will launch a wave of next-generation network-based applications and services. During this event Brocade will discuss and demonstrate solutions to help customers realize the full potential of SDN.

RouteFlow featured at ONS2013.

Team members from CPqD will be presenting demonstrations of RouteFlow in the exhibition area at ONS.  Router Analysis proudly donated at Pica8 3290 to the RouteFlow project earlier this year.

Router Analysis and The Network Device Education Foundation (NetDEF) to attend ONS

Members of Router Analysis and NetDEF will be attending the ONS 2013 Conference.  We plan to be available near the CPqD RouteFlow Demo area.  We will also appear at the plugfest.

The post ONS 2013, RouteFlow and NetDEF appeared first on Router Analysis.

After a great presentation at NANOG by Scott Whyte of Google, there have been quite a few updates to the ProjectW system.

• The bootable CD is v0.5
• Support for MPLS and ISIS
• Support for controlling multiple switches at the same time
• Router Analysis plans to integrate the changes from v0.5 into the Reference Controller.  There will be no changes to the hardware.
• Router Analysis will be handing control of the Reference Controller Project to The Network Device Education Foundation.

The Loss of the word Open

There have been a lot of announcements recently using the term “Open” and trying to ride the OpenSource/SDN media glut.  We at Router Analysis have started using the word Transparent to discuss truly open projects.  We have also been focusing our efforts on building the Network Device Education Foundation so that we can better educate the public on Testing, OpenSource and other work that deserves to hold the term Open.

Next Testing Project

We are working on our next testing project, the ideas surround NFV and our team is working on designing tests that will best prove out the value of NFV.  Our goal is to get the plan out in April and run the tests in May.

The post Updates to the Reference Controller appeared first on Router Analysis.

On February 27th, 2013 the Network Device Education Foundation, Inc.(NetDEF) a not for profit entity was formed.  The Foundation has many goals, one of the most important is to carry on the philanthropic mission of Router Analysis, Inc.  The Foundation will initially be funded out of my own pocket and eventually by companies such as Pica8, Cisco and SideBand Networks (My new Employer)

Goals of the Foundation:

1.) To provide transparent, open information about Network Devices (Hardware or Software based) through testing and technology deep dives.

2.) To provide training and education services related to Network Device testing.  This includes testing concepts, test plan design, test day preparation and issues normally run into when doing Network Device testing.

3.) To provide access to and donations of Network Device equipment such as OpenFlow Switches (Router Analysis, Inc. recently donated a Pica8 3290 switch to CPqD) to academic, non-profit and open source projects who maybe have limited access to this type of equipment.

4.) To continue the Reference SDN Controller project including the donation of systems to suitable parties.

Want to be involved?

If you or anyone or group you are associated with is interested in either being involved in, or getting support from the Foundation, feel free to drop me a note via info at netdef.org.

The post Network Device Education Foundation appeared first on Router Analysis.

If all went well with building the machine from my first post, you should have a functional system running on a bootable ProjectW iso.  For the next steps we will cable up the controller and make some changes to ProjectW to send traffic across the switches.

The Router Analysis Reference SDN Controller Quick Setup Guide

If you click on the page, it should expand if needed, go ahead and print it, do whatever you would like.  This is the first revision of the document, essentially if you follow the directions here, all of the cabling should be correct when we reconfigure ProjectW.

Here is another picture of the actual devices with each spot labeled

Again, just connect each port to switch to the correct port on the controller and everything will work once we make the changes to ProjectW.

From an earlier post, I have copied the directions over:

Starting the Pronto

You will want to be on the console of the Pronto switch and tell it to use option 3 (boot to shell).  Once you are at the shell you can then create a bootovs.sh like the one I show below:

bootovs.sh for the Pronto 3290:


MYIP=192.168.1.100
CTLIP=192.168.1.17
GWIP=192.168.1.1
DPPORTS=2
EP=ge
VSCTL="ovs-vsctl --db=tcp:$MYIP:9999"
cd /
ifconfig eth0 $MYIP netmask 255.255.255.0
route add -net default gw $GWIP
rm -f /ovs/ovs-vswitchd.conf.db
ovsdb-tool create /ovs/ovs-vswitchd.conf.db /ovs/bin/vswitch.ovsschema
ovsdb-server /ovs/ovs-vswitchd.conf.db --remote=ptcp:9999:$MYIP &
ovs-vswitchd tcp:$MYIP:9999 --pidfile=pica8 -- &
$VSCTL add-br switch1
$VSCTL set bridge switch1 datapath_type=pronto
for i in `seq 1 $DPPORTS` ; do
PORT=$EP-1/1/$i
$VSCTL add-port switch1 $PORT -- set Interface $PORT type=pronto $OPTS
done
$VSCTL set Bridge switch1 other-config:datapath-id=0000000000000099
$VSCTL set-controller switch1 tcp:$CTLIP:6633

I will go through this a bit, basically, we are setting up some static information such as the IP of the switch (192.168.1.100) the IP of the OpenFlow controller (192.168.1.17) and then starting OVS using that information on port 9999.

Put this script in your / directory. Then you can simply execute it and everything will work. I have defined 2 interfaces to be used, ge-1/1/1 and ge-1/1/2. You could define more. Also if you are using a 10G Pica8 switch, you can change the $EP variable to te.

The physical machine setup

Boot the machine using the projectwv04.iso and do the following:

Once the boot cd is up, do the following:

ifconfig eth0 192.168.1.17/24

You should now be able to ping 192.168.1.100 which is the pronto switch.

You will need to now run bootstrap-lxc.sh which will expand the lxc files onto the file system.

I have modified the config files for b1 and b2 in /var/lib/lxc/bx/config with the following for network:


/var/lib/lxc/b1/config

lxc.utsname = b1
lxc.network.type = phys
lxc.network.flags = up
lxc.network.name = eth0
lxc.network.link = eth2

/var/lib/lxc/b2/config

lxc.utsname = b2
lxc.network.type = phys
lxc.network.flags = up
lxc.network.name = eth0
lxc.network.link = eth3

Again, pretty simple stuff, I am simply telling the lxc containers to use physical intefaces eth2 and eth3.

for the projectw.sh script you need to change a few lines:

SWITCH1DPID=0x99
STARTBVMS=0

The first one defines the switches DPID which is in Hex, the second tells the system not to start the b1/b2 VMs.

Also you need to delete references to the b1 and b2 machines :

# lxc-stop -n b1 &> /dev/null;
# lxc-stop -n b2 &> /dev/null;

# rm -rf $LXCDIR/b1/rootfs/var/run/network/ifstate;
# rm -rf $LXCDIR/b2/rootfs/var/run/network/ifstate;

These lines will stop the projectw.sh from killing the b1/b2 machines and removing their network state.

At this point, you can run “projectw.sh –nox”.  It will start up NOX, the RouteFlow processes and the VM running Quagga.

You will then need to start the b1/b2 LXCs by doing the following:


lxc-start -n b1 -d
lxc-start -n b2 -d

Now you should be able to attach to b1 “lxc-console -n b1″ login root/root and ping 172.31.1.1 (router) and 172.31.2.2 (b2).

If you will want to ssh into the machine at some point, you will need to add a host key:

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

Hit enter twice and it will complete.

Summary

At this point you have a running testbed.  The only issue is, if you reboot, power off, reset, crash or if anything else happens to the controller, you will have to start over with the modifications.

The post Building a Reference SDN Controller – Part 2 – Cable and Configure appeared first on Router Analysis.

Router Analysis has been working for the last six months constructing and testing a Reference SDN Controller.  The project has two goals:

Create a enterprise grade PC based system that compliments OpenFlow enabled switches that allows for an easy introduction to OpenFlow based SDN for Network Administrators.

Create a baseline testing system for the use of Router Analysis in testing and benchmarking OpenFlow based SDN Switches.

We refer to the project as “The RA System” internally.

The Basics

To make the system simple to use, it is based on a SuperMicro case that has all ports front facing, the 513F:

Router Analysis Reference SDN Controller – Port View

The motherboard used, the SuperMicro X9SCi-LN4F  has 4 built in Gigabit Ethernet ports, a separate IPMI, built in video and a serial port.  An Intel Xeon E3-1220V2 CPU is used to keep the system enterprise class while keeping costs and power use down.  The last parts are 8GB of RAM and a 16GB SataDOM.

The Software

For the first run at the software image, Router Analysis utilized a combination of the RouteFlow project from CPqD and ProjectW from Josh Bailey.  ProjectW is a bootable, modified version of RouteFlow as a cd image.  ProjectW runs wonderfully on the RA-REF setup as you can boot the CD virtually via the built in IPMI/iKVM built into the SuperMicro motherboard.

This is one of the main reasons we went with this SuperMicro board, to give as much flexibility as possible with the system.

Once the system is booted, you can easily work through the ProjectW/RouteFlow examples and work with a live OpenFlow system.

Router Analysis, Inc. has been working on a modified version of ProjectW that boots from the SataDOM and allows for configurations to be saved and built.  On request an alpha version of this software can be given out.

Running the modified version of ProjectW on the “RA Reference Platform” i.e. “The RA System” allows for the following design to be executed:

The RA System based on ProjectW and RouteFlow

Included in this diagram are extra ports on the switch that can be hooked up to an IXIA, Spirent or tester of your choice.

In Part 2 we will discuss the “RA System” and how to utilize it.

Follow Up:

By request here is information on how to purchase your own machine:

King Star Computer (KSC) built the current system that we use from the following parts:

KSC knows how to build the system, the best person to talk to is Jessie Chen as she was responsible for the modifications to the system to make sure it would function correctly.  We ended up having to use an active heat sink on the CPU to make sure it stayed cool.

ProjectW v.04 is available via this link.  Josh’s team is always updating it, but this version is stable and has a few fixes that were important.

The post Building a Reference SDN Controller – Part 1 appeared first on Router Analysis.

What the customers are looking for from NFV:

With the advent of NFV the networking industry is seeing a big change in the historically conservative views of their Telco customers.  The Telcos are willing to:

• Take a larger CapEx hit if it means very large reductions on OpEx
• Work with smaller (startup) vendors
• Give up their historical 5 9′s requirements of networking hardware
• Go to an all Software-led infrastructure if they can get the performance needed

These are very large changes when you look at who is offering to make them;  Companies like Deutsch Telekom, Vodafone and AT&T who have generally been conservative on their take-up of new technology.  While the Service Providers are generally quicker to adopt new technology from NEMs, even startup NEMs, the Telcos take their time.

The timing of NFV makes sense

So much has changed in the last few years with regard to commodity hardware systems.  Cisco bought up and brought out the UCS platform.  UCS was initially viewed as another confusing move by Cisco, why would they go up against HP, IBM, Dell and their other close partners? How would Cisco take on such a challenge.

As it turns out, the UCS products have been amazingly successful for Cisco and are helping to push Cisco towards being a Software-led company.  Cisco is involved in the OpenStack movement.  Cisco is virtualizing different routing and switching components and cannibalizing their own conventional hardware router sales (not to a great extent.. yet).

HP has built some of the best performing and trusted blade systems while continuing to push their networking products.

VMware has been building out their networking support and become a player not just in server virtualization, but rack and datacenter consolidation.

Intel has been moving the controller chipsets into their CPUs, Westmere, Sandy Bridge, Ivy Bridge all build upon each other, raising the speed with which a commodity x86 processor can deal with IP packets.  And vice-versus NEMs have been adding x86 blades to their hardware.

How are Network Equipment Manufactures Dealing With NFV?

Cisco and Juniper both offer blades that go in their conventional routers, the Service Ready Engine (SRE) and JunOS vApp Engine.  These blades allow parts of NFV to be executed without a large change to how Telcos and Service Providers handle equipment today.  Instead of having to install commodity servers in their central offices, the Telcos and SPs can add a blade to their current routing equipment and quickly deploy/test services.

NEMs are also involving themselves in the ETSI NFV meetings and processes, offering ideas and solutions that keep the NEMs central to Telco and SP needs.

Startups are working to re-define what a network is, utilizing overlays, underlays and strategies that were unheard of just a few years ago .

All of this comes together at the operational level: making networks easier to manage.

The post NFV’s Impact on Network Equipment Manufacturers appeared first on Router Analysis.

In partnership with SiliconANGLE we are proud to release The State of OpenFlow 2012 – Report and Analysis.

Here are some snippets from the report:

Testing Session Overview

The goal of the testing was straightforward; confirm that currently available switches interoperate with two of the most used OpenFlow controllers, Floodlight and NOX (using the RouteFlow project).

The minimum requirements for the switches were set low on purpose:

• Minimum of 1000 Flows in Hardware
• Support of OpenFlow v1.0
• Interact with both Floodlight and RouteFlowTo keep the tests fair support for higher versions of OpenFlow was ignored, as were HP’s extensions such as priority queue support.All three vendors who participated in our State of OpenFlow 2012 test passed the basic features tests.

Vendor Involvement

Router Analysis, Inc. indirectly via Twitter, Blog posts and word of mouth invited any vendor with an OpenFlow v1.0 capable switch to be involved in the testing.

One vendor, IWNetworks contacted Router Analysis, Inc. to take up the public offer.

We directly invited the following vendors:

• Juniper – Unable to participate – Still in limited testing
• Cisco – Unable to participate – Still in limited testing
• Pica8 – Participated and provided support
• HP – Responded by did not provide an evaluation unit – Router
  Analysis, Inc. purchased a 6200yl for the tests
• Arista – No Answer
• Brocade – Responded and DeclinedTotal number of vendors invited: 6, total participating: 3.

The post The State of OpenFlow 2012 – Report and Analysis appeared first on Router Analysis.

It started decades ago, routers, firewalls, load balancers, etc were and still are computers.  The computers are more specialized, have FPGAs and other specialty hardware, but they are still computers.

The reason the network had to move to the current generation of focused products was that traffic levels were pushing the limits of what could be done using a generic machines.  If I recall correctly, in the mid 90′s the last of the minicomputer based routers were removed from the peering exchanges and the era if Cisco/Juniper came to be.

Today the hardware available in servers: Ivy Bridge based processors, packet offloading NICs and other enhancements have brought back the possiblity of handling high numbers of packets per second (PPS) and Gigabits per second (Gbps) on inexpensive hardware.  Companies like Vyatta, LineRate Systems, Midokura and others are out to prove that you no longer need expensive, proprietary hardware to do Network tasks.

In public, the ETSI Network Function Virtualization working group is pushing hard on vendors to provide virtualized versions of products and solutions.  Even Cisco has released UCS based Network products that it claims can do up to 17Gbps.

But there is an issue, how do you get from a Hardware Defined Data Center to a Software Defined one?  My view is that we need to follow the Software-led path towards what we currently call Software Defined Networking (SDN)

How to transition from Proprietary Hardware to Commodity Hardware?

As SDN tends to be described as a separation of the Control Plane and the Forwarding Plane, one of the first steps is to implement a Control Plane that runs separate from the rest of the hardware.  Eventually this Control Plane will become part of an Orchestration toolset.  Once the Control Plane is implemented, there are products that can be put in place to reduce costs, while adding a minimum of complexity.  OpenFlow controlled switches can provide part of the solution.

Putting a few OpenFlow switches to put in the network to re-path some of the current traffic, would be a good first step.  The switches could be used to offload traffic from your current hardware path, freeing up resources on your routers, firewalls, load balancers, etc.  The main hurdle here is to have a system that optimizes the flows put onto the OpenFlow switches.

As more mature solutions come out to help manage flow tables, these same products could be used in concert with other network control products, to Orchestrate a NFV based version of the infrastructure via Network APIs.

Summary

While current commodity based hardware servers are not capable of pushing tens of millions of PPS or 100s of Gbps,  OpenFlow based switches are.  The orchestration of the packet flow for both SDN and NFV will be very similar.  While OpenFlow may not, in the end, be the Network API used to manage all of the Hardware and vDevices in the Network, the work of building the Control Plane, OpenFlow integration and eventually the Orchestration management tool continues to provide value.

We are at the beginning of the Software-led Network Virtualization transition.  It is important to look at what benefits are gained via Software-led designs and how you can take advantage of them now and in the future.

The post The NFV Conundrum – A Migration Path appeared first on Router Analysis.

We are happy to be able to announce the third vendor in our tests: IWNetworks.

The IWNetworks SDN 8952S OpenFlow capable 10/40GbE Switch

IWNetworks has provided Router Analysis with an SDN 8952S switch.  The SDN 8952S is a 48 port 10GE + 4 port 40GE line-rate capable switch with OpenFlow v1.0 support.  In our testing we were able to connect the switch to our RouteFlow setup and our Floodlight setup without any issues.  As this is not a speed test, we did not do any benchmarking of the IWNetworks SDN 8952S.  We are happy to have IWNetworks join in the State of OpenFlow 2012 Testing and Analysis.

Latency Measurements

As discussed in our last post, we have been working on better measurements regarding latency of the first (few) packets that are passed to the OpenFlow Controller and re-directed through the switch.  As we are attempting to make very precise measurements, we do not want to pre-post any data before we are able to reproduce it.  We are working with all three vendors to cross confirm all test results.  We are also working with Dr. Christian Esteve Rothenberg Ph.D from CqPD which developed and supports the RouteFlow Project an open source project to provide virtualized IP routing services over OpenFlow enabled hardware.

Initial measurements were done using ICMP, i.e. ping to determine how much time the initial packet took to get through the system.  Here are some of the “test” (I have to use the word loosely as using ping is a very generic way of testing things and reliant on too many moving parts, machine speed, link speed, etc).

Here we are pinging the test port of our machines from the RouteFlow Routing VM (rfvm1 = Quagga running in a LXC container).  The first packet takes ~13.5ms to return, the packets after that take ~2ms.

We at Router Analysis are currently working on more specific measurements down to the nano-second.

Summary

The inclusion of IWNetworks in our tests last week as “Vendor X” and the “unnamed vendor” supports our and many of our friends assertion that the Routing and Switching market will be disrupted by Network Programable switches.  We have worked with IWNetworks before and because of that relationship IWNetworks reached out to us about their new switch.  There are other vendors out there developing or possibly releasing switches that support OpenFlow that we as Router Analysis don’t know about.  If your company has an OpenFlow compatbile switch that we have not mentioned, please reach out and let us know.

As for Latency, the more we know, the better off we all are in the networking field.  Being able to define the latency of your design is important.  From what we have seen, you can add anywhere between 10-30 ms to your path.  This can be improved as we are using copper GE, VMs and other tools that add to the latency, it won’t be 0, but it will get closer.

The post State of OpenFlow 2012 Testing Notes – Days 12-14 – IWNetworks SDN 8952S appeared first on Router Analysis.