xthuijs
Cisco Employee
Cisco Employee

 

Introduction

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.

 

DDOS mitigation via RTBH (remote triggered blackhole)

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:

  • drop the traffic
  • inject it in a different vrf (for analysis)
  • or allow it, but police it at a specific defined rate.

Cool. Now that we got that theory out of the way, how about Flowspec then, what does it do and how is it different?!

 

BGP flowspec definitions

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:

1.Destination IP Address (1 component)
2.Source IP Address (1 component)
3.IP Protocol (+1 component)
4.Port (+1 component)
5.Destination port (+1 component)

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!

Client/Server Model

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:

CLIENT

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.

SERVER

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

 

Configuration

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

 !

Client

requires no special config other then a flowspec enabled peer.

Server

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:

 

  1. traffic will be policed by flowspec at 50Mbps.
  2. traffic will be redirected by flowspec to VRF honeypot.
  3. flowspec will not overwrite dscp marking, traffic will be forwarded using dscp af11 instead of af43.

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

 

Comments
Terry Pattinson
Level 1
Level 1

Hi Xander,

Great write up. Any chance that BGP FlowSpec can be used to implement something like Juniper's prefix-action - which is basically UBRL but at a subnet granularity rather than a flow granularity? Our requirement is to police subnets within an address block:

Parent subnet x.y.0.0/17 - /29 subnetwork within this block to be policed at 1Gbps

x.y.0.0/29    > Total inbound traffic will not exceed 1Gbps

x.y.0.8/29    > Total inbound traffic will not exceed 1Gbps

x.y.0.16/29  > Total inbound traffic will not exceed 1Gbps

x.y.0/24/29 > Total inbound traffic will not exceed 1Gbps

Thanks,

Terry

xthuijs
Cisco Employee
Cisco Employee

Hi Terry, thank you!! :)

I dont think the flowspec would lend itself for that too easily, but I think you can very easily use QPPB for that requirement!! If the prefixes you have referenced here are actually bgp prefixes, then we can trap those and set a qos-group on them and have them policed either on ingress or egress.

If you do it on ingress, it will be a feedback loop (so cost some pps perforamnce). Doing it on egress will make it "aggregate" from all incoming sources, but that may just want you want anyway it sounds like.

Check the QPPB write up here:

https://supportforums.cisco.com/document/12050971/asr9000xr-implementing-qos-policy-propagation-bgp-qppb

cheers

xander

xthuijs
Cisco Employee
Cisco Employee

Giving it a second thought also, I think you can leverage flowspec here too, by basically advertising the FS subnets and assigning a policer action on it in the flowspec "server" down to the clients. Yes that shoudl work also!

xander

Terry Pattinson
Level 1
Level 1

Hi Xander,

Thanks for your reply! What if the prefixes weren't BGP prefixes? That is to say, the ASR is configured to statically route 10.1.0.0/17 and the policy that needs to be imposed is every /29 requires 1G of traffic. If the /29 in aggregate uses more than 1G, a policer exceed action (for example) needs to be taken.

Typically, UBRL would implement this for each /32. What I need is this for a /29.

Thanks again,

Terry

Terry Pattinson
Level 1
Level 1

I guess what I'm trying to avoid is having to statically define 4096 policer configs

2^(subnet - route) = 2^(29-17) = 2^12 =4096

UBRL is the obvious solution if the granularity required is /32.

I can use BGP and inject /29s if that would make it simpler, but with both QPPB and FS I'd have to define the policer individually, which doesn't get around my basic problem. Ideally what I need is a mechanism to define policers via a template.

Thanks,

Terry

 

carlossanchez72
Community Member

Hey Xander thanks for the great article!

I would like your thoughts on the following. Still for a SP DDoS 'clean pipes' type of design, by making use of BGP FS you would gain more granularity to do a specific action (police, drop,etc) a flowspec of the attack traffic and still have the rest of 'clean' traffic to flow to the end destination.

But to really 'clean' the traffic you still need a TMS (mitigation) element in your DDoS architecture (as the CGSE in a CRS) etc right?

 

Any thoughts on this are greatly appreciated!

thanks

Carlos

xthuijs
Cisco Employee
Cisco Employee

Hi Carlos, that is correct, you would need a device to clean the traffic.

A generic approach taken is that on the suspicion of "dirty traffic" a filter via FS is set up to tunnel/redirect that traffic to the cleaner, once that cleaner has filtered this traffic it can send it back for original path transmission to the destination it was set for.

