In the previous video we configured external BGP and we started learning routes
coming in from
R21 and also routes that were advertised via BGP from R31. So those are both
external BGP neighbors
of R11. And one of those routes was a loopback that's being advertised over
here in AS20 and that's
22.22.22. And as that route was advertised by R21, the ASPath attribute simply
included ASPath 20,
which had gone through and as it was advertised down here, down here and then
up to R11 this way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up to R11 this way.
And as that route was advertised up here, the ASPath that included 30 because
it had gone through AS30
and also gone to AS40 and also gone through AS20 where it was sourced. So R11
chose the route that went
or to R21 because all other things being equal, ASPath was shorter on the route
it learned from
R21 compared to the route it learned from R31. And another attribute that
shipped over when it
routes are advertised is an attribute called Next Top. So in R21, advertised
that route for 22, 22, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that route for 22, 22,
22, etc. One of the attributes besides the ASPath was Next Top. And so the next
top in R21
advertised that would be its own IP address. So the next top value would be 23.
10.20. And this is 21. So
it would be .21. Now that's not a problem for R11 because R11 knows how to get
to that Next Top.
It's directly connected to that network segment. However, as that route is
being advertised inside
of the Atom System 10 here and when R12 learns about 22, 22, 22, 22, that Next
Top of 23.10.20.21 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Top of 23.10.20.21
is carried with it. It doesn't change. So here when that route is being
advertised from R11 to R12,
it's going to have the ASPath of 20. That's not going to change. It was still
sourced from AS20.
It's also going to keep the same Next Top information. So it's going to show
Next Top of 23.10.20.21.
That's this interface address right here. And that's going to cause a problem
here in this
lab apology because R12 inside the Atom System, it does not have a route for
that Next Top of 23.10.20.21. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that Next Top of 23.10.20.21.
And as a result, because it doesn't have a route for that, it's going to go
ahead and say, "Well,
I see the route in BGP and the BGP routing information base, but I'm not going
to add it to my
routing table because I don't know how to get to the Next Top." So we can
verify that by taking a
quick look at R12. So here on R12, let's go over to R12 and let's do a show IP
BGP. So there's the 22, 22, 22 network.
We're missing that symbol, meaning none of these routes are considered best.
And there's our Next Top of 23.10.20.21.
So one way of addressing this is we could tell R11. You know what? R11, when WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So one way of addressing this is we could tell R11. You know what? R11, when
you receive this route from
an external BGP neighbor and they have the Next Top, instead of just keeping
that same Next Top as you
send it into your internal BGP neighbors, go ahead and simply modify that value
, that Next Top value,
and just say it's your own address. In this case of R11, there'd be 11 to 11 to
11 to 11 to 11. And that
way when R12 receives it and sees the Next Top is 11, 11, 11, 11, 11, 11, they
'll say, "Oh, you know
what? I didn't have to reach that." And then it can go ahead and consider that
to be a valid route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be a valid route
that it can put inside its routing table. And by valid route, meaning it's a
route that it can use
and it would put a little symbol next to it indicating it's the best route. So
to implement this,
we simply modify the configuration on R11 and just tell it, "Hey, listen, as
you forward updated
routes to your peers R13 and R12, which are both IBGP peers, go ahead and
simply modify the Next Top
and make it your own IP address." Instead of the original Next Top value that
you receive. Now,
that's the only happening when we send it to internal peers. We need to modify
that because
when we send that route, for example, from R11 to another external BGP neighbor WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when we send that route, for example, from R11 to another external BGP neighbor
, we're automatically
going to go ahead and use whatever our egress interface IP address is and
modify the Next Top to
that value. So changing the Next Top value is important for these edge routers
here before sending
updates to other internal BGP neighbors. So let's head over to R11. We'll
modify our
neighborship to R13 and R12 and specify we're using our own Next Top address
for the updates that we
send out. And then we should see the difference show up here on R12 and R13.
All right. So let's just
do a quick verification. In fact, I'm going to use this option right here. The WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
do a quick verification. In fact, I'm going to use this option right here. The
little send commands
to multiple routers at the same time. And I'm going to do a show. And then we
'll do a few spaces
there to clear the screen a little bit. Let's do a show IP BGP and press Enter
and then we'll send
that to R12 and R13 and we'll send that out. Great, great, great. So there's R
12. There's the 22
network with the Next Top of 2310 2021. And if we look at our 13, same thing.
We have that route
to 22222222 that BGP information with the Next Top. But also in R13, R13 doesn WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to 22222222 that BGP information with the Next Top. But also in R13, R13 doesn
't have reach
really that Next Top. So it's not considering that a valid route. So let's go
to R11 and change
the rules. Now, an easy way to do this is to do a show, run, pipe, section. And
you can do router or
if you just want to see the BGP, BGP. And then from here, we'll just copy and
paste router BGP.
And then we want to modify the neighbor 12, 12, 12, 12. And we're going to say
Next, Hop,
self. And we'll do the same thing for 13. So we'll copy and paste neighbor 13 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
self. And we'll do the same thing for 13. So we'll copy and paste neighbor 13
13 13 13 13
and say Next Top self. And then let's take a look at our config. So we'll do a
show, run, pipe,
section, BGP, press Center. So now when we're sending updates to R12 and now
when we're sending
updates over to R13, instead of leaving that original Next Top attribute, we're
going to change it
to R11's address. And in a production environment, it would be wise not to do
what I'm about to do.
But because it's a lab, it'll be okay. I'm going to go ahead and do a clear IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But because it's a lab, it'll be okay. I'm going to go ahead and do a clear IP
BGP
asterisk. And then I'm going to apply that to 11 12 and 13. And it's going to
take probably a minute
or two for the whole thing to converge and to get those routes all ready to go.
But I want to just
verify that we have a nice clean config. And we're not hanging on to any older
information. So if we
head over to R12 and we do a show IP BGP summary, currently what this says is
that R12 has not
learned any routes based on this last column states/prefix received. We haven't
learned any routes yet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
learned any routes yet.
But they're coming. So if we hit that bar of key, we can simply wait. We can
also show IP BGP.
And currently there's nothing there. But once we have received the prefixes,
they should show up
here as account. And we should also be able to show IP BGP. And that's up there
as well. But again,
it may take a minute or two for it to converge. So we'll give it a moment. Let
the upper key show
IP BGP. Ah, there they are. So fantastic. So if we hit the upper key a couple
times and do a show
IP BGP summary, notice that we have received three prefixes from our peer 11 11 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
IP BGP summary, notice that we have received three prefixes from our peer 11 11
11 11 which is R11.
So now if we do a show IP BGP right here next to all three routes, we have that
greater than
symbol, which means best path. And check it out. The next top is 11 11 11 11,
which is R 11,
which we know how to get to. So now these three BGP learned routes. They should
also be showing up
in the winner's table, the routing table by doing a show IP route and pressing
enter.
And in fact, we go ahead and do a show IP route and filter that to just BGP
learned routes.
And there they are right there. The 22 network, the 32 and the 43, which are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there they are right there. The 22 network, the 32 and the 43, which are
the loop backs over on
router 22, router 32 and router 43. Now, should we be able to ping those
addresses we have routes?
Should we be able to ping them and get a response pack? And the answer is no.
And the reason is
because we have those routes. So router 12 knows how to forward in that
direction R 11. But what happens
though, if we ping the loop backs on R 22 or R 43 or R 32, unfortunately, those
other autonomous WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
other autonomous
systems have no clue how to get back here to the 10 12 address space or 10 11
address space
or the 12 12 12 address space. So if you want to do a ping, for example, from R
12 and is loop back
over to AS 20 or AS 40 or AS 30, we also want to make sure we're advertising
those networks inside
of BGP so that the other autonomous systems in the routers there would know how
to forward back.
So right now, if we went to R 22, for example, and we did a show IP route,
there's no information here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there's no information here
about any networks over at a ton of system 10. So the loop back on R 12 is 12
12 12 12. It's not
here. So we sourced the ping from 12 12 12 and it was coming over here to R 22.
R 22 would not know
how to respond. And to verify that, let's go to R 12 and let's do a ping over
to 22. 22. 22. 22. 22. 22.
We'll source it from our loop back zero. And those pings are reaching the
destination. But the
responses are not coming back. So that'll be our next step in the next video is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
responses are not coming back. So that'll be our next step in the next video is
how do we advertise
and network in BGP. I'll see you in that next video in just a moment.