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: [email protected]
http://www.CustodianDC.com
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