Unless you have such a good signature handler that knows exactly the right from wrong, learnt from netflow or DPI (eg via VSM, the virtual service module application) then it can instruct FS also to immediately drop or police that traffic.

I think the approach to first attempt to clean is better, for this simple reason it helps learning more about mallicious flow, so it is great for datamining.

Another thing to add next to FS, if you're dual homed, is by readvertising some metrics for the affected destination prefix, this so it only goes into one of the homed pairs so that the other border router is dealing with mostly clean traffic, also not necessary, but a nice option.

cheers!

xander

EvaldasOu
Level 4
Level 4

Thanks Alexander for the great post!

Can You tell us, is it possible to configure and test bgp flowspec on CSR1000v or XRv platforms?

Nicolas Fevrier
Cisco Employee
Cisco Employee

You won't be able to test forwarding plane on XRv but you will be able to use XRv as a BGP FlowSpec controller to inject rules.

As long as you don't want to pass traffic, you can still play with several XRv and learn how it can be configured. The rules will be advertised and learned but of course, nothing will be programmed at the data plane level.

Cheers,

N.

EvaldasOu
Level 4
Level 4

Thanks Nicolas!

As I understand, FlowSpec is just BGP extension for distributed rules/acl's/blackholing...

We should use a FlowSpec server (with NetFlow collector) in order to detect and inject forwarding rules (dynamically when necessary). 

Is there a full solution, I mean what server/software we should use here in order to detect and mitigate DDoS attacks?

Thanks!

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi,

actually, BGP FS goes beyond ACL/Blackholing: It can also be used to rate-limit the traffic matched by the description, or divert it to a new next-hop address or to leak into a different VRF, or to remark the DSCP field of the traffic.

I'm not aware of any open-source / free pre-packaged solution to do the detection (based on NFv9 records), and rules injecting. But commercial solutions (like Arbor Peakflow SP for example) can do this pretty well.

BR,

N.

btarno782
Level 1
Level 1

Xander,

 

Thanks for the great article.   What would the configuration look like if you want the policy to be enforced in a VRF on your client?  When I generate a flowspec route from the controller (which also happens to be a client of itself), locally the policy is enforced just fine:

 

RP/0/RSP0/CPU0:9006-4-LAB#show flowspec vrf BLA01 ipv4 detail

VRF: BLA01     AFI: IPv4
 Flow           :Dest:10.62.80.13/32
  Actions       :Traffic-rate: 1 bps Redirect: VRF BLA01 Route-target: ASN2-65200:10110101  (policy.1.POLICY1.CLASS1)
  Statistics                        (packets/bytes)
   Matched             :           403720173/302794570111       
   Dropped             :           403607779/302709184649      

 

...However when I move over to one of the clients the flow only shows up in the global table.  There is no flow entry for the vrf table at all:

 

RP/0/RSP0/CPU0:9006-3-LAB#show flowspec vrf all afi-all detail

AFI: IPv4
 Flow           :Dest:10.62.80.13/32
  Actions       :Traffic-rate: 0 bps  (bgp.1)
  Statistics                        (packets/bytes)
   Matched             :                   0/0                  
   Dropped             :                   0/0             

 

 

I think I'm missing something simple here and hoping you might know off the top of your head.  Thanks in advance!

 

Brad

xthuijs
Cisco Employee
Cisco Employee

hey brad, I probably need to see the precise configuration to understand some things better, but enabling flowspec on an interface in a vrf should be just fine.

it may be a cosmetic issue, or some config issue that we could possibly resolve.

cheers

xander

btarno782
Level 1
Level 1

I thought that this was the only way to enable flowspec on an interface:

 

RP/0/RSP0/CPU0:9006-3-LAB#show run flowspec
flowspec
 vrf BLA01
  address-family ipv4
   local-install interface-all
  !
 !
!

 

Is there a different way?

 

To expand on the flowspec specific config a bit more the "client" has ipv4/ipv6 flowspec peering relationships with reflectors, and what I pasted above.  Nothing else.

 

The "controller" has the same BGP peering relationships to the reflectors, along with the class-map, policy-map and the below config:

 

RP/0/RSP0/CPU0:9006-4-LAB#show run flowspec
flowspec
 address-family ipv4
  local-install interface-all
  service-policy type pbr POLICY1
 !
 vrf BLA01
  address-family ipv4
   local-install interface-all
   service-policy type pbr POLICY1
  !
 !

 

