06-07-2014 01:55 PM - edited 08-08-2019 08:04 AM
BGP flow spec is a new tool that can be used to assist in DDOS mitigation in a dynamic fashion, levering BGP.
When I first started working and looking at BGP-FS I was a bit confused and in this article I would like to try and unravvle some of the specifics of BGP-FS, what you can do with it and how it works.
Conceptually in this picture:
DDOS mitigation with the help of BGP is generally done via RTBH (remote triggered blackhole). And this comes basically in 2 key flavors: Source and Destination based.
The concept is that a BGP edge speaker has a static route defined to a "special next hop" to null0.
From a central point we inject a new route for a particular destination (eg our affected webserver) with a next hop pointing to that special next hop. This means that now at our border routers, our webserver address is set to a next hop, and this next hop is drop, and we prevent this traffic from hitting our server. This protects it nicely. But it removes the ability to reach this server completely!
The source based model is a similar concept whereby we KNOW where an attack comes from and now we send in a bgp path for that source with the special next hop, which then points to null.
Now when we use uRPF (reverse path forwarding), when a packet from that suspect source comes in, we apply RPF, we find the nexthop set to null0/discard. This would make RPF fail and we drop the packet from that host (or subnet for that matter).
Both options work great, but are big hammers.
BGP flowspec allows for a more granular appraoch and effectively construct instructions to match a particular flow with source AND destination, and L4 parameters and packet specifics such as length, fragment etc, and allow for a dynamic installation of an action at the border rotuers to either:
Cool. Now that we got that theory out of the way, how about Flowspec then, what does it do and how is it different?!
This conceptually describes how flowspec works:
So instead of sending/injecting a route for our server or server subnet with a special community that the border routers will associated with a nexthop to drop in their route policy language, in this case we are sending the new flowspec attribute format down to the border routers instructing them to create a sort of ACL with class-map and policy-map to implement this rule that we are advertising!
Very nifty, am lovin it. So in order to do that, we need to extend the BGP protocol a bit, and this is how the RFC is defining that approach:
BGP FS adds a new NLRI (network layer reachability info) to the BGP protocol:
NLRI defined (AFI=1, SAFI=133)
It adds the following packet/attribute format:
It allows for the following parameters to be defined:
6.Source Port (+1 component)
7.ICMP Type (asr9k has support for this yet, CRS does also)
8.ICMP Code (asr9k has support for this yet, CRS does also)
9.TCP Flags (asr9k supports lower byte, crs can not look at all bits)
10.Packet length
11.DSCP
12.Fragment
The actions that can be associated to a flow that we matched on by the parameters specified above are encoded as follows:
And the available actions that we can define are:
So with these new rules we can define a prefix or prefix set and not just that, we can base it on L3 source, L3 dest, its L4 specifics and even on packet length and L3 header options such as fragments! Then we can specify what actions we want to associate with that flow, redirect it, remark it, drop it or police it. And that is the full flow info.
All actions are supported by both CRS and ASR9000.
Ok this is all awesome, now that we got the theory out of the way, you want to go set it up I am sure!
In BGP-FS there is a client and a server. What that effectively means is that there is a device that injects the new flowspec entry (for the lack of a better word I guess) and there is a device (BGP speaker) that receives that NRLI and has to implement something in the hardware forwarding to act on that instruction.
So the device sending or injecting the NRLI is what I call the server, and the device that receive the NRLI and programs the hardware forwarding is called the client.
Visually:
In this concept the server in the grey box injects the flowspec NRLI and the client in the right box receives the information, sends it to the flow spec manager, configures the ePBR (enhance Policy based routing) infrastructure who then in turn programs the hardware from the underlaying platform in use.
The server is configured either via CLI or XML to provide that entry for NRLI injection.
Note that XRv, virtual XR, can be a Server, it can inject those NRLI's for an asr9000 or CRS to act on those. Obviously XRv, not having a hardware forwarding layer is not a client
conceptually
BGP
applicable to both client and server, we need to enable the new address family for advertisement:
router bgp 100
address-family ipv4 flowspec
! Initializes the global address family
address-family ipv6 flowspec
!
neighbor 1.1.1.1
remote-as 100
address-family ipv4 flowspec
! Ties it to a neighbor configuration
address-family ipv6 flowspec
!
Interface
You can disable flowspec on the interface as follows:
Interface gigabit0/0/0/0
ipv4 flowspec disable
!
requires no special config other then a flowspec enabled peer.
The server side configuration includes the policy-map definition and the association to the ePBR config consists of 2 portions, the class definition, and using that class in ePBR to define the action.
Classification
class-map type traffic match-all <class-name>
<match statement> #Any combination of tuples 1-13 match statements goes here.
end-class-map
!
!
Tuple definition possibilities:
#Type 1: match destination-address {ipv4| ipv6} <IPv4/v6 address>/<mask-length>
#Type 2: match source-address {ipv4| ipv6} <IPv4/v6 address>/<mask-length>
#Type 3: match protocol { <value> | <min_value> - <max_value> }
<!In case of IPv6, it will map to last next-header >
#Type 4: create two class-maps one with source-port and another with destionation-port
match source-port { <value> | <min_value> - <max_value> }
match destination-port { <value> | <min_value> - <max_value> }
<! Applicable only for TCP and UDP protocol !>
#Type 5: match destination-port { <value> | <min_value> - <max_value> }
#Type 6: match source-port { <value> | <min_value> - <max_value> }
#Type 7: match {ipv4 | ipv6} icmp-type { <value> | <min_value> - <max_value>}
#Type 8: match {ipv4 | Ipv6} icmp-code { <value> | <min_value> - <max_value>}
#Type 9: match tcp-flag <value> bit-mask <mask-value>
#Type 10: match packet length { <value> | <min_value> - <max_value> }
#Type 11: match dscp { <value> | <min_value> - <max_value> }
match ipv6 traffic-class { <value> | <min_value> - <max_value> }
[for providing 8 bit traffic class value]
#Type 12: match fragment-type {dont-fragment, is-fragment, first-fragment, last-fragment}
#Type 13: match ipv6 flow-label { <value> | <min_value> - <max_value> }
policy-map type pbr <policy-name>
class type traffic <class-name>
<action> #Any one of the extend community action listed below
class class-default
end-policy-map
ACTIONS:
##Traffic rate:
police rate < > | drop
#Traffic action:
sample-log
#Traffic marking:
set dscp <6 bit value> |
set ipv6 traffic-class <8 bit value>
#VRF redirect based on route-target:
redirect {ipv6} extcommunity rt <route_target_string>
# Redirect IP nexthop support
redirect {ipv6} next-hop <ipv4/v6 address> {ipv4/v6 address}
The following ties the flowspec to the PBR policies defined earlier.
flowspec
[local-install interface-all]
address-family ipv4
[local-install interface-all]
service-policy type pbr <policy-name>
service-policy type pbr <policy-name>
address-family ipv6
[local-install interface-all]
service-policy type pbr <policy-name>
service-policy type pbr <policy-name>
!
!
vrf <vrf-name>
address-family ipv4
[local-install interface-all]
service-policy type pbr <policy-name>
service-policy type pbr <policy-name>
address-family ipv6
[local-install interface-all]
service-policy type pbr <policy-name>
service-policy type pbr <policy-name>
!
!
!
Example use case/configuration:
Target:
all packets to 10.0.1/24 from 192/8 and destination-port {range [137, 139] or 8080, rate limit to 500 bps in blue vrf and drop it in vrf-default. Also disable flowspec getting enabled on gig 0/0/0/0.
Associated copy paste config:
class-map type traffic match-all fs_tuple
match destination-address ipv4 10.0.1.0/24
match source-address ipv4 192.0.0.0/8
match destination-port 137-139 8080
end-class-map
!
!
policy-map type pbr fs_table_blue
class type traffic fs_tuple
police rate 500 bps
!
!
class class-default
!
end-policy-map
policy-map type pbr fs_table_default
class type traffic fs_tuple
drop
!
!
class class-default
!
end-policy-map
flowspec
local-install interface-all
address-family ipv4
service-policy type pbr fs_table_default
!
!
vrf blue
address-family ipv4
service-policy type pbr fs_table_blue local
!
!
!
!
Interface GigabitEthernet 0/0/0/0
vrf blue
ipv4 flowspec disable
BGP Flowspec and local QoS configuration
When flowspec is implemented on an interface that is also having local QoS configuration, local config will come before flowspec processing.
Local config will police and dscp-mark the packets and pass them to flowspec.
Flowspec will then do its processing (police, redirect) except dscp marking.
Flowspec will retain dscp marking as dictated by local qos config.
Say, we have the following:
inbound qos config : police 100Mbps, mark dscp af11
=============================================================
ipv4 access-list acl_ipv4_qos_stream
6 permit ipv4 any host 200.255.5.2
!
!
class-map match-any cm_ipv4_qos_stream
match access-group ipv4 acl_ipv4_qos_stream
end-class-map
!
policy-map pm_ipv4_qos_stream
class cm_ipv4_qos_stream
police rate 100 mbps
!
set dscp af11
!
class class-default
!
end-policy-map
!
interface hundredGigE 0/4/0/35
service-policy input pm_ipv4_qos_stream
=============================================================
Then we receive the following in flowspec advertisement.
flowspec config : police 50Mbps, mark dscp af43, redir vrf.
=============================================================
RP/0/RP0/CPU0:fretta-50#sh flowspec ipv4 detail | b 200.255.5.2
Flow :Dest:200.255.5.2/32
Actions :Traffic-rate: 50000000 bps DSCP: af43 Redirect: VRF honeypot Route-target: ASN2-4787:13 (bgp.1)
Statistics (packets/bytes)
Matched : 116570713/12822778430
Transmitted : 57360817/6309689870
Dropped : 59209896/6513088560
=============================================================
Then the outcome will be:
NCS5500 platform will also display this same behavior.
Special thanks to Nic Fevrier whose pictures I used for some of the visuals above.
Xander Thuijs CCIE#6775
Principal Engineer, ASR9000
Hi,
Do you have any plans to implement flowspec on NCS 5508 platform?
Thanks!
Definitely Vladimir, although I can't confirm the release. the challenge is here the ACL size that the ncs5500 can support, hence the delay.
regards!
xander
Which of cisco series routers can be used in CLIENT mode? Can anybody list devices with IOS versions?
In my lab I tested on IOS XRv9K in CLIENT mode and ASR9001 as SERVER.
Also I tried to use ASR1002-X(IOS XE 3.16) in CLIENT mode, but I can't send instructions. BGP FS in UP state between routers.
It seems that ASR1002-X very limited for BGP FS functional.
Hello Xander,
While going through the section "5.1. Order of Traffic Filtering Rules" of BGP Flowspec RFC 5575, I got a doubt. My doubt is how to decide the precedence order when the match components have multiple sub-components. I will try to explain it through an example.
Lets say we have 2 Flow Spec Rules.
Rule-1:
(type 1) destination prefix : 1.2.3.0/24
(type 5) Destination port : 245 OR 256
Rule-2:
(type 1) destination prefix : 1.2.3.0/24
(type 5) Destination port : <=200 AND >=150
Now as per the RFC since the content of type 1 is same, we need to compare the data of type 5. Here operators and values are different in the sub-components of the component of type 5. Can you please explain how to compare now Rule-1 and Rule-2 to decide which has higher precedence?
Hello,
How about ASR9010 (with IOS XR 6.1.4) and flowspec? More specifically, should I be able to inject flowspec routes (BGP peer with controller in default vrf) in different routing table (VRF)? Here are my options:
RP/0/RSP0/CPU0:(config)#router bgp XXX vrf YYY address-family ipv4 flowspec ?
additional-paths Additional paths configuration
advertise Advertise BGP path
as-path-loopcheck Configure AS Path loop checking
bgp BGP Commands
nexthop Nexthop
route-target Route target RIB installation
weight Define or modify weight
<cr>
Can not find any import/export options here.
Thank you for your answer in advance!
E
Hello community.
I try to test in lab BGP flowspec rules propagation through VPNv4 flowspec. My BGP FS controller XRv 9000 6.5.3:
RP/0/RP0/CPU0:XR-FS-CTRL#show ver
Cisco IOS XR Software, Version 6.5.3
Copyright (c) 2013-2019 by Cisco Systems, Inc.
Build Information:
Built By : ahoang
Built On : Tue Mar 26 06:52:25 PDT 2019
Built Host : iox-ucs-019
Workspace : /auto/srcarchive13/prod/6.5.3/xrv9k/ws
Version : 6.5.3
Location : /opt/cisco/XR/packages/
RP/0/RP0/CPU0:XR-FS-CTRL#show platform
Tue Oct 22 05:41:28.864 UTC
Node Type State Config state
--------------------------------------------------------------------------------
0/0/CPU0 R-IOSXRV9000-LC-C IOS XR RUN NSHUT
0/RP0/CPU0 R-IOSXRV9000-RP-C(Active) IOS XR RUN NSHUT
My BGP Flowspec related configuration:
vrf VRF-1
address-family ipv4 flowspec
import route-target
65100:1
!
export route-target
65100:1
class-map type traffic match-all FS-RULE
match source-address ipv4 65.1.0.1 255.255.255.255
match destination-address ipv4 65.2.0.1 255.255.255.255
end-class-map
policy-map type pbr FS-PLC
class type traffic FS-RULE
redirect ipv4 nexthop 10.12.1.1
!
class type traffic class-default
!
end-policy-map
!
router bgp 65100
address-family ipv4 flowspec
!
address-family vpnv4 flowspec
!
neighbor 100.100.100.100
remote-as 65100
update-source Loopback100
!
address-family vpnv4 flowspec
!
!
vrf VRF-1
rd 65100:1
address-family ipv4 flowspec
When finally configure and commit "flowspec vrf service-policy" I got an error:
RP/0/RP0/CPU0:XR-FS-CTRL# conf t
RP/0/RP0/CPU0:XR-FS-CTRL(config)#flowspec
RP/0/RP0/CPU0:XR-FS-CTRL(config-flowspec)#vrf VRF-1
RP/0/RP0/CPU0:XR-FS-CTRL(config-flowspec-vrf)#address-family ipv4
RP/0/RP0/CPU0:XR-FS-CTRL(config-flowspec-vrf-af)#service-policy type pbr FS-PLC
RP/0/RP0/CPU0:XR-FS-CTRL(config-flowspec-vrf-af)#show
flowspec
vrf VRF-1
address-family ipv4
service-policy type pbr FS-PLC
!
!
!
RP/0/RP0/CPU0:XR-FS-CTRL(config-flowspec-vrf-af)#commit
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted.
Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RP0/CPU0:XR-FS-CTRL(config-flowspec-vrf-af)#show configuration failed
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
flowspec
vrf VRF-1
address-family ipv4
service-policy type pbr FS-PLC
!!% 'FlowSpec' detected the 'warning' condition 'FS MGR': Operation not supported
!
!
!
end
Is it restriction of XRv9000 platform or release in support of BGP flowspec for VRF or something wrong in configuration?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: