Configuration guide¶

The following configuration activates IPv4 flowspec for the A.B.C.D neighbor:

vsr running vrf main# routing bgp
vsr running bgp# neighbor A.B.C.D remote-as AS
vsr running bgp# neighbor A.B.C.D address-family ipv4-flowspec
vsr running ipv4-flowspec# enabled true

Note

Flowspec can only be configured in the default L3VRF.

AS: The remote Autonomous system ID associated with neighbor
A.B.C.D: The remote BGP peer to peer with BGP flowspec address family support

Example:

routing bgp
    as 5
    neighbor 1.0.0.1 remote-as 2
    neighbor 1.0.0.1 address-family ipv4 flowspec
    ..

Similarly, the following extract activates IPv6 flowspec for the 10.125.0.2 neighbor:

vrf main
  routing bgp
    as 65500
    neighbor 10.125.0.2 remote-as AS
    neighbor 10.125.0.2 address-family ipv6-flowspec enabled true

Flowspec Per Interface¶

Flowspec is enabled on all the interfaces of the VRF where it is configured by default. To avoid performance problems, and double-accounting the traffic, we recommend limiting flowspec to one specific interface, using the local-install command:

vsr running config# vrf main
vsr running vrf main# interface physical eth1
vsr running physical eth1#! port pci-b0s3
vsr running physical eth1# ipv4 address 192.168.0.162/24
vsr running physical eth1# .. ..
vsr running vrf main# routing bgp
vsr running bgp#! router-id 192.168.0.162
vsr running bgp#! as 65100
vsr running bgp# neighbor 192.168.0.161
vsr running neighbor 192.168.0.161#! remote-as 65100
vsr running neighbor 192.168.0.161# address-family
vsr running address-family# ipv4-flowspec
vsr running ipv4-flowspec# local-install eth1

Note

After local-install is changed and committed, flowspec rules will be flushed from the previously configured interfaces.

Using flowspec to redirect traffic to an IP address¶

BGP flowspec entries have an extended community option telling that traffic should be redirected to the next hop network address of the BGP update received. To be able to achieve this redirection, this IP address should be routable. For instance, a static route can be added for this purpose.

vsr running config# vrf main
vsr running vrf main# interface physical eth2
vsr running physical eth2#! port pci-b0s4
vsr running physical eth2# ipv4 address 1.1.1.1/24
vsr running physical eth2# .. ..
vsr running vrf main# routing
vsr running routing# static
vsr running static# ipv4-route 2.2.2.2/32 next-hop 1.1.1.100
vsr running static# ..
vsr running routing# bgp
vsr running bgp#! router-id 192.168.0.162
vsr running bgp#! as 65100
vsr running bgp# neighbor 192.168.0.161
vsr running neighbor 192.168.0.161#! remote-as 65100
vsr running neighbor 192.168.0.161# address-family
vsr running address-family# ipv4-flowspec
vsr running ipv4-flowspec# .. .. ..

Using flowspec to redirect traffic to an L3VRF¶

Another BGP flowspec option named redirect extended community tells that traffic should be routed to a separate L3VRF routing domain. For a given L3VRF to match incoming traffic, a BGP L3VRF instance must be set up with the configured RT value encoded in the BGP redirect extended community:

vsr running config# vrf main
vsr running vrf main# routing bgp
vsr running bgp#! router-id 192.168.0.162
vsr running bgp#! as 65100
vsr running bgp# neighbor 192.168.0.161
vsr running neighbor 192.168.0.161#! remote-as 65100
vsr running neighbor 192.168.0.161# address-family
vsr running address-family# ipv4-flowspec
vsr running ipv4-flowspec# .. .. ..
vsr running bgp# .. ..
vsr running vrf main# l3vrf l3vrfmonitor
vsr running l3vrf l3vrfmonitor#! table-id 10
vsr running l3vrf l3vrfmonitor# routing bgp
vsr running bgp# as 65500
vsr running bgp# address-family ipv4-unicast
vsr running ipv4-unicast# route-target redirect-import 11:22
vsr running ipv4-unicast# commit

Above example indicates that traffic matching BGP update with the redirect extended community set to 11:22 will be routed to l3vrfmonitor L3VRF.

Flowspec redirect VRF for IPv6¶

BGP flowspec for IPv6 uses a specific redirect IPv6 option that redirects IPv6 traffic to a separate L3VRF routing domain.