The client receives the route just fine:

 

RP/0/RSP0/CPU0:9006-3-LAB#show bgp ipv4 flowspec Dest:10.62.80.13/32/48
BGP routing table entry for Dest:10.62.80.13/32/48
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  3           3
Last Modified: Jan 29 21:34:13.968 for 00:17:00
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    0.0.0.0 from 10.1.1.20 (10.1.1.4)
      Origin IGP, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 3
      Extended community: FLOWSPEC Traffic-rate:200,0
      Originator: 10.1.1.4, Cluster list: 0.1.8.0

 

But it's only installing the flow rule into the global table:

 

RP/0/RSP0/CPU0:9006-3-LAB#show flowspec vrf default ipv4 detail   

AFI: IPv4
 Flow           :Dest:10.62.80.13/32
  Actions       :Traffic-rate: 0 bps  (bgp.1)
  Statistics                        (packets/bytes)
   Matched             :                   0/0                  
   Dropped             :                   0/0               

 

RP/0/RSP0/CPU0:9006-3-LAB#show flowspec vrf BLA01 ipv4 detail
<no output>

 

 

The controller, which is also a client of itself, installs the policy into the correct table, and filters traffic as expected:

 

RP/0/RSP0/CPU0:9006-4-LAB#show flowspec vrf BLA01 ipv4 detail

VRF: BLA01     AFI: IPv4
 Flow           :Dest:10.62.80.13/32
  Actions       :Traffic-rate: 1 bps  (policy.1.POLICY1.CLASS1)
  Statistics                        (packets/bytes)
   Matched             :           821063216/615803701906       
   Dropped             :           821159191/615873323343      

Nicolas Fevrier
Cisco Employee
Cisco Employee

Looks like you didn't enable the vpnv4 flowspec peering between your controller and client.

Could you please share the router BGP config on both sides ?

Thanks,

N;

btarno782
Level 1
Level 1

Hi Nicolas,

That is what it looks like isn't it?  That's something that I tried before my last post.  It doesn't seem to make a difference though:

 

!!!!!!!!!!!! on the client:

router bgp 200
 neighbor 10.1.1.20
  use neighbor-group RRR

!

router bgp 200
 neighbor-group RRR
  remote-as 200
  capability additional-paths receive
  capability additional-paths send
  update-source Loopback0
  send-buffer-size 131072 131072
  receive-buffer-size 131072 131072
  address-family vpnv4 unicast
   route-policy VPNV4-IN in
   maximum-prefix 16000000 75 warning-only
   route-policy VPNV4-OUT out
  !
  address-family vpnv6 unicast
   route-policy VPNV6-OUT out
  !
  address-family l2vpn vpls-vpws
   route-policy L2VPN-VPLS-VPWS-OUT out
  !
  address-family ipv4 rt-filter
  !
  address-family l2vpn evpn
  !
  address-family ipv4 flowspec
   validation disable
  !
  address-family ipv6 flowspec
   validation disable
  !
  address-family vpnv4 flowspec
  !
 !
!

 

!!!!!!!!!!!!!!! on the reflector:

router bgp 200
 neighbor 10.1.1.3
  use neighbor-group PE

!

router bgp 200
 neighbor-group PE
  remote-as 200
  capability additional-paths receive
  capability additional-paths send
  update-source Loopback1
  send-buffer-size 131072 131072
  receive-buffer-size 131072 131072
  address-family vpnv4 unicast
   route-reflector-client
   maximum-prefix 16000000 75 warning-only
  !
  address-family vpnv6 unicast
   route-reflector-client
   maximum-prefix 16000000 75 warning-only
  !
  address-family l2vpn vpls-vpws
   route-reflector-client
  !
  address-family ipv4 rt-filter
   default-originate
  !
  address-family l2vpn evpn
   route-reflector-client
  !
  address-family ipv4 flowspec
   route-reflector-client
   validation disable
  !
  address-family ipv6 flowspec
   route-reflector-client
   validation disable
  !
  address-family vpnv4 flowspec
   route-reflector-client
  !
 !
!

 

!!!!!!!!!!!!!!! on the controller:

router bgp 200
 neighbor 10.1.1.20
  use neighbor-group RRR

!

