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
    ..

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 vrf0
   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 analyser
  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 analyser
    enabled true
    link-interface main
    link-vrf analyser
    ..
  ..
  routing
    bgp
      router-id 192.168.0.162
      as 65100
      neighbor 192.168.0.161
        remote-as 65100
        address-family
          ipv4-flowspec
          ..
        ..
      ..
    ..
  ..
vrf analyser
  interface xvrf main
    link-interface analyser
    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 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 analyser looks like, since a default route in table 257 has been installed to reach analyser.

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,
             > - selected route, * - FIB route
B>* 0.0.0.0/0 [20/0] is directly connected, analyser, 19:07:48

router> show ipv4-routes vrf analyser
             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,
             > - selected route, * - FIB route
VRF analyser:
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