Flowspec (VRF w/ Redirect)
Last updated
Last updated
Topology: ine-spv4
Load flowspec.vrf.redir.init.cfg
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.
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:
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.
The PEs should learn the default route with a nexthop of R5, which is advertised by R8.
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:
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.