# Flowspec (Global IPv4/6PE) **Topology**: ine-spv4

Load **flowspec.global.init.cfg** ``` #IOS-XE config replace flash:flowspec.global.init.cfg #IOS-XR (XRv1 only) configure load bootflash:flowspec.global.init.cfg commit replace y ``` R1, R7 and R8 are all dual-stacked internet peers in the global table. IPv6 uses 6PE in the core. Configure source-based RTBH within the core so that traffic sourced from 1.1.1.1/32 and 2001:1::1/128 is dropped. Also configure destination-based RTBH so that traffic destined to 8.8.8.9/32 and 2001:8::9/128 is dropped at the edge. Use XR1 as the central policy control router using flowspec. ## Answer ``` #R2, R4, R5 flowspec address-family ipv4 local-install interface-all address-family ipv6 local-install interface-all ! router bgp 100 add ipv4 flowspec nei 3.3.3.3 activate add ipv6 flowspec nei 3.3.3.3 activate #R3 router bgp 100 template peer-policy IBGP_FS route-reflector-client send-community both exit ! neighbor 19.19.19.19 inherit peer-session IBGP ! add ipv4 flowspec neighbor 2.2.2.2 activate neighbor 2.2.2.2 inherit peer-policy IBGP_FS neighbor 4.4.4.4 activate neighbor 4.4.4.4 inherit peer-policy IBGP_FS neighbor 5.5.5.5 activate neighbor 5.5.5.5 inherit peer-policy IBGP_FS neighbor 19.19.19.19 activate neighbor 19.19.19.19 inherit peer-policy IBGP_FS add ipv6 flowspec neighbor 2.2.2.2 activate neighbor 2.2.2.2 inherit peer-policy IBGP_FS neighbor 4.4.4.4 activate neighbor 4.4.4.4 inherit peer-policy IBGP_FS neighbor 5.5.5.5 activate neighbor 5.5.5.5 inherit peer-policy IBGP_FS neighbor 19.19.19.19 activate neighbor 19.19.19.19 inherit peer-policy IBGP_FS #XR1 router bgp 100 add ipv4 flowspec add ipv6 flowspec ! neighbor 3.3.3.3 remote-as 100 update-so lo0 add ipv4 flow add ipv6 flow ! class-map type traffic match-all CM_FLOWSPEC_V4_R1 match source-address ipv4 1.1.1.1 255.255.255.255 ! class-map type traffic match-all CM_FLOWSPEC_V4_R8 match destination-address ipv4 8.8.8.9 255.255.255.255 ! class-map type traffic match-all CM_FLOWSPEC_V6_R1 match source-address ipv6 2001:1::1/128 ! class-map type traffic match-all CM_FLOWSPEC_V6_R8 match destination-address ipv6 2001:8::9/128 ! policy-map type pbr PM_FLOWSPEC_V4 class type traffic CM_FLOWSPEC_V4_R1 drop class type traffic CM_FLOWSPEC_V4_R8 drop ! policy-map type pbr PM_FLOWSPEC_V6 class type traffic CM_FLOWSPEC_V6_R1 drop class type traffic CM_FLOWSPEC_V6_R8 drop ! flowspec address-family ipv4 service-policy type pbr PM_FLOWSPEC_V4 address-family ipv6 service-policy type pbr PM_FLOWSPEC_V6 ``` ## Explanation Flowspec is a BGP tool used to disseminate ACLs/firewall filters. A centralized controller defines ACL rules using QoS logic, and advertises this as BGP flowspec NLRI. All receiving routers will dynamically implement this as an ingress filter on their participating interfaces in hardware. The ability to turn the flowspec NLRI into hardware filters is called “ePBR” (enhanced Policy Based Routing). Flowspec allows us to use a traffic rate of “zero bytes/sec” which means to drop the traffic. This gives us a very elegant method of implementing S/D-RTBH without needing the clunky null0 dummy routes. Instead, traffic matches the source address or destination address in the flowspec policy, and is dropped as an ingress filter. In fact, we can be even more granular with our matching for RTBH, for example matching only small packets to/from the IP address, or matching packets with certain L4 characteristics to/from the IP address. This is controlled dynamically from the controller, so this is not signaled with BGP communities as we did previously with regular RTBH. IOS-XE routers are only able to implement flowspec policy on interfaces in hardware. We cannot propagate flowspec policies from IOS-XE. On XRv, we can only advertise flowspec policies, using the router as a controller. The XRv, without a true line card, cannot actually implement the policies in the data plane. This means that in our labs, XRv will always be the controller and XE will always be the PEs. Flowspec uses BGP SAFIs 133 (global unicast) and 134 (L3VPN unicast). It can be used with both IPv4 and IPv6, meaning it is supported for IPv4/uni, VPNv4/uni, IPv6/uni, and VPNv6/uni. Traffic policies are coded as TLVs within the NLRI. Several NLRI types exist to accomodate flexible and complex ACL logic. For example, type 1 and type 2 are used to code a dest/src prefix, type 4/5/6 codes layer 4 ports, and type 11 matches DSCP value. Essentially these all define different criteria for ACL matching. Here is a full list of NLRI type codes:

