CCNP training : FRRouting (FRR)

4 1 1 1 1 1 Rating 4.00 (1 Vote)

What is FRRouting ?

FRRouting (FRR) is an IP routing protocol suite for Linux which has it's roots in the Quagga / Zebra projects. which includes protocol daemons for BGP, IS-IS, LDP, OSPF, EIGRP PIM, and RIP. I's linux integration makes it usable to connect physical hosts, virtual machines, and containers to the network.

It's Cisco-like command line interface (CLI) with many commands similar to the Cisco IOS commands makes FRR easy to configure and a good candidate for building a lightweight routing lab environment for Cisco CCNP enterprise training.

 

Getting started with FRRouting ?

Installing FRRouting

The FRRouting project publishes packages for Red Hat, Centos, Debian and Ubuntu on the GitHub releases page. It can also be installed from Github source or deployed using the frrouting/frr Docker container based on Alpine Linux available on Docker Hub.

When using the official frrouting/frr docker image, don't forget to build a custom image including the required network tools (telnet, tcpdump, ...) and exposing all the network ports needed by routing protocols for peering. TCP port 179 has to be exposed by the container and mapped on the Docker host when using bgpd to allow BGP peering outside of the Docker network.

# Sample Dockerfile exposing TCP port 179
FROM frrouting/frr

EXPOSE 179

Build the custom Docker image and run it using Docker commands:

docker build -t packettracernetwork/frr .

docker run -d --name=frr3 --privileged=1 -p179:179 packettracernetwork/frr:latest

 

Configuring FRRouting routing protocols daemons

Before starting FRRouting, edit the /etc/frr/daemons file to enable each routing daemon required for the target environment. For example, to enable BGP, set bgpd to yes. The zebra daemon is enabled by default and does not have to be enables in deamons file anymore. Please note that all of the routing protocol daemons are dependent and started by the main zebra deamon.

bgpd=yes
ospfd=no
ospf6d=no
ripd=no
ripngd=no
isisd=no
fabricd=no
pimd=no
ldpd=no
nhrpd=no
eigrpd=no
babeld=no
sharpd=no
pbrd=no
vrrpd=no
...

All the network configuration is stored in /etc/frr/frr.conf and can be edited using the vtysh command line interface (CLI).

switch# write memory
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]
switch# exit

Useful tips when running FRRouting in a Docker

1. Disable userland-proxy

By default, docker containers don’t see which source IP address is connecting when they have a listening port. The docker userland-proxy is rewriting the packet public IP address to the docker bridge source IP which makes BGP peering fail as the FRRouting BGPD daemon received packets with a different IP address than it's configured neighbors.

To make BGP peering between FRRouting BGPD daemon running in a docker container and any remote router (ie : not located in the same docker network), docker userland-proxy needs to be disabled by creating the /etc/docker/daemon.json file and configuring it with the following content :

{
  "userland-proxy": false
}

Then, restart Docker to apply the configuration :

sudo systemctl restart docker

 

2. Configure tour BGP peering with a ttl-security of 2 hops

The BGP TTL Security Check is a mechanism to protect eBGP peering sessions from attacks that can be caused using forged IP packets by comparing the TTL of received IP packet against a hop-count configured locally for each eBGP neighbor. If the TTL value of received IP packet is equal to or greater than the configured value, then the IP packet is accepted and processed normally. If the TTL value of the IP packet is less than the configured value, then the IP packet is silently discarded and no ICMP notification message is sent.

As the docker host is routing IP packets between the docker network and the docker host public network, the TTL of BGP packets is increased when peering with any remote BGP router (ttl >= 2). BGP packets are dropped because of the TTL Security Check feature because the TTL value of the packet (2) is greater than the default TTL Security Check value (1).

To make the peering work, both BGP peers have to configure the ttl-security to a minimum of 2 hops on both peers (configuring it only on the FRRouting instance running in Docker is not enough, both BGP peers have to be configured) :

Router 1 configuration (bare-metal or virtual machine):

router bgp 44000
 neighbor 192.168.1.94 remote-as 65001
 neighbor 192.168.1.94 ttl-security hops 2
!

Router 2 configuration (running in docker) :

router bgp 65001
 neighbor 192.168.1.82 remote-as 44000
 neighbor 192.168.1.82 ttl-security hops 2
 !
 address-family ipv4 unicast
  network 10.0.0.1/32
  neighbor 192.168.1.82 route-map ANYCAST-RM out
 exit-address-family
!
ip prefix-list ANYCAST seq 5 permit 10.0.0.1/32
!
route-map ANYCAST-RM permit 1
 match ip address prefix-list ANYCAST
 set ip next-hop 192.168.1.94
!

FRRouting logo