Now it's time to fire up the virtual lab
and see rule number 2 in action.
My challenge to you is open the virtual lab
and get the topology setup where everybody
has an iBGP peering with R2.
We don't have to worry about a full mesh topology again.
That's what route reflectors are looking to solve.
And we're not sharing any networks yet.
And you don't even have to worry about configuring the route
reflector.
That's what we're going to cover.
So get the virtual lab stood up, and then make those neighbor
relationships come to life.
And then join me as we go through rule number
2 of Route Reflector Clients.
I'm back on R2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm back on R2.
And if I give it a show bgp ipv4 unicast summary,
we can see I've got my neighbor relationships here,
and I'm not advertising any prefixes at this point.
What we want to do is we want to advertise a network from R1
and have it bounce everywhere.
So we need to make sure that R1 is a client, a route reflector
client, to R2.
So from R2-- whoop.
You've got to say conf t, not cong t.
We'll go to router bgp 100.
I'll say neighbor 1.1.1 to modify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll say neighbor 1.1.1 to modify
how our neighbor relationship is going to behave.
And I'll say route reflector client, press Enter.
I'm going to watch the neighbor relationship bounce here
for a second.
Goes down, topology change.
And then after just a moment, the neighbor relationship
comes back to life.
There it is.
Hit up a couple times.
Show me the summary.
There we go.
I see that everything is back up and running.
Four messages have been sent back and forth.
Now it's time to advertise a route
from 1.1.1.1 towards 3.3.3.3 and 11.11.11.11. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from 1.1.1.1 towards 3.3.3.3 and 11.11.11.11.
So what I'm going to do to make this a little bit cleaner
this time is from R1, I'm going to create a new loopback
address.
We'll call this loopback 0.
And I'll just give it an IP address
of something like 15.15.15.15, mask of 255.255.255.255,
no shut.
And that's what I want to advertise towards R3 and R11.
So jumping back to--
I always type end.
It's such a natural habit to me.
I'm going to jump back into router bgp 100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to jump back into router bgp 100.
I'm going to advertise network 15.15.15.15
with a mask of 255.255.255.255.
Press end.
So to validate that R1 is advertising 15.15.15.15,
I'll do show bgp ipv4 unicast neighbor towards 2.2.2.2.
Oop, too many dots.
Advertised routes.
And I see it's advertising 15.15.15.15. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I see it's advertising 15.15.15.15.
Let's jump over to R2.
And we'll give it a show bgp ipv4 unicast summary.
Looks like I'm receiving a prefix from 1.1.1.1.
If I just delete the summary, we can see--
well, here we go.
We've got this issue again, where
we've got the 15.15.15 route, but there is a RIB failure.
Let's check out show ip route to see what's going on.
And you know what the thing is?
I used OSPF to grab all networks.
And at this point, the OSPF route
is winning because the administrative distance, 110, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is winning because the administrative distance, 110,
is lower than what BGP would advertise.
So if I manipulate the OSPF distance for just a minute--
we can go to router ospf 1, and I can say distance.
Set it to something like 201.
I'll press end.
Now when I check out my unicast, ah.
Now I've got the installed best route.
And if I do show ip route, look at that.
I now have the BGP learned route of 15.15.15.15.
That's just a little troubleshooting tip for you. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's just a little troubleshooting tip for you.
The administrative distance here was 200, which is 1 less
than 201.
But the real thing that we're here to look at
is what happened on R3 and R11?
Were the routes reflected towards R3 and R11?
If I jump to R3, I'll do show ipv4--
not r, 4-- unicast summary.
Ah, 2.2.2.2 did, in fact, bounce a prefix towards us.
And if I tap up, delete the summary,
there is the 15.15.15.15.
Again, there's a RIB failure because OSPF WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again, there's a RIB failure because OSPF
administrative distance hasn't been changed at this point.
But that's rule number 2 in action,
routes learned from a client will be reflected everywhere,
including to non-clients.
I hope this has been informative for you.
And I'd like to thank you for viewing.