@Cristian Matei wrote:
Hi,
From my experience, the outcome of you using timeout 0, was clearly with CPU impact, however your BFD session flapped and afterwards your BGP session flapped not because of CPU was impacted, but because you've consumed all the Ethernet TX ring slots, at least for minimum 1 second which was enough for BFD to go down given the timers you're using.
Since this test, with timeout 0, is not a real life / valid test, and something that you'll obviously not repeat, there's nothing to be addressed here, other than don't do it again.
Thanks,
Cristian.
I just updated my prior reply with some PT observational data, which appear that the next ping transmission waits on either receipt of the prior ping request and its reply, or the timeout value. So, a timeout of zero, is very likely to create a transmission burst, although whether there's actually no transmission pause (with the zero timeout setting), might not be the case. (Why? Well, possibly the next ping transmission might pause until whatever clock is being used to measure responses times, advances beyond its current value.)
I fully agree, that BFD, would fail if it misses all its keep alives during the time interval it's measuring.
As to the Ethernet filling all its TX ring slots, if that happen, usually they are backed by main RAM (software) buffers. However, it's certainly possible, that all egress buffers, hardware and software, are exhausted, and the BFD packets are lost (interface egress drops). It's also possible, the BFD packets are not lost, but are instead, delayed by packets ahead of them in the egress queues. Either, will cause BFD to see its peer connectivity as lost.
I recall Cisco, by default, tags BGP packets with IP Prec 6. Don't know if it does anything similar for BFD. QoS that "protects" such traffic, would help insure that it's neither dropped or excessively delayed.
Cisco also has something called PAK_priority, I believe Cisco doesn't use this for BGP. Unsure about BFD. Regardless, even if PAK_priority is active, I've read it's mainly to protect against packet loss, but not packet delay. Further, QoS, depending on platform, might be adjusted to better insure an SLA for BFD and/or BGP, to prevent just such an outage (if, indeed, caused by a burst of ping traffic).
Lastly, I would consider using timeout zero, possibly, as a handy way to attempt saturate an interface. Ordinarily, I use an external traffic generator, for that purpose, because ordinary pings don't generate enough traffic. However, ping using a max IP sized packet, with a zero timeout, might be (new to me) substitute. Oh, I might mention, when doing such testing, I insure such traffic is ToS tagged to direct it to a specific egress policy for such traffic. (Also, BTW, Cisco's extended ping allows setting the ToS value.)
(One of my most common QoS tests, to demonstrate the "power" of QoS, is to send traffic, to an egress interface, at 10% or higher than that interface's bandwidth capacity. But, that traffic is commonly tagged to be prioritized below everything else. I.e. even though the interface is running at 100%, and egress drops are counting up rapidly, all other traffic should see almost no impact to their SLAs.)
