Aside from fall-over, is there a BCP way to detect multihop bgp failures? I know timers can be trimmed, but is frequently warned against (at least in docs) - any others?
Can you elaborate it a little more?
You could some weird stuff with IP SLA and EEM. But this is not always what you want due to the complexity.
So please let me know what is your scenario..
Thanks in advance.
Basically, that's it - what are the BCP ways to signal an ebgp multihop session should be torn down?
I don't really have a scenario, I was just labbing up some different multihop scenarios today, and was playing with various ways of detecting failures in these situations. BFD, which seems to have very spotty support, doesn't work for multihop, apparently.
Fall-over does, but at least in gns3, only on one side of the connection - I know that maybe this is incorrect since link-level failure detection is pretty finicky with gns3. I haven't been able to find a whole lot about fall-over other than it possibly uses IGP reachability to determine whether to shutdown a neighbor.
Timers work fine, but I'm personally a little worried about setting them too low, and IIRC, you have to completely kill a session to get timers to update after a config change (timers are not attributes, and are negotiated in open messages, and bgp scanner doesn't care about the keepalives and holddown timer, correct?)
I have seen couples things to adjust to have fast BGP peering session failure detection:
1. BGP timers, where we can adjust keepalive and holdtime using bgp timers or neighbor x.x.x.x timers command
2. BGP scan time, this is the timer to poll the information from RIB into BGP table and defult time is 60 seconds you can change using bgp scan-time command
3. advertisement-interval : BGP waits for the expiration of the BGP advertise-interval before sending out the BGP update better set it to 0 using neighbor x.x.x.x advertisement-interval 0.
4. BGP fast fallover or fall-over
BGP fast-external-fallover is for directly connected BGP peers as soon as inteface state changed to down BGP process will be de-activate.
but in case of eBGP multihop,
neighbor x.x.x.x fall-over command is recommend: as soon as the IP address of the BGP peer disappears from the IP routing table, the BGP session with the peer is deactivated, resulting in immediate convergence.
I think INE's R&S Vol 1 explained very well about all those stuffs. Please go with that.
#1 is a reasonable thing to tweak. You'll get IOS warnings with short timers, but 1 packet every 5 seconds (0.2pps) is tiny compared to what would be flowing over the link in most cases.
I would highly recommend against tuning scan time. Maybe for the test, but never on a production network. Except on certain optimized IOS versions, the BGP scanner checks the BGP RIB, and while it does CPU usage will skyrocket. This will cause the router to be slow to answer pings or traceroutes. Since 90% of the Internet population doesn't understand traceroute, they think your router is slowing them down, when it isn't.
I don't think #3 will help you detect a broken path between neighbors.
#4 will accelerate the failure-reaction process, but it won't necessarily result i immediate convergence.
I've used shorter timers in the past(10/30 iirc) w/o issue, but all the current configs I have are either ibgp or over connected links, so I've been leaving them default.
Fall-over seems to work pretty well from the labbing I've done. FWIW, even with real routers the one-way issue remains an issue if you have a stupid config. I was labbing with 3 routers 2 in as1 and 1 in as2, as1 was running an IGP, as2 wasn't. Obviously fall-over only works when there's an IGP to hear from.
I've never messed with tweaking scantime or adv interval.
Obviously fall-over only works when there's an IGP to hear from.
You are correct . BGP fast-external-fallover is for directly connected eBGP peers and neighbor x.x.x.x fall-over checks the peer address on routing table.