So now at this point, we've seen how
IBGP can get around the fact that it
doesn't forward network prefixes or NLRI's to other IBGP peers.
We've seen how we can get around that
by implementing a full mesh topology.
But the formula showed us pretty quickly that full mesh topology
is not realistic for service providers,
because there would be way too many BGP sessions flapping all
the time, or it would just overwhelm routers
in the first place.
So how we can fix this is with something
called route reflectors, and there's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
called route reflectors, and there's
three rules to how route reflectors work
in an IBGP solution.
That's what this Nugget is going to setup
is what is rule number one and how do route reflectors really
work.
Let's jump on a whiteboard draw it up.
So our IBGP topology for AS100 looks like this currently.
And this is a perfect scenario of how
we can use route reflectors.
So to recap what happened is when
R1 advertised to routes R2, or R3 advertised to route R2,
or R11 advertised a route to R2, that's where the buck stopped. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or R11 advertised a route to R2, that's where the buck stopped.
R2 is not going to forward any prefixes or NLRI's in an IBGP
topology, because IBGP does not forward
internally learned routes.
What we may want to have happen though is we may want routes
to come in from one of these devices, R2 learns about them
and then reflects them on two more devices.
So let's say R3 advertises its loopback address into IBGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's say R3 advertises its loopback address into IBGP.
R2 could then learn about it and then
reflect it onto other routers in its IBGP pair table.
In this case, R2 is called, wait, you guessed it,
the route reflector.
But again, BGP is a deliberate protocol,
so we have to choose where routes get reflected to.
In this case, let's call R1 the route reflector client.
Luckily for us, the configuration
of route reflectors is extremely simple, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of route reflectors is extremely simple,
but the behavior of route reflectors is a little bit
complicated.
And that's why we have three rules, or really,
three different scenarios as to how
a route reflector will work.
In this case, we're talking about rule number one, where
R2 is serving as the route reflector
and R1 is the route reflector client.
R3 is not a route reflector client,
and R11 is not a route reflector client.
Even though R2 has an IBGP relationship with it,
the way it handles a client versus a non-client WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the way it handles a client versus a non-client
is what matters here.
So in rule 1, when R3 advertises 3.3.3.3,
the rule looks like this.
R2 will send routes learned from non-clients to clients only.
So R3 will advertise 3.3.3.3.
R2 will then forward this to its client of R1.
It will not forward it down to R11.
So this sets up rule 1, what to do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this sets up rule 1, what to do
when a route reflector receives a route from a non-client.
In this case, it will forward it to clients only.
That's rule 1, and in the next Nugget,
we're going to implement this topology.
In the meantime, I hope has been informative for you,
and I'd like to thank you for viewing.