Open Source Routers?
In the old westerns (often actually shot in Italy or Mexico, rather than the Western United States), when a new gunfighter strolls into town there will always be that fateful moment when someone will say, “this town ain’t big enough for the two of us.” Then some arrangement will be made to meet at dawn on the main street. In the routing world, the problem is often not too many gunfighters, but too few, particularly when it comes to routing stacks. There are a few, of course, including Cisco, Juniper, IP Infusion, Ericsson, and some other well-known names.
The list of available options narrows significantly when it comes to open source implementations. There are Bird and gpBGP in the BGP only space. There is snaproute’s implementation in go, which is moving towards being a full stack. But the only “real” choice available in the open source space for a fairly complete routing stack has always been Quagga.
While Quagga has always been the mainstay of the open source routing world, but this “granddaddy of open source routing stacks” has always suffered from a shallowness of community participation, a lack of a solid legal framework, and—probably more than anything else—a lack of automated and regular integration testing. In fact, the lack of a widely supported, thoroughly tested, and strongly founded open source routing stack has hindered the disaggregation and white box worlds for a long while.
That is, until now. At the last Open Networking Summit (ONS), a fork of Quagga, called FR Routing (for Free Range Routing), joined the stable of projects under the Linux Foundation in the area of open source networking projects. The aims of this new project are to provide a full, commercial grade routing stack that can be used as the basis for commercial and open source projects. One of the unique aspects of FR Routing, as opposed to many other open source routing stacks, is the automated integration testing performed on the code; these test validate the proper operation of the code against a well-known route testing environment, including fuzz testing.
To understand the importance of this new routing stack, it might be useful to review one of the original posts I wrote here at ECI on the topic of disaggregation. The basic idea behind disaggregation is to separate network software from network hardware in a way that allows each to be considered a different “buy,” or system, in the overall network architecture. By disaggregating, a company can separate the lifecycle of hardware from the lifecycle of software.
Traditionally, when a piece of hardware needs to be replaced because of new interface, density, or switching feature requirements, the software must be replaced with it. In a sense, the software represents the architecture of the network; the interface between the business and the hardware that actually switches packets through the network. Tying software to hardware in this way essentially forces the architecture of the network itself to change in response to new hardware requirements, rather than in response to business needs. Disaggregating hardware and software allows the network architecture to be more closely tied to the business requirements, rather than to the hardware lifecycle.
While it is possible for disaggregation to occur in a completely vendor driven world, it is far more difficult—it is generally in the vendor’s best interest to tie the hardware and software together, creating lock-in, and controlling the operator’s spending cycle by managing the rate at which hardware is no longer supported.
How does an open source routing stack relate to this problem? FR Routing can serve as a basis for larger operators to build some parts of their software, while purchasing others, and completely separating the software from the hardware. Further, open source projects like FR Routing are a good source for small, innovative vendors to base new products on; a smaller vendor may not have the resources to build an entire stack, but may have enough to work on the pieces that will differentiate their business. More competition in the network software space will ultimately mean more flexibility in the products available to operators, even if they do not want to build their own software based on FR Routing.
FR Routing is, in short, a major step forward for operators, a great resource for individual engineers who want to learn about routing, and a key component in the maturing disaggregation/white box ecosystem.
