<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">On Thu, 15 Oct 2020 at 09:11, Ryan Hamel <<a href="mailto:ryan@rkhtech.org">ryan@rkhtech.org</a>> wrote:</span><br></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Yep. Make sure you run BFD with your peering protocols, to catch outages very quickly.</div></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">Make sure you get higher availability with BFD than without it, it is easy to get this wrong and end up losing availability.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">First issue is that BFD has quite a lot of bug surface, because unlike most of your control-plane protocols, BFD is implemented in your NPU ucode when done right.</div><div class="gmail_default" style="font-family:monospace,monospace">We've had the entire linecard down on ASR9k due to BFD, their BFD-of-death packet you can send over the internet to crash JNPR FPC.</div><div class="gmail_default" style="font-family:monospace,monospace">When done in a control-plane, poor scheduling can cause false positives more often than it protects from actual outages (CISCO7600).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">In a world where BFD is perfect you still need to consider what you are protecting yourself from, so you bought Martini from someone and run your backbone over that Martini. What is an outage? Is your provider IGP rerouting due to backbone outage an outage to you? Or would you rather the provider convergees their network and you don't converge, you take the outage?</div><div class="gmail_default" style="font-family:monospace,monospace">If provider rerouting is not an outage, you need to know what their SLA is regarding rerouting time and make BFD less aggressive than that. If provider rerouting is an outage, you can of course run as aggressive timers as you want, but you probably have lower availability than without BFD.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Also, don't add complexity to solve problems you don't have. If  you don't know if BFD improved your availability, you didn't need it. </div><div class="gmail_default" style="font-family:monospace,monospace">Networking is full of belief practices, we do things because we believe they help and faux data is used often to dress the beliefs as science. The problem space tends to be complex and good quality data is sparse to come by, we do necessarily fly a lot by the seat of our pants, if we admit or not.</div><div class="gmail_default" style="font-family:monospace,monospace">My belief is the majority of BFD implementations in real life on average reduce availability, my belief is you need frequently failing link which does not propagate link-down to reliability improve availability by deploying BFD.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">  ++ytti</div></div>