# 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.
