In the previous Nugget, we set up a pretty big nuance
between EBGP and IBGP.
When EBGP advertises routes to its partner,
it will change the next hop address
to be our next hop address.
So if we're AS100, and we're advertising a route to AS200,
we will set the next hop address to be our address
that the router it's coming from.
So that way the EBGP peer knows how to get back
to what we're advertising.
But when it comes to IBGP, we're not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But when it comes to IBGP, we're not
changing the next hop address.
So if a route comes in from EBGP,
or if we learn a route from IBGP,
we aren't changing the next hop address.
That created a problem for us.
Remember this problem?
Yeah, remember this scenario here?
When R4 advertised it's loop back down to R2,
it made sure to set the next hop address to be the exiting IP
address towards R2.
R2 received this route, had no problem WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R2 received this route, had no problem
because it could reach the next hop address,
but then it sent the advertisement over
to R1 naturally, but it didn't change the next hop address.
Because R1 can't reach this interface on R4,
it didn't install the route in its routing table.
It said, this isn't going to work for me.
This isn't a best path.
0 what we need to do is we need to get
R2 to change the next hop address to be its interface, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R2 to change the next hop address to be its interface,
and luckily for us, this isn't that
hard of a task to accomplish.
So firing up the virtual lab, we can jump over to R2.
And my challenge to you is stand up the virtual lab,
getting it to a point where it's formed neighbor relationships
and R4 is sharing its loopback address.
This is great for really nailing down the commands
and building that muscle memory.
Once that's stood up, we can go back into R2, router BGP100,
and now we can alter how our relationship with R1 works. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and now we can alter how our relationship with R1 works.
Routes that we advertise towards R1,
we can automatically tell it to change the next hop
address to be our own address.
The command looks like this.
We'll specify our neighbor of R1, 172.16.12.1,
then we'll specify next hop self, press Enter,
and that's it.
We've done the trick.
Now routes that we advertise only to this neighbor, that's
a key thing about BGP.
Remember, BGP is super delivery.
It's not going to set next self everywhere. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's not going to set next self everywhere.
It's only going to be the neighbors that we specify.
Now in this case, the routes that we send over to R1
will have a next hop address of our exiting address.
So if I jump back to R1, I'll run show IP BGP again.
And we do have to wait sometimes for this to refresh.
Let's give it a minute to refresh.
There we go.
Look at that.
Now we've tacked on the little sideways carrot
there that we've needed that says this is best,
and if I check out show IP route,
I now see that this route has been installed. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I now see that this route has been installed.
Let's take a look at the topology one more time.
We've got R1, R2, and all the way up to R4.
What I propose we do is I propose
we advertise the loopback address on R1 up to R4.
R1 will advertise this address naturally over
to R2 with the correct next hop of R1's address.
But because R2 will then advertising via EBGP,
it would change the next hop address going up to R4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it would change the next hop address going up to R4.
So clearing the screen, I'll go into Configuration mode,
will go Router BGP100, and we'll specify our network 1.1.1.1
mask of 255.255.25.255.
Press Enter.
Let's jump over to R2.
Let's give it a show IP BGP.
I see that we have learned about 1.1.1.1,
and it's got a correct next hop address.
Let's verify that we can ping 1.1.1.1.
Looks good.
Round trip. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Round trip.
And because we understand how EBGP verse IBGP works now
with next hops, we don't have to specify a next hop self
when we're going towards R4.
That's an EBGP relationship.
And routes that we've learned internally through IBGP
will be advertised out externally
with the correct next hop.
So if I go to R4, I'm going to run show IP BGP,
and look at that.
There is the valid route to R1 with a next hop address using WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There is the valid route to R1 with a next hop address using
R2's next hop address.
So from R4, if I ping 1.1.1.1, and make
sure to specify a source of loopback 1, hey, look at that.
Round trip.
We have now conquered one of the big nuances
of EBGP versus IBGP.
And that's how the next hop address is handled.
While we've got this output pulled up from show IP BGP,
it's now time to talk just a second about how
it chose to send that route.
How BGP chooses what's the best path to send something to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
How BGP chooses what's the best path to send something to
is quite complicated.
There are a tremendous number of factors going into it.
Things like the weight plays into it.
The local preference plays into it.
The metric plays into it.
But if we don't change anything, what it defaults to
is the path.
You know how RIP chooses the best path,
is by hop count from one hop to the next in the least
amount of hops is how it chooses the best path in RIP.
Well, BGP isn't terribly unlike that.
It looks at hop count, but for AS's. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It looks at hop count, but for AS's.
It's kind of like the AS hop count.
And what we're looking at here in path
is the paths of AS's that it traverses,
so maybe one day we'll see a path that looks like 200 100 i.
From the router's perspective, this
would go through autonomous system 200 before it gets
sent to autonomous system 100.
Every time an EBGP advertisement takes
place, the exiting autonomous system is added to the list, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
place, the exiting autonomous system is added to the list,
and the receiving router then sees how many paths
it has to go through.
All of these things here that we're looking at
are called path attributes.
So when a network statement is run,
it advertises the prefix plus path attributes.
The prefix and path attributes combined
together are called and NLRI, that
stands for network layer reachability information.
Now we're going to dig into this stuff, especially WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now we're going to dig into this stuff, especially
path attributes, a lot more when we
start talking about filtering with route maps,
as well as manipulating the best path algorithm.
What I wanted you to see now is, first of all,
how EBGP verse IBGP handles the next hop address,
as well as how it determines which
path it's going to install in its routing table.
The next Nugget is going to dig a lot more into how in LRIs
are both received and sent on a router running BGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are both received and sent on a router running BGP.
In the meantime, that's been further understanding
EBGP verse IBGP.
I hope this has been informative for you,
and I'd like to thank you for viewing.