Flowspec (Global IPv4/6PE w/ CE Advertisement)

Topology: ine-spv4

Load flowspec.global.ce.adv.init.cfg

#IOS-XE
config replace flash:flowspec.global.ce.adv.init.cfg
 
#IOS-XR (XRv1, XRv2)
configure
load bootflash:flowspec.global.ce.adv.init.cfg
commit replace
y

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.

Answer

#R2, R4, R5
router bgp 100
 add ipv4 flowspec
  neighbor 3.3.3.3 validation off
 add ipv6 flowspec
  neighbor 3.3.3.3 validation off

#R3
router bgp 100
 add ipv4 flowspec
  neighbor 19.19.19.19 validation off
 add ipv6 flowspec
  neighbor 19.19.19.19 validation off

#XR1
router bgp 100
 neighbor 10.19.20.20
  address-family ipv4 flowspec
   validation disable
 !
 neighbor 2001:10:19:20::20
  address-family ipv6 flowspec
   validation disable

Explanation

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.

#XR2
class-map type traffic match-all CM_R7_V4
 match source-address ipv4 7.7.7.7 255.255.255.255
 end-class-map
!
policy-map type pbr PM_FLOWSPEC_V4
 class type traffic CM_R7_V4
  drop

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:

router static
 address-family ipv4 unicast
  20.20.20.0/24 Null0
 !
!
router bgp 20
 address-family ipv4 unicast
  network 20.20.20.0/24
  no network 20.20.20.20/32

Verification

We’ll now disable flowspec verification for XR2 on XR1. This will allow XR1 to accept the R1 policies and advertise them to R3.

#XR1
router bgp 100
 neighbor 10.19.20.20
  address-family ipv4 flowspec
   validation disable
 !
 neighbor 2001:10:19:20::20
  address-family ipv6 flowspec
   validation disable

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:

#R2, R4, R5
router bgp 100
 add ipv4 flowspec
  neighbor 3.3.3.3 validation off
 add ipv6 flowspec
  neighbor 3.3.3.3 validation off

#R3
router bgp 100
 add ipv4 flowspec
  neighbor 19.19.19.19 validation off
 add ipv6 flowspec
  neighbor 19.19.19.19 validation off

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.

#R8
ping 1.1.1.1 so lo0 repeat 3
ping 2001:1::1 so lo0 repeat 3

Redirect Validation

You’ll also notice that there is a knob to disable redirection validation per-peer:

#IOS-XR
neighbor 1.1.1.1
 add ipv4 flow
  validation redirect disable

#IOS-XE
add ipv4 flow
 neighbor 1.1.1.1 validation redirect-off

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.

Answer

Explanation

Verification

Redirect Validation

Further Reading