|
0:00:14
|
In our next section with redistribution,
|
|
0:00:16
|
we're gonna look at an example of a loop that would occur based on the metric value,
|
|
0:00:21
|
and the different ways that we could prevent this
|
|
0:00:23
|
based on route tagging, of filtering with access lists, prefix lists,
|
|
0:00:28
|
and with administrative distance.
|
|
0:00:31
|
Now, the previous problem that we looked at
|
|
0:00:33
|
was related to EIGRP's behavior,
|
|
0:00:36
|
where a route that is not installed from the topology into the routing table
|
|
0:00:40
|
cannot be advertised by the protocol.
|
|
0:00:44
|
With the previous topology, we would have also seen the same case
|
|
0:00:47
|
if EIGRP had been replace with RIP.
|
|
0:00:50
|
Because likewise, if RIP has not installed a route into the routing table,
|
|
0:00:53
|
it means that it cannot advertise it.
|
|
0:00:57
|
Now, in either of those cases, usually, they're based on administrative distance-based loops
|
|
0:01:01
|
that can only be solved by changing the distance.
|
|
0:01:05
|
Now, in this topology, we have a different case,
|
|
0:01:07
|
where there are multiple points of redistribution between the RIP domain and the OSPF domain.
|
|
0:01:15
|
Now, as I mentioned before,
|
|
0:01:17
|
in a topology like this, if there were only one single point of redistribution,
|
|
0:01:22
|
so if router 3 did not exist in this network,
|
|
0:01:25
|
then, we would never have a case for a possibility of a loop.
|
|
0:01:29
|
We could simply go to router 4,
|
|
0:01:31
|
redistribute OSPF into RIP, redistribute RIP back into OSPF,
|
|
0:01:35
|
and we would never have a problem.
|
|
0:01:37
|
The issues with redistribution are gonna come in to the topologies
|
|
0:01:40
|
when the protocol is meeting multiple times.
|
|
0:01:44
|
Just like the case where we had before,
|
|
0:01:47
|
where OSPF and EIGRP were running on multiple routers at the same time,
|
|
0:01:52
|
then, we would have a potential issue
|
|
0:01:54
|
with routes learned from both EIGRP and OSPF at the same time.
|
|
0:01:59
|
So, the case is gonna be similar in this example,
|
|
0:02:03
|
but the loop here is gonna be based on
|
|
0:02:06
|
wrong metric values, not on the wrong administrative distance.
|
|
0:02:11
|
So ultimately,
|
|
0:02:13
|
router 6 is learning routes from BB1 via RIP.
|
|
0:02:19
|
These are then being advertised out all its connected interfaces, these are going to router 4
|
|
0:02:23
|
to switch 1, from switch 1 then goes down to switch 3 and over to router 3.
|
|
0:02:31
|
Router 4 is then gonna be redistributing these prefixes into OSPF.
|
|
0:02:36
|
From router 4, they go to 5.
|
|
0:02:38
|
From 5, they go down to switch 2 and switch 4.
|
|
0:02:42
|
From 5, it then goes back to router 3, and back to router 2.
|
|
0:02:49
|
Then, there would be additional LSA flooding on the link between router 2 and router 3,
|
|
0:02:54
|
but based on the default costs, we should see that most likely, that link is not gonna be used.
|
|
0:03:00
|
Now, with just the single redistribution on router 4,
|
|
0:03:04
|
what is the potential problem that we now have
|
|
0:03:08
|
between the RIP and the OSPF domains?
|
|
0:03:11
|
We see that on router 3,
|
|
0:03:14
|
we now have multiple potential paths to the same destination.
|
|
0:03:18
|
One of them is gonna be coming from RIP with a distance of 120.
|
|
0:03:24
|
One of them is coming from OSPF with the distance of 110.
|
|
0:03:30
|
So, this means that for prefixes that are the same longest match,
|
|
0:03:35
|
router 3 would be installing the OSPF route over the RIP route.
|
|
0:03:41
|
Now, in this topology, it really doesn't matter which way router 3 installs the route,
|
|
0:03:46
|
as long as we ultimately have reachability to the destination.
|
|
0:03:50
|
What would be a problem in this type of topology though
|
|
0:03:54
|
is that if router 3 has a link to some other device in RIP,
|
|
0:04:00
|
let's say, router 7.
|
|
0:04:03
|
And this link was running RIP.
|
|
0:04:06
|
When router 3 chooses to install the OSPF route over the RIP route,
|
|
0:04:15
|
what would this then imply about advertisements from router 3 to router 7?
|
|
0:04:22
|
For any RIP prefixes that are not installed in the routing table as RIP,
|
|
0:04:27
|
those would not be advertised out that link.
|
|
0:04:30
|
So, if router 4 is the only one doing redistribution of RIP into OSPF,
|
|
0:04:34
|
it essentially means that router 7 would be isolated from the rest of the RIP topology.
|
|
0:04:40
|
So again, there's really no general rules that you can apply on to redistribution.
|
|
0:04:46
|
You simply need to look at the flow of the topology,
|
|
0:04:49
|
look at where the routes are gonna be advertised on a hop-by-hop basis,
|
|
0:04:53
|
that's gonna give you a better idea if there are potential problems in the individual topology design.
|
|
0:05:01
|
So here, our problem is unrelated to that.
|
|
0:05:04
|
We have, again, the routes coming from BB1.
|
|
0:05:06
|
These are advertised everywhere into RIP.
|
|
0:05:10
|
Router 4 is doing redistribution of RIP into OSPF.
|
|
0:05:14
|
The routes get to 5.
|
|
0:05:16
|
5 should send these to switch 2 and 4,
|
|
0:05:19
|
5 sends them back to 2 and 3.
|
|
0:05:22
|
Now, router 3 has the route through OSPF with the distance of 110.
|
|
0:05:27
|
And the route from RIP with the distance of 120.
|
|
0:05:30
|
This then means that the RIP route is no longer installed in the routing table.
|
|
0:05:34
|
And the OSPF route takes its place.
|
|
0:05:39
|
Let's also now say that router 3 is redistributing from OSPF back into RIP.
|
|
0:05:47
|
Now, depending on what the seed metric is that router 3 configures,
|
|
0:05:52
|
when 3 sends this to switch 1,
|
|
0:05:55
|
switch 1 now has two possible choices.
|
|
0:05:59
|
Both of these are RIP routes with a distance of 120.
|
|
0:06:04
|
So, this means that we would then need to look at the metric or the hop count.
|
|
0:06:10
|
So, whichever hop count is lower,
|
|
0:06:13
|
that would be the route that switch 1 installs into the routing table,
|
|
0:06:18
|
which means, that is the one that it continues to advertise.
|
|
0:06:23
|
So, what could be the potential design problem
|
|
0:06:27
|
in a topology like this. If we're doing mutual redistribution
|
|
0:06:30
|
on both router 3 and router 4 at the same time...
|
|
0:06:34
|
between OSPF and RIP.
|
|
0:06:37
|
Now, let's look at this in a perspective of one individual prefix.
|
|
0:06:43
|
Let's say that BB1 is advertising to router 6...
|
|
0:06:50
|
some prefix X.
|
|
0:06:53
|
At this point, router 6 has X...
|
|
0:06:57
|
via BB1...
|
|
0:07:01
|
from RIP.
|
|
0:07:05
|
6 then advertises this to router 4.
|
|
0:07:09
|
Router 4 says, "I have X via RIP...
|
|
0:07:15
|
via router 6."
|
|
0:07:18
|
4 is then redistributing this into OSPF.
|
|
0:07:21
|
It goes from 4 to 5, 5 says, "I have X via OSPF...
|
|
0:07:28
|
via router 4."
|
|
0:07:31
|
5 sends this to 3, 3 says, "X is via OSPF...
|
|
0:07:37
|
from router 5."
|
|
0:07:40
|
Now, router 3 is doing redistribution of the same prefix back into RIP.
|
|
0:07:47
|
Switch 1 now has multiple paths to the same destination.
|
|
0:07:51
|
It has X via RIP in both cases,
|
|
0:07:55
|
but 1 is via router 6,
|
|
0:07:59
|
1 is via router 3.
|
|
0:08:01
|
So, it's gonna pick whichever one of these has the lower hop count.
|
|
0:08:06
|
So really, it depends when I learn these routes originally in from BB1,
|
|
0:08:11
|
what was the metric that router 6 was receiving.
|
|
0:08:15
|
Let's say theoretically, the metric is 5.
|
|
0:08:20
|
When router 6 receives the metric of 5,
|
|
0:08:23
|
it's gonna increment this as it's advertised out to switch 1.
|
|
0:08:28
|
Switch 1 now says, "I have it as a metric of 6 if I were to go to router 6".
|
|
0:08:32
|
And the metric via router 3 is gonna be dependent on what we set the seed metric as.
|
|
0:08:39
|
Let's say we set it to a metric of 1.
|
|
0:08:45
|
This would then mean
|
|
0:08:47
|
that switch 1 invalidates the update coming in from router 6,
|
|
0:08:52
|
and prefers the update coming in from router 3.
|
|
0:08:57
|
Now, at this point, that's not necessarily bad,
|
|
0:09:01
|
it's just most likely sub-optimal routing to get to the destination.
|
|
0:09:05
|
It basically would mean that switch 1 would route its packets this direction...
|
|
0:09:10
|
in order to get to BB1.
|
|
0:09:14
|
But now, what's gonna happen if switch 1 advertises this route
|
|
0:09:18
|
up to router 6 with a metric of 2?
|
|
0:09:27
|
Router 6 now says, "I have two possible paths to the destination:
|
|
0:09:31
|
one of them is via BB1 with a metric of 5,
|
|
0:09:34
|
one of them is via switch 1 with a metric of 2."
|
|
0:09:40
|
Since they both have an equal administrative distance,
|
|
0:09:43
|
then, we're gonna look at the metric value.
|
|
0:09:46
|
Metric is 2 is better that a metric of 5,
|
|
0:09:49
|
which means that we install the route via switch 1,
|
|
0:09:53
|
we withdraw this route.
|
|
0:09:57
|
Then, we advertise to router 4
|
|
0:10:00
|
the route via switch 1.
|
|
0:10:07
|
Now, whether this problem is actually gonna happen
|
|
0:10:09
|
is dependent on what the underlying metric values are.
|
|
0:10:13
|
If it just so happens that the metric value from BB1
|
|
0:10:17
|
is already lower than the metric that router 3 is seeing,
|
|
0:10:22
|
we wouldn't see the problem.
|
|
0:10:25
|
The issue is that it's non-deterministic.
|
|
0:10:28
|
It depends on the different variables of the topology that may or may not be within our control.
|
|
0:10:36
|
So, in reality, to fix this problem,
|
|
0:10:38
|
we wouldn't want to change the metric value.
|
|
0:10:42
|
What we would instead want to do is tell router 3,
|
|
0:10:47
|
when a route goes from RIP to OSPF,
|
|
0:10:51
|
then, I'm gonna redistribute OSPF into RIP.
|
|
0:10:55
|
Don't redistribute the routes that router 4 also learned from RIP.
|
|
0:11:04
|
So, if we were to put these into two categories, if we say the...
|
|
0:11:08
|
the routes that router 4 learns from RIP, we'll say that these R4.
|
|
0:11:14
|
And the routes that router 4 is learning from OSPF are O4,
|
|
0:11:20
|
when router 3 does its redistribution...
|
|
0:11:25
|
from...
|
|
0:11:25
|
OSPF into RIP,
|
|
0:11:29
|
basically, we should say, "Don't redistribute...
|
|
0:11:32
|
those RIP routes from 4."
|
|
0:11:35
|
But we could redistribute anything that's actually learned from OSPF to begin with.
|
|
0:11:42
|
So we see, implementation-wise, there's a number of different ways that we could do this.
|
|
0:11:46
|
One way would be to match on the exact prefixes.
|
|
0:11:50
|
So, I could say, "Match all the individual routes...
|
|
0:11:53
|
that are inside the RIP domain."
|
|
0:11:55
|
Then on router 3, tell it not to redistribute these from OSPF into RIP.
|
|
0:12:01
|
I could also match on the route type.
|
|
0:12:04
|
I could say on router 4, when I redistribute from RIP into OSPF,
|
|
0:12:09
|
I'm gonna set these to external Type-1.
|
|
0:12:14
|
Then on router 3, when I go from OSPF back into RIP,
|
|
0:12:17
|
I could say, Not External Type-1 Routes.
|
|
0:12:21
|
And then permit anything else after that.
|
|
0:12:24
|
It would mean, these particular prefixes...
|
|
0:12:28
|
would not be redistributed again on router 3.
|
|
0:12:34
|
Okay, another method would be to use the route tag...
|
|
0:12:38
|
that is included in the OSPF and EIGRP update.
|
|
0:12:45
|
On router 4, as we redistribute routes from RIP into OSPF,
|
|
0:12:49
|
we could set a tag value
|
|
0:12:52
|
of any arbitrary number that we define. Let's say we'll set the tag value to be 4.
|
|
0:12:59
|
When router 3 now redistributes from OSFP into RIP,
|
|
0:13:03
|
we would say, Redistribute Not Tag 4,
|
|
0:13:09
|
but then, anything else after that.
|
|
0:13:14
|
So, this type of implementation
|
|
0:13:17
|
would then automatically account for any new routes
|
|
0:13:20
|
that were injected in the RIP domain.
|
|
0:13:26
|
So, it really is a design question
|
|
0:13:30
|
as to do we want absolute control over what particular routes are advertised,
|
|
0:13:35
|
or do we just wanna put them into a more general category?
|
|
0:13:38
|
If we want an absolute control,
|
|
0:13:41
|
then, we would have to actually match the prefix with the prefix list or an access list.
|
|
0:13:46
|
But if we're looking with just a general category,
|
|
0:13:48
|
we're saying on router 3, don't redistribute anything that router 4 already did.
|
|
0:13:55
|
This is generally what the tag value is gonna be used for.
|
|
0:13:58
|
There is a question here,
|
|
0:14:02
|
"As I said earlier, it's nearly impossible to have a routing loop if you redistribute only on one router.
|
|
0:14:09
|
How would the loop occur?"
|
|
0:14:10
|
Well, the loop is gonna happen in this place if we do redistribution on multiple routers.
|
|
0:14:17
|
So, if I don't do any redistribution on router 3,
|
|
0:14:21
|
it's not gonna be an issue.
|
|
0:14:23
|
Okay, the key is, you need to look at a topology,
|
|
0:14:28
|
where the same routing domains are meeting in multiple places.
|
|
0:14:33
|
So, in this case, we have the RIP domain where we could say that this is routing domain A,
|
|
0:14:40
|
and OSPF is routing domain B.
|
|
0:14:43
|
A and B are meeting at router 4,
|
|
0:14:46
|
which is fine. It's not necessarily gonna cause a problem,
|
|
0:14:49
|
but now, A and B are also meeting again on router 3,
|
|
0:14:54
|
this is then a potential issue that we need to watch out for.
|
|
0:14:58
|
Because anything that comes from A to B
|
|
0:15:02
|
could potentially be fed back from B to A,
|
|
0:15:06
|
and then, we could either cause a loop based on administrative distance or based on the metric value.
|
|
0:15:14
|
But if router 3 did not exist in this topology,
|
|
0:15:17
|
if the only meeting point between these protocols was on router 4,
|
|
0:15:21
|
then, we don't need to worry about any type of filtering.
|
|
0:15:24
|
So, we don't need access lists, or prefix lists, or route tag, or administrative distance,
|
|
0:15:29
|
we could simply go under the RIP process. Say, Redistribution OSPF 1 Metric 1.
|
|
0:15:34
|
Then, under OSPF say, Redistribution RIP Subnets.
|
|
0:15:39
|
It's only the case where there is multiple meeting points...
|
|
0:15:43
|
between the same routing domain.
|
|
0:15:46
|
Okay, it could also be a case where there's a third protocol that's meeting,
|
|
0:15:50
|
which would be one of the examples we'll look at after this.
|
|
0:15:55
|
So, if we had for example OSPF
|
|
0:16:00
|
that is redistributing into EIGRP,
|
|
0:16:05
|
then, EIGRP is redistributing into RIP,
|
|
0:16:11
|
and RIP is redistributing back into OSPF,
|
|
0:16:15
|
this is the same type of case.
|
|
0:16:18
|
Because there's now nothing preventing a route that came from OSFP to begin with...
|
|
0:16:23
|
to go to EIGRP...
|
|
0:16:29
|
From EIGRP to RIP,
|
|
0:16:30
|
and then get redistributed back into OSPF,
|
|
0:16:34
|
and then it's starting to route the traffic that way.
|
|
0:16:39
|
But if there are only two domains to begin with,
|
|
0:16:43
|
if there was only EIGRP and OSPF,
|
|
0:16:45
|
then, we could never have this problem.
|
|
0:16:49
|
Then likewise, if there's a second meeting point between them,
|
|
0:16:51
|
this is again a potential issue.
|
|
0:16:53
|
Because we don't want the prefix A to go from OSPF to EIGRP,
|
|
0:16:57
|
and then get fed back in to OSPF.
|
|
0:17:02
|
This is the case where...
|
|
0:17:04
|
what we're gonna look at here.
|
|
0:17:11
|
So, let's actually look at this on the command line.
|
|
0:17:14
|
At this point, if we look at the...
|
|
0:17:17
|
the routing process on the devices,
|
|
0:17:22
|
the meeting points which are router 3 and router 4,
|
|
0:17:27
|
up to this point, we're not doing any redistribution.
|
|
0:17:30
|
So, on router 3, if we look at the Show IP Route RIP,
|
|
0:17:35
|
we see, we have prefixes that are coming from the RIP domain.
|
|
0:17:40
|
These 212 routes,
|
|
0:17:42
|
these are the ones that came from the external BB1 router.
|
|
0:17:48
|
So, router 6 is learning those from BB1.
|
|
0:17:51
|
6 is then advertising them...
|
|
0:17:57
|
advertising them to switch 1, switch 1's advertising them to router 3.
|
|
0:18:02
|
Likewise, router 6 should be advertising these to router 4.
|
|
0:18:05
|
So at this point, we should have reachability to these prefixes,
|
|
0:18:09
|
because they're internal to our routing domain.
|
|
0:18:12
|
Router 3 is able to reach them.
|
|
0:18:16
|
And then likewise, router 4 should be able to reach them.
|
|
0:18:23
|
Okay, the next step we're gonna redistribute...
|
|
0:18:25
|
from RIP into OSPF,
|
|
0:18:30
|
and then from OSPF into RIP on router 4.
|
|
0:18:40
|
So first, let's go under the OSPF process, we'll say Redistribute RIP Subnets.
|
|
0:18:45
|
Under RIP, we'll Redistribute OSPF 1.
|
|
0:18:50
|
And give it a metric. We'll say Metric 1.
|
|
0:18:55
|
Now, on router 4, we can verify locally, did this redistribution actually occur?
|
|
0:19:00
|
So, if we Show IP RIP Database,
|
|
0:19:05
|
we should see the routes locally getting redistributed, which they are.
|
|
0:19:12
|
If we look at the OSPF database,
|
|
0:19:17
|
we should see Type-5 external LSAs that are generated by router 4, which they are.
|
|
0:19:23
|
So, this is telling us now bi-directionally,
|
|
0:19:26
|
redistribution from RIP to OSPF and from OSPF to RIP is working.
|
|
0:19:33
|
So now, let's try testing the reachability.
|
|
0:19:36
|
Let's say we want to go to switch 2,
|
|
0:19:39
|
and we want to test reachability to these different RIP routes.
|
|
0:19:44
|
So again, we could do these all individually,
|
|
0:19:47
|
or we could do this with a TCL script.
|
|
0:19:52
|
So, the vast majority of these prefixes are the same as out previous example
|
|
0:19:56
|
with a few minor differences.
|
|
0:19:58
|
Okay, the external routes that I now want to test are 212.18.0.1,
|
|
0:20:07
|
212.18.1.1,
|
|
0:20:11
|
2.1 and 3.1.
|
|
0:20:15
|
The rest of the routes are internal to the rest of the topology.
|
|
0:20:20
|
And also, router 1 is not part of this. So, I'm gonna remove...
|
|
0:20:25
|
any of the links that are referencing router 1 here.
|
|
0:20:39
|
So, from switch 2, we should see that...
|
|
0:20:42
|
pretty much everything we have reachability to.
|
|
0:20:46
|
Which we do.
|
|
0:20:48
|
So, this is telling us that since there's only a single point of redistribution,
|
|
0:20:53
|
there's no need for us to do any filtering.
|
|
0:20:56
|
There's never gonna be a case where router 4 redistributes from RIP to OSPF.
|
|
0:21:04
|
Then, the route comes back on a different interface,
|
|
0:21:06
|
and router 4 redistributes from OSPF back into RIP.
|
|
0:21:13
|
Why would this case never occur here?
|
|
0:21:19
|
Because remember, OSPF doesn't use Split Horizon.
|
|
0:21:23
|
So, we are gonna run into a case where router 5
|
|
0:21:26
|
advertises router 4's route back to itself.
|
|
0:21:35
|
When router 4 originates the RIP routes into OSPF to begin with,
|
|
0:21:40
|
what is it using for loop prevention?
|
|
0:21:46
|
It's using its OSPF router ID.
|
|
0:21:50
|
So, inside the Type-5 LSA,
|
|
0:21:52
|
if we were to go to router 4, and say Show IP OSPF Database,
|
|
0:21:59
|
for the external route 212.18.0.0,
|
|
0:22:07
|
router 4 says that the advertising router is 150.28.4.4,
|
|
0:22:14
|
which is the same as our router ID. So, it says we are the originator.
|
|
0:22:18
|
This means that if we were to learn LSA in a different interface,
|
|
0:22:23
|
router 4 would automatically discard it.
|
|
0:22:27
|
The same case would be true if this were EIGRP.
|
|
0:22:30
|
Since both EIGRP and OSPF use the router ID as essentially a tag value
|
|
0:22:35
|
inside the external route,
|
|
0:22:38
|
there's never a case where we would go from RIP to OSPF,
|
|
0:22:41
|
and then send the same route from OSPF back into RIP.
|
|
0:22:45
|
Assuming it's only happening on one router.
|
|
0:22:49
|
The problem that we're now gonna need to prevent
|
|
0:22:51
|
is that it's happening on multiple routers.
|
|
0:22:54
|
There's now nothing stopping router 4 from sending the routes to OSPF.
|
|
0:23:00
|
They arrive at router 3,
|
|
0:23:02
|
then, 3 to advertise them back into RIP.
|
|
0:23:08
|
So, if we look at router 3 and look at the Show IP Route,
|
|
0:23:13
|
we should now see that those routes that were previously installed as RIP
|
|
0:23:18
|
are now being installed as OSPF,
|
|
0:23:21
|
because the distance of OSPF at 110 is lower than the distance of RIP at 120.
|
|
0:23:28
|
So now, let's do the same type of redistribution on router 3 without doing any filtering,
|
|
0:23:33
|
and then, we'll look at what the end result is.
|
|
0:23:36
|
So, on router 3, this go under the OSPF process, we'll say Redistribute RIP Subnets.
|
|
0:23:44
|
Then, under the RIP process, we'll say Redistribute OSPF 1.
|
|
0:23:49
|
We'll give it a metric value of 1.
|
|
0:23:54
|
Now, if we look in the OSPF database,
|
|
0:23:58
|
Show IP OSPF Database. And I wanna know what are the LSAs that router 3 is locally generating here?
|
|
0:24:06
|
The Type-5 AS external link states.
|
|
0:24:10
|
It says, "I'm originating 150.28.4.0,
|
|
0:24:17
|
and 155.38.37.0."
|
|
0:24:31
|
So, only two prefixes there.
|
|
0:24:37
|
Why would router 3 only be redistributing two routes...
|
|
0:24:43
|
from RIP to OSPF
|
|
0:24:45
|
and not everything that came from RIP to begin with?
|
|
0:24:53
|
So, let's take this...
|
|
0:24:55
|
155.28.9.0 as an example.
|
|
0:25:01
|
That is the prefix that switch 3 has assigned on that VLAN 9.
|
|
0:25:09
|
From switch 3, this goes to switch 1,
|
|
0:25:11
|
switch 1 sends it to router 3,
|
|
0:25:15
|
switch 1 sends to 6,
|
|
0:25:17
|
6 sends it to router 4,
|
|
0:25:21
|
4 is now redistributing from RIP to OSPF.
|
|
0:25:26
|
Eventually, this gets back to router 3.
|
|
0:25:30
|
3 now has two routes to the destination.
|
|
0:25:35
|
One of them is an OSPF route with a distance of 110,
|
|
0:25:39
|
one of them is the RIP route with the distance of 120.
|
|
0:25:47
|
What is this now gonna change on router 3?
|
|
0:25:55
|
Well, we know that the OSPF route is gonna get installed in the routing table, right?
|
|
0:25:59
|
Because it's the one that has the lower distance.
|
|
0:26:03
|
But what else is that going to affect about the RIP domain now?
|
|
0:26:10
|
If the RIP route is not in the routing table,
|
|
0:26:13
|
it also means that it cannot be redistributed.
|
|
0:26:17
|
So, we end up in a case here where even though router 3 is doing RIP to OSPF redistribution,
|
|
0:26:24
|
nothing is being originated
|
|
0:26:26
|
with the exception of that connected interface.
|
|
0:26:31
|
And there was one other route that we saw, it was the, I believe the loopback of router 4.
|
|
0:26:37
|
And I believe the reason why this is being advertised, if we look at the Show IP Route RIP
|
|
0:26:44
|
versus the Show IP Route OSPF,
|
|
0:26:48
|
this particular prefix, this is the loopback address of router 4,
|
|
0:26:53
|
whereas in OSPF, this is being learned as the host route.
|
|
0:27:00
|
Because by default in OSPF, the loopback is being treated as network type loopback.
|
|
0:27:06
|
So, from router 4's perspective,
|
|
0:27:09
|
this route is advertised... The loopback of router 4 is advertised in the RIP as 150.28.4.0/24.
|
|
0:27:19
|
In this OSPF, it's advertised as 150.28.4.4/32.
|
|
0:27:27
|
So, it's simply that there are two different routes.
|
|
0:27:30
|
One of them exists on in RIP, and one of them exists only in OSPF.
|
|
0:27:36
|
Now, I could fix this if I went to router 4,
|
|
0:27:39
|
and said...
|
|
0:27:42
|
on the loopback, IP OSPF Network Point-to-Point.
|
|
0:27:47
|
This should then withdraw my /32 from my OSPF domain, and it's gonna replace it with a /24.
|
|
0:27:56
|
So now, on router 3, when we look at the Show IP Route RIP,
|
|
0:27:59
|
basically, it has nothing here.
|
|
0:28:03
|
If we look at the OSPF database,
|
|
0:28:06
|
we should now see, the only thing that router 3 is redistributing
|
|
0:28:11
|
is the connected interface that's running the RIP process.
|
|
0:28:19
|
So, this is a key point to know here because again, the redistribution happens from the routing table,
|
|
0:28:25
|
not from the routing database.
|
|
0:28:28
|
The end result of this is gonna be...
|
|
0:28:30
|
that essentially, whoever performs the redistribution first
|
|
0:28:35
|
is gonna be the device that is preferred for the OSPF route.
|
|
0:28:40
|
So, let's say we were to go to...
|
|
0:28:46
|
router 3.
|
|
0:28:49
|
And we do a traceroute for that particular prefix.
|
|
0:28:55
|
If router 3 is using the RIP route, then, the traffic should go that way.
|
|
0:29:01
|
If it's using the OSPF route, then, it's gonna go...
|
|
0:29:04
|
this way.
|
|
0:29:08
|
So, on router 3, let's trace 155.28.9.9.
|
|
0:29:20
|
Now, we have a problem.
|
|
0:29:27
|
So, we could see at the traceroute from router 3,
|
|
0:29:31
|
the packet goes to 5.
|
|
0:29:34
|
From 5 it goes to 4.
|
|
0:29:36
|
4 sending it to 6.
|
|
0:29:38
|
6 is sending it to switch 1.
|
|
0:29:41
|
Then, switch 1 sends it back to router 3.
|
|
0:29:51
|
So, we really we want the traffic flow either to go...
|
|
0:29:55
|
that way.
|
|
0:29:57
|
Or to go this way
|
|
0:30:00
|
as long as we end up to the destination, which is VLAN 9.
|
|
0:30:06
|
But now, the problem is...
|
|
0:30:07
|
the traffic goes from router 3, from 3 to 5, 5 to 4, 4 to 6, 6 to switch 1, switch back to router 3.
|
|
0:30:22
|
This now means from switch 1's perspective,
|
|
0:30:26
|
it's the one making the incorrect routing decision.
|
|
0:30:30
|
It's sending the packets to router 3, where in reality, it should have been sending it this direction down towards switch 3.
|
|
0:30:39
|
Since we know that both of these routes are coming from RIP to begin with,
|
|
0:30:43
|
we could tell that this loop is based on the wrong metric values,
|
|
0:30:48
|
and nothing to do with the administrative distance.
|
|
0:30:55
|
Now, if we look at any of the other prefixes, let's say that we go to switch 2,
|
|
0:31:01
|
and we do a trace to those external routes that came from BB1.
|
|
0:31:06
|
We end up in the same type of case.
|
|
0:31:10
|
Where now in the packet gets to router 6,
|
|
0:31:13
|
router 6 is sending this to switch 1
|
|
0:31:19
|
instead of sending this to BB1.
|
|
0:31:25
|
Where really, our traffic flow to this destination should go...
|
|
0:31:29
|
that way,
|
|
0:31:32
|
but instead, it's going this way.
|
|
0:31:45
|
Now again, one way we could fix this...
|
|
0:31:47
|
would be simply to set the metric values
|
|
0:31:50
|
so that router 6 does make the correct decision to begin with.
|
|
0:31:56
|
Or likewise, that switch 1 makes the correct decision to begin with.
|
|
0:32:00
|
The problem with that design
|
|
0:32:03
|
is that it would be very hard to predict to what the metric value is supposed to be to begin with.
|
|
0:32:08
|
So, it's gonna depend on when BB1 advertises the routes to router 6,
|
|
0:32:14
|
there would be some sort of threshold where if the metric is lower than a certain number,
|
|
0:32:18
|
the route is not gonna loop,
|
|
0:32:20
|
but if the metric is above a certain threshold, it could cause a loop.
|
|
0:32:27
|
So, solving the problem this way, is really not that good of an idea,
|
|
0:32:31
|
because sometimes, it's gonna work, but not a 100% of the time.
|
|
0:32:35
|
So, we want a solution that is never gonna cause a loop to begin with.
|
|
0:32:39
|
And again, this is really gonna be based on the filtering of the redistribution,
|
|
0:32:43
|
where anything that router 4 redistributes from RIP to OSPF,
|
|
0:32:47
|
3 should never send it from OSPF back to RIP.
|
|
0:32:51
|
Or likewise, the other way.
|
|
0:32:54
|
Anything that 3 redistributes from RIP to OSPF,
|
|
0:32:56
|
4 should not redistribute from OSPF back to RIP.
|
|
0:33:02
|
And the easiest way to do this is gonna be based on route tag values.
|
|
0:33:12
|
So, on router 3,
|
|
0:33:14
|
the first thing that we're gonna do is create a route map
|
|
0:33:18
|
that is gonna set the tag value
|
|
0:33:21
|
that when we go from RIP to OSPF.
|
|
0:33:32
|
So, in the RIP to OSPF redistribution,
|
|
0:33:35
|
I'm gonna set the tag value to any arbitrary value that I want.
|
|
0:33:40
|
Okay, for simplicity, I'll say 3 for router 3.
|
|
0:33:43
|
That's gonna be everything that is going from RIP to OSPF.
|
|
0:33:47
|
On router 4, I'm gonna do the same thing.
|
|
0:33:50
|
But Im gonna use a different value.
|
|
0:33:54
|
Okay, we'll say, Set Tag 4.
|
|
0:33:59
|
Now, in the reverse direction, as I'm going from OSPF back into RIP,
|
|
0:34:06
|
I want to allow all routes on router 3
|
|
0:34:11
|
with the exception of what?
|
|
0:34:19
|
With the exception of the ones that router 4 already did the redistribution for.
|
|
0:34:27
|
So, on router 3, we're gonna do a reverse logic, we're gonna say...
|
|
0:34:31
|
Route Map match the tag from OSPF to RIP.
|
|
0:34:37
|
I'm going to deny any route
|
|
0:34:41
|
that already has tag value 4.
|
|
0:34:45
|
If there's anything else left that does not have tag value 4, I'm gonna permit it.
|
|
0:34:51
|
Then likewise, router 4 is gonna do the same thing,
|
|
0:34:55
|
but with the reverse value.
|
|
0:34:57
|
Router 4 says that "If the tag value is 3,
|
|
0:35:01
|
it means that this is some route that router 3 already sent from RIP into OSPF."
|
|
0:35:08
|
So, there's no reason that I should pass it fro OSPF back into RIP.
|
|
0:35:14
|
I'm gonna deny those routes, but then, I'm going to permit...
|
|
0:35:17
|
everything else.
|
|
0:35:20
|
So again, the route map, just like in access list of prefix list, it does have an implicit deny.
|
|
0:35:25
|
If I didn't add this second statement here that say, Permit 20 or Permit a thousand,
|
|
0:35:31
|
then, anything about 10, then, all of the routes would be denied.
|
|
0:35:38
|
Now, under the OSPF process,
|
|
0:35:41
|
when I redistribute RIP subnets,
|
|
0:35:44
|
I wanna use the route map that is going to set the tag
|
|
0:35:48
|
as I'm going from RIP to OSPF.
|
|
0:35:55
|
Then, under the RIP process,
|
|
0:35:57
|
as I'm redistributing OSPF back to RIP,
|
|
0:36:02
|
I'm gonna use the route map that is filtering out any prefixes that already have router 3's tag value.
|
|
0:36:20
|
So, from RIP to OSPF, we are...
|
|
0:36:23
|
setting that tag.
|
|
0:36:26
|
From OSPF back to RIP, we are matching the tag.
|
|
0:36:29
|
Router 3 is gonna do the same exact thing, because we have route maps named with the same values.
|
|
0:36:40
|
Once we have it applied and when we clear the routing table,
|
|
0:36:43
|
make sure that the new filter is taking effect. So, Clear IP Route Star (*).
|
|
0:36:49
|
And now, let's look at the change in the OSPF database, if I Show IP OSPF Database,
|
|
0:36:54
|
on both router 3 and 4.
|
|
0:37:00
|
Show IP OSPF Database.
|
|
0:37:07
|
Notice now that the routes that router 4 has redistributed,
|
|
0:37:15
|
these now have a tag value of 4.
|
|
0:37:22
|
Where the single routes that router 3 redistributed, this has a tag value of 3.
|
|
0:37:30
|
This then means,
|
|
0:37:32
|
when router 3 does the redistribution of OSPF back into RIP,
|
|
0:37:37
|
all of these prefixes are gonna be denied with the exception of that one.
|
|
0:37:46
|
Now, since this link here, the 37.0, this is already running RIP to begin with,
|
|
0:37:51
|
then, it's not gonna be redistributed from the OSPF process back into RIP.
|
|
0:37:57
|
Because on router 3, if we were to look at the Show IP Protocols,
|
|
0:38:05
|
this link, 155.28.37, this is already running the RIP process.
|
|
0:38:11
|
So, it's in the database, we don't need to redistribute it back in.
|
|
0:38:16
|
The end result of this should be...
|
|
0:38:19
|
that we no longer have the traffic loop.
|
|
0:38:29
|
Now, we will see for RIP since it's gonna take a long time to converge,
|
|
0:38:33
|
we could either wait for the old information to age out,
|
|
0:38:37
|
or we could go to the routers and flush out the routing table.
|
|
0:38:40
|
So, for this particular destination, for 212.18.0.1,
|
|
0:38:45
|
the device that's making the wrong decision is router 6.
|
|
0:38:50
|
Because again, for this particular route,
|
|
0:38:53
|
we should be forwarding the traffic that way.
|
|
0:38:58
|
Where currently, the traffic is getting to router 6,
|
|
0:39:01
|
then, 6 is looping it back to that direction.
|
|
0:39:07
|
If we're to look at the routing table of 6,
|
|
0:39:14
|
and Show IP Route RIP,
|
|
0:39:22
|
we essentially need to flush out this bad old information.
|
|
0:39:27
|
So, let's say Clear IP Route Star (*).
|
|
0:39:33
|
And we essentially need to do this on every router in the RIP domain.
|
|
0:39:38
|
One other way I could fix this would be to shut down some of the interfaces,
|
|
0:39:42
|
and wait for RIP to re-converge,
|
|
0:39:45
|
but eventually, we should see...
|
|
0:39:51
|
that these 212 routes, these should not be learned from switch 1.
|
|
0:40:01
|
So, let's try this. Let's look at switch 1 and Show IP Route RIP.
|
|
0:40:11
|
Switch 1 is no longer installing
|
|
0:40:15
|
these 212 routes...
|
|
0:40:20
|
actually at all. Let's say Show IP Route.
|
|
0:40:35
|
And we can see, based on the timers in the routing table,
|
|
0:40:37
|
now, this is starting to age out.
|
|
0:40:41
|
So, with the default update timer of 30 seconds for RIP,
|
|
0:40:45
|
essentially, anything that goes above this timer value
|
|
0:40:48
|
means that it's stale information and it's eventually gonna get removed from the table.
|
|
0:40:52
|
So, we could wait until the flush timer expires, which is gonna be 240 seconds by default,
|
|
0:40:58
|
or if I just continue to clear the routing table,
|
|
0:41:01
|
eventually, the correct information should be re-installed.
|
|
0:41:09
|
Which it now is. We have the 212.18.0.0,
|
|
0:41:13
|
212.18.1, 212.18.3, these are all now being learned from BB1's next hop value.
|
|
0:41:25
|
The end result, if we go to switch 2 and actually send the traffic,
|
|
0:41:29
|
now, it's following the correct path.
|
|
0:41:34
|
If we run the ping script again, we should see that all of these particular destinations are correctly reachable.
|
|
0:41:44
|
Now, if for some reason, router 4 were to go down,
|
|
0:41:48
|
let's say that on router 4,
|
|
0:41:51
|
this link fails.
|
|
0:41:54
|
This means that the RIP routes will be withdrawn,
|
|
0:41:57
|
which means that the OSPF routes are then withdrawn.
|
|
0:42:02
|
Eventually, this would get to router 3,
|
|
0:42:05
|
router 3 would delete its OSPF routes,
|
|
0:42:09
|
and then do what?
|
|
0:42:12
|
It's gonna delete the OSPF route with the distance of 110,
|
|
0:42:16
|
but it still has the RIP route coming in with 120.
|
|
0:42:21
|
So, if 3 now learned the route from RIP,
|
|
0:42:26
|
which of the end result be?
|
|
0:42:31
|
3 should then redistribute this route from RIP to OSPF,
|
|
0:42:37
|
and router 4 is gonna learn it via OSPF.
|
|
0:42:42
|
So, what we'll see is that the exit point that's used
|
|
0:42:46
|
out of the OSPF network
|
|
0:42:49
|
is gonna be a variable depending on who loads the process first.
|
|
0:42:55
|
So, right now, we can see router 4 is the exit point from OSPF to RIP.
|
|
0:43:00
|
If we were to go to router 4,
|
|
0:43:03
|
and shutdown Fast Ethernet 0/1,
|
|
0:43:07
|
that's where the RIP routes were being learned.
|
|
0:43:11
|
If we now Show IP Route RIP,
|
|
0:43:14
|
it means all of these information was withdrawn.
|
|
0:43:17
|
We now look at the Show IP OSPF Database,
|
|
0:43:23
|
we see that under the Type-5 external link states,
|
|
0:43:27
|
now, router 3 is performing the redistribution.
|
|
0:43:34
|
All of these prefixes, they now have a tag value of 3.
|
|
0:43:40
|
This now means that even though
|
|
0:43:44
|
if the interface comes back up, then, we disable.
|
|
0:43:51
|
Router 4 is never gonna learn these routes as RIP.
|
|
0:43:58
|
Well, technically, it will learn that it's RIP, it's not gonna install it in the routing table,
|
|
0:44:01
|
because now, the update coming in from router 6
|
|
0:44:06
|
is a distance of 120
|
|
0:44:09
|
versus the one that came from router 3 originally, which is 110.
|
|
0:44:15
|
So, the only problem with this type of design
|
|
0:44:17
|
is that it's still kind of non-deterministic depending...
|
|
0:44:20
|
or as to what exit point you're gonna use between the routing domains.
|
|
0:44:26
|
Since only one of them is gonna do the redistribution at a time,
|
|
0:44:31
|
it essentially means that whoever learns the RIP route and redistributes it into OSPF first
|
|
0:44:37
|
is gonna be the one that's used as the exit point.
|
|
0:44:41
|
If we go to switch 2 and look at the traceroute,
|
|
0:44:45
|
we see now, the exit point change to router 3 as opposed to router 4.
|
|
0:44:52
|
Even if we were to do this on router 4,
|
|
0:44:55
|
we'd see router 4 would take the long way around to get there.
|
