Free Range Routing – open source networking takes off

Free Range Routing – open source networking takes off

Open source routing has been around for a while, but in the last few years, it’s been given a well-needed shake-up with the formation of the Free Range Routing (FRR) project. There are a number of open source initiatives related to routing, but FRR has become the most important community with the broadest support. In fact, FRR has been added to the SONiC project. Volta is an active participant and contributor to FRR.

So, Where Did it All Start?

The idea of providing an open source routing suite has been around since the mid-1990’s when a group of like-minded individuals, feeling constrained by the limitations of off the shelf routing software decided to write their own and open it up to the world. They started the GNU Zebra project, which by 2000 had a pretty decent OSPF, RIP and BGP routing stack. As productivity started slowing down, a fork of Zebra was created – the Quagga project, which carried the baton until recently, when it in turn was split into Free Range Routing (FRR).

The FRR project has really given open source routing a well needed shot in the arm – and has also been helped by the explosion of open source overall during the last few years. In addition, the founding members of FRR – from day one – wanted to be more agile, more collaborative, and generally get things moving – and they‘ve certainly done just that.

As a result, some big players in the industry are already working with FRR, including VMware, Orange and even Microsoft with its SONiC program. However, as the community is based around the individual contributors rather than the corporations they work for, the project is maintaining a vibrant and agile ethos, with anyone welcome to come forward with new features and bug fixes. When you also take into account the ever-growing roadmap already packed with features, it’s no surprise that interest in FRR is growing exponentially.

FRR hit the ground running in 2017 with a stack that already included many of the usual favorites: OSPF BGP, ISIS, LDP, and PIM, and development has continued at a breakneck pace ever since. As an example, this year we’ve seen several new features across all the supported routing protocols (especially BGP), plenty of new usability and efficiency improvements, the coming of VRRP support, and the beginnings of a YANG and Netconf management abstraction layer.

You can run the stack on just about any flavor of Unix – Linux, Free BSD, Open BSD, and even Solaris. You can also download the source code and tweak it to your heart’s content. FRR has also created Debian and Red Hat packages for those of us who prefer to just get it installed and see what it can do.

The architecture

Starting at the top, as of this year there is the beginning of a management abstraction layer – still limited to a few routing protocols. Then there are the protocols themselves, all running within their own daemons that are constantly updating the Zebra RIB. Zebra, in turn, calculates and downloads the FIB – and here is where things get really interesting, as not only can the FIB be downloaded to the host’s OS, but if you prefer you can bypass the host completely and install the FIB directly into the ASICs of a white box switch.

There’s been a lot of work done on improving the speed and efficiency of communication between these elements, and as well as data optimization. Each daemon has been given its own dedicated Pthread – which means a faster reaction to network changes.

So, What’s the Plan?

The FRR vision is an industry where network equipment providers will go straight to the open source community rather than writing their own routing stack for new products. This means that new offerings should get to market faster, as developers won’t be wasting effort reinventing the wheel but instead working with, adapting and improving the existing FRR stack. This collaboration should help maintain a busy roadmap of new features and bug fixes.

There’s also a real drive within FRR to keep focusing on usability improvements rather than just bringing out reams of new features and nerd knobs that network engineers in the field may struggle to keep up with.

I’ve already mentioned the recent baby steps in opening up the stack to northbound management APIs. This work, along with other usability improvements, has spurred the architecture people at FRR to think more about the future, and how to make sure the stack is as ready as possible for the Next Big Thing. This year we are already seeing a rewrite of Zebra into a more extensible architecture, meaning FRR will be ready – and continue to be ready – for any other game-changing network trends that come down the line.