|
0:00:13
|
In our next section here, we're gonna look at problems that can occur during redistribution.
|
|
0:00:18
|
We'll see two different types of loops that are related either to the metric or to the administrative distance.
|
|
0:00:25
|
How to identify these potential looping problems?
|
|
0:00:28
|
And then how to prevent them with different tools in the IOS?
|
|
0:00:33
|
Now, first and foremost, the reason that we could have potential problems in redistribution,
|
|
0:00:38
|
with either traffic loops or actual routes, loops of the route information themself,
|
|
0:00:44
|
is that anytime we're doing redistribution between different protocols,
|
|
0:00:48
|
we're causing a loss of the end-to-end route calculation
|
|
0:00:51
|
and the loop prevention mechanisms that are normally built-in to that protocol.
|
|
0:00:57
|
So, for example with EIGRP, in the diffusing update algorithm,
|
|
0:01:01
|
we're using that feasibility condition to figure out,
|
|
0:01:04
|
"Is a destination that I'm learning a prefix from?"
|
|
0:01:07
|
"Either closer to the destination or further away from the destination than I am."
|
|
0:01:12
|
Now, when we compare this to OSPF's building up the graph for SPF,
|
|
0:01:18
|
the two algorithms are not compatible.
|
|
0:01:20
|
Which means that when we do the redistribution,
|
|
0:01:23
|
we're essentially, potentially breaking those loop prevention mechanisms.
|
|
0:01:27
|
So, really, there's no way that we can prevent this
|
|
0:01:30
|
since the protocols are having different formats.
|
|
0:01:32
|
Ideally, in a real design, you would just try to get away from any redistribution points at all.
|
|
0:01:38
|
And simply run the same IGP end-to-end.
|
|
0:01:41
|
So, if I'm running EIGRP everywhere in my network or running OSPF everywhere in the network,
|
|
0:01:46
|
then we can assume those protocols are gonna build a loop free topology to begin with.
|
|
0:01:52
|
It's only when we pass the information between the protocols
|
|
0:01:55
|
and then we have a loss of the entire reachability information.
|
|
0:01:58
|
That's where the potential problems can occur.
|
|
0:02:03
|
Now, we'll see in the command line, that any design that is using just a single point of redistribution,
|
|
0:02:10
|
so, where one router is doing OSPF to RIP redistribution or doing RIP to EIGRP redistribution.
|
|
0:02:17
|
In those type of cases, there is not a potential for a route feedback
|
|
0:02:21
|
or not a potential for a traffic loop.
|
|
0:02:25
|
We'll see that the internal routing process is automatically gonna control
|
|
0:02:30
|
what routes are supposed to go from EIGRP to RIP
|
|
0:02:33
|
and then make sure those routes don't go from RIP back to EIGRP.
|
|
0:02:39
|
The only potential problems we could have with redistribution
|
|
0:02:42
|
is when there are multiple points that the different protocols are meeting.
|
|
0:02:48
|
So, if we're redistributing between OSPF and EIGRP,
|
|
0:02:52
|
but there are two different routers that are doing mutual redistribution between EIGRP and OSPF,
|
|
0:02:59
|
then we have a potential possible issue.
|
|
0:03:03
|
Now, specifically, there's two cases where these routing loops can occur.
|
|
0:03:09
|
Regardless of which type of routing loop it is,
|
|
0:03:12
|
it's simply based on the fact that some router in the network or possibly multiple routers
|
|
0:03:18
|
is choosing the wrong information in order to get to the particular destination.
|
|
0:03:23
|
So, if my correct route is from RIP, but I'm choosing the incorrect route from OSPF,
|
|
0:03:30
|
then we're gonna have a loss of the traffic or feedback of the route itself.
|
|
0:03:35
|
So, there's two general cases that we can apply onto this.
|
|
0:03:38
|
One of them is that the wrong path could be chosen based on the lower metric value
|
|
0:03:45
|
when we're looking at two routes of the same protocol.
|
|
0:03:50
|
Or that the lower administrative distance is chosen
|
|
0:03:53
|
when we're comparing two routes between different protocols.
|
|
0:03:59
|
So, for example, if I have RIP and OSPF redistribution in two different points,
|
|
0:04:05
|
the RIP domain could potentially get confused by choosing the wrong route that has a lower hop count
|
|
0:04:12
|
versus the correct route tha thas a higher hop count.
|
|
0:04:15
|
Or if I had multiple points of redistribution where I'm going from RIP to OSPF,
|
|
0:04:21
|
OSPF to EIGRP, then EIGRP back to RIP.
|
|
0:04:25
|
I could potentially have a case where one of the devices chooses the wrong prefix
|
|
0:04:30
|
based on it choosing the lower distance of OSPF
|
|
0:04:34
|
versus the higher distance of RIP, or the higher distance of external EIGRP.
|
|
0:04:40
|
The problem with this though
|
|
0:04:43
|
is that there are really no general rules that you can apply on the redistribution
|
|
0:04:47
|
to make sure that you're gonna avoid problems 100% of the time.
|
|
0:04:51
|
So instead, what we really need to do is to figure out based on this particular topology,
|
|
0:04:59
|
where are the potential problems that we could run into.
|
|
0:05:03
|
And this is gonna be based on just us visually inspecting the network topology,
|
|
0:05:07
|
looking at where the different redistribution points are
|
|
0:05:11
|
and being able to predict what are the potential problems.
|
|
0:05:16
|
So, ideally, before you get to the CCIE lab exam,
|
|
0:05:20
|
you should be able to look at any network topology
|
|
0:05:23
|
and a 100% of the time, predict whether there is gonna be a problem
|
|
0:05:28
|
and whether that problem is related to metric-based loops or distance-based loops.
|
|
0:05:33
|
Or say, "No, there's not gonna be a problem because the routing process is gonna figure it out itself."
|
|
0:05:40
|
The issue usually with redistribution is that if there is a loop in the topology,
|
|
0:05:46
|
a lot of the times, it's very time consuming in order to figure out what the actual problem is
|
|
0:05:51
|
and then figure out what the resolution is.
|
|
0:05:54
|
So, ideally, we would work on the opposite way to figure out before even doing the redistribution,
|
|
0:05:58
|
what is going to be the problem?
|
|
0:06:01
|
And then fix the problem before it happens.
|
|
0:06:05
|
But today, we'll look at some example topologies where there routing loops.
|
|
0:06:08
|
And then see what are the different mechanisms we can use to identify where the problem is
|
|
0:06:13
|
and then ultimately, figure out depending on the loop is based on the metric or based on the distance.
|
|
0:06:19
|
What are the different implementations we can use in order to fix that particular problem.
|
|
0:06:25
|
Now, we already talked about using the TCL shell
|
|
0:06:27
|
with the ICMP for doing ping scripting.
|
|
0:06:31
|
Another tool that we'll look at today is the Debug IP Routing Output.
|
|
0:06:35
|
That's gonna show us what particular protocol the routes are being learned from.
|
|
0:06:40
|
What is the metric value? What is the administrative distance value?
|
|
0:06:43
|
And then whether the route has being added or deleted over and over and over.
|
|
0:06:50
|
So, if we look at the Debug IP Routing Output, and we don't see that the topology is changing,
|
|
0:06:56
|
then that case is less likely for a problem with redistribution
|
|
0:07:00
|
versus some case where we see the route is added and deleted every 5 seconds.
|
|
0:07:06
|
We'll also gonna look at the IP Route Profile Feature,
|
|
0:07:10
|
which is used to collect statistics on the routing table
|
|
0:07:13
|
and then tell us how many changes are happening over a certain period of time.
|
|
0:07:19
|
So, if we look at the result of the IP Route Profile Statistics,
|
|
0:07:23
|
and we see that within the past minute, there's been a thousand changes in the routing table,
|
|
0:07:28
|
then that most likely means that the routing topology is not stable.
|
|
0:07:34
|
Also, we'll look at outputs from trace route
|
|
0:07:36
|
where this should be pretty self explanatory if I trace to a destination
|
|
0:07:40
|
and I see the packets are bouncing back and forth between the same hops in the network.
|
|
0:07:44
|
Then that's a pretty good indication that there's some problem with the routing domain.
|
|
0:07:49
|
So, if my route's pointing towards you and your route points towards back me,
|
|
0:07:53
|
then we're simply gonan bounce the traffic back and forth until the IP time to live is exceeded.
|
|
0:08:00
|
Now, we'll see again that there's gonna be two main categories of looping that we'll see today.
|
|
0:08:05
|
Loops that are based onthe metric and loops that are based on the distance.
|
|
0:08:10
|
the reason that we need to separate the two of them
|
|
0:08:12
|
is that there are fixes we can apply to metric-based loops that will not work for administrative distance-based loops.
|
|
0:08:21
|
Now, the metric-based loops, these are the ones that are the easiest to prevent.
|
|
0:08:26
|
Simply by filtering the routes at the different redistribution points.
|
|
0:08:30
|
So, this is mainly where the route tag filtering will be used.
|
|
0:08:34
|
Or we can manually specify access lists or prefix lists
|
|
0:08:38
|
that list what particular routes we do or do not want to redistribute.
|
|
0:08:43
|
Techincally, we could also use administrative distance here.
|
|
0:08:47
|
But a lot of the times for metric-based loops,
|
|
0:08:49
|
a route tag filter is gonna be the easiest and most efficient way to fix the problem.
|
|
0:08:57
|
Now, with administrative distance-based loops,
|
|
0:09:00
|
generally, filtering at the redistribution point itself is not going to accomplish anything.
|
|
0:09:06
|
So, there's a fundamental difference between
|
|
0:09:09
|
when the router is choosing two routes inside the same protocol and looking at the metric value
|
|
0:09:15
|
versus looking at two routes between different protocols
|
|
0:09:19
|
and looking at the one with the lower administrative distance.
|
|
0:09:24
|
But again, for either of these, whether the loop is metric or distance-based,
|
|
0:09:28
|
there's really no general rules that we can apply onto the topology.
|
|
0:09:32
|
The key is we need to look at the network diagram
|
|
0:09:35
|
and essentially follow the route advertisement path on a hop-by-hop basis
|
|
0:09:41
|
to predict for this particular router what interface is the routing update gonna come in on.
|
|
0:09:49
|
And if it is learning from multiple interfaces.
|
|
0:09:52
|
And if they are via the same protocol, which are we gonna choose based on the metric?
|
|
0:09:57
|
Or if it's coming in multiple interfaces through multiple protocols,
|
|
0:10:01
|
which is gonna choose based on the lower administrative distance.
|
|
0:10:07
|
So again, ultimately, once you are proficient with the route redistribution,
|
|
0:10:12
|
you should be able to spend maybe 5 or 10 minutes
|
|
0:10:14
|
just visually looking at the topology and tracing out the route path
|
|
0:10:18
|
and figuring out where the issues gonna be before you actually do the implementation.
|
|
0:10:24
|
So, let's look back at our example topology here.
|
|
0:10:27
|
Where we have three different protocols in the network.
|
|
0:10:29
|
We have OSPF, RIP and EIGRP.
|
|
0:10:32
|
Where all three of them are terminating on router 4.
|
|
0:10:37
|
So, our ultimate goal here is to get reachability between all three of these domains
|
|
0:10:41
|
and we're gonna be doing the redistruibution on router 4.
|
|
0:10:45
|
Now, we already looked at during the redistribution between RIP and OSPF
|
|
0:10:50
|
and it did not look like there were any issues there.
|
|
0:10:52
|
So RIP went in to OSPF. OSPF went back in to RIP.
|
|
0:10:56
|
We did some basic tests by using the ping command and using the TCL scripting.
|
|
0:11:01
|
Router 6 and switch 1, they were able to reach all of the destinations in the RIP domain.
|
|
0:11:08
|
So, next, let's look at onrouter 4, we need to add the EIGRP and RIP redistribution.
|
|
0:11:14
|
And then lastly, we're gonna go between EIGRP and OSPF.
|
|
0:11:21
|
Now, as I mentioned before, for situations where there is only one meeting point of the routing protocol,
|
|
0:11:29
|
it is nearly impossible to cause a routing loop.
|
|
0:11:33
|
Because the routing process itself is gonna take care of any of these issues.
|
|
0:11:37
|
Now, this type of topology would look like,
|
|
0:11:41
|
let's say between router 4 and BB3,
|
|
0:11:46
|
we're running RIP.
|
|
0:11:49
|
Then the rest of the network, we are running OSPF.
|
|
0:11:56
|
If router 4 is the only physical meeting point from the RIP domain to the OSPF domain,
|
|
0:12:02
|
Then we know immediately, there's not gonna be any problems with looping.
|
|
0:12:07
|
We can simply redistribute RIP into OSPF.
|
|
0:12:09
|
Redistribute OSPF into RIP. And then let the routing process worry about it on its own.
|
|
0:12:15
|
So, internally, there is a mechanism that the routing process knows,
|
|
0:12:19
|
I should not take a route from OSPF and put it into the RIP database
|
|
0:12:24
|
then take it from the RIP database and put it back in to OSPF.
|
|
0:12:28
|
So, we don't need to do any type of route tagging,
|
|
0:12:31
|
any type of access list or prefix list filtering or modify the admisistrative distance.
|
|
0:12:36
|
Router 4 should automatically prevent this type of case.
|
|
0:12:41
|
Now, where we are gonna see problems
|
|
0:12:43
|
is this type of example topology here where there are multiple meeting points of the same protocol.
|
|
0:12:51
|
So, in this specific case, we have EIGRP and OSPF meeting on router 4.
|
|
0:12:58
|
It's meeting on router 5.
|
|
0:13:00
|
And then also on router's 1 and 3.
|
|
0:13:04
|
So, this then means anytime I take a route form OSPF and advertise it into EIGRP,
|
|
0:13:12
|
it's gonna be learned by the different routers through multiple protocols.
|
|
0:13:18
|
So, let's say on router 4, we're doing just one way redistribution.
|
|
0:13:23
|
We redistribute from RIP into OSPF and we redistribute from RIP into EIGRP.
|
|
0:13:32
|
So, now, I wanna know visually on a hop-by-hop basis,
|
|
0:13:36
|
what exaclty is gonna happen when router 4 advertise these routes into OSPF?
|
|
0:13:40
|
And then separately, what's gonna happen when we advertise into EIGRP?
|
|
0:13:45
|
So, first, let's look at the OSPF domain.
|
|
0:13:49
|
So, router 4, redistributes into OSPF.
|
|
0:13:52
|
The route is gonna go to router 6 and to router 1.
|
|
0:13:57
|
Assuming that we are using all of the default values,
|
|
0:14:01
|
the router should see these as OSPF E2, with the metric of 20.
|
|
0:14:09
|
The administrative distance is gonna be 110.
|
|
0:14:12
|
As the default for OSPF for both the internal and the external routes.
|
|
0:14:18
|
So, now, both routers 1 and 6 have this installed as an OSPF external type 2 route.
|
|
0:14:23
|
Router 6 is gonna pass this to switch 1.
|
|
0:14:27
|
Switch 1 passes this to router 3 and to switch 3.
|
|
0:14:31
|
So, now, all 5 of these routers, router 1, 3, 6, switch 1, and switch 3,
|
|
0:14:37
|
should have the prefix that came from RIP,
|
|
0:14:41
|
installed as E2 with a distance of 110 and a metric of 20.
|
|
0:14:46
|
Now, router 4 is also redistributing these same prefixes into EIGRP.
|
|
0:14:56
|
So, from router 4, they go to router 5.
|
|
0:15:01
|
Assuming that router 5 has EIGRP split horizon disabled on this frame-relay interface,
|
|
0:15:07
|
5 should then send the route back to 1, to 3, to 2
|
|
0:15:15
|
2 and 3 are gonna exchange it over this point-to-point link.
|
|
0:15:19
|
1 and 3 are gonna exchange it over that point-to-point link.
|
|
0:15:22
|
Then router 5 is gonna send this down to switch 2.
|
|
0:15:25
|
And then over to switch 4.
|
|
0:15:30
|
So, now, the potential problem areas are gonna be anywhere in this topology
|
|
0:15:36
|
where the routers are learning the routes multiple times.
|
|
0:15:40
|
Thsi specifically would be router 1, router 3, and router 5.
|
|
0:15:47
|
Okay, I forgot to draw here, router 5 is also gonna learn this from OSPF, from router 4.
|
|
0:15:55
|
Now, from router 1's perspective, it's gonna have two possible routes.
|
|
0:16:00
|
the first of them is the OSPF E2 route, with the metric of 20, with the distance of 110.
|
|
0:16:09
|
It's also going to have the external EIGRP.
|
|
0:16:14
|
This should be in the routing table as DEX.
|
|
0:16:19
|
With a distance of 170.
|
|
0:16:22
|
And then a metric value of whatever the lowest bandwidth along the path is plus the cummulative delay.
|
|
0:16:29
|
So, in reality, it doesn't matter what the metric value is here.
|
|
0:16:33
|
Because we're only comparing it against one possible EIGRP path.
|
|
0:16:35
|
We're not comparing it agains multiple ones.
|
|
0:16:39
|
But the keypoint now is that when router 1 compare the EIGRP route to the OSPF route,
|
|
0:16:47
|
which one is it gonna choose and why?
|
|
0:16:55
|
So, again, when we're comparing the same longest match through multiple protocols,
|
|
0:17:01
|
we're gonna look at whichever one has the lower administrative distance.
|
|
0:17:05
|
Since OSPF has a distance of 110 versus EIGRP's 170,
|
|
0:17:10
|
it means the OSPF route is the one that gets installed in the routing table.
|
|
0:17:15
|
Now, where this is gonna be an issue,
|
|
0:17:18
|
is that for any device that is running EIGRP, and it's also learning the OSPF route,
|
|
0:17:26
|
if the EIGRP route does not get installed in the routing table,
|
|
0:17:31
|
what does that then imply about its advertisement?
|
|
0:17:38
|
Becasue remember when I mentioned about RIP and EIGRP
|
|
0:17:41
|
that's different from OSPF and BGP.
|
|
0:17:48
|
With RIP and EIGRP, since they are distance vector protocols,
|
|
0:17:51
|
they can only advertise what is actually installed in the routing table.
|
|
0:17:57
|
Now, BGP and OSPF, since they have a larger view of the overall topology,
|
|
0:18:03
|
they can advertise the route without actually having to install it.
|
|
0:18:09
|
Specifically in this case, the problem that we are gonna run into
|
|
0:18:13
|
is that when the route is advertised from router 4 into the EIGRP domain,
|
|
0:18:23
|
and from router 4 into the OSPF domain, router 5 has two choices.
|
|
0:18:30
|
It has the OSPF with a distance of 110.
|
|
0:18:34
|
And it's gonna have the EIGRP with the distance of 170.
|
|
0:18:40
|
The OSPF route wins, this is the one that goes into the routing table.
|
|
0:18:45
|
If the EIGRP route is then not installed,
|
|
0:18:49
|
it means that router 5 won't be able to advertise it.
|
|
0:18:56
|
So, in this particular topology design,
|
|
0:18:59
|
if we were to do mutual redistribution between RIP, OSPF and EIGRP on router 4,
|
|
0:19:06
|
we should see that everyone in the network is gonna have reachability everywhere
|
|
0:19:11
|
with the exception of switch 2 and switch 4.
|
|
0:19:19
|
Because when router 5 is learning the OPSF route versus the external EIGRP,
|
|
0:19:24
|
it's gonna choose the one with the lower distance which is OSPF,
|
|
0:19:27
|
which means that the EIGRP route doesn't get installed,
|
|
0:19:31
|
which then means, it cannot be advertised.
|
|
0:19:36
|
So, let's actually look at the result of this.
|
|
0:19:37
|
Let's go to route 4 and we're gonna do the redistribution.
|
|
0:19:42
|
So, to start on router 4, let's look at the Show Run Section Router.
|
|
0:19:48
|
You see what we have currently.
|
|
0:19:50
|
Okay, between OSPF and RIP, we are already doing the redistribution, that's fine.
|
|
0:19:55
|
Now, under the RIP process, I'll say Redistribute EIGRP 1.
|
|
0:20:00
|
Give it a seed metric, we'll say Metric 1.
|
|
0:20:05
|
Under the OSPF process, I wanna redistribute my EIGRP process 1 and include the subnets.
|
|
0:20:13
|
Then under EIGRP, I wanna redistribute OSPF and RIP.
|
|
0:20:18
|
Okay, under the process here, I'm gonna specify what the default metric is.
|
|
0:20:24
|
So, let's say bandwidth and kilobits per second, we'll say 100,000
|
|
0:20:28
|
So, that's a 100 meagabits per second.
|
|
0:20:31
|
Delay in 10 of microseconds if we say 100, that means 1000 microseconds.
|
|
0:20:39
|
255 is a 100% reliable.
|
|
0:20:44
|
The load of 1 means the minimum load.
|
|
0:20:47
|
Then we'll say an MTU of 1500
|
|
0:20:52
|
Now, the load reliability and MTU,
|
|
0:20:56
|
technically, these values don't even matter.
|
|
0:20:58
|
Unless you have your metric weightings set in a way that the load and the reliability are gonna be included.
|
|
0:21:05
|
The MTU is only used as a tie breaker if you have multiple equal routes.
|
|
0:21:10
|
Where most of the time, the effective MTU is gonna be 1500 or less.
|
|
0:21:15
|
But otherwise, it's really gonna matter what is the minimum bandwidth along the path
|
|
0:21:21
|
and what is the cummulative delay.
|
|
0:21:24
|
So,now, when I redistribute OSPF 1 and redistribute RIP,
|
|
0:21:30
|
I should see that both of these source protocols are then getting the same seed metric.
|
|
0:21:37
|
Just like I verified previously with RIP and OSPF,
|
|
0:21:41
|
we would be able to look at the local EIGRP process.
|
|
0:21:44
|
Look at the topology and see, are the RIP routes and the OSPF routes actually being redistributed?
|
|
0:21:56
|
So, we can see it says that the 146 network which is our connected route for OSPF,
|
|
0:22:03
|
that's getting redistibuted.
|
|
0:22:05
|
These 30 and 31 networks, these are the ones that were coming from RIP.
|
|
0:22:10
|
So, the RIP to EIGRP redistribution is working.
|
|
0:22:15
|
If we keep going, we see the VLAN 7 interace from switch 1.
|
|
0:22:23
|
And switch 1 was part of the OSPF process.
|
|
0:22:27
|
So, that's telling us the OSPF to EIGRP is working.
|
|
0:22:33
|
So, as long as the metric value is specified,
|
|
0:22:38
|
again, it doesn' matter what it as long as it's there.
|
|
0:22:41
|
And we have the correct process numbers,
|
|
0:22:44
|
then the redistribution should be accomplished locally.
|
|
0:22:48
|
Now, you can run into some cases where the routing process gets hung
|
|
0:22:53
|
and some prefix that should get advertised don't actually get into the database.
|
|
0:22:58
|
The way that you can fix this is simply by clearing the routing table.
|
|
0:23:03
|
So, if I say Clear IP Route Star (*) on router 4,
|
|
0:23:05
|
that's gonna remove all routes from the routing information base, which is the routing table.
|
|
0:23:10
|
They're gonna get repopulated from the source routing protocols
|
|
0:23:16
|
and then repopulate the CEF table.
|
|
0:23:19
|
Problem is in production, when you do this, you're gonna end up dropping packets
|
|
0:23:23
|
while your temporarily repopulating the table.
|
|
0:23:27
|
So, for our purposes for the lab, it's not gonna be an issue,
|
|
0:23:30
|
but you do need to be aware of this in your actual production designs.
|
|
0:23:39
|
So now, on...
|
|
0:23:42
|
the rest of the topology, let's look at what's the end result of this redistribution.
|
|
0:23:47
|
If we were to go to switch 3, ideally, we should see the routes coming from RIP,
|
|
0:23:53
|
which were the 30 networks,
|
|
0:23:57
|
that 204 network.
|
|
0:24:00
|
And then, also, stuff that's originating from OSPF.
|
|
0:24:03
|
So, let's say, the VLAN 10 interface is switch 4, which is 155.28.10.0/24.
|
|
0:24:15
|
So, on switch 3, if we look at the Show IP Route OSPF,
|
|
0:24:23
|
we see we have bunch of E2 routes.
|
|
0:24:26
|
Some of them are related to the routes coming from the RIP process originally,
|
|
0:24:30
|
some of them are coming from EIGRP.
|
|
0:24:34
|
Now, if I wanted to give some more visibility as to where did the routes actually come from,
|
|
0:24:39
|
I could go to router 4 and say under the OSPF process,
|
|
0:24:44
|
when I redistribute EIGRP,
|
|
0:24:47
|
I'll set the metric type...
|
|
0:24:51
|
the metric type to 1.
|
|
0:24:54
|
Okay, I'll also include subnets.
|
|
0:24:55
|
But when I'm redistributing RIP subnets,
|
|
0:24:58
|
the default metric type is 2.
|
|
0:25:03
|
So now, when I look at the result of the routing table from the OSPF domain's perspective,
|
|
0:25:08
|
it gives me a little bit more visibility as to where did the route come from to begin with.
|
|
0:25:14
|
Now again, it's not really gonna matter in this particular topology what the route type is,
|
|
0:25:20
|
because there's only one physical path that we can use in order to get there.
|
|
0:25:24
|
So, whether router 4 is advertising an E1 route or an E2 route,
|
|
0:25:29
|
it's not really gonna matter, because we have to go through router 4.
|
|
0:25:33
|
But now, it's just showing me that these particular prefixes, the E1s,
|
|
0:25:36
|
those are the ones that came from EIGRP.
|
|
0:25:40
|
The E2 routes, those are the routes that came from the RIP domain.
|
|
0:25:46
|
So now, on switch 3, let's do some basic tests.
|
|
0:25:50
|
We'll ping 30.0.0.1.
|
|
0:25:54
|
Okay, this tells me I can reach from OSPF to the RIP domain.
|
|
0:25:58
|
Let's try OSPF to EIGRP.
|
|
0:26:01
|
We'll try the 150.28.10.10.
|
|
0:26:07
|
This is the loopback zero interface of switch 4,
|
|
0:26:13
|
which I do not have reachability to.
|
|
0:26:18
|
So now, this is telling me, there's something wrong...
|
|
0:26:21
|
in the OSPF to EIGRP redistribution process.
|
|
0:26:25
|
I don't necessarily know what.
|
|
0:26:27
|
I just know that I have end-to-end connectivity.
|
|
0:26:31
|
Now, the next thing I may wanna look at here
|
|
0:26:34
|
is the traceroute output to figure out how far can I actually get into the network
|
|
0:26:39
|
before the packets begin to get lost.
|
|
0:26:42
|
So now, if I trace to 150.28.10.10,
|
|
0:26:47
|
this is gonna tell me on the outbound path
|
|
0:26:51
|
who has a route to get to 150.28.10.10.
|
|
0:26:56
|
Then, on the inbound return,
|
|
0:26:58
|
who has a route to get back to me?
|
|
0:27:04
|
Now, if we compare this output here of the four hops
|
|
0:27:07
|
to the diagram.
|
|
0:27:10
|
From switch 3's perspective,
|
|
0:27:13
|
we are able to send packets to switch 1.
|
|
0:27:18
|
From switch 1, they're going to router 6.
|
|
0:27:21
|
Then, to router 4, then to router 5.
|
|
0:27:26
|
So, to router 6, to router 4,
|
|
0:27:29
|
then, the link is using between 4 and 5 is the...
|
|
0:27:33
|
the frame-relay. So, it's going down into the EIGRP domain.
|
|
0:27:37
|
From here, now, the packets are getting lost.
|
|
0:27:42
|
So, this tells me that somewhere behind router 5,
|
|
0:27:45
|
so, somewhere in that direction.
|
|
0:27:48
|
Either router 5 does not have a route to that destination,
|
|
0:27:53
|
or the next hop doesn't have a route back.
|
|
0:27:58
|
Now again, this is assuming that we're not doing any filtering in the network.
|
|
0:28:01
|
If someone is filtering out UDP packets of ICMP unreachables,
|
|
0:28:06
|
then, the traceroute is not gonna be a good indication of this.
|
|
0:28:09
|
But assuming we don't have any type of application layer filtering,
|
|
0:28:12
|
then, traceroute is gonna be a good indication of what the routing table actually has.
|
|
0:28:19
|
So now, let's look at switch 2 and switch 4 and see what is their view of the topology.
|
|
0:28:26
|
On switch 2, let's look at the Show IP Route.
|
|
0:28:30
|
And we should be learning both internal and external EIGRP,
|
|
0:28:38
|
which if we look at it in the routing table, we can tell that there is a problem here.
|
|
0:28:43
|
So, I'm learning my internal EIGRP routes,
|
|
0:28:47
|
but I don't have any external EIGRP routes that are being learned from router 5.
|
|
0:28:53
|
Now, notice the prefixes that switch 2 does have reachability to.
|
|
0:28:58
|
This would be...
|
|
0:29:00
|
Let's say 155.28.13.1.
|
|
0:29:06
|
Or 23.2.
|
|
0:29:12
|
These particular prefixes
|
|
0:29:14
|
are ones that are natively inside the EIGRP domain already.
|
|
0:29:20
|
Now, even though EIGRP is being redistributed into OSPF,
|
|
0:29:25
|
since the internal EIGRP routes are a distance of 90,
|
|
0:29:30
|
and OSPF has a distance of 110,
|
|
0:29:32
|
it shouldn't really matter that I have the same overlapping routes in the database as I do in internal EIGRP.
|
|
0:29:42
|
So, we'll see, for most cases between OSPF and EIGRP,
|
|
0:29:45
|
the protocols are pretty much gonna take care of this on their own
|
|
0:29:48
|
what they should or should not redistribute,
|
|
0:29:52
|
and what they should or should not install in the routing table.
|
|
0:29:59
|
But we could see what the problem is now on switch 2.
|
|
0:30:02
|
We don't have any of the external routes.
|
|
0:30:05
|
Both the routes that should be coming from the RIP domain,
|
|
0:30:07
|
and the ones that should be coming from the OSPF domain.
|
|
0:30:13
|
So, let's go one hop closer to the source,
|
|
0:30:16
|
and look at what does router 5 say about these prefixes.
|
|
0:30:21
|
So, router 5 should be learning them from OSPF via router 4,
|
|
0:30:26
|
and from EIGRP via router 4.
|
|
0:30:34
|
Let's look at the Show IP Route.
|
|
0:30:42
|
So, notice in the routing table, we have...
|
|
0:30:45
|
internal EIGRP.
|
|
0:30:48
|
We have both internal and external OSPF.
|
|
0:30:53
|
But we don't have any external EIGRP.
|
|
0:30:57
|
So now, I probably wanna know,
|
|
0:31:00
|
is router 5 even learning these external routes to begin with?
|
|
0:31:05
|
Because remember with EIGRP, what's in the routing table
|
|
0:31:09
|
doesn't necessarily have to match up with what's in the EIGRP topology.
|
|
0:31:13
|
We can have routes in the topology that don't make it to the routing table,
|
|
0:31:17
|
because of other prefixes that are taking their place.
|
|
0:31:21
|
So on router 5, if we look at the Show IP EIGRP Topology,
|
|
0:31:27
|
we can see that a bunch of these prefixes,
|
|
0:31:31
|
say, that the feasible distance...
|
|
0:31:33
|
is inaccessible.
|
|
0:31:39
|
What this essentially means is that router 5 is learning whatever this prefix is,
|
|
0:31:45
|
but for some reason, it's not getting installed in the routing table.
|
|
0:31:50
|
And the reason why in this particular case
|
|
0:31:53
|
is that OSPF has a lower administrative distance.
|
|
0:31:57
|
So, even though we're learning the prefix from router 4, if we were to look at the...
|
|
0:32:02
|
the Show IP EIGRP Topology for that particular route,
|
|
0:32:08
|
we have valid information about the prefix.
|
|
0:32:11
|
It says the originating router is router 4.
|
|
0:32:15
|
The minimum bandwidth is T1, the total delay, 21,000 microseconds.
|
|
0:32:20
|
The reliability, the load, the MTU.
|
|
0:32:23
|
Normally, the metric value...
|
|
0:32:26
|
should be 2.1 million.
|
|
0:32:30
|
But it says our feasible distance is actually the infinite value.
|
|
0:32:37
|
So, when we see a difference between this value here, the feasible distance,
|
|
0:32:43
|
and what the actual metric we'd calculated through the neighbor,
|
|
0:32:47
|
this means that we're learning the route from some other protocol
|
|
0:32:52
|
that is stopping the EIGRP route from being installed.
|
|
0:32:57
|
Now, since we're not installing the route as EIGRP,
|
|
0:33:01
|
it then implies that we can't advertise the route through EIGRP.
|
|
0:33:06
|
So, if we look at the routing table and say Show IP Route
|
|
0:33:11
|
for 155.28.146.0,
|
|
0:33:16
|
the source protocol is not EIGRP.
|
|
0:33:18
|
The source protocol is OSPF.
|
|
0:33:22
|
And since OSPF distance is lower than external EIGRP,
|
|
0:33:27
|
it means that EIGRP route is not getting installed, which means it's not getting advertised.
|
|
0:33:35
|
Now, we could actually check this for every prefix in the network.
|
|
0:33:39
|
What we essentially would have to do is go on all of the routers
|
|
0:33:42
|
and collect all the addresses they had assigned on their links.
|
|
0:33:45
|
And then, we could use that to put together a TCL script.
|
|
0:33:50
|
Now, I have an example of this already set up here.
|
|
0:33:53
|
And let me cool up the...
|
|
0:34:03
|
actual document here.
|
|
0:34:06
|
And I have a little bit of a variation of the script written here,
|
|
0:34:11
|
where the script is inside a procedure.
|
|
0:34:14
|
The reason I'm doing this is that...
|
|
0:34:17
|
once I define the variable,
|
|
0:34:20
|
and this is the list of all the addresses in the network,
|
|
0:34:23
|
once I run to this for loop,
|
|
0:34:26
|
the...
|
|
0:34:31
|
the variable basically is only temporary in that particular scope.
|
|
0:34:35
|
So, by defining a procedure, I can run the script more than once
|
|
0:34:38
|
without having to redefine what are all of the addresses.
|
|
0:34:43
|
Now additionally, I have some other logic at the end
|
|
0:34:46
|
that instead of showing all of the results for the output,
|
|
0:34:50
|
it's basically gonna give me two return codes.
|
|
0:34:52
|
It's gonna say either it's okay or the address is unreachable.
|
|
0:34:57
|
And the way it's doing this is by looking at the result of the ping,
|
|
0:35:02
|
and then, looking for three explanations in a row.
|
|
0:35:08
|
So, if I'm sending five packets with a time out of 1,
|
|
0:35:11
|
ideally, I should be able to get at least three responses in a row.
|
|
0:35:15
|
That's gonna be fairly a good indication of whether the reachability is actually there.
|
|
0:35:21
|
Now, something like this within the scope of the lab exam,
|
|
0:35:23
|
you probably wouldn't wanna write a script like this
|
|
0:35:25
|
unless you're really good at programming syntax to begin with.
|
|
0:35:29
|
Okay, but I'm gonna use this for the rest of our examples
|
|
0:35:32
|
just so we can quickly tell what prefixes we do or do not have reachability to.
|
|
0:35:39
|
Now, also, I'm only listing 30.0.0.1.
|
|
0:35:43
|
I'm not listing all of the routes in the RIP domain.
|
|
0:35:46
|
The reason why is that if I have reachability to 1,
|
|
0:35:49
|
I can assume I can have reachability to all of them,
|
|
0:35:52
|
because in this topology, these are just basically just loopback addresses on BB3.
|
|
0:36:00
|
So, let's actually try this out.
|
|
0:36:02
|
Let's go to router 1.
|
|
0:36:07
|
Start the TCL shell.
|
|
0:36:11
|
So, I had a full list of addresses there.
|
|
0:36:15
|
Now, you can see it's going through the pings for all of them.
|
|
0:36:21
|
So, from router 1's perspective, it does not have any reachability problems.
|
|
0:36:26
|
If we were to do the same thing from router 2,
|
|
0:36:29
|
and let's actually test this from all of them.
|
|
0:36:32
|
Okay, and so start the TCL shell from all of the routers and I'm pasting the same script in.
|
|
0:36:43
|
On the switches here,
|
|
0:36:46
|
for these 3560s, these are running 12.2(46)SE.
|
|
0:36:53
|
So pretty much anything around this release should support TCL.
|
|
0:36:57
|
Some of the lower level platforms like the 2950s, the 3550s, those don't support TCL.
|
|
0:37:04
|
We'll look at it in a little bit what are some workarounds we can do
|
|
0:37:07
|
if you have a platform that doesn't run TCL,
|
|
0:37:10
|
a different type of scripting logic you can use in the Catalyst IOS.
|
|
0:37:15
|
But in the case of switch 1 and switch 2,
|
|
0:37:18
|
these devices do support TCL.
|
|
0:37:22
|
Switch 3 and switch 4 don't,
|
|
0:37:26
|
because these are lower level platforms. These are...
|
|
0:37:30
|
These are 3550s.
|
|
0:37:32
|
So, you can see, even though it's pretty much the same version of code,
|
|
0:37:36
|
one platform supports, one does not.
|
|
0:37:40
|
But from switch 3 and switch 4's perspective, if we look at the diagram,
|
|
0:37:44
|
I can pretty much assume that if switch 2 has reachability everywhere,
|
|
0:37:50
|
then, switch 4 is going to as well.
|
|
0:37:52
|
Because there's really no difference between these two configuration-wise.
|
|
0:37:55
|
Then, likewise, if switch 1 can reach everything,
|
|
0:37:58
|
it's pretty likely that switch 3 is going to as well.
|
|
0:38:02
|
Because there's no difference in the OSPF configurations.
|
|
0:38:13
|
Okay, so let's look at the result of this.
|
|
0:38:16
|
From router 1, it says, "I have reachability everywhere." That's fine.
|
|
0:38:20
|
Router 2 says there's a bunch of stuff that's unreachable.
|
|
0:38:24
|
We'd look at some of these, it's the VLAN 146.
|
|
0:38:30
|
So, both on router 1, 4, and 6's links.
|
|
0:38:36
|
Anything that's on switch 1,
|
|
0:38:40
|
anything that's on switch 3, router 2 does not have reachability to this.
|
|
0:38:45
|
So, if we look at specifically in the topology where router 2 is,
|
|
0:38:50
|
for all of the OSPF routes, router 2 would have to be learning them from what protocol?
|
|
0:39:00
|
It would have to be learning it from EIGRP, because that's the only one that is running.
|
|
0:39:05
|
So now, this is a pretty good indication
|
|
0:39:08
|
that there's something wrong in the EIGRP network.
|
|
0:39:11
|
From router 1's perspective, we were able to reach everything,
|
|
0:39:14
|
which means inside OSPF, inside EIGRP,
|
|
0:39:18
|
and then, this way to get to RIP.
|
|
0:39:22
|
So, this is kind of narrowing down for me where the problem is gonna be located.
|
|
0:39:30
|
So, we know now what the particular issue is
|
|
0:39:32
|
that router 4, or excuse me, router 5...
|
|
0:39:36
|
is receiving the OSPF route and the EIGRP route.
|
|
0:39:39
|
We have the OSPF distance of 110 versus EIGRP's 170.
|
|
0:39:45
|
This means that the EIGRP route is not installed in the table,
|
|
0:39:48
|
and that it cannot be advertised.
|
|
0:39:53
|
So, how can we fix this now?
|
|
0:39:59
|
Now, ultimately, the fix for these loops...
|
|
0:40:02
|
is gonna depend on why did the problem happened in the first place.
|
|
0:40:07
|
So, in the case of a metric-based loop,
|
|
0:40:10
|
we generally can do some sort of filter
|
|
0:40:13
|
that is going to delete the route that was chosen based on the wrong metric.
|
|
0:40:20
|
But anything that has to do with the administrative distance,
|
|
0:40:23
|
basically, the only fix that we could have would be to change the administrative distance.
|
|
0:40:29
|
Now, there's some very few minor exceptions to this.
|
|
0:40:32
|
We'll show one example here on router 5.
|
|
0:40:35
|
But for the vast majority of cases,
|
|
0:40:37
|
if the problem is because of administrative distance,
|
|
0:40:40
|
you're gonna have to change the distance to fix it.
|
|
0:40:43
|
If the problem is based on the metric, it gives you more options as to exactly what you can use.
|
|
0:40:49
|
But we know here specifically, our problem is that router 5 is choosing the wrong route based on the distance
|
|
0:40:56
|
which is preventing it from having reachability to...
|
|
0:40:59
|
preventing it from advertising other portions of the network.
|
|
0:41:06
|
So, to fix this thing, we're gonna have to do what?
|
|
0:41:11
|
We're gonna have to change the distance of 5.
|
|
0:41:14
|
So, if we can change the distance in some way
|
|
0:41:17
|
that the EIGRP route is installed in the routing table,
|
|
0:41:22
|
it should then mean that we can advertise the route.
|
|
0:41:26
|
But in our current case now where OSPF is being installed instead of EIGRP,
|
|
0:41:32
|
it means that EIGRP cannot be advertised.
|
|
0:41:36
|
Now, another key point here with the administrative distance
|
|
0:41:40
|
is that the value is only locally significant.
|
|
0:41:43
|
So, if I were to change it on router 4, it's not gonna affect router 5.
|
|
0:41:47
|
If the distance problem is on router 5,
|
|
0:41:49
|
I need to change it on router 5 in order to fix that.
|
|
0:41:54
|
So, we essentially have two different options.
|
|
0:41:57
|
We could take OSPF's distance and raise it so it's larger than EIGRPs,
|
|
0:42:04
|
or take EIGRPs distance and lower it so that it's less than OSPF.
|
|
0:42:12
|
It doesn't really matter which one we do.
|
|
0:42:14
|
It's gonna have the same end result.
|
|
0:42:17
|
The only time where this implementation is gonna matter
|
|
0:42:20
|
is if we're trying to change the distance on a per-route basis.
|
|
0:42:26
|
Where with EIGRP,
|
|
0:42:28
|
we cannot change the distance of an external route
|
|
0:42:32
|
on a per-prefix basis.
|
|
0:42:37
|
With OSPF, or RIP, or BGP,
|
|
0:42:40
|
we can selectively change the administrative distance on both internal routes and external routes.
|
|
0:42:48
|
So, I can say for the routes 1.2.3.4, I'm gonna set the distance to be 5.
|
|
0:42:53
|
But for the route 5.6.7.8, I'm gonna set the distance to be 10.
|
|
0:42:58
|
For EIGRP, that's works for only internal routes, doesn't work for external routes.
|
|
0:43:05
|
Which is really fine in this case, because we don't need to match the individual prefixes.
|
|
0:43:09
|
I basically just need to say that router 5 should not be installing anything through OSPF.
|
|
0:43:16
|
Because anything that is installed via this link
|
|
0:43:19
|
is immediately gonna invalidate the EIGRP information
|
|
0:43:23
|
that's coming over the alternate path.
|
|
0:43:28
|
So, let's fix this by lowering the distance on router 5.
|
|
0:43:32
|
We're gonna take the external EIGRP from 170,
|
|
0:43:35
|
and we're gonna drop if from anything lower than 110.
|
|
0:43:38
|
So, 109 or below.
|
|
0:43:47
|
So, let's go to the routing process. Router EIGRP 1.
|
|
0:43:52
|
We'll say, the...
|
|
0:43:54
|
the distance,
|
|
0:43:57
|
for EIGRP internal, we'll leave that as 90.
|
|
0:44:01
|
For external, I'm gonna set this to be 109.
|
|
0:44:05
|
So, it's at least one lower than OSPF.
|
|
0:44:09
|
I could say anything lower than that just that it's no larger than 109.
|
|
0:44:16
|
Now, when I clear the routing table,
|
|
0:44:21
|
then, Show IP Route,
|
|
0:44:25
|
we should now see the change
|
|
0:44:27
|
that the external EIGRP routes
|
|
0:44:31
|
are now being installed with the distance of 109
|
|
0:44:34
|
as opposed to the OSPF externals.
|
|
0:44:42
|
Since these are now being installed in the routing table,
|
|
0:44:46
|
it then implies that these routes should be able to be advertised.
|
|
0:44:49
|
So now, if we were to go to switch 2, and look at the routing table, Show IP Route EIGRP,
|
|
0:44:57
|
we see now, we have the external routes installed.
|
|
0:45:03
|
So, I can now rerun my ping script procedure.
|
|
0:45:08
|
And test reachability to...
|
|
0:45:13
|
the internal EIGRP routes,
|
|
0:45:16
|
and then any of the external EIGRP routes, the ones that came from the RIP process, or from OSPF.
|
|
0:45:24
|
So now, it's telling me from switch 2's perspective,
|
|
0:45:27
|
basically, I have reachability to everything
|
|
0:45:30
|
with the exception of just one link.
|
|
0:45:33
|
That is the link that is directly connected between...
|
|
0:45:37
|
router 5 and router 4.
|
|
0:45:42
|
But from switch 1, I am able to reach...
|
|
0:45:45
|
the addresses on switch 1.
|
|
0:45:49
|
I'm also able to reach the addresses on switch 3.
|
|
0:45:53
|
If we were to look at a traceroute,
|
|
0:45:56
|
let's say to 155.28.9.9, which is switch 3,
|
|
0:46:04
|
it says, "The packets are going to 5, to 4, to 6, to switch 1, then to switch 3."
|
|
0:46:12
|
So, it's going to 5, to 4 over the frame-relay because now, we're choosing the EIGRP route over the OSPF route.
|
|
0:46:21
|
Then, from 4 to 6, 6 to switch 1, and then switch 1 to switch 3.
|
|
0:46:30
|
So, it looks like now, the vast majority of problems have been solved here
|
|
0:46:34
|
with the exception of just that one link.
|
|
0:46:36
|
The link between router 4 and router 5.
|
|
0:46:41
|
So, even with the distance change on router 5,
|
|
0:46:45
|
why did that not solve our problem with having reachability to that...
|
|
0:46:50
|
serial link directly 4 and 5?
|
|
0:47:01
|
Let's take a look at what router 4 and router 5 says.
|
|
0:47:05
|
So, I first wanna know on router 4,
|
|
0:47:07
|
did this prefix actually get advertised into EIGRP?
|
|
0:47:12
|
If I look at the Show IP EIGRP interfaces,
|
|
0:47:17
|
that link...
|
|
0:47:22
|
the frame-relay... I actually wanna look at... No that, I wanna look at the Show IP OSPF Interface Brief.
|
|
0:47:28
|
Okay, interface serial 0/1/0,
|
|
0:47:31
|
that's running OSPF area 0.
|
|
0:47:34
|
That's the links that's connecting over to router 5.
|
|
0:47:37
|
Since I am redistributing OSPF into EIGRP,
|
|
0:47:41
|
it should imply that any routes installed as EIGRP
|
|
0:47:46
|
plus any connected links, actually, excuse me, we're going the other way.
|
|
0:47:49
|
We're going OSPF to EIGRP.
|
|
0:47:52
|
It means any routes installed in the table as OSPF,
|
|
0:47:56
|
plus any connected links running OSPF, that's what should be redistributed in the EIGRP topology.
|
|
0:48:02
|
So, if I look at the Show IP EIGRP Topology for 155.28.45.0/24,
|
|
0:48:10
|
I wanna know, did router 4 actually do the redistribution for this?
|
|
0:48:16
|
Which it did.
|
|
0:48:18
|
It says, "The next hop is 0.0.0.0 from redistributed."
|
|
0:48:22
|
This basically means that I am doing the origination.
|
|
0:48:25
|
Okay, originating router is 150.28.4.4.
|
|
0:48:30
|
This system means that's my router ID.
|
|
0:48:35
|
Now, router 4 is adjacent with router 5 via EIGRP.
|
|
0:48:40
|
So, this prefix should be advertised in an EIGRP update message.
|
|
0:48:46
|
If we look at router 5 and look at the same exact output,
|
|
0:48:52
|
router 5 says "I am learning it.
|
|
0:48:57
|
I am learning it form router 4.
|
|
0:49:00
|
My metric normally would be 2.1 million,
|
|
0:49:06
|
but the feasible distance value there is the infinite one."
|
|
0:49:17
|
So, why in this case would router 5
|
|
0:49:21
|
not install this route that is learning from EIGRP?
|
|
0:49:32
|
So, let's look at what is router 5 installing it as.
|
|
0:49:36
|
If we Show IP Route 155.28.45.0,
|
|
0:49:42
|
this is a connected link.
|
|
0:49:44
|
The administrative distance of connected links is always zero,
|
|
0:49:49
|
and there's no way to change that.
|
|
0:49:51
|
So, the router is always gonna prefer it's connected interface
|
|
0:49:54
|
over any dynamically learned route about that.
|
|
0:49:59
|
So, this now means, even though I'm now learning it through EIGRP
|
|
0:50:02
|
with the modified distance of 109,
|
|
0:50:06
|
109 is still higher than the connected distance of 0,
|
|
0:50:10
|
so, it means I cannot install the route as EIGRP, and I cannot advertise it.
|
|
0:50:19
|
Now, the issue we're gonna run into here
|
|
0:50:22
|
is that we can't change the distance of a connected route.
|
|
0:50:26
|
So, if router 5 is gonna be advertising this prefix,
|
|
0:50:31
|
what does it imply we have to do?
|
|
0:50:42
|
So, router 5 is only gonna advertise...
|
|
0:50:46
|
this link...
|
|
0:50:47
|
to switch 2...
|
|
0:50:48
|
in what case?
|
|
0:50:56
|
If router 5 is locally originating it.
|
|
0:51:00
|
So, if router 5 were to do the redistribution,
|
|
0:51:03
|
we would never see this problem to begin with,
|
|
0:51:08
|
because there's now issue of taking the routes from the routing table as OSPF,
|
|
0:51:13
|
and then, originating them myself as EIGRP.
|
|
0:51:18
|
The only problem in this topology
|
|
0:51:21
|
is that router 4's doing the redistribution.
|
|
0:51:23
|
So, 5 is learning them through EIGRP with the higher distance than the OSPF routes,
|
|
0:51:29
|
which means the EIGRP cannot get installed.
|
|
0:51:33
|
Since it's not installed, it means that we're not advertising it.
|
|
0:51:36
|
Switch 2 is never gonna learn those routes.
|
|
0:51:40
|
We tried to fix this by setting the EIGRP distance to 109,
|
|
0:51:45
|
and left OSPF as default for 110,
|
|
0:51:48
|
that's gonna be fine for the dynamically learned routes,
|
|
0:51:56
|
but it's not gonna affect our connected interface.
|
|
0:51:59
|
So really, the only solution for this would be to go to router 5,
|
|
0:52:04
|
and then under the EIGRP process,
|
|
0:52:07
|
either do Redistribute Connected,
|
|
0:52:09
|
or just have a network statement that is matching that particular link.
|
|
0:52:14
|
So, if I say Redistribute Connected,
|
|
0:52:19
|
and then, set the metric value. Let's say... It doesn't matter what it is. I'll just say all 1s.
|
|
0:52:28
|
Now, on router 5, when I look at the topology,
|
|
0:52:34
|
notice the change here, it now says, this is coming from me
|
|
0:52:39
|
as Redistribute Connected.
|
|
0:52:46
|
So, if we now look at the result of this on...
|
|
0:52:49
|
switch 2,
|
|
0:52:51
|
we say, Show IP Route 155.28.45.0,
|
|
0:52:57
|
we see now the route is learned through EIGRP,
|
|
0:53:00
|
which means then, we should be able to reach it.
|
|
0:53:03
|
So, in this particular example,
|
|
0:53:06
|
we don't necessarily have a routing loop per se,
|
|
0:53:10
|
it's simply based on the advertisement rules of EIGRP,
|
|
0:53:14
|
we're not allowed to continue to advertise the route that is not actually installed through that protocol.
|
|
0:53:21
|
If we were to change the EIGRP domain with RIP,
|
|
0:53:26
|
we would still see the same problem here.
|
|
0:53:29
|
Because RIP has a distance of 120, where OSPF has a distance of 110.
|
|
0:53:35
|
It means that when router 5 were to learn the RIP routes,
|
|
0:53:39
|
and the equal matches via OSPF,
|
|
0:53:45
|
we would choose the 110 through OSPF,
|
|
0:53:48
|
which means we would not advertise the route out any interfaces running RIP.
|
|
0:53:56
|
Now, if this was swapped around though, on the point-to-point link between router 4 and 5,
|
|
0:54:00
|
if this was EIGRP,
|
|
0:54:03
|
and then down here, this was OSPF,
|
|
0:54:06
|
then, we're not gonna have the problem.
|
|
0:54:10
|
Because from OSPF's perspective, it doesn't care if the route is installed in the routing table,
|
|
0:54:15
|
it says that everyone who's in the link state area
|
|
0:54:19
|
has to have the identical copy of the database.
|
|
0:54:21
|
So, the LSA flooding is independent of the path selection.
|
|
0:54:25
|
Whereas with EIGRP and RIP,
|
|
0:54:27
|
the path selection, and the advertisements map on a 1 to 1 basis.
|
|
0:54:33
|
So, during path selection, if I say that some route is invalid,
|
|
0:54:37
|
it means that I cannot advertise it.
|
