Flowspec (Global IPv4/6PE w/ CE Advertisement)
Last updated
Last updated
Topology: ine-spv4
Load flowspec.global.ce.adv.init.cfg
R1, R7, R8 and XR2 are all dual-stacked internet peers in the global table. IPv6 uses 6PE in the core.
XR2 is now the flowspec controller. It is advertising policies to drop traffic destined to 1.1.1.1/32, 20.20.20.20/32, 2001:1::1/128, and 2001::20:20:20:20/128.
Explain why the flowspec policies aren’t working, and find a way to fix it.
Flowspec uses validation rules to ensure that an eBGP peer cannot blackhole traffic belonging to another AS. The rules work as follows for destination-based policies:
If the AS_PATH attribute is empty, then accept the route.
This allows all flowspec policies to be accepted that were originated by an iBGP controller.
If there is a non-empty AS_PATH attribute on the flowspec NLRI, then the originating AS must match the originating AS for the associated unicast route.
This allows an eBGP peer to only blackhole traffic for which is it advertising unicast routes for.
Before disabling flowspec validation, we can see that XR1 only accepts routes from XR2 for which it is also advertising the associated unicast route. Let’s first look at the unicast routes advertised by XR2:
Now look at the ipv4/ipv6 flowspec table on XR1. XR1 is not marking the R1 routes as valid:
If we examine the route details, we can see that these do not pass the flowspec validity check:
Interestingly, this validation only occurs for destination-based flowspec policies. If we implement a source-based flowspec policy from XR2 for a prefix it does not own, we can see that XR2 accepts it.
This allows any AS to do source-based RTBH, allowing any AS to identify a bad actor. However, only the AS advertising a given prefix can do destination-based RTBH for that prefix.
We can also verify that flowspec validation works when XR2 advertises an aggregate instead of the specific /32 route:
We’ll now disable flowspec verification for XR2 on XR1. This will allow XR1 to accept the R1 policies and advertise them to R3.
Now R3 receives the routes, but it too is marking the paths as invalid. The flowspec validity check happens independently at each router.
If we look at the route details on R3, we can again see that the validity check is failing:
We must disable the validation check on routes received from XR2. Additionally, we can go ahead and disable the validation check on routes reflected by R3 on all other PEs:
If we look at any other PE, for example R2, we should see that all routes are accepted and all policies are locally installed:
If we source pings from R8 destined for R1, we should see drops on R5.
You’ll also notice that there is a knob to disable redirection validation per-peer:
This is simply another validation which is for a redirect-to-IP action. The redirect IP is checked against the BGP unicast routes. The originating ASN (last ASN in the path) for the redirect IP must match the ASN of the eBGP peer advertising the flowspec policy.
