The concept of bidirectional forwarding detection or BFD, this is something
that is typically
used alongside routing protocols and it's not tied to any particular routing
protocol.
It is actually considered to be out of band of these routing protocol
operations.
And the idea is to provide assistance.
We want to provide our assist on routing protocols with the ability to very
quickly detect outages.
So it's going to help us perform outage detection in a way that routing
protocols aren't able
to do natively, not nearly as well.
So here's exactly what we're talking about.
Let's say we have two routers and they have some network in between them.
This is a layer three connection.
And in this case, let's just say that we're running OSPF.
So these are OSPF adjacencies and they're sending out hello messages in order
to make
sure that the other side knows that they're still there.
Well what happens when we have a break in this layer three network?
We're going to have to wait on the concept of a timeout.
And so we're sitting there waiting for the next hello to come through.
Let's just do it from this router's perspective.
We're waiting for that hello to come through and the halo is not coming through
and it's
not coming through and it's not coming through.
So how long does this take?
Well depending on the routing protocol, it could take a long time.
It could actually take minutes.
For example, OSPF by default on this type of network link might be 40 seconds
that we
have to wait to know that part of our network is down, which is too bad because
otherwise
we could maybe redirect around this.
Now also keep in mind this assumes that there's some maybe layer two switch in
here so that
this router thinks that that connection's still online.
If the link goes down, we can react immediately.
But what if the link is still up and yet we've lost the other side?
And maybe this whole device just reloaded.
We don't know what happened.
We just know we have to wait for us to detect that there was an outage.
So we could tune this.
Well option one is to tune OSPF.
In fact, OSPF will allow us to get down to very low amounts of time.
We might say, hey, I want to tune the hello timer all the way down to one
second.
So now instead of 40 seconds, maybe I'm waiting for seconds.
But even this is too long.
And furthermore, there's a lot of information inside of us sending these hello
messages.
And it takes a lot of time to process the other side when everything is working
correctly.
And so the idea here is to use a protocol.
Let's just say it's bidirectional forwarding detection to start to solve both
of these
problems.
For one, we want to make sure that, well, I guess this is option number two
here, do
is BFD.
We want to make sure that, first of all, we are sending these fast.
And BFD allows us to send hello messages at the millisecond interval.
So we don't have to wait full seconds in order to send hello messages as well
as to process
it and detect outages.
But then the other thing is it's going to be lightweight.
We want to avoid the processing time of the protocol of the packets being sent
when everything
is in steady state operation.
Want to get rid of this concept here, where it's constantly receiving messages
and having
to process them and more or less answer back and say, yes, I'm still here.
So that's exactly what BFD is going to accomplish.
And this allows us, by the way, to tune OSPF back to say, hey, just send your
hello messages
every 10 seconds, that's perfectly fine at this point, because BFD will tell us
when
things are down.
So now on top of OSPF still sending its hello messages, but now let's say it's
every 10
seconds, we are now going to also send BFD messages constantly to the other
side.
Now if this side still had to process all of that, that might not be a great
thing, even
if it is more lightweight, and so BFD actually uses the concept of echo mode.
This is very important to BFD because what's going to happen is the packet is
going to
arrive on this rider's interface and because it's also configured for BFD, it
doesn't
have to actually do anything.
Its job is simply to echo the same message back to the other side.
That way the message device like this on the left, sending a BFD packet, when
it gets its
own packet back in response, that is itself the response to the hello message.
This echo concept couldn't have happened if the router was down.
And so BFD is going to again achieve both of these goals.
And the cool thing about this is it can be used with multiple routing protocols
.
Because it's not tied to any specific protocol, meaning I can use it with EIGRP
and OSPF and
even BGP.
And yes, we can use it with OMP.
So let's now talk about how we're going to use BFD in SDWAN.
We're going to find that there's two purposes for it.
But first of all, where exactly is it used?
Well, when we have an SDWAN edge device, and let's say there's another edge
device over
here, and maybe we'll just say that there's two WAN service providers, service
provider
A, service provider B.
So we've got our circuits going to both of these WAN circuits.
Well, we've got up-struplinks to both of the WAN clouds, and now we're going to
build
our IPsec tunnels.
So we build the IPsec tunnel from the WAN edge on the left to the WAN edge on
the right,
and we do so through each circuit.
So now what we're going to do is we're going to run BFD here inside of those IP
sec tunnels.
So we build IPsec tunnels.
I'm going to be sending BFD messages back and forth on both of these.
So that is where BFD lives.
Now what are we trying to accomplish with it?
First of all, we're trying to accomplish the concept that my peer is alive.
Now one thing to keep in mind, that we mentioned, is that yes, we can use it in
concert with
OMP.
However, these two devices are not OMP neighbors.
So we can use it to make sure that our controllers are alive, but we do still
want to make sure
that the peer is alive independent of OMP.
So keep that in mind.
So we're trying to make sure the peer is alive, but here's the big thing that
we're going
to use it for.
We're going to use this to track the metrics specifically for the quality of
the link.
It's really easy to detect when a link is up or down.
As long as it's directly connected and the link goes down, then I can
understand that
I've got to redirect everything out the other side.
And certainly if the other edge goes down, again, VFT is going to help me
figure out
that the other side went down very quickly.
So either way, if I know my connection doesn't exist, then I can redirect
traffic out the
other side and everything is good.
Here's what's a lot trickier.
It's a lot trickier to recognize that Circuit Provider A is having a bad day.
And all of a sudden we're at hundreds, if not thousands of milliseconds of
latency on
that link.
But from a routing protocol perspective, the Hello packets are still going
through.
And so we're going to keep sending traffic out to WAN Circuit A, even though
there are
major problems happening.
Clearly they're having some issues that they're trying to figure out.
Well, I as the customer would want to stop sending things out to WAN Circuit A,
if it's
having those hundreds or thousands of milliseconds of delay, and redirect all
of that traffic
out a WAN Circuit that isn't having that problem.
And so that's great that I might want to do that.
But how do I know from a network perspective that these things are happening?
Well, BFD is going to be the answer.
By running BFD back and forth, I actually see that, hey, I sent this message at
whatever
timeframe this was, let's just call it the zero basis.
And then I got a response back and that took, I don't know, 10 milliseconds.
Okay, no problem.
That's cool.
Except now it's up to 20 milliseconds.
Well, 20 milliseconds as a latency isn't terrible, but notice the jitter that's
happening here.
This is actually, actually, wait, no, that would actually be very consistent j
itter.
Jumped ahead.
So we increased it by, you know, took 10 milliseconds to come.
It took 10 milliseconds to come.
But now it takes a really long time to come and we don't get a response back
until the
100 millisecond mark.
Well this was 10 milliseconds and this was 10 milliseconds.
Now it took 80 milliseconds for it to come back and that is the jitter concept
that can
start to develop where the latency is not consistent over the course of time.
So BFD is going to help us a lot.
It's going to help us with the up down status, which is very important in and
of itself,
of course.
But then we're also going to be able to measure loss.
How many of my BFD messages never made it back?
We can also take a look at the latency measurements.
And as we just saw, we can even calculate out jitter, which impacts our voice
over IP
communications by paying attention to the latency measurements over time.
We can also use this by the way to measure MTU.
What is my maximum transmit unit size as well as what is the tunnel status?
So quite a few things that we can track thanks to using BFD across our IP sec
tunnels and
it goes well beyond BFD's original purpose of simply measuring whether
something is
up or down.
Now at the end of all of this, what ends up happening is that the edge device
is going
to take all of this information, all of these metrics.
It's going to report it back to the controller.
So our C here, our V smart, as we used to call it, and we're going to report it
back
using OMP.
So that is how we report the information back to the rest of the SD-WAN
environment.
And then the manager can potentially push policy down via the V smarts to let
our edge
devices know what exactly they should be doing about it.