Photo by Sahand Babali on Unsplash

Photo by Sahand Babali on Unsplash

Flexible software routing with open source FRR

Special Delivery

Article from ADMIN 65/2021
By
The FRR open routing stack can be integrated into many networks because it supports a large number of routing protocols, though its strong dependence on the underlying kernel means it requires some manual configuration.

In the past, many network administrators used pre-installed and expensive appliances for routing. Although this was used for a long time as a reliable solution, it is no longer suitable for more flexible use. For example, if you have highly virtualized server environments, the norm today, hardware appliances don't really make sense.

New approaches, such as network function virtualization (NFV) or software-defined networking (SDN), decouple networks from the hardware. Routing therefore needs to support integration into a service chain (i.e., the concatenation of the required services, alongside other functions such as firewalling or intrusion detection and prevention).

Moreover, it used to take a large amount of space, power, and money to learn in a test environment how routing protocols work with real hardware routers or to recreate specific behaviors. Network administrators who wanted to test their implementations for vulnerabilities had to build elaborate hardware environments or write their own routing stacks.

In this article, I look at an open routing stack provided by the open source project Free Range Routing [1], usually known as FRRouting or FRR.

Open Source Routing Stack Remedy

An open source routing stack can be an alternative to classic routers. In contrast, the conventional monolithic architectures with specialized application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) for hardware-optimized packet forwarding obviously cannot directly offer the same performance optimizations; however, in some constellations, it is not so much a question of forwarding performance, but more likely about the functionality of the control plane, as when validating a network design. Control plane refers to the functions that can be used to control networks – Spanning Tree on Layer 2, for example,

...
Use Express-Checkout link below to read the full article (PDF).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Routing with Quagga

    Cisco and Juniper have implemented routing protocols to help your router find the optimum path. On Linux, you can use software like Quagga, with its Zebra daemon, to help automate this process.

  • Creating a redundant array of inexpensive links
    The Fault Tolerant Router daemon uses multipath routing among multiple Internet connections to keep you connected, even when some connections go down.
  • Layer 3 SDN
    Calico chooses an unusual approach for software-defined networking, relying on open standards like BGP. We look at the distinctions and advantages of Calico.
  • Scalable network infrastructure in Layer 3 with BGP
    Large environments such as clouds pose demands on the network, some of which cannot be met with Layer 2 solutions. The Border Gateway Protocol jumps into the breach in Layer 3 and ensures seamlessly scalable networks.
  • Data center networking with OpenSwitch
    When it comes to network devices on Linux, legacy firmware still seems to have a competitive edge. Lately, however, some highly promising approaches have shown up, including the OpenSwitch project.
comments powered by Disqus