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