[c-nsp] Source-based RTBH on ASR9k - bug?

Robert Williams Robert at CustodianDC.com
Sun Dec 15 08:30:37 EST 2013


Hi All,

To avoid duplication, I'm following this process: http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116386-configure-asr9000-00.html

On an ASR9k running 5.1.0 - but it will not "set next-hop discard" in a route-policy.

I've confirmed that the route-policy is correctly matching the BGP community and if I "set" anything else in the rule it works fine. Including setting a next-hop to another IP address, or change a local-preference, or anything basically. I've just requested a TAC case for it, as I'm suspicious of a bug.

In the meantime I'm curious if anyone else is able to set next-hop discard in a BGP route-policy on 5.1.0? Or if there is some gotcha which I'm missing. The process in the document above is pretty simple, and all other elements of it are in place (redistributing the tagged static route, uRPF etc.).

The only element which does not work is when the prefix is learnt by the border router it does not set its' next hop to discard; therefore uRPF does not filter the traffic.

---------------------------------------------------------
---------------------------------------------------------

The relevant config extracts on the border router are:

route-policy <inbound on the border router>
  if community matches-any (xxxx:8888) then
    set next-hop discard
  else
    <rest of the usual policy, which is ignored in this case>
  endif
end-policy

neighbor-group <group of iBGP routers>
  remote-as xxxx
  bfd fast-detect
  timers 20 60
  password encrypted xxx
  address-family ipv4 unicast
   route-policy <inbound on the border router> in
   route-policy xxxx out
   next-hop-self
   soft-reconfiguration inbound always

neighbor x.x.x.x
  use neighbor-group <group of iBGP routers>
  update-source <40GB bundle-ether>
  address-family ipv4 unicast

---------------------------------------------------------
---------------------------------------------------------

If you lookup the 'test' prefix (10.8.8.8/32) then you get:

BGP routing table entry for 10.8.8.8/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker           10145123    10145123
Paths: (2 available, best #1, not advertised to EBGP peer)
  Path #1: Received by speaker 0
  Local, (received & used)
    x.x.x.186 from x.x.x.189 (x.x.x.44)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate
      Received Path ID 1, Local Path ID 1, version 10145123
      Community: xxxx:xxxx xxxx:8888 no-export
      Originator: x.x.x.44, Cluster list: x.x.x.43
  Path #2: Received by speaker 0
  Local, (received & used)
    x.x.x.193 from x.x.x.193 (109.74.255.44)
      Origin incomplete, metric 0, localpref 100, valid, internal, backup, add-path
      Received Path ID 1, Local Path ID 2, version 10145123
      Community: xxxx:xxxx xxxx:8888 no-export

---------------------------------------------------------
---------------------------------------------------------

Apparently I should be seeing:

  Local, (received & used)
    x.x.x.186 (discarded) from x.x.x.189 (x.x.x.44)

---------------------------------------------------------
---------------------------------------------------------

The routing entry confirms we are forwarding and definitely not going to null0:

Routing entry for 10.8.8.8/32
  Known via "bgp xxxx", distance 200, metric 0
  Number of pic paths 1 , type internal
  Routing Descriptor Blocks
    x.x.x.186, from x.x.x.189
      Route metric is 0
    x.x.x.193, from x.x.x.193, BGP backup path
      Route metric is 0
  No advertising protos.

---------------------------------------------------------
---------------------------------------------------------

I've tried to include what is relevant but please tell me if you need to see something else. We use BGP PIC, hence the two paths are showing up in the results above.

So, any ideas anyone? Or if someone out there already has it working and/or is using next-hop discard in a policy on 5.1.0 with success please would you mind sharing some suggestions?

Thanks in advance!


Robert Williams
Custodian Data Centre
Email: Robert at CustodianDC.com
http://www.CustodianDC.com




More information about the cisco-nsp mailing list