GSoC 2022 FRRouting - Zebra Traffic Control
Project Summary
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.
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
: Queue Discipline
QDISC
determines how packets can get their chances to be
queued and then sent.
TCLASS
: Class
Only classful QDISC
s can own a bunch of
TCLASS
. By limiting some parameters, and applying the
discipline rules from QDISC
, it can thus do traffic
shaping.
TFILTER
: Filter
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:
QDISC
:htb
(Hierarchy Token Bucket)
This kind of QDISC
will apply Token Bucket
Filter algorithms to the queue.
Check tc-htb(8)
for more details.
TCLASS
:htb
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.
TFILTER
:flower
(Enhanced version offlow
)
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
).
It is then clear about TODOs when it comes to adding traffic control capability:
- message encoders / decoders between
zebra
and OS (QDISC
,TCLASS
,TFILTER
); - expose functions on dplanes (update the kernel objects with some contexts);
- abstract new states about the underlying kernel objects (call the underlying dplane operations);
- ZAPI message encoders / decoders between
zebra
and routing daemons; (manipulate the underlying states)
Pull Requests
- #11694 zebra: add basic traffic control API (merged)
- #11824 zebra: fix deadcodes in tc dplane & netlink (merged)
- #11832 zebra: trim unused tc dplane result values (merged)
- #11908 zebra: traffic control state management & ZAPI (open)
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:
- with IP protocol
tcp
- from prefix
192.168.100.0/24
- to prefix
192.168.101.0/24
- from ports
8000
- to ports
8001
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.