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.