[c-nsp] BGP Next hop tracking / 'hold down' route...

[Andrew Brant]

Hello Drew,

1) This is not a bug, the router is simply cycling through all available options until it arrives at the longest prefix match (Null0 is a valid egress interface option); PBR kludge can be configured to override the longest prefix match algorithm, however selective address tracking is a much cleaner option.
 
2) Yes, if configured as described in the configuration guide the session will be reset immediately upon the BGP peer route change:

 http://www.cisco.com/en/US/docs/ios/12_4t/ip_route/configuration/guide/brbpeer.html

=====================================================
ip prefix-list PFX-BGP-PEER seq 5 permit 192.168.25.7/32

route-map RTM-BGP-FALLOVER permit 10
	match ip address prefix-list PFX-BGP-PEER

router bgp x
	neighbor 192.168.25.7 fall-over route-map RTM-BGP-FALLOVER
=====================================================

3) Multihop BFD assuming its supported on your platform - http://tools.cisco.com/ITDIT/CFN/

HTH

Cheers,
Andrew

CCIE 14715

On Jun 24, 2013, at 11:53 AM, Drew Weaver <drew.weaver at thenap.com> wrote:

> Hello all, I've been having a bit of an issue and I refuse to believe that nobody else has seen this or solved it before =)
> 
> This route exists as a hold down to announce to border/edge routers for eBGP:
> 
> ip route 192.168.0.0 255.255.224.0 Null0 192.0.2.1 199 tag 50
> 
> 192.168.25.1 peers with 192.168.25.7 for iBGP, 192.168.25.1 knows 192.168.25.7/32 via OSPF:
> 
> Routing entry for 192.168.25.7/32
>  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1000
> 
> When the physical connection between 192.168.25.1 and 192.168.25.7 is severed:
> 
> Jun 24 10:46:38 EDT: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.25.7 on TenGigabitEthernet3/5 from FULL to DOWN, Neighbor Down: BFD node down
> RTR#sh ip route 192.168.25.7
> Routing entry for 192.168.0.0/19, supernet
>  Known via "static", distance 199, metric 0
>  Tag 50
>  Redistributing via ospf 1, bgp 65535
>  Advertised by bgp 65535 route-map STATIC-TO-BGP
>  Routing Descriptor Blocks:
>  * 192.0.2.1, via Null0
>      Route metric is 0, traffic share count is 1
>      Route tag 50
> 
> RTR#sh ip cef 192.168.25.7
> 192.168.0.0/19
>  nexthop 192.0.2.1 Null0
> 
> The problem is, once the /32 no longer exists in OSPF the router tries to use the less specific 192.168.0.0/19 route to communicate with 192.168.25.7 until the BGP session *finally* closes which in this day and age may as well be an eternity.
> 
> Questions:
> 
> 1) 192.0.2.1 routes to Null0 and the static route also points to Null0 as it's interface, should IOS really be using something that recurses to Null0 as a BGP next-hop or is this a bug? Is there any way to configure IOS not to do this?
> 2) Is selective next-hop tracking event driven? Meaning if I enable it while the /32 is in IGP and the above scenario takes place, will it prevent this scenario from blackholing traffic while waiting for the BGP hold timer to expire?
> 
> I am also open to any other suggestions.
> 
> Thank you all so much =)
> -Drew
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/