The *action* of the traffic policy is implemented as an extcommunity. * 0x8006 = police rate * A rate of 0 bytes per second means “drop” * 0x8009 = remark DSCP value * 0x0800 = mirror the traffic to an IP address This means that flowspec is able to be used for much more than simple S/D-RTBH behavior. Also note that flowspec allows for multiple policies to be defined, unlike when using QoS on an interface. In the case that multiple policies have been pushed via flowspec, all are applied to the interfaces. But only the first matching flowspec rule will be applied. It does not appear that you can control the order in which the flowspec policies are applied. To implement flowspec, we first must activate the address-family on all participating routers: ``` #R2, R4, R5 router bgp 100 add ipv4 flowspec nei 3.3.3.3 activate add ipv6 flowspec nei 3.3.3.3 activate #R3 router bgp 100 template peer-policy IBGP_FS route-reflector-client send-community both exit ! neighbor 19.19.19.19 inherit peer-session IBGP ! add ipv4 flowspec neighbor 2.2.2.2 activate neighbor 2.2.2.2 inherit peer-policy IBGP_FS neighbor 4.4.4.4 activate neighbor 4.4.4.4 inherit peer-policy IBGP_FS neighbor 5.5.5.5 activate neighbor 5.5.5.5 inherit peer-policy IBGP_FS neighbor 19.19.19.19 activate neighbor 19.19.19.19 inherit peer-policy IBGP_FS add ipv6 flowspec neighbor 2.2.2.2 activate neighbor 2.2.2.2 inherit peer-policy IBGP_FS neighbor 4.4.4.4 activate neighbor 4.4.4.4 inherit peer-policy IBGP_FS neighbor 5.5.5.5 activate neighbor 5.5.5.5 inherit peer-policy IBGP_FS neighbor 19.19.19.19 activate neighbor 19.19.19.19 inherit peer-policy IBGP_FS #XR1 router bgp 100 add ipv4 flowspec add ipv6 flowspec ! neighbor 3.3.3.3 remote-as 100 update-so lo0 add ipv4 flow add ipv6 flow ``` To configure the IOS-XE PEs to implement the flowspec policy on their interfaces, we simply enable flowspec on “all-interfaces.” This is all that is required on IOS-XE to start implementing S/D-RTBH at the edge! ``` #R2, R4, R5 flowspec address-family ipv4 local-install interface-all address-family ipv6 local-install interface-all ``` Note, to disable flowspec on individual interfaces, we can use the following command: ``` int gi2.10 ip flowspec disable ipv6 flowspec disable ``` The complexity comes on the controller (XRv). We use QoS CLI tools (MQC) to define the policy. First we have class-maps that match the traffic criteria. Note that we must use “match-all” when using the “class-map type traffic.” ``` #XR1 class-map type traffic match-all CM_FLOWSPEC_V4_R1 match source-address ipv4 1.1.1.1 255.255.255.255 ! class-map type traffic match-all CM_FLOWSPEC_V4_R8 match destination-address ipv4 8.8.8.9 255.255.255.255 ! class-map type traffic match-all CM_FLOWSPEC_V6_R1 match source-address ipv6 2001:1::1/128 ! class-map type traffic match-all CM_FLOWSPEC_V6_R8 match destination-address ipv6 2001:8::9/128 ``` Next, we match these classes in a PBR policy-map, and define the action. This is not very different from regular QoS. ``` #XR1 policy-map type pbr PM_FLOWSPEC_V4 class type traffic CM_FLOWSPEC_V4_R1 drop class type traffic CM_FLOWSPEC_V4_R8 drop ! policy-map type pbr PM_FLOWSPEC_V6 class type traffic CM_FLOWSPEC_V6_R1 drop class type traffic CM_FLOWSPEC_V6_R8 drop ``` Finally, we instruct the router to use these policy maps in flowspec: ``` #XR1 flowspec address-family ipv4 service-policy type pbr PM_FLOWSPEC_V4 address-family ipv6 service-policy type pbr PM_FLOWSPEC_V6 ``` ## Verification First we can verify the policy on the local controller, and verify that it is advertising the policies into BGP:

To inspect the details of the NLRI, we can simply copy+paste the NLRI syntax:

Above, we can see that the traffic-rate is 0. The first number is the ASN (100). This appears to be purely informational. Looking at a pcap of the flowspec advertisement clears this up. Here’s an IPv4 flowspec Update. We can see how the NLRI types are used to define the match criteria, and how the extcommunity is used to define the action:

Here’s an IPv6 flowspec Update which looks very similar:

On the PEs, we can confirm that we receive these policies via BGP:

Notice that there is no nexthop, because the nexthop does not really matter here. This is not a route update that needs to point to a nexthop. It’s just a policy instruction. We can only see the details for all NLRIs at once on IOS-XE, using **show bgp ipv4|ipv6 flowspec detail**:

We can see that these policies were imported into the local flowspec table on the PE:

To verify that this is working, we can source pings from R1 (1.1.1.1 and 2001:1::1), or send pings to R8 (8.8.8.9 and 2001:8::9). We should see drops on the PE. The PE is implementing both source-based and destination-based RTBH at the edge:

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/bgp/flowspec-global-ipv4-6pe.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.