Flowspec (Global IPv4/6PE w/ Redirect) T-Shoot
Last updated
Last updated
Topology: ine-spv4
Load flowspec.global.redir.tshoot.cfg in the EVE INE SPv4 topology.
R1 and R7 are all dual-stacked internet peers in the global table. IPv6 uses 6PE in the core.
R8 is an “analysis box.” A flowspec policy exists that redirects traffic sourced from R1 at 1.1.1.1 to R8. R8 should then route this back to the core and allow the traffic to work, however this is not the case.
Find a way to fix this so that R1 can still ping R7, but it is “scrubbed” through R8.
When you enable flowspec on a client, you must allow the flowspec policy to be installed on all interfaces. This creates a problem for hairpinning traffic to a scrubbing device. R8 is routing the traffic back to R5, but R5 will perform flowspec on that received traffic and loop it right back to R8.
In order to fix this we must disable flowspec on some interfaces. First we disable flowspec on Gi2.58 which is obvious, but that is still not enough. We are not running MPLS, so R5 will just IP forward the packet back to R4, which will also perform flowspec and redirect the traffic back to R8 again. Essentially, we must turn off flowspec on all of our internal core links, and only run flowspec on the external-facing links towards customers.
Using a scrubbing device like this is useful for detecting attacks that are more granular than just L3/L4 information, which the routers are limited to. Sometimes a scrubber is needed if the L7 payload needs to be inspected.
A few side notes that are good to understand about flowspec:
You can have multiple actions, such as rate-limit, DSCP mark, and redirect. (They are performed in that order). But you cannot redirect to a VRF and also redirect to a certain IP within that VRF.
Flowspec filtering is implemented after netflow collecting and after ACL processing on the inbound interface.
If you wish to also run flowspec in the egress direction, you can use ip flowspec output enable on the interface. But usually it doesn’t make sense to do this.
