[AUDIO LOGO]
So let's jump in by getting an introduction to redistribution.
And what that basically means, we
want to talk about why we need to do redistribution,
under what situations we may have to, and, of course,
the different caveats that each routing protocol has
that we want to watch out for when we do redistribution.
So let's go ahead and jump in and look
at some of those details.
One of the first things we want to say about redistribution
is, whenever it's at all possible,
use a single routing protocol.
In other words, we do want to avoid redistribution.
The reason for that we've already said during
the introduction-- and we're going to see more of it as we
move through this video--
but we introduced the possibility of loops
and we lose routing information, and, overall,
it's really something that we should
avoid if at all possible.
Of course, we wouldn't be having this discussion
if it was always possible.
So, in many cases, it's not possible to avoid this.
And some of the reasons for that-- and there could be,
of course, many--
but just one example would be mergers.
One company buys another company.
And one of them was running EIGRP.
The other one's running OSPF.
At some point in time, you may merge on
to a single routing protocol.
But in the meantime, you are probably
going to want your network to function,
and you're using two different protocols.
Same sort of thing with business partners.
We may have business partners that we need to exchange routes
with, and they may be running a completely different protocol.
Different vendors can be an issue.
Sometimes companies do this one to themselves.
I used to work for a company, which I will not mention,
but they had a policy that all network
equipment had to be Cisco.
That was just their policy.
And because of that policy--
and this happened before I started--
but they had chosen to run EIGRP.
Fair enough, the EIGRP worked perfectly fine
in their environment.
And then down the road--
of course, while I was working there--
they decided to build a whole new building,
and they outfitted that entire building with Nortel equipment.
Yes, it was a little while ago.
Nortel's not really around anymore.
But the Nortel equipment would only run OSPF.
So now we have two different protocols
within our own network just because of a policy change,
where all of a sudden they started
buying from another vendor.
So again, should this be avoided?
Yes.
In this case, it was honestly political.
It obviously was not a decision of the networking department
to do that.
We would have outfitted that building with Cisco equipment,
just like everything else.
But, of course, the decision came from higher up.
We don't exactly know why.
But the point is we got forced into that situation where
we had to do redistribution.
And, to a certain extent, that can bleed over
into this last point that I have on here as well--
different areas of the network.
That same company had a very, very old mainframe,
and that old mainframe would only run RIP version 2.
It's, of course, been replaced.
But the point is we had to redistribute to the mainframe
as well.
You could argue that that's because of vendors,
or you could argue that that's different areas of the network.
Again, these are all similar concepts.
But the idea is, when possible, avoid redistribution.
And one other thing that should probably be on this list
but I didn't put it on here, sometimes the technology
itself requires it.
Later in this course, we'll be covering MPLS Layer 3 VPN.
And just because of what layer VPN is--
passing customer routes through a service provider environment
and so on--
it almost requires redistribution.
Now, that redistribution may happen in the service provider,
and it may happen at the customer's site.
That's a discussion we can have when
we get to MPLS Layer 3 VPNs.
But, regardless of where it happens,
that's another situation where we almost
have to do redistribution.
So again, can we always avoid redistribution?
Absolutely not.
Should we avoid it whenever possible
just because of the problems that it can introduce?
Absolutely.
Now, since we can't always avoid it,
it's, of course, very important to understand
how to avoid its caveats and problems, such as what
do we do with metrics and what do
we do to prevent routing loops.
And that's exactly where we're headed.
So let's get back into this.
Now, this may be a little bit redundant.
But again, the reason we have to do redistribution
in these cases that we mentioned is
to get that end-to-end reachability.
Otherwise, the two different routing protocols
would not be exchanging routes, and we
wouldn't be able to get traffic from one domain to the other.
Now, a couple attributes of redistribution
to keep in mind as we move through the rest of this skill.
First, redistribution always happens from the routing table.
It never happens from the database.
Now, a side effect of this is that redistribution cannot be
redistributed again on the same device.
So let's talk about what this means from two
different perspectives.
First, let's just talk about what
these points mean directly.
And that is, if I learn a route, say, through RIP,
and then I redistribute RIP into OSPF, on the same router,
I then redistribute OSPF into, say, EIGRP.
That route will not end up in EIGRP.
And the reason is it's still in the routing table from RIP.
That's the original routing protocol I learned it from.
So I can't redistribute from RIP into OSPF and then OSPF
into EIGRP and expect the RIP route to end up in EIGRP.
It won't happen.
You never use your own redistributed routes.
So the route stays in the routing table
from the original protocol, which, in my example, is RIP.
Now, the other thing to keep in mind
about redistributing from the database is simply this.
Let's do a slightly different example.
Let's say I learn the exact same route from OSPF and EIGRP.
Now, admin distance would kick in that case.
And assuming it's an EIGRP internal route,
I would put the EIGRP route into my routing table
because it's got an admin distance of 90, by default.
Now, I redistribute OSPF into RIP.
Is that route in the OSPF database?
Yes.
Is it in the routing table from OSPF?
No.
Therefore, when I do the redistribution into RIP,
I will not get that route even though it's
in the OSPF database.
That's what we mean when we say we never
redistribute from the database.
It has to be in the routing table from the source protocol
when you do the redistribution.
Again, another important thing to keep in mind
is that routing protocols do have their own built-in loop
prevention mechanism.
Now, that varies, of course, from protocol to protocol.
However, when we do redistribution between those
routing protocols, we are going to lose that built-in loop
prevention mechanism.
That's fine.
It's a side effect of doing this.
However, that makes it the administrator's responsibility
to prevent the loops.
That means you.
So we have to ensure that loops are prevented.
And something else to keep in mind,
that, with a few exceptions, we do
lose the attributes of the redistributed route.
Again, we can't take an OSPF metric
and try to put it into a RIP hop count.
Now, as it says here, there are a few exceptions.
We'll talk about some of these as we go.
But one notable exception is, for example,
when we redistribute into BGP, whatever metric
is on the route that's coming from the routing table will be
copied into the BGP MED field, or the metric field that Cisco
calls it.
So there are a few exceptions.
But, generally speaking, we lose the attributes.
Of course, when we take a BGP route, for example,
and redistribute it into an IGP, we're
going to lose all sorts of things.
You would lose communities and local preference
and all of those attributes that BGP
carries that none of the other routing protocols support.
Those would all be gone.
So again, most of the time, we lose all the attributes.
There are again a handful of exceptions.
So since we are losing those attributes,
depending on the protocol in question,
we as administrators may need to provide a seed metric.
So let's take a look at the examples here.
First example is RIP.
If you are redistributing connected or static,
those will have a metric of 1.
Everything else, you're going to need a seed
metric because there isn't 1, which
means you need to supply it.
What it actually does is it sets all of the metrics to infinite.
So that makes all of the routes unusable.
So you as the administrator will have to set this.
EIGRP is very similar.
Once again, no seed metrics, which means you're
going to have to provide one or it simply
won't do the redistribution.
One exception to that is if you're redistributing
from one EIGRP AS to another EIGRP AS,
it will actually copy the metric over because it's
going EIGRP to EIGRP, just into different AS numbers.
OSPF actually defaults to a seed metric of 20 for most routes.
Again, there's going to be a few exceptions here.
Just like EIGRP, if you're redistributing OSPF to OSPF,
it's again going to copy that metric.
So that's an exception.
And if you're coming from BGP, it's
going to default to a metric of 1 rather than the 20
that it does for all of the other protocols.
IS-IS is very straightforward.
It simply uses a seed metric of 0 for everything.
And BGP, again, it'll copy it from the other routing
protocols, as we mentioned earlier, except connected
and static will have a MED or metric of 0.
Some final notes on redistribution.
First, it, of course, can be done either in one direction
or in both directions, which we generally
call mutual redistribution, and it
can be done on either one device or multiple devices.
So, of course, we usually want to use multiple devices
for redundancy.
However, be aware that when you're
doing mutual redistribution on multiple devices,
this is where we get a risk of loops,
and we have to be very, very careful.
Again, you can safely do mutual redistribution
on a single router without creating loops.
But again, you have that problem is there's no redundancy.
So if you lose that one device, of course,
your entire network would be down.
Now, it can still cause sub-optimal routing even
on a single router.
Very, very simple example, if I have two routers here--
let's say, over here, I'm running RIP; over here, I'm
running OSPF--
and I only configure redistribution
on one of these routers.
Well, let's say we have a RIP route over here,
Network X. Network X gets sent to this router.
This router redistributes it into OSPF
and sends it down to this router.
Well, now, here's the problem.
OSPF has an admin distance of 110,
and RIP has an admin distance of 120.
I didn't draw it, but remember that this
will learn it from RIP as well.
So the router at the bottom--
we'll call it Router B--
learns the route from OSPF and RIP.
Well, given the two admin distances, which
one is it going to follow?
The answer is it's going to follow OSPF.
And, therefore, any traffic that arrives
at Router B going to Network X, instead of going directly,
like we would normally want it to, instead it's
going to go up to this router following OSPF
and then over here to network X.
Will it still work?
Yes, of course.
It's just sub-optimal routing.
It's not a loop.
But just keep in mind that sub-optimal routing
is only one step away from being a routing loop.
We'll talk about that more a little bit later.
But look at that white line that I just drew on there.
It's almost a loop.
All I'd have to do is this to make it a loop.
So it's very close to being a loop.
We have to be very, very careful.
Again, without doing the mutual redistribution,
though, that last error won't happen.
And that's why we said this is safe.
It just may be sub-optimal.
And again, this last point, we've pretty much already said
if you do redistribution on multiple routers,
it will, of course, add redundancy,
but it can lead to those routing loops.
This is what we have to watch out for.
So, in this video, we got an introduction to redistribution
between routing protocols, specifically
our IGPs with a minor mention of BGP here and there.
We saw the caveats of each of the different IGPs, how they
handle the metrics, and we talked about some
of the dangers we have to watch out for with this creating
loops if we're doing mutual redistribution
on multiple routers.
So it's time to jump in and start actually
doing this redistribution, and we'll
start that in the next video with IS-IS redistribution.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.