Flowspec Monitor and troubleshooting¶

You can monitor policy routing objects by using one of the following commands. Those command rely on the filtering contexts configured from BGP, and get the statistics information retrieved from the underlying system. In other words, those statistics are retrieved from linux netfilter.

vsr> show bgp pbr ipset

About rule contexts, it is possible to know which rule has been configured to redirect some specific traffic. The first table identifier displayed on the former show bgp pbr iptable command can be used in the latter command to know about routing information.

vsr> show bgp pbr iptable

You can troubleshoot BGP flowspec, or BGP policy-based routing. Ensuring that a flowspec entry has been correctly installed and that incoming traffic is redirected correctly can be checked as illustrated below. First of all, you must check whether the flowspec entry has been installed or not.

vsr> show bgp ipv4 flowspec prefix 5.5.5.2/32
 BGP flowspec entry: (flags 0x418)
   Destination Address 5.5.5.2/32
   IP Protocol = 17
   Destination Port >= 50 , <= 90
   FS:redirect VRF RT:255.255.255.255:255
   received for 18:41:37
   installed in PBR (match0x271ce00)

The emphasized line shows that the flowspec entry named match0x271ce00 has been installed. You can check whether you find the associate entry by executing the following command. You can also check whether incoming traffic has been matched by looking at the counter line.

vsr> show bgp pbr ipset set match0x271ce00
   IPset match0x271ce00 type net,port
     to 5.5.5.0/24:proto 6:80-120 (8)
        pkts 1000, bytes 1000000
     to 5.5.5.2:proto 17:50-90 (5)
        pkts 1692918, bytes 157441374

rt1> show bgp pbr iptable match0x271ce00
   IPtable match0x271ce00 action redirect (5)
     pkts 1700000, bytes 158000000
     table 10, fwmark 257

As you can see, the entry is present. In order to know where the matching traffic is redirected to, the policy routing is done by forwarding traffic to a routing table number. The relationship between the routing table number and the incoming traffic is done in the above show bgp pbr iptable command output, where table and fwmark values are associated.

In the case of a L3VRF redirect action, a policy route rule is created to send incoming traffic to the routing table of the given L3VRF.

vsr> show state vrf main routing policy-based-routing
 policy-based-routing
     ipv4-rule 0 action lookup local
     ipv4-rule 1000 match l3vrf action lookup l3vrf-table
     ipv4-rule 32765 match mark 0x101 action lookup 10
     ipv4-rule 32766 action lookup main
     ipv4-rule 32767 action lookup default
     ipv6-rule 0 action lookup local
     ipv6-rule 1000 match l3vrf action lookup l3vrf-table
     ipv6-rule 32766 action lookup main
     ..

The example below depicts what contains the routing table of the l3vrfmonitor L3VRF looks like.

router> show ipv4-routes l3vrf l3vrfmonitor
 Codes: K - kernel route, C - connected, S - static, R - RIP,
        O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
        T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
        F - PBR, f - OpenFabric,
        > - selected route, * - FIB route, q - queued route, r - rejected route

VRF l3vrfmonitor:
K * 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 19:31:44
S>* 0.0.0.0/0 [1/0] via 10.1.1.100, eth3, 19:25:04
C>* 10.1.1.0/24 is directly connected, eth3, 19:25:05

In the case of redirect IP action, a similar policy route rule is pushed to steer incoming traffic to routing table indicated by the below dump:

vsr> show bgp pbr iptable
   IPtable match0x272ce00 action redirect (6)
     pkts 2700000, bytes 258000000
     table 258, fwmark 258

As can be seen, the table-id number is 258. The table has been reserved by flowspec to handle routing traffic matching all flowspec operations requesting to redirect traffic to a given IP address.

The example below depicts what contains the routing table 258:

router> show ipv4-routes table 258
 Codes: K - kernel route, C - connected, S - static, R - RIP,
        O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
        T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
        F - PBR, f - OpenFabric,
        > - selected route, * - FIB route, q - queued route, r - rejected route

VRF default table 258:
S>  0.0.0.0/0 [1/0] via 2.2.2.2 (recursive), 19:35:04
  *                via 1.1.1.100, eth2, 19:35:04

Note

A range of table-id is reserved for flowspec operations when redirect IP actions have to be handled. That range goes from table-id number 256 to table-id number 100256. This implies that the table-id chosen when creating a L3VRF instance can not be chosen in that range.