router bgp 200
 neighbor-group RRR
  remote-as 200
  capability additional-paths receive
  capability additional-paths send
  update-source Loopback0
  send-buffer-size 131072 131072
  receive-buffer-size 131072 131072
  address-family vpnv4 unicast
   maximum-prefix 16000000 75 warning-only
   route-policy VPNV4_OUT out
  !
  address-family vpnv6 unicast
   route-policy VPNV6_OUT out
  !
  address-family l2vpn vpls-vpws
   route-policy L2VPN_VPLS-VPWS_OUT out
  !
  address-family ipv4 rt-filter
  !
  address-family l2vpn evpn
  !
  address-family ipv4 flowspec
   validation disable
  !
  address-family ipv6 flowspec
   validation disable
  !
  address-family vpnv4 flowspec
  !
 !

 

 

!!!!!!!!!!!! show commands on the client:

RP/0/RSP0/CPU0:9006-3-LAB#show bgp vpnv4 flowspec summary
BGP router identifier 10.1.1.3, local AS number 200
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0   RD version: 0
BGP main routing table version 1
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker               1          1          1          1           1           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.1.1.20         0 200 5559202   67822        1    0    0 01:54:08          0
 

 

!!!!!!!!! show commands on the reflector:

RP/0/RSP0/CPU0:9006-1-LAB#show bgp vpnv4 flowspec summary
Thu Jan 29 19:30:19.964 UTC
BGP router identifier 10.1.1.20, local AS number 200
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0   RD version: 0
BGP main routing table version 1
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker               1          1          1          1           1           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.1.1.3          0 200  133928 15649260        1    0    0 01:55:13          0
10.1.1.4          0 200  108611 14313510        1    0    0 01:55:13          0

 

!!!!!!!!!! show commands on the controller:

RP/0/RSP0/CPU0:9006-4-LAB#show bgp vpnv4 flowspec summary
BGP router identifier 10.1.1.4, local AS number 200
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0   RD version: 0
BGP main routing table version 1
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker               1          1          1          1           1           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.1.1.20         0 200 14349512  112864        1    0    0 01:56:31          0
10.1.1.21         0 200 7991764  131883        1    0    0 01:54:31          0

 

RP/0/RSP0/CPU0:9006-4-LAB#show bgp vpnv4 flowspec
<no output>

RP/0/RSP0/CPU0:9006-4-LAB#show bgp vpnv4 flowspec advertised

<no output>

 

 

 

 

Thanks for the help guys, keep it coming!

 

b

Nicolas Fevrier
Cisco Employee
Cisco Employee

I will give it a try this week-end in my lab but I thought we needed also a statement in the VPNV4 VRF address-family.

Something more or less like:

 

router bgp 100

 address-family vpnv4 flowspec

 !

 address-family vpnv6 flowspec

 !

 neighbor 1.1.1.1

  remote-as 100

   address-family vpnv4 flowspec

   !

    address-family vpnv6 flowspec

   !

  !

   vrf foo

     address-family ipv4 flowspec

     !

     address-family ipv6 flowspec

     !

     neighbor 10.10.10.10

      remote-as 100

      address-family ipv4 flowspec

      !

      address-family ipv6 flowspec

     !

 

I'll do my best to get two boxes peering during the WE and give it a try myself.

Cheers,

N.

btarno782
Level 1
Level 1

Nicolas,

 

Thanks for the feedback, I appreciate it.  Looks like what was missing was the enabling of the ipv4 flowspec address-family under the actual vrf.  I had the vpnv4 flowspec address-family enabled but that wasn't correct.

 

So the working config is all of what was pasted above, and the following:

 

!!!!!!!! on controller

vrf BLA01

address-family ipv4 flowspec
  export route-target
   666:999
 

 

!!!!!!!! on clients

vrf BLA01

address-family ipv4 flowspec
  import route-target
   666:999

 

I knew it was something simple that I was missing.  I just wish there was some additional documentation that made this a little less painful.   But it's all working now.   Thanks again for all the help guys!

 

 

b

Nicolas Fevrier
Cisco Employee
Cisco Employee

Good job :)

We will produce some whitepapers in the next coming weeks (well, I've been promising them for a while, so it's time to re-prioritize this task) to address this lack of proper documentation.

Glad you found the missing config and that it works now.

Cheers,

N.

costan
Level 1
Level 1

