- [Instructor] In this lab exercise,
so let's take a look at troubleshooting
a route redistribution.
And if you'll import the route redistribution
at dot yammel file that you have access to
into your copy of a Cisco modeling labs
or the Cisco modeling labs out of the Cisco devnet sandbox,
then you'll get a base topology
and I've already configured router R2
for route redistribution.
However, we've got an issue,
even though everything looks good on R1
R1 seems to see all of our networks, R3 does not,
R3 has not learned about any OSPF networks.
So your challenge is to import that yammle file
in the Cisco modeling labs, pause the video,
resolve the route redistribution, that configuration issue.
And then you can resume the video
and we'll go through a complete solution.
(gentle upbeat music)
Let's walk through a solution for this
route redistribution configuration issue.
First of all, let's check out router R2,
it's the one that's sitting in the middle between
these two different autonomous systems.
Let's see how route redistribution is configured.
I'll do a show run in part two section
beginning with router,
and for EIGRP, I'm saying redistribute OSPF process ID one.
And we see that I do have an OSPF process ID one,
and it is redistributing EIGRP, autonomous system one,
and we're using the subnets keyword.
Now, interestingly in older versions of Cisco iOS,
the subnets keyword was something you had to enter yourself.
However, now in modern versions of Cisco iOS,
it's typically entered for you.
And what this does is enable OSPF
to redistribute routes that are not using
their classful mask.
So if I were trying to redistribute a network
that didn't have a default subnet mask into OSPF
without the subnets keyword, that would not happen.
However, with the subnets keyword, it would.
Now let's see what R1 and R3 know about.
If I go to R1 and do a show IP route,
it seems to have learned those three networks
living over any EIGRP.
We see the O code indicating the routes were learned
via OSPF and the E2, says, this is OSPF external type two.
And what that means is when our two is redistributing out
networks into OSPF, it redistributes them
with a particular cost.
And you might think that the cost would add up,
if we went through say three or four routers
that should add some costs.
However, interestingly, with E2, we don't do that.
Whatever the original cost was when we redistributed
into OSPF, which by the way, defaults to 20,
that doesn't change, it doesn't change as we exit
one router or two routers or three routers
or however many routers, it stays the same.
And in this particular case, it doesn't make any difference
because router R2 is the only way to get to those networks.
But if we had more than one exit point from OSPF
getting us into EIGRP,
we might want to consider changing that to an E1.
But right now there's really nothing wrong with our OSPF
redistribution configuration,
because I see all the networks living in EIGRP.
But if I go over to router R3 into a show IP route,
we are not so fortunate.
Look at this, we only know about locally attached,
directly connected networks.
We haven't learned anything.
Now, if I go back to R2 and look at our configuration,
I'm clearly saying redistribute OSPF one,
and you might think, did I forget to give
the subnet's key word?
No, that's not applicable to EIGRP, that's an OSPF thing.
So why is this not working,
do you remember when I said by default,
when we redistribute routes into OSPF,
those routes are going to have a cost of 20
and we can change that.
But by default of the cost or the metric is 20.
Or for EIGRP and also for RIP,
the default metric is infinity.
So we must set a metric for those routes
being redistributed, and we have not done that here.
And there are a few different ways that we can approach it.
So if you solved this lab scenario,
you probably used one of three approaches,
and I want to show you all three.
And whichever one you used,
I recommend that you practice the other two
after watching this solution.
One way to do it, let's go into router configuration mode
for router EIGRP autonomous system one,
I can say default hyphen metric,
and this will apply to all redistributed routes.
Maybe I'm redistributing OSPF and EIGRP,
maybe I'm redistributing a static networks into EIGRP,
and so on.
All of them will assume this default metric
and here I'm just redistributing OSPF.
And if we use context sensitive help,
we see that we need to put in bandwidth,
one of the EIGRP parameters for calculating it's metric.
And the unit of measure is in kilobits per second.
We'll say that we're on a giggling.
So that'll be 1 million case, a one followed by six zeros,
one, two, three, four, five, six,
and our delay has a value of 10 microseconds,
every time we exit a gig interface
and the units of measure are in tens of microseconds,
So I'm going to put a one there.
Next step reliability,
255 indicates that we are totally reliable.
One for load indicates that we are minimally loaded.
And finally, the MTU I'll use the default of 1500 bytes.
And that default metric is now going to apply
to routes that we're trying to redistribute from OSPF
In to EIGRP.
Let's go back to router R3
and see if we now see some of those networks.
Let's do another show IP route,
Great news, we now see those three networks
that live in OSPAF, and that we see those with the D code
D indicating they were learned via EIGRP.
And the EX indicates that this is EIGRP external,
meaning that this route came from outside
our EIGRP autonomous system.
By the way, as a side note, EIGRP, external routes,
have a different and less attractive administrative distance
as compared to regular EIGRP.
Regular EIGRP routes have an administrative distance
of a nanny.
And remember a lower is better, Lower is more believable.
But if a route comes in from outside
the EIGRP autonomous system,
instead of having an administrative distance of a nanny,
it is a whopping one 70, So it is less believable.
That was one way to fix it,
Let's take a look at a couple of other ways of fixing it.
Let me negate what I just did.
I'll put a no in front of that,
so that's going to get rid of the default metric.
Here's a second way we could have approached this.
We could have said when we did our redistribute OSPF
process ID one command,
I could have said just as part of this command,
I could have said here's the metric.
And I could have said metric, and given those same five
parameters, 1 million, a one, a 255 and a one and a 1500
that would have done it.
Let's confirm that over on R3.
Do I still see those networks?
Yes, I do.
And there's one other way of doing this.
Let me negate this and I'll put back redistribute, OSPF one.
So now we have no metric.
And if I go back to R3, we should see that we've now
lost those three routes.
You see now we only know about locally connected things,
and let's configure that third way of assigning a metric.
And that's using a route map.
Let's go back out to a global configuration mode.
I'm going to create a route map
and you can call it whatever you want.
I'm going to call mine simply metric.
And in this route map, I want to set the metric
to those EIGRP parameters,
the band width of 1 million,
the delay of one tens of microseconds,
the 255 reliability,
the one indicating we are minimally loaded
and the 1500 byte MTU.
So that creates a route map that I can then apply
to my redistribute command.
Let's go back into router configuration mode for EIGRP,
autonomous system one.
And I'll say redistribute, OSPF process ID one.
But notice, in addition to just saying here's the metric,
I could reference a route map, which has the metric in it.
And that's what I'll do, I'll say route hyphen map,
and I call the route map simply metric.
We'll press enter, now let's go back over to R3
and see if we've now learned those routes that live in OSPF.
And we have.
So that's a look at three different ways
of assigning a metric to routes that are being redistributed
into EIGRP.
And again, if you successfully solved
this troubleshooting challenge,
I encourage you to go back and try the other two methods.
Or if you were not successful,
I encourage you to try all three methods.
But that's all looking at a troubleshooting scenario
for a route redistribution.