qstockmedia - Fotolia
There has been a lot of talk around open source routing these days. The concept itself isn't new; Quagga, considered the clear forerunner in the industry as open source routing code, has been around for more than 15 years. A number of OS vendors, chief among them Cumulus Networks, have largely based their business on Quagga's code.
Today, attention is being shifted to a new open source routing protocol, dubbed Free Range Routing. FRR, an effort backed by the Linux Foundation, Cumulus and other networking vendors, builds on the framework of Quagga and Zebra, while adding some new features and capabilities.
Freely available on GitHub, Free Range Routing is designed to run on Unix and Linux, and it supports several key protocols, including Border Gateway Protocol, Open Shortest Path First (OSPF), Routing Information Protocol and intermediate system to intermediate system.
With FRR, as with Quagga, each protocol exists as a daemon. Protocols talk to a kernel abstraction layer, which in turn makes the decision of what information goes into the routing information base and what doesn't.
As a result, FRR doesn't actually do any forwarding; it only implements the routing protocols themselves. Thus, you can implement FRR on a Linux system and use the Linux kernel for forwarding. This would be a software router implementation. Alternatively, it could be connected to a distributed forwarding platform using something like OpenFlow, or you could enable the routing protocols to interface with off-the-shelf routing hardware.
How Free Range Routing handles OSPF
FRR is coded mostly in C, the most widely used programming language. If you have any programming experience, you can git clone the repo and look directly at the source code. This is beneficial; being able to look at the code can answer many questions about how the routing protocol functions.
Have a look at this sample code from FRR that shows just a bit of what happens under the hood of OSPF. This code was provided by Russ White, an author, network engineer and a TechTarget contributor, and there are several comments in the code that explain what's happening. Notes are indicated with a // or by a preceding /* and closing */.
ospf_process_self_originated_lsa (struct ospf *ospf,
struct ospf_lsa *new, struct ospf_area *area)
struct ospf_interface *oi;
// creates a pointer to a structure that holds information about ospf on a per interface basis
struct external_info *ei;
// creates a pointer to a structure that holds information about external routes
struct listnode *node;
// create a pointer to a list of nodes
/* If we're here, we installed a self-originated LSA that we received
from a neighbor, i.e. it's more recent. We must see whether we want
to originate it.
If yes, we should use this LSA's sequence number and reoriginate
a new instance.
if not --- we must flush this LSA from the domain. */
/* Originate a new instance and schedule flooding */
area->router_lsa_self->data->ls_seqnum = new->data->ls_seqnum;
/* We must find the interface the LSA could belong to.
If the interface is not a broadcast type or we are not
the DR, we flush the LSA, otherwise we create the new instance and
schedule flooding. */
/* Next, Look through all interfaces, not just area, since interface
could be moved from one area to another. */
for (ALL_LIST_ELEMENTS_RO (ospf->oiflist, node, oi))
/* These are sanity check. */
if (IPV4_ADDR_SAME (&oi->address->u.prefix4, &new->data->id))
if (oi->area != area ||
oi->type != OSPF_IFTYPE_BROADCAST ||
!IPV4_ADDR_SAME (&oi->address->u.prefix4, &DR (oi)))
ospf_schedule_lsa_flush_area (area, new);
if (new->data->type == OSPF_OPAQUE_LINK_LSA)
oi->network_lsa_self->data->ls_seqnum = new->data->ls_seqnum;
/* Schedule network-LSA origination. */
case OSPF_AS_EXTERNAL_LSA :
if ( (new->data->type == OSPF_AS_EXTERNAL_LSA)
&& CHECK_FLAG (new->flags, OSPF_LSA_LOCAL_XLT))
ospf_translated_nssa_refresh (ospf, NULL, new);
ei = ospf_external_info_check (new);
ospf_external_lsa_refresh (ospf, new, ei, LSA_REFRESH_FORCE);
ospf_lsa_flush_as (ospf, new);
ospf_opaque_lsa_refresh (new); /* Reconsideration may needed. *//* XXX */
Looking at code snippets like this helps us get a sense for what's going on behind the scenes. In this example, we see the process of receiving a link-state advertisement from a neighbor and determining if it's new, and then figuring out if we are going to source it and forward it out of another interface.
One of the benefits of open source routing is you can actually get to the source. There's no hidden magic going on that only a vendor can explain and slant in any way it may see fit.
Why care about Free Range Routing?
It's hard to have a conversation about networking vendors these days without hearing about white box alternatives to Cisco. Everyone wants to save a buck while still having products that offer all the features and capabilities they need to keep their networks operating.
Clearly, vendors like Cisco have put a lot of money into the development of their protocol suites, and that investment is reflected in the price tag affixed to their products. That investment also means Cisco is the one responsible for writing new code, and if there is a lag in its release, it's handled internally and customers are -- usually -- none the wiser.
That said, open source software and white box switching are gaining a lot of steam in today's design meetings. Discussions around these developments aren't likely to go away anytime soon. It's imperative to keep your finger on the pulse of what's driving these discussions and what the alternatives are.
Can a modern enterprise function with an open source routing platform running on an x86 box? Cumulus claims you can -- and at a fraction of the price. There are tradeoffs: If you have issues with a community-driven project, you can't exactly submit a Technical Assistance Center ticket to Cisco and obtain a speedy response.
For most general networking environments, however, you can certainly get away with open source alternatives like Free Range Routing. The question is whether you want to invest in open source or if you'd rather pay the "tax" and let someone else deal with the issues you encounter.
My opinion is you don't need to master any of these open source options to be able to implement basic routing, Keep this in mind, however, if you decide that getting familiar with open source routing and FRR is not for you, you may left behind as these projects become more popular.
Looking into software-based routers on x86 servers
How virtual router software will affect industry
Open source network software may bring about industrial shifts