Actually on the open-source part, ExaBGP should work as a flowspec enabled speaker (only on control-plane part, ExaBGP would not interact with dataplane since it's a pure control-plane technology).

Given ExaBGP flexibility it would not be that hard to plug into an already existing opensource Netflow technology to add the react part, given you can already detect with Netflow.

So basically we need a Netflow technology (like flowd or flow-tools to stay in open-source field), some customization and you can plug into ExaBGP to react when conditions are met.

 

BR/

AC

Nicolas Fevrier
Cisco Employee
Cisco Employee

ExaBGP is indeed a good controller.

For the rest, I've seen this: https://github.com/FastVPSEestiOu/fastnetmon

(but didn't try it yet).

vikas.hazrati1
Level 1
Level 1

Hello Xander

and thanks for a very good introduction for FlowSpec. I have questions regarding the resources needed to implement the flow-spec policies. To my understanding flow-spec policies use TCAM resources (so they compete with ACL, QoS policies etc)

Can you point us to a set of commands that we can use to monitor the TCAM consumption for a particular linecard / np in ASR9000?

 

Thanx

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Vikas,

unfortunately, no simple command to check the allocation today on 9k.

Probably something like:

  sh prm server tcam summary all PBR np0 location 0/0/CPU0

(for each NP of your linecard) can give you an hint.

Cheers,

N.

xthuijs
Cisco Employee
Cisco Employee

yeah that is correct Vikas, they will use TCAM resources for the classification and possibly a policer if applied.

Interestingly you asked since I had a section in this years Cisco Live preso I did this morning!

Dont know if they are available for download already, but when, you probably want to pull the cisoc live sandiego id 2904 session for that tcam resource utilization piece.

Here an exerpt, ah that didnt paste well, 2 pics attached then.

Carlos A. Silva
Level 3
Level 3

Hi, Xander/Nick:

 

The "or divert it to a new next-hop address or to leak into a different VRF" part might come in really handy for a customer of ours. So, XRv is not an option at all? Would I be able to see the installed flows even if it doesn't actually leak the traffic into a different VRF?

 

Thanks,

c.

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Carlos,

I'm not sure I understand the question: "Would I be able to see the installed flows even if it doesn't actually leak the traffic into a different VRF?"

XRv can be used as a controller to program an action of redirect-to-IP or redirect-to-VRF that will be received and programed by a physical client (in our case, CRS-3, ASR9000, NCS6000, ASR1000, etc...).

Please help clarify the last question, may be with an example ?

Thanks,

N.

 

Carlos A. Silva
Level 3
Level 3

Sure, Nicolas.

 

I do not have a 9k or CRS to test with. I do have XRv 5.3.1 (5.3.0 doesn't have the flowspec command) and I was wondering if, even though the data plane operation cannot be tested, at least take a look at the control plane for BGP-FS. Is this possible?

 

Thanks,

c.

Carlos A. Silva
Level 3
Level 3

Looks like no such luck. This if from the XRv demo releases.

 

RP/0/0/CPU0:RR5(config)#flowspec local-install interface-all
RP/0/0/CPU0:RR5(config)#commi
Fri Jun 12 09:24:52.305 UTC

% 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/0/CPU0:RR5(config)#show configuration failed
Fri Jun 12 09:24:59.985 UTC
!! 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
 local-install interface-all
!!% 'FlowSpec' detected the 'warning' condition 'FS MGR': Not supported
!
end

RP/0/0/CPU0:RR5(config)#

xthuijs
Cisco Employee
Cisco Employee

yeah while the XRv can be used as a "controller" so we can inject the updates for flowspec to "real devices", xrv cannot be used as a client to receive such rules and install them.

XRv doesnt have a tcam and all that hence it wouldnt be a true valid test either.

the commands I gave earlier on the hw entries require a "true" device as that output is pulled from the forwarding asics directly.

cheers

xander

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Carlos,

as clearly explained by Xander, no chance to use the virtual XRv used as a client. It will be possible with the future XRv-9000 but not at FCS (this summer, it will be also only used as a controller or route-reflector).

All you are right about the 5.3.0 lacking all BGP FS features, we fixed this mistake in 5.3.1.

Cheers,

N.

vikas.hazrati1
Level 1
Level 1

Thanks this new version of BRKSPG-2904 provided many answers

Bradley Gould
Level 1
Level 1

Hi Xander,

 

There is some performance penalty with QPPB and re-circulation of packets to assign the qos-group.

 

No mention of that here - so is flow-spec superior in this regard?  Is there any other limitations apart from what you have discussed?

 

Thanks!

 

Brad

xthuijs
Cisco Employee
Cisco Employee

hi bradley, BGP-FS is merely "PBR" (and the pbr constructed by a bgp message), so the performance impact here is like using an ACL with an ABF next hop, which is about 25%-ish.

xander

nimmi.phasil
Level 1
Level 1

Hi Xander,

When I try to commit the flowspec configuration , Im getting the the error " !!% 'FlowSpec' detected the 'warning' condition 'FS MGR': Not supported ".

RP/0/RSP0/CPU0:LAB-ASR-2-R4(config-flowspec-af)#commit
Mon Jul 27 00:01:35.474 UTC

% 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/RSP0/CPU0:LAB-ASR-2-R4(config-flowspec-af)#show configuration failed
Mon Jul 27 00:01:53.037 UTC
!! 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
 address-family ipv4
  service-policy type pbr nv1
!!% 'FlowSpec' detected the 'warning' condition 'FS MGR': Not supported
 !
!
end

RP/0/RSP0/CPU0:LAB-ASR-2-R4(config-flowspec-af)#

 

Thanks 

Nimmi MP

Nicolas Fevrier
Cisco Employee
Cisco Employee

HI NIimmi,

are you using an ASR9000 with a minimum version of 5.2.0 ?

Please provide a "show install act sum".

Thanks,

N.

nimmi.phasil
Level 1
Level 1

Hi Nicolas,

Yes,.

RP/0/RSP0/CPU0:LAB-ASR-2-R4#sh install act sum
Mon Jul 27 00:27:03.616 UTC
Default Profile:
  SDRs:
    Owner
  Active Packages:
    disk0:asr9k-mini-px-5.2.0
    disk0:asr9k-fpd-px-5.2.0
    disk0:asr9k-mcast-px-5.2.0
    disk0:asr9k-mpls-px-5.2.0
    disk0:asr9k-mgbl-px-5.2.0

RP/0/RSP0/CPU0:LAB-ASR-2-R4#

 

Thanks

Nimmi 

Nicolas Fevrier
Cisco Employee
Cisco Employee

Ok, you should be good on this front then,

please share the part of your configuration related to the BGPFS so we can try to understand what goes wrong.

Also, you can create a new forum post for the sake of clarity, up to you.

Cheers,

N.

nimmi.phasil
Level 1
Level 1

Configuration.

class-map type traffic match-all nv
 match destination-address ipv4 119.227.2.252 255.255.255.255
 match source-address ipv4 0.0.0.0 0.0.0.0
 end-class-map

policy-map type pbr nv1
 class type traffic nv
  drop

router bgp 9583
 
 !
 address-family ipv4 flowspec
 !
 neighbor 202.144.74.184
  
  !
  address-family ipv4 flowspec
  !

Trying to add ,

flowspec
 local-install interface-all
 address-family ipv4
  service-policy type pbr nv1
 !

  getting error.

 

I have applied the above configuration to another ASR 9000(acting as server) and committed successfully. For testing purpose , added the same configuration to the client ; but got error.

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Nimmi,

I thought it could be your source statement (which is not really useful, matching everything or not specifying anything providing the same results) but I tried in my setup and it works just fine.

I've seen trouble in the past when a router was used with other PBR path features like openFlow and then configured for FlowSpec. But it was never a config commit failed.

I suppose your two lab boxes have the exact same hardware and IOS XR installed on it ?

Cheers,

N.

nimmi.phasil
Level 1
Level 1

Hi Nicolas,

The idea is to drop packets from any source to destination 119.227.2.252 . It was not working . So I tried to configure in the client as well. Both have same hardware and IOS XR . 

Documentation for the Flowspec configuration:

Flowspec router CLI example:
class-map type traffic match-all cm1
match source-address ipv4 100.0.0.0/24
policy-map type pbr pm1
class type traffic cm1
drop
flowspec
address-family ipv4
service-policy type pbr pm0
Transient router CLI:
flowspec
address-family ipv4
service-policy type pbr pm1

In transient router (client) , I could not configure service-policy type pbr pm1 under flowspec since pm1 should be defined under policy . This lead to configuring the class-map and policy in the client.

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Nimmi,

Let's separate the discussion in two parts.

- the fact that the config is not committed: it's unexpected and at the moment, I can not explain the root cause

- The way you approach the design BGP FS Client / Controller: it's not the way BGP flowspec is supposed to work.

You don't have to configure your class-map/policy-map on the client (it defeats comply the purpose of dissemination of the rules) but only on the controller.

On the controller you will have:

class-map type traffic match-all CLASS-MAP-1
 match destination-address ipv4 119.227.2.252 255.255.255.255
 end-class-map
!
policy-map type pbr POLICY-MAP-1
 class type traffic CLASS-MAP-1
  drop
!
router bgp XXX
 !
 address-family ipv4 flowspec
 !
 neighbor @client
  remote-as XXX
  !
  address-family ipv4 flowspec
  !
flowspec
 address-family ipv4
  service-policy type pbr POLICY-MAP-1
 !

and on the client:

router bgp XXX
 !
 address-family ipv4 flowspec
 !
 neighbor @cserver
  remote-as XXX
  !
  address-family ipv4 flowspec
  !
flowspec
 local-install interface-all
!

And that should be it. No need to configure a match any for the source, it's implicit.

Best regards,

N.

nimmi.phasil
Level 1
Level 1

Hi Nicolas,

 

Yes, I did the same  configuration . Since it didnt work (there was no match and no drop) , I tried to do the conf in client as well. Lets discuss that part later. 

With the same configuration , my ICMP packets are not getting dropped.

Output from client.

RP/0/RSP0/CPU0:LAB-ASR-2-R4#sh flowspec ipv4 detail
Mon Jul 27 02:57:42.931 UTC

AFI: IPv4
 Flow           :Dest:119.227.2.252/32
  Actions       :Traffic-rate: 0 bps  (bgp.1)
  Statistics                        (packets/bytes)
   Matched             :                   0/0
   Dropped             :                   0/0
RP/0/RSP0/CPU0:LAB-ASR-2-R4#

xthuijs
Cisco Employee
Cisco Employee

could it be you have a trident linecard in your system or that you are using XRv?

that will throw an unsupported error.

cheers!

xander
 

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Nimmi,

let's start from here then. It seems that you received the rule on the client which means the config is probably OK.

First, remember that Flowspec is only applied on the ingress interface only. It can be physical or logical (bundle or dot1q) but not a tunnel (GRE or other).

It doesn't apply in egress or from the locally generated traffic.

In your case, if you trying to drop ICMP traffic, it will need to come from an external source into your client router interface.

Source --> ClientIngressInterface - ClientRouter - ClientEgressInterface --- 119.227.2.252

So make sure you are indeed receiving the traffic on the proper place (you can try ACL with logging option to verify that the traffic is indeed flowing on your interface, or more simple you can use "show interface 0/X/X/X accounting rate" to check the IPv4 traffic).

As mentioned briefly in the discussion, we got some bugs affecting the PBR path in case of multiple configuration. So, if it's possible in your lab environment, you should probably start reloading the router (admin reload location all) or at the minimum the ingress linecard.

If the problem persists, we will need to understand some other details of your topology (do you have the controller and client in the same ASN, for example). Also, it will be good to get detailed on:

show policy-map transient targets type pbr
show policy-map transient type pbr pmap-name __bgpfs_default_IPv4
show flowspec ipv4 internal
show flowspec trace manager event error
show flowspec trace client event error
show flowspec client internal

debug flowspec error 
(before establishing the BGP FS session and pushing the rule).

Thanks,

N.

 

 

 

 

Nicolas Fevrier
Cisco Employee
Cisco Employee

Good point Xander, I overlooked the basics.

Nimmi, please send us a "show plat" to confirm.

Thanks,

N.

nimmi.phasil
Level 1
Level 1

Hi Nicolas,

 

It worked. Removed some configurations and reloaded . Thanks for the support.

Regards

Nimmi MP

nimmi.phasil
Level 1
Level 1

RP/0/RSP0/CPU0:ios#sh platform
Tue Jul 28 01:43:39.843 UTC
Node            Type                      State            Config State
-----------------------------------------------------------------------------
0/RSP0/CPU0     ASR9001-RP(Active)        IOS XR RUN       PWR,NSHUT,MON
0/0/CPU0        ASR9001-LC                IOS XR RUN       PWR,NSHUT,MON
0/0/0           A9K-MPA-4X10GE            OK               PWR,NSHUT,MON
0/0/1           A9K-MPA-20X1GE            OK               PWR,NSHUT,MON
RP/0/RSP0/CPU0:ios#

 

Thanks

Nimmi

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Nimmi,

ASR9001 is Typhoon based, all supported for BGP FS.

But if you said a reload fixed it, you can keep on running your tests then.

BR,

N.

spapageorgiou
Level 1
Level 1

Hi all,

We have an ASR9001. I would like some info about the sizing of BGP-FS. For example, how many /32 routes can i send over it, without reaching tcam limits?

DDOS attacks can easily reach hundred of thousands attacking hosts...

thanx,

Sp

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Sp,

The scale we support (ie that we test in our labs) is 3000 rules. In the context of DDoS mitigation it's usually way enough because we are not trying to identify every single source responsible for the attack, but more generally we identify the victim or the range of addresses under attack and we try to filter based on packet specificities.

For example: in the case of NTP amplification attack, we will drop packet following this description:
- Destination address: victim IP or range of the victim IPs
- protocol 17: UDP
- port source or destination: 123
- packet size: larger than 400 (it's a random number)

--> we don't define the source, so it could be from everywhere as long as these other conditions are met (also, it's common to define a second rule for fragmented packets targeted to the victim because the attack packets may be larger than the PMTU and will often be fragmented).

Hope it helps a bit,

N.

Aleksandar Vidakovic
Cisco Employee
Cisco Employee

On asr9k we support 3k simple rules per system. If you require a more advanced solution, you could consider the DDoS prevention solution that we developed in collaboration with Arbor. You would need a larger asr9k for that solution and a VSM line card.

/Aleksandar

spapageorgiou
Level 1
Level 1

Thank you Nicolas and Aleksandar for the answers!

Sp

costan
Level 1
Level 1

Given FS limite indication, you can mix and match with RPF unicast check and RTBH.

If it's a DoS or small source set DDoS, you use FS. If it's a massive DDoS (thousand of sources), it's better to RBTH, whose limit is route table size (way mooore), and its protection applies to all customers at the same time, and whose drawback is only that the DDoS source become unreachable (not a big deal if they are botnet infected machines).

Hi, can you please share some design guide for ASR9K and Arbor integration?. Specific for ASR9K VSM + BGP FlowSpec. I not found in Cisco Website.

xthuijs
Cisco Employee
Cisco Employee

hi mauricio, I dont have something pre-cut for that at the moment, but I know some sales guidance exists for it that explains the VSM+arbor solution for ddos mitigation.

There is a white paper that talks about the solution here, does that get you going?

cheers!

xander

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Mauricio,

I suggest you watch the CiscoLive Berlin session "BRKSPG-3012 - SP Security - Leveraging BGP FlowSpec to protect your infrastructure (2016 Berlin)". 

You'll find recommandation for each type of attacks.

Also this one "BRKSPG-3335 - Advanced - DDoS Mitigation Deployment: Impact on your Architecture " still has a lot of good examples.

Cheers,

N.

satish.txt1
Level 1
Level 1

Do we need special router to run flowspacs? we have ASR1001-X does it support BGP flowspecs? 

also does ISP or provider need to enable flowspecs in their side to run flowspecs?

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hi Satish,

ASR1001-X should support BGP FS as a client since IOS XE 3.15.

By nature, BGP is a peering relationship between two entities. So you need another end to control your ASR1000 and inject rules via BGP FS.

In short, it really depends what you are trying to do :)

BR,

N.

pvlrpm
Level 1
Level 1

 Hi Alexander,

   As per the RFC 5575 there are validation steps for the Flow Spec NLRI containing destination prefix component. What about the Flow Spec NLRIs that don't have the destination prefix component? Is there no validation for such kind of Flow Spec NLRIs? Please clarify.

Thanks,

Pavana.

xthuijs
Cisco Employee
Cisco Employee

hi pavana, it is basically for ebgp advertisements, it defines the "protocol" for advertising the flow rules to a peer based on the best path selection algorithm. if the dest prefix is missing it wouldn't match a "real" prefix, hence the flow spec rule is not advertised along since the best path doesnt match the flowspec rule.

eBGP usage of flowspec is topic of much discussion (that is me having a flowspec rule and passing it on to another AS for implementation at their borders) and today possibly not part of consideration (yet).

xander

Hi,

Do you have any plans to implement flowspec on NCS 5508 platform?

Thanks!

xthuijs
Cisco Employee
Cisco Employee

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

Alexandr Gurbo
Level 1
Level 1

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.

pvlrpm
Level 1
Level 1

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?

ED-lv
Level 1
Level 1

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

AZhumashev
Level 1
Level 1

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?

@xthuijs