Readers of this blog already know, at Volta, we are disrupting networking industry. Innovation is in our DNA, but we also stand on the shoulders of giants. For example we use FRR as our IP routing protocol suite. FRR is a relatively new project which recently joined the Linux Foundation.
But FRR is no spring chicken. As you can see on their website, FRR has its roots in the Quagga project (which dates back almost 20 years ago!). In fact, FRR was started by many long-time Quagga developers who combined their efforts to improve on Quagga’s well-established foundation in order to create the best routing protocol stack available. The community has been organized around nonprofits, NetDEF and OpenSourceRouting, with large participation from multiple commercial organizations.
Here’s a bird’s eye view of some things the team has been busy working on:
- 32-bit route tags were added to BGP and OSPFv2/v3, improving route policy maintenance and increasing interoperability in multivendor environments
- Update-groups and nexthop tracking enable BGP to scale to ever-increasing environments
- BGP add-path provides users with the ability to advertise service reachability in richly connected networks
- The addition of RFC 5549 to BGP provides IPv4 connectivity using IPv6 native infrastructure, enabling customers to build IPv6-centric networks;
- Virtual routing and forwarding (VRF) enables BGP users to operate isolated routing domains such as those used by web application infrastructures, hosting providers, and Internet Service Providers
- EVPN Type 5 routes allow customers with Layer 2 data centers to exchange subnet information using BGP EVPN
- PIM-SM and MSDP enable enterprise applications that rely on IP multicast to use FRR
- Static LSPs along with LDP enable architects to use MPLS to engineer network data flow
- Enabling IETF NVO3 network virtualization control allows users to build standards-based interoperable network virtualization overlays.
We have integrated this awesome suite into our Volta Cloud Routing Engine. This way we can scale it to meet high computations demands and fast-pace of service delivery. By means of our Network Element Virtual Interface (NEVI) we ensure that is always in sync with the Volta Agent in the hardware.
It is usually advised not to put all eggs in one basket. I think it’s wise. Our distributed architecture makes us very resilient and gives us the flexibility to adapt and change easily any component in our stack. This includes FRR too, of course. So we could use other routing daemons if, for example, a customer ask us so.
But Mark Twain wrote in his book The Tragedy of Pudd’nhead Wilson:
Behold, the fool saith, “Put not all thine eggs in the one basket”—which is but a manner of saying, “Scatter your money and your attention;” but the wise man saith, “Put all your eggs in the one basket and—watch that basket”.
So we take this advice too. That’s why we are fully committed to FRR project, involved in the community and contributing back, as we believe it’s the best solution available now.