[AUDIO LOGO]
The last protocol we have to configure redistribution for
is EIGRP.
Now, like RIP, this is not one of our major topics.
However, again, it's worth looking at just
in case you run into it.
So just like RIP, let's just take a quick look
at the topology.
And then just jump right into the command line
and check out any caveats that we have
with dealing with the EIGRP.
Small hint.
Just like RIP, we're going to have to specify
a metric on the redistribution.
There is no seed metric in EIGRP.
So again, let's jump in and take a look.
So now, we're going to be dealing with EIGRP 100
up here on router 9.
And to get the routes up there, we'll
be redistributing on router 2 from OSPF into EIGRP.
And we'll do the same thing on router 1.
So let's just go ahead and jump into the command line
and get this configured.
So we'll start here on router 9 with a show ip router eigrp.
And we see that router 9 is actually learning nothing
from EIGRP at this point.
So let's go ahead and jump down to router 1
and configure our redistribution.
So we'll go into configuration mode, into our EIGRP process,
into our address-family.
And we'll say to redistribute ospf 1.
Now, we already mentioned that EIGRP
does require a seed metric.
So watch what happens when we commit the changes.
We get a message right away telling us
that we're setting EIGRP to redistribute with no metric.
So it's pretty much just not even accepting this.
Now, one way we can do this is to set a default metric.
So let's go ahead and set a default metric.
The way you put the metric in for EIGRP
is first, the bandwidth.
And these numbers aren't all that critical.
Of course, on a production network,
you would want to set these to be accurate.
I'm just going to set them to say like, 1500.
We'll pretend it's a T1 line.
Then the delay.
So we'll set this to 10, reliability, 255.
Next is load, which we'll set to 1.
And the last thing is the MTU, which is 1500.
So once we have all these values in, we'll just hit Enter
and we'll hit Commit again.
This time, we don't get any errors.
So now, let's go back up to router 9.
And let's look at our EIGRP routes again.
And now, we see we have all of these external EIGRP routes.
If we look at these entries, again, we'll
just pick on the one here at the bottom, the 172.16.245.0.
Things to note-- one, it is flagged as external in EIGRP.
EIGRP keeps track of external networks.
Also, notice that all of these routes
have the same metric, the 1709312.
That's simply the value that each group
calculates using its formula based on the metrics we put in.
They're all the same because they're all being distributed
with the same metric.
So we would expect this to be the same.
And of course, we could adjust this
based on the metrics we used on the redistribution line.
In this particular case, it's not that critical
what they are.
We're just trying to get the routes into EIGRP group.
So we saw how to configure this using a default metric.
Let's look at the other option as we do
the redistribution on router 2.
So what we'll do here is we'll set the metric a little bit
different for say, loopback interfaces
than we do for everything else.
So in order to do that, we're going to need a prefix that.
We'll just call it like PS_LOOPS.
That'll match on anything that begins with a 10
and has a mask of 32 bits.
We'll end set.
So that should match on our loops.
Now, let's write our policy.
We'll just call it RP_EIGRP_METRIC.
We'll say if the destination is in PS_LOOPS, then
what we're going to do is set the EIGRP metric.
Let's set this one to 15000.
We'll use the same numbers for the rest.
And then we'll say, else set the eigrp-metric.
And let's just add a 0 to the bandwidth.
We'll end our if statement and our policy, then
in the router eigrp, address-family ipv4.
Once again, we're redistributing OSPF 1.
But this time, we're going to run it through the route policy
RP_EIGRP_METRIC.
The difference here, of course, being
that we're going to be setting the metric differently
on different routes using our policy,
rather than just using a default metric like we did on router 1.
It just gives us more power, more capability
to control the metrics if we want to.
Now, let's go take a look at these on router 9 again.
So to compare the routes to these,
just keep in mind that these are 1709312.
Remember that the metric here was exactly the same,
except we did a 1500.
The other ones we just did have a higher bandwidth.
Therefore, they should win.
So all of these should flip from going to router 1
to going to router 2.
We can see here that they have.
And they have a much better metric.
And we see that the non-loopback interfaces
have an even better metric.
So our loopbacks, for example, here, have 173312.
And then a non-loopback interface
is, for example, 19712.
Now, this, of course, is going to be a really long table
because we should now be getting all of the routes
from our entire environment.
However, that still doesn't mean we
have end-to-end reachability.
If we trace that 88 loopback, notice
that we're getting stuck in the exact same routing
loop that still exists because we haven't fixed that yet.
In this video, we saw how to redistribute routes
in the EIGRP.
And again, the main thing here is
that you do have to supply a seed metric because otherwise,
they're redistributed essentially as
infinite like RIP.
Although, in the case of EIGRP, it just doesn't redistribute
them at all.
However, we can supply that seed metric, of course.
We can do it either globally under the process
by setting a default metric.
Or of course, we can do it with a route policy.
Or if we were doing this on IOS XE,
we could, of course, use a route map as well.
Now, as we can see this still doesn't solve the looping
problem that still exists in our environment,
and we need to fix that.
That is exactly what we're going to do next.
Until then.
I hope this has been informative for you,
and I'd like to thank you for viewing.