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.
See also
RFC 4360 for details about the RT encoding.
The following configuration example depicts how a RT list can also be configured on a L3VRF BGP instance.
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# interface physical eth3
vsr running physical eth3#! port pci-b0s6
vsr running physical eth3# ipv4 address 10.1.1.2/24
vsr running physical eth3# .. ..
vsr running l3vrf l3vrfmonitor# routing
vsr running routing# static
vsr running static# ipv4-route 0.0.0.0/0 next-hop 10.1.1.100
vsr running static# ..
vsr running routing# bgp
vsr running bgp# as 65200
vsr running bgp# address-family
vsr running address-family# ipv4-unicast
vsr running ipv4-unicast# route-target
vsr running route-target# redirect-import 11:22
vsr running route-target# redirect-import 10.1.1.2:65200
vsr running route-target# redirect-import 10.1.1.2:65100
vsr running route-target# ..
vsr running ipv4-unicast#
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.
See also
RFC 5701 for details about the BGP ipv6 extended community format encoding.
The redirect IPv6 extended community must be configured in the L3VRF instance so that incoming traffic is routed to that L3VRF instance. The below example illustrates how this can be configured:
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# ipv6-flowspec
vsr running ipv6-flowspec# .. .. ..
vsr running bgp# .. ..
vsr running vrf main# l3vrf l3vrfmonitor
vsr running l3vrf l3vrfmonitor#! table-id 10
vsr running l3vrf l3vrfmonitor# interface physical eth3
vsr running physical eth3#! port pci-b0s6
vsr running physical eth3# ipv6 address 11:22::2/64
vsr running physical eth3# .. ..
vsr running l3vrf l3vrfmonitor# routing
vsr running routing# static
vsr running static# ipv6-route ::/0 next-hop 11:22::254
vsr running static# ..
vsr running routing# bgp
vsr running bgp# as 65200
vsr running bgp# address-family
vsr running address-family# ipv6-unicast
vsr running ipv6-unicast# ipv6-route-target redirect-import 11:22::0:0
vsr running ipv6-unicast#
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.