GSoC 2022 FRRouting - Zebra Traffic Control

Project Summary

FRRouting

FRRouting (FRR) is an IP routing protocol suite for Linux and Unix platforms which includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM, PBR, RIP, BFD, Babel, OpenFabric, VRRP, EIGRP, and NHRP. FRR’s seamless integration with the native Linux/Unix IP networking stacks makes it applicable to a wide variety of use cases including connecting hosts/VMs/containers to the network, advertising network services, LAN switching and routing, Internet access routers, and Internet peering. FRR is a high performance suite written primarily in C. It can easily handle full Internet routing tables and is suitable for use on hardware ranging from cheap SBCs to commercial grade routers. It is actively used in production by hundreds of companies, universities, research labs and governments. A Linux Foundation Collaborative Project, FRR is distributed under GPLv2, with development modeled after the Linux kernel. Anyone may contribute features, bug fixes, tools, documentation updates, or anything else. FRR is a fork of Quagga.

Mentor: sworleys, qlyoung

Add the ability for ZEBRA to modify TC tables via the netlink protocol. Currently FRR has no ability to modify the underlying TC tables. This would be extremely useful for BGP Flowspec as well as with PBR.

Linux Traffic Control Summary

Currently tc command line in iproute2 is the de facto standard tool to configure QoS / traffic control at userlands.

tc can manipulate three objects via Linux netlink:

QDISC determines how packets can get their chances to be queued and then sent.

Only classful QDISCs can own a bunch of TCLASS. By limiting some parameters, and applying the discipline rules from QDISC, it can thus do traffic shaping.

TFILTER contains a group of criteria, attached to a QDISC and then decide the outgoing TCLASS for those matched packets.

Linux offers a lot of secondary kinds to choose for each TC netlink object. For this project, the following combinations are chosen:

This kind of QDISC will apply Token Bucket Filter algorithms to the queue.

Check tc-htb(8) for more details.

This kind of TCLASS must have a parent QDISC of kind htb. By specifying the rate (in fact changing the underlying bucket size and new token interval) a new class on the queue is created.

Check tc-htb(8) for more details.

This is a very powerful whilst friendly implementation of TFILTER. It allows users to create filters based on Layer 2/3/4 fields, and sends the captured traffic to a class defined before.

Check tc-flower(8) for more details.

Adding New Objects to FRR

The figure below shows how routing daemons manipulate objects in FRR. ZAPI, an OS-independent binary message protocol is used to bridge routing daemons and zebra. Then zebra will talk to the underlying OS interfaces (e.g. Linux netlink, BSD socket).

FRRouting Path

It is then clear about TODOs when it comes to adding traffic control capability:

Pull Requests

Proof of Concept & Future

PoC

Currently sharpd owns a super easy command to declare a traffic filter and its rate on specific interface.

You need to build FRR first. After ensuring sharpd is running, configure TC through vtysh, for example:

sharp tc dev eth0 source 192.168.100.0/24 destination 192.168.101.0/24 ip-protocol tcp src-port 8000 dst-port 8001 rate 20mbit

This will add a filter to interface eth0 (egress), capturing traffic:

Captured traffic will be limited in a class with maximum rate 20mbits/s.

The rate string can be a number alone (bits/s) or suffixed with any of the following:

bit
Kibit
kbit
mibit
mbit
gibit
gbit
tibit
tbit
Bps
KiBps
KBps
MiBps
MBps
GiBps
GBps
TiBps
TBps

Future

Traffic control will be very useful if it can be associated with routing entries, especially in terms of policy-based routing.

FlowSpec (defined in RFC 5575) is another promising application of traffic control in BGP, which also offers a fine-grained mitigation against flooding attacks.