> For the complete documentation index, see [llms.txt](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/bgp/flowspec-global-ipv4-6pe-w-redirect.md).
# Flowspec (Global IPv4/6PE w/ Redirect)
**Topology**: ine-spv4
Load **flowspec.global.redir.init.cfg**
```
#IOS-XE
config replace flash:flowspec.global.redir.init.cfg
#IOS-XR (XRv1 only)
configure
load bootflash:flowspec.global.redir.init.cfg
commit replace
y
```
R1 and R7 are all dual-stacked internet peers in the global table. IPv6 uses 6PE in the core.
All flowspec BGP peerings are already pre-established.
R8 is an “analysis box.” Your task is to redirect DDoS traffic sourced from 1.1.1.1/32 and 2001:1::1/128 to R8 (8.8.8.8 and 2001:8::8) using flowspec. XR1 is the flowspec controller.
## Answer
```
#XR1
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 ipv4 nexthop 8.8.8.8
end-policy-map
!
policy-map type pbr PM_FLOWSPEC_V6
class type traffic CM_FLOWSPEC_V6_R1
redirect ipv6 nexthop 2001:8::8
end-policy-map
!
flowspec
address-family ipv4
service-policy type pbr PM_FLOWSPEC_V4
!
address-family ipv6
service-policy type pbr PM_FLOWSPEC_V6
```
## Explanation
Flowspec can not only drop/police traffic, but it can redirect traffic. This is very useful for designs in which you have a DDoS analysis device. Instead of just simply dropping the traffic, you can redirect traffic to this analysis box.
To do so, we simply use a “redirect” action on the policy-map, instead of a “drop” or “police” action. First we define the traffic (sourced from R1):
```
#XR1
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
```
Then we define the “redirect” action in the policy-map:
```
#XR1
policy-map type pbr PM_FLOWSPEC_V4
class type traffic CM_FLOWSPEC_V4_R1
redirect ipv4 nexthop 8.8.8.8
end-policy-map
!
policy-map type pbr PM_FLOWSPEC_V6
class type traffic CM_FLOWSPEC_V6_R1
redirect ipv6 nexthop 2001:8::8
end-policy-map
```
Finally, the service-policy is applied to the flowspec process:
```
#XR1
flowspec
address-family ipv4
service-policy type pbr PM_FLOWSPEC_V4
!
address-family ipv6
service-policy type pbr PM_FLOWSPEC_V6
```
## Verification
On R2, notice that the flowspec NLRIs now have a nexthop. Previously, these all had a nexthop of 0.0.0.0, because the action was to drop the traffic.
We can verify in the flowspec table on R2 that the action is now to redirect to this nexthop address, instead of dropping the traffic:
If we ping 7.7.7.7 from R1, we should see hits on the IPv4 flowspec policy:
```
#R1
ping 7.7.7.7 so lo0 repeat 3
```
Now R2 shows 3 hits for the IPv4 flowspec policy:
Additionally, we see ACL log entries on R8, proving that it received the traffic. (An ACL was applied to Gi2.58 in the initial config file). Use **term mon** on R8, or **show logging**.
Notice that on R1, the pings time out completely. The packet is not copied, as in R-SPAN. Instead it is literally redirected to R8.
Let’s try it with IPv6 now:
```
#R1
ping 2001:7::7 so lo0 repeat 3
```
We again see logs on R8:
```
*Mar 30 14:54:08.166: %FMANFP-6-IPV6ACCESSLOGDP: R0/0: fman_fp_image: list LOG_ICMPV6 permitted icmpv6 2001:1::1 -> 2001:7::7 (0/32768), 1 packet
```
Note that on version 17.x I found the pings actually worked. This must be a bug. But on 16.9.8 the IPv6 redirect is working properly.