In the previous video, we took a look
at using BFD in combination with EIGRP to make it even faster.
Well, in this demo, I'd like to walk you
through how we can use BFD--
bi-directional forwarding detection--
to improve the ability for two BGP speakers,
who appeared with each other to identify, hey, party's over,
and not just wait for the normal time outs that BGP has,
based on its routing protocol.
So here's the topology we're going to be using in this demo. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here's the topology we're going to be using in this demo.
And it goes something like this.
This is still interface gig 0/2.
This is 0/0, and this is 0/0.
And currently, OSPF and EIGRP are running.
Also, all the interfaces are enabled for the BFD,
which is all fine and good.
But we're going to also add an element of BFD with our border
gateway protocol.
So here's the config that we're going to implement.
And we're going to make R4 and R2 interior or internal BGP
neighbors.
And there are several ways of doing that, actually. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there are several ways of doing that, actually.
There's lots of options with BGP.
But here's how we're going to fly in this demonstration.
And make sure my face isn't on top of there.
Good.
BGP configuration mode for 673 on both sides.
That means we are internal BGP neighbors.
We are specifying the neighborships
pointing to the outside IP address of 10.24.0.2 and 4,
respectively.
And I'm also adding, for that neighbor, all over BFD.
And that means that if we lose--
when we're running BGP, and we use this option here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when we're running BGP, and we use this option here,
and we have the interfaces configured
for BFD, which we've done previously
with EIGRP and OSPF-- so those are already in place.
If we add this here, then if there's a failure of BFD,
this BGP neighborship can immediately
know there's a problem instead of waiting on the normal time
outs for the BGP session.
So that's the relevant portion for this config.
And we'll put that in at R2, and also on R4.
And then we'll do some show commands
to verify that it's working. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to verify that it's working.
So we'll go to just grab all that.
Right click.
Copy.
Go to R2.
Maybe put it on the right router and paste.
And then we'll go grab the config for R4.
Right click.
Copy.
And on R4, right click and paste.
And let's use some BGP commands.
So we'll do a show IP BGP summary. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll do a show IP BGP summary.
So there we go.
Ah, there we go.
So what-- so the idle was-- they were not fully neighbored up.
And so now the neighborship is up.
And check it out right there.
There's a BFD session for it, as well.
So if we were to do a show BFD--
still cracks me up.
Show BFD neighbors, and detail, and press enter.
And we'll go down to the neighbor that's 10.45.0.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll go down to the neighbor that's 10.45.0.4.
Oh, no, no.
I'm on R4.
So let's scroll up here.
We want to go to the one that's the neighbor of 10.24.0.2,
which is this bad boy right here.
So if we go down just a little bit,
take a look at all the protocols that are associated with BFD.
We have EIGRP paying attention.
We have OSPF paying attention.
And now, BGP paying attention.
So if we have a failure on this link-- which we can simulate,
again, here on the switch--
and we can do a--
in fact, let's just one more time
to do a show BFD neighbors. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to do a show BFD neighbors.
So everything's up, up, and happy.
So on the layer 2 switch, if we go
into interface config for gig 0/0, and we do a shut down--
we're going to add a whole bunch of losses--
OSPF, EIGRP, and the BFD session, as well.
And as a result, it's not going to take the full minute
like it normally would for the two BGP neighbors
to realize there is a problem.
So if we go back to R2, for example, and look at that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we go back to R2, for example, and look at that.
It just knows everything's bad.
OSPF, no.
BGP, no.
EIGRP, no.
So they all know that the first no is a N-O,
and now they all K-N-O-W.
They all know there's a problem, because they were all
paying attention to BFD, and the BFD failed.
Go to show BFD neighbors.
The one between us and R4 is down.
And all the routing protocols that were paying attention
to that BFD session-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
now they all know.
OK, there's a problem.
We're bailing.
And then they can go ahead and converge that much faster.
That's the power of BFD.
So let's take a look next, at one more demo I'd like to do.
And that is using BFD with a static route.
That way, if the next hop isn't reachable, we can use BFD,
and we can simply have that static route pulled out
of the routing table if that next hop, for whatever reason,
is no longer reachable.
So we'll do that in the next video.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.