There are three rules to working with route reflectors and route
reflector clients though.
We've covered one of them.
What happens when a prefix or an NLRI
comes in from a non-client?
Now what we need to talk about, is
what happens when an NLRI comes in from a client.
Let's jump on the whiteboard and set up the scenario
and talk about how route reflectors are going to behave.
In the previous Nugget, we demoed
how to configure a route reflector client.
From the route reflector itself, in this case, R2,
you simply modify your neighbor relationship WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you simply modify your neighbor relationship
with the command, route reflector client.
And that's it.
That's all there is to configuring a route reflector.
It's the behavior that really matters.
We demoed what happens when R3 advertised around in.
Because it was not a client, it forwarded the route to R1.
But now what we need to talk about
is what happens when R1 advertises
a route towards a route reflector client.
What it does at this point, the route reflector
will advertise this route everywhere. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
will advertise this route everywhere.
It will even bounce the route back to R1.
Yeah, that's absolutely right.
In this case, the route reflector
will reflect routes towards clients
and towards non-clients.
Because R1 sees that it originated the route,
it's going to discard it as a loop
and not install it in the local routing table
in the first place.
So recap.
From non-clients go towards only clients.
From clients go towards everywhere.
So what we're going to do in the next Nugget,
is we're going to jump in the virtual lab WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is we're going to jump in the virtual lab
and we're going to advertise a network from R1
and verify that it shows up on our non-clients R3 and R11.
In the meantime, that's been rule number 2.
I hope this has been informative for you
and I'd like to thank you for viewing.