Flowspec (VRF w/ Redirect)

Topology: ine-spv4

Load flowspec.vrf.redir.init.cfg

#IOS-XE
config replace flash:flowspec.vrf.redir.init.cfg
 
#IOS-XR (XRv1 only)
configure
load bootflash:flowspec.vrf.redir.init.cfg
commit replace
y

R1 and R7 are dual-stacked internet peers. Internet is running in an INET vrf in the core.

R8 is in a VRF called “ANALYZE”, in which it advertises a default route. Redirect traffic sourced from 1.1.1.1/32 and 2001:1::1/128 to this VRF for analysis. Use XR1 as the central policy control router using flowspec. BGP flowspec is already pre-configured.

Answer

#R2, R4
vrf definition ANALYZE
 rd 100:666
 route-target export 100:666
 route-target import 100:666
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family

#XR1
vrf INET
 address-family ipv4 flowspec
  import route-target
   100:100
  export route-target
   100:100
 !
 address-family ipv6 flowspec
  import route-target
   100:100
  export route-target
   100:100
!
router bgp 100
 vrf INET
  rd 100:100
  add ipv4 flowspec
  add ipv6 flowspec
!
class-map type traffic match-all CM_FLOWSPEC_V4_R1
 match source-address ipv4 1.1.1.1 255.255.255.255
 end-class-map
!
class-map type traffic match-all CM_FLOWSPEC_V6_R1
 match source-address ipv6 2001:1::1/128
 end-class-map
!
policy-map type pbr PM_FLOWSPEC_V4
 class type traffic CM_FLOWSPEC_V4_R1
 redirect nexthop route-target 100:666
!
policy-map type pbr PM_FLOWSPEC_V6
 class type traffic CM_FLOWSPEC_V6_R1
 redirect nexthop route-target 100:666
!
flowspec
 vrf INET
  address-family ipv4
   service-policy type pbr PM_FLOWSPEC_V4
  !
  address-family ipv6
   service-policy type pbr PM_FLOWSPEC_V6

Explanation

Using a flowspec redirect in a VRF is quite similar to doing a redirect with flowspec in the global table. The main differences are:

• You must define the “ANALYZE” VRF on all PEs

• You use redirect nexthop route-target instead of redirect ipv4|ipv6 nexthop

Notice the difference in the policy-maps on XR1 now:

policy-map type pbr PM_FLOWSPEC_V4
 class type traffic CM_FLOWSPEC_V4_R1
  redirect nexthop route-target 100:666
!
policy-map type pbr PM_FLOWSPEC_V6
 class type traffic CM_FLOWSPEC_V6_R1
  redirect nexthop route-target 100:666

The route-target is obtained by looking at R5’s export RT for the ANALYZE VRF:

If you don’t define the ANALYZE VRF on the other PEs, they will not have a RIB for the VRF, and therefore can’t redirect traffic into the VRF.

#R2, R4
vrf definition ANALYZE
 rd 100:666
 route-target export 100:666
 route-target import 100:666
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family

The PEs should learn the default route with a nexthop of R5, which is advertised by R8.

Verification

On the PEs, notice that the VPNv4/v6 flowspec NLRI has a 0.0.0.0 nexthop again:

Unlike the global redirect, which has the actual value of the IP to use to redirect the traffic to, a VRF redirect uses an extcommunity action instead of implementing the redirect with the BGP nexthop.

On PE2, we can see that the flowspec action is to redirect to the ANALYZE VRF:

If we run some pings to test this traffic out, we can see that the hits increment on these flowspec policies:

#R1
ping 7.7.7.7 so lo0 repeat 3
ping 2001:7::7 so lo0 repeat 3

We see ACL hits for both IPv4 and IPv6 on R8.

By the way, the IPv6 redirect to a VRF works on CSR1000v version 17.x as well, while a global nexthop IPv6 redirect does not work. But both of these work on version 16.9.8.