And now it's time to jump in the virtual lab
and make sure that we understand the third rule of how
route reflectors work.
In this case, they don't really do anything because EBGP
behavior, it remains the same.
When a route comes in from EBGP, it
goes to all the IBGP neighbors.
And when routes come in from IBGP,
it gets advertised out to EBGP neighbors.
Let's jump in the virtual lab and verify that we
understand that behavior too.
At this point, I've stood up our IBGP relationships.
I'd challenge you to launch the virtual lab and do the same.
If I do a summary real quick, not the unicast, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I do a summary real quick, not the unicast,
I can see I've got my neighbor relationships here.
I'm on R2.
I've got 1, 3, and 11 all paired up.
Let's go ahead and build a relationship now
towards R4, this time being an EBGP relationship.
I'll go into router BGP 100--
move my mouse a little bit.
We'll say neighbor is going to be--
let's go out the external link 100.100.24.4.
Remote access is going to be 200.
It's more common to peer based on the directly connected route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's more common to peer based on the directly connected route
when it comes to EBGP anyways.
My neighbor relationship comes alive, and there we go.
I'm now paired with R4.
If I type end and I give it a show BGP IPV4 unicast,
we'll press Enter here.
I see that R1 is advertising a prefix of 15.15.15.15 to me.
So if I go to R4, I would assume that R4
would see that NLRI being advertised out EBGP.
So if I give it a show IPV4, unicast, there we go. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if I give it a show IPV4, unicast, there we go.
The EBGP behavior works exactly as expected.
We received the NLRI and the next hop address
has been changed to be R2's locally connected address.
Now what I want to do is I'm going to give this
a show IP interface brief.
And I see that I have this address here--
100.200.45.4.
This is the link between R4 and R5.
I want to advertise that down to AS100.
So I'm going to go into configuration mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm going to go into configuration mode.
I'm going to go into router BGP 200.
BGO-- BGP 200.
I'm going to advertise that network.
It's 100.200.45.4 mask 255.255.255.0 Nope,
that's not the correct mask.
Let's do show IP interface gig 00 and get the correct mask
here.
So right here, I see that my address is 100.200.45.4/29
on the interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on the interface.
Let's go ahead and give that network command a run.
We'll say network 100.200.45.0 because that's the network
address we're talking about.
The mask for [INAUDIBLE] is 255.255.255.248, I believe.
Yeah, that's what it is.
Press Enter, End.
Let's give it a show BGP IPV4 unicast neighbor 100.100.24.2
advertise routes.
Let's make sure it's advertised.
There it is.
It's being advertised. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's being advertised.
We can jump over to R2, run the summary one more time.
I see that I've got an advertised route here.
So based on EBGP behavior of routes coming in,
I should now expect to see this rule at least in the BGP
database for R1.
Let's do show BGP IPV4 unicast.
And look at that, there's the route right there.
And because I had already configured next hop self
to be R2, it is a valid and installed route.
I can give it a show IP route and I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I can give it a show IP route and I
see the BGP learned route right here in my routing table.
So that is the behavior for rule number three
of how EBGP sessions are handled when
it comes to route reflectors and route reflector clients.
I hope has been informative for you,
and I'd like to thank you for viewing.