Flowspec
Last updated
Last updated
BGP Flowspec is an extension to BGP, defined in RFC 5575. It adds new address-families to BGP: ipv4/ipv6 flowspec and vpnv4/vpnv6 flowspec. The purpose of this new address family is to share traffic flow specifications with all routers in your internal network.
Flowspec is a much more powerful and advanced version of RTBH. In the previous article, we accomplished source-based and destination-based RTBH by implementing a null0 static route on all routers, and pointing the traffic we want to drop to this null route.
With Flowspec we can accomplish the same thing but much more elegantly. With flowspec we don’t need to configure static routes and redistribute static routes into BGP. We define the flow we want to drop (i.e. source address = 1.1.1.1), disseminate that information via MP-BGP to all PE routers, and all PE routers will automatically perform the action.
In addition to matching on source/destionation IPv4 address, we can essentially match on anything we can match with a class-map. This incldues L4 ports, IP precendence, TCP flags, etc. In fact we can also rate-limit instead of drop traffic altogether. The BGP NLRI defines the matching criteria, and an extended community defines the action (drop, police, etc).
In a way, Flowspec allows you to use the flexibility of QoS tools and dissemintate the policy through BGP. All routers will automatically install the policy or “rules” learned through BGP into their own forwarding plane.
Let’s use the same topology as the last article (RTBH). First, remove all the static routes and static redistribution into BGP on P4.
In this lab, P4 will simply be the Flowspec “server” or distribution point. We’ll configure all policies on P4, but P4 will not have to act on the policies itself, since it is not on the internet edge.
On all PEs, configure flowspec to locally install policies learned via BGP on all interfaces. On P4, we’ll simply enable flowspec.
We’ll now enable the ipv4 flowspec BGP address-family so that all PE routers will learn policies defined on P4.
All PEs should have a neighborship with P4 now for the flowspec address-family, but with no routes learned yet:
Let’s configure a simple policy on P4 to drop any traffic sourced from 100.1.1.2 (CE1)
This CLI syntax should look familiar, as it is practically the same as configuring QoS. Flowspec can only use a service-policy type of pbr, at least on XRv. We use the class-map to match the traffic we want to control, then use the policy map to define the action we take, which is drop. Finally we associate this policy-map with flowspec, and it is automatically signalled into BGP. Optionally you can use the local keyword on the service-policy to only install the policy locally and not redistribute it into BGP.
On PE1 you should see that the flowspec policy was automatically received and installed.
Let’s try pinging CE3 from CE1.
PE1 shows us the number of packets and bytes that have matched this policy.
Isn’t this more straightforward than manually-configured RTBH? Flowspec allows us to essentially disseminate firewall policy and have routers automatically install the policy as soon as we commit. This makes Flowspec very powerful but perhaps a bit dangerous, as it was the source of a large CenturyLink outage back in 2020. (https://www.thousandeyes.com/blog/centurylink-level-3-outage-analysis)
Let’s view a pcap of the BGP NLRI that defines this policy:
Notice that flowspec has its own NLRI which defines filter information. Here we see that we are using a source prefix filter for 100.1.1.2/32. Also notice that the drop instruction is coded as a shaper rate of 0 Mbps. This is communicated using an extended community. By default, XR will send communities to iBGP neighbors, but if we were using IOS-XE to define the policy, we would have needed to specify send-community extended on the iBGP neighbor(s).
Let’s now rate-limit traffic sourced from 100.1.1.2/32 instead of dropping it completely.
PE1 immediately receives a new BGP update and installs the policy.
When testing, the policing doesn’t appear to be applied. I believe this may be a limitation of the CSR1000v platform.
What if a traffic stream matches multiple policies? Let’s say policy 1 says to drop the traffic but policy 2 says to police it at 100meg. Which takes effect?
Let’s try it out by changing our 100.1.1.2/32 source police back to drop, and configuring an ICMP policy that polices at 1meg.
PE1 now has the two policies.
If we ping from CE1, the traffic is dropped. This is because the first match is the policy that takes effect. The drop policy is higher than the police policy.
While I would not suggest memorizing this, it may be good to be familiar with the match options.
Destination Prefix
Source Prefix
IP Protocol
Port
Destination Port
Source Port
ICMP type
ICMP code
TCP flags
Packet length
DSCP value
Fragment
Drop
Police
Redirect VRF
Set DSCP
Redirect IPv4 or IPv6 next-hop
Flowspec policies are only implemented on ingress traffic. This makes sense, as you want to take action against traffic as it enters your network from the internet edge. Once it passes through your network and is now egressing your PE, it is a little late to apply policy.
In comparison, source-based RTBH works on ingress traffic as well by using uRPF. Destination-based RTBH takes action against ingress traffic but by examining the destination address, as it does under normal IP routing.
Each router platform will have a different number of supported TCAM entries for flowspec. I’ve seen numbers around 1500 - 8000. This means you will likely not be able to have more than 8000 flowspec policy entries at a given time.
Flowspec is a very powerful tool which uses MP-BGP to dissemeniate information on traffic flow specifications. These dictate match criteria (i.e. source address=100.1.1.2/32) and an action (i.e. drop or police).
This is a much cleaner way of preforming RTBH compared to the previous article. Instead of static null0 routes and uRPF, we can simply use the QoS tools that we are familiar with and pair this with BGP to automatically install policy on all routers in our network.
RFC 5575 https://datatracker.ietf.org/doc/html/rfc5575
https://www.youtube.com/watch?v=Pu9duyPjaxM&ab_channel=DecodingPackets
https://www.youtube.com/watch?v=TVIcvHS6hp4&ab_channel=DecodingPackets
