Configuration guide¶
In order to configure an IPv4 flowspec engine, use the following configuration. As of today, it is only possible to configure flowspec on default VRF. To enter the BGP flowspec sub-context:
vrouter running bgp# neighbor A.B.C.D remote-as AS
vrouter running bgp# neighbor A.B.C.D address-family ipv4-flowspec
vrouter running ipv4-flowspec# enabled true
- 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
Exemple:
routing bgp
as 5
neighbor 1.0.0.1 remote-as 2
neighbor 1.0.0.1 address-family ipv4 flowspec
..
In a similar way, following extract illustrates how IPv6 flowspec engine can be set:
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¶
One nice feature to use is the ability to apply flowspec to a specific interface, instead of applying it to the whole machine. Despite the following IETF draft idr flowspec interface set is not implemented, it is possible to manually limit flowspec application to some incoming interfaces. Actually, not using it can result to some unexpected behaviour like accounting twice the traffic, or slow down the traffic (filtering costs). To limit flowspec to one specific interface, use the following command, under BGP flowspec family.
routing bgp
address-family ipv4-flowspec
enabled true
local-install eth1
By default, Flowspec is activated on all interfaces. Installing it to a named interface will result in allowing only this interface. Reversely, enabling any interface will flush all previously configured interfaces.
Flowspec redirect IP¶
Flowspec provides also the ability for traffic to be redirected according to nexthop IP information. BGP flowspec entries have a BGP extended community option, that tells that the flowspec information should be redirected to the IP contained in the nexthop attribute of the BGP update received. Using that option to redirect traffic simply consists in ensuring that the IP information is reachable through using the routing table logic. For instance, create a static route
vrf main
routing static ipv4-route 2.2.2.2/32 next-hop 10.1.2.3
Flowspec redirect VRF¶
An other nice feature to configure is the ability to redirect traffic to a separate VRF. This feature does not go against the ability to configure Flowspec only on default VRF. Actually, when you receive incoming BGP flowspec entries on that default VRF, you can redirect traffic to an other VRF.
As remind, BGP flowspec entries have a BGP extended community that contains an RT, that is to say a route target. Finding out a local VRF based on route target consists in the following:
A configuration of each VRF must be done, with its RT set
Each VRF is being configured within a BGP VRF instance with its own RT list.
RT is defined in RFC 4364 and is an attribute associated to a VRF. In the VRF
context, incoming route entries have their own RT, and incoming BGP instance selects
for which VRF the incoming entry is imported, thanks to RT. route entries can be
duplicated, if one route target matches several VRs. In the flowspec context, only the
first VRF matching the incoming flowpsec entry will be selected.
The RT is encoded as BGP extended communities and is 8 byte long. The first 2 byte
contain the format of the RT, while the last 6 byte define the values of the RT.
Accepted format matches the following: A.B.C.D:U16, or U16:U32, U32:U16.
U32 and U16 respectively stand for 4 byte integer value and 2 byte short value. Values can either
be mapped to ASnumber of VXLAN identifier in case of overlay with vxlan tunnels. A.B.C.D stands
for an IP address, and can be mapped to bgp router identifier or tunnel endpoint.
As said before, a VRF can have a list of route targets. To configure the RT list, use the following command under BGP ipv4 unicast family:
vrf main
routing bgp
router-id 1.0.0.2
as 65500
neighbor 1.0.0.1 remote-as 65100
neighbor 1.0.0.1 address-family ipv4-flowspec enabled true
..
..
..
vrf monitor
routing bgp
as 65500
address-family ipv4-unicast
route-target redirect-import 11:22
In order to illustrate, if the route target configured in the flowspec entry is 10.1.1.2:65200,
then a BGP instance of a specific VRF with the same route target will be set. That VRF
will then be selected. The below full configuration example depicts how route targets are
configured and how VRF and interfaces configuration is done. Note that the VRs are mapped
on Linux Network Namespaces. For convey traffic through VRs, Cross-VRF interfaces are needed.
Basically, those are veth pair interfaces with specific properties, and without IP
attributes. More information in XVRF Interface types.
router> show config
vrf main
interface xvrf monitor
enabled true
link-interface main
link-vrf monitor
..
..
routing
bgp
router-id 192.168.0.162
as 65100
neighbor 192.168.0.161
remote-as 65100
address-family
ipv4-flowspec
..
..
..
..
..
vrf monitor
interface xvrf main
link-interface monitor
link-vrf main
..
..
routing
bgp
as 65200
address-family
ipv4-unicast
route-target
redirect-import 11:22
redirect-import 10.1.1.2:65200
redirect-import 10.1.1.2:65100
..
..
..
..
Flowspec redirect VRF for IPv6¶
In a similar way, BGP flowspec for IPv6 uses specific ipv6 extended communities
attributes, as defined in RFC 5701. The format of the community attribute is 20
bytes length, instead of 8 bytes length, and as such, can be used to store an IPv6
address and 2 additional extra-bytes. The format is defined as follows :<IPV6>:AS2B.
As defined in Dissemination of Flow Specification Rules for IPv6,
the BGP NLRI is sent with an extended IPv6 community attribute with
community type set to 0x00 and community sub type set to 0x0c. The BGP daemon
reads the incoming parameters and compares the extended IPv6 communnity with
locally configured IPv6 route targets. The first IPv6 RT matching the
incoming extended community will represent the bgp VRF instance where traffic will be
redirected to. Below example illustrates how this can be configured:
vrf main
routing bgp
router-id 1.0.0.2
as 65500
neighbor 1.0.0.1 remote-as 65100
neighbor 1.0.0.1 address-family ipv6-flowspec enabled true
..
..
..
vrf monitor
routing bgp
as 65500
address-family ipv6-unicast
ipv6-route-target redirect-import 11::22::0:0
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.
rt1> show bgp pbr ipset
About rule contexts, it is possible to know which rule has been configured to policy-route
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.
rt1> 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 policy-routed correctly can be checked like illustrated below. First of all, you must check whether the flowspec entry has been installed or not.
rt1> 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)
This means that the flowspec entry has been installed in a linux iptable named
match0x271ce00. Once you have confirmation it is installed, you can check
whether you find the associate entry by executing following command. You can also
check whether incoming traffic has been matched by looking at counter line.
rt1> 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
As you can see, the entry is present. Note that a linux iptable can be used to host several BGP flowspec entries.
In order to know where the matching traffic is redirected to, you have to look at the policy routing rules. The policy-routing is done by forwarding traffic to a routing table number. That routing table number is reached by using a linux iptable. The relationship between the routing table number and the incoming traffic is a MARKER that is set by the iptable referencing the linux ipset. In flowspec case, linux iptable referencing the linux ipset context have the same name.
So it is easy to know which routing table is used by issuing following command:
rt1> show bgp pbr iptable
IPtable match0x271ce00 action redirect (5)
pkts 1700000, bytes 158000000
table 257, fwmark 257
...
This allows to see where the traffic is forwarded to. Actually, in the case of redirect
VRF action, a route leak has been pushed to reach a separate VRF. Example below
depicts what a route to VRF monitor looks like, since a default route in table 257
has been installed to reach monitor.
router> show ipv4-routes table 257
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
B>* 0.0.0.0/0 [20/0] is directly connected, monitor, 19:07:48
router> show ipv4-routes vrf monitor
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 monitor:
S>* 0.0.0.0/0 [1/0] via 1.1.1.2, eth1, 19:25:04
C>* 1.1.1.0/24 is directly connected, eth1, 19:25:05