Now it's time to fire up the virtual lab
and see rule 1 of route reflectors in action.
My challenge to you is fire up the virtual lab
and just get basic neighbor relationships set up to R2.
Don't build a full topology yet, because that is what
route reflectors looks to save.
So here I am on R2.
I can give it a show bgp ipv4 unicast summary.
And we'll see pretty quickly I have neighbor relationships
with 1.1.1.1, 3.3.3.3, 11.11.11.11.
Let's jump over to R3 for a second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's jump over to R3 for a second.
Let me bounce out of configuration mode.
Give it a show bgp ipv4 unicast summary one more time.
It only has neighbor relationships on 2.
Let's advertise an NLRA of our loopback address, 3.3.3.3,
towards R2.
I'll go into router bgp 100, and I'll
specify my network of 3.3.3.3, mask of 255.255.255.255.
And at this point, it should be advertising
the 3.3.3.3 network towards R2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the 3.3.3.3 network towards R2.
If I bounce out, I can go to R2.
I'll run the exact same command again, showing that summary.
And I see that now, I've received a prefix.
So at this point, I would expect that none
of the other neighbors, 11 or 1, have received that prefix.
Let's give it a show bgp ipv4 unicast summary.
And I see here, I've got a neighbor relationship
with 2.2.2.2.
But I'm not receiving any advertised NLRIs.
Does R11 hold the same truth to it? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Does R11 hold the same truth to it?
Let's do show bgp ipv4 unicast summary.
And sure enough, there is my neighbor relationship
with 2.2.2.2.
But no prefixes received.
That illustrates that rule of iBGP, that none of these routes
will be forwarded along, unless we configure a route reflector.
So in our scenario, we had R3 here, peered with R2.
And we wanted it to bounce routes
learned from R3 over to R1.
There was also R11.
So R1 will be our client. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So R1 will be our client.
R2 will be our route reflector.
And these, R3 and R11, will be non-clients.
And rule 1 specified that when R3 advertised
a route, a non-client advertised route,
it would only be forwarded into clients.
So to configure R1 as a client, from R2,
we'll go into configuration mode.
We'll say router bgp 100.
That's our instance.
And all we have to do is say neighbor
1.1.1.1 route reflector client. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1.1.1.1 route reflector client.
Hit Enter.
And that's it.
Look at that.
It bounces the topology, though.
You see, we've had an adjacency change.
And now the neighbor relationship comes back up.
I'll exit out of configuration mode.
And I'll give it a show bgp ipv4 unicast neighbor 1.1.1.1.
And now, if I scroll down just a hair
in the second section for address family IPv4 unicasts,
we can see that we've configured neighbor 1.1.1 as a route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can see that we've configured neighbor 1.1.1 as a route
reflector client.
This is another key talking point.
Route reflectors are configured for each address family.
So just because we configured 1.1.1.1
as a route reflector client, it's only applied to IPv4.
If we also wanted to apply that to, say, IPv6,
we would have to go into that address family and fix that up.
Let's go back to R1 for a second,
and let's check out the summary one more time.
Now I see that I've got a prefix that's being advertised to me. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now I see that I've got a prefix that's being advertised to me.
If I give it a show bgp ipv4 unicast without the summary,
I see the route that's being sent here is 3.3.3.3.
Interestingly, though, it's not installed in the IP routing
table because we had a-- what's the code right here-- a RIB
failure.
Look at that next hop.
The next hop is the address that we
learned after all, because we set the source updates to be
3.3.3.3, and that's what gets advertised out,
another nuance of BGP that you need to know.
When you do an update source command, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When you do an update source command,
that's the route that it's going to advertise as the next hop.
So what we could do to fix this is we
could use a route map, which we're
going to talk about in a later series of skills.
And that's really what you would have to do.
Because I know where your head went.
Your head went, oh, we'll just do next hop self, right?
Let's go into router bgp 100, neighbor 1.1.1.1,
next hop self.
And that should fix it.
But check this out.
If I go back to R1, I run this command a few more times.
No, it's not updating the route.
It's still not passing that RIB check, is it? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's still not passing that RIB check, is it?
That's because the route reflector is a reflector.
It's not advertising a route that it learned.
It's literally bouncing off.
So when 3.3.3.3 advertises the next hop of 3.3.3.3,
it's literally bouncing off of R2 over to R1 unchanged.
To fix this, we would have to use a route
map to change the next hop address as it's coming in.
That's going to be one of those inbound policies.
But this has demonstrated part of rule number 1,
which is that routes learned from non-clients WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is that routes learned from non-clients
are reflected to clients.
Let's validate this by also checking out
what's going on over at R11, another non-client.
Did R11 in fact receive a reflection from R3?
Jumping over to R11 one more time,
I'm going to run the summary command one more time.
And you can see, there it is.
No prefixes received or reflected down to a non-client.
So that finishes up rule number 1.
In the next Nugget, we're going to talk about rule number 2.
In the meantime, I hope this has been informative for you. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In the meantime, I hope this has been informative for you.
And I'd like to thank you for viewing.