|
0:00:13
|
In our next section here, we're gonna look at an example topology that I have set-up
|
|
0:00:17
|
with three different IGPs.
|
|
0:00:19
|
Where router 4 is running RIP OSPF and EIGRP.
|
|
0:00:24
|
And we want to get reachability from the EIGRP domain to both OSPF and RIP domains
|
|
0:00:30
|
and from the OSPF domain to RIP domain.
|
|
0:00:35
|
So, first, we look at what happens under the normal case of redistribution.
|
|
0:00:39
|
What we should expect to see in the RIP database versus the OSPF and the EIGRP topology
|
|
0:00:45
|
when router 4 does the redistribution.
|
|
0:00:48
|
And then some potential issues based on the normal advertisement rules
|
|
0:00:53
|
of EIGRP versus OSPF versus RIP.
|
|
0:00:56
|
So, let's take a look at the topology on router 4 to start.
|
|
0:01:01
|
And let's make sure that we are learning routes from RIP, EIGRP, and OSPF separately
|
|
0:01:07
|
before we get ito any redistribution.
|
|
0:01:11
|
So, on router 4, if we look at the Show IP Protocols,
|
|
0:01:15
|
this is gonna tell us what are the local processes that we are running.
|
|
0:01:19
|
And what are the local interfaces that have that particular protocol enabled.
|
|
0:01:23
|
So, we can see in this case that we are running EIGRP 1 on interface...
|
|
0:01:32
|
that has this particular prefix assigned.
|
|
0:01:36
|
Okay, which in this case is router 4's connection to the frame-relay network.
|
|
0:01:40
|
Also, it says that we're learning updates from this particular neighbor,
|
|
0:01:45
|
which is router 5 over the frame-relay.
|
|
0:01:48
|
The default administrative distance over that neighbor is 90,
|
|
0:01:52
|
Which is our default internal distance and our default external distance is 170.
|
|
0:01:58
|
So, essentially, the only thing that we have configured under the EIGRP process,
|
|
0:02:02
|
is just the network statement that is corresponding to that particular interface
|
|
0:02:06
|
and then the no auto-summary.
|
|
0:02:09
|
It says, "Automatic Summarization is not in effect."
|
|
0:02:15
|
Likewise, for the OSPF process,
|
|
0:02:18
|
it tells us what particular links that we are running the protocol on.
|
|
0:02:21
|
So, whatever interface has this address 45.5 and the 146.4,
|
|
0:02:27
|
these links are running in area 0.
|
|
0:02:30
|
We're learning updates from four different neighbors,
|
|
0:02:33
|
which implies that we have adjacencies with these devices.
|
|
0:02:37
|
It says, "The administrative distance for all of them is 110."
|
|
0:02:43
|
So, we'll see that when we do modifications of the distance.
|
|
0:02:46
|
We can either do this globally to the process.
|
|
0:02:49
|
We can do it on a per-neighbor basis or we can do it on a per-neighbor per-prefix basis.
|
|
0:02:55
|
But by default, the global administrative distance default value is going to apply for all routes learned from all neighbors.
|
|
0:03:05
|
Then, lastly, under the RIP process, it says that we're running RIP.
|
|
0:03:09
|
On this particualr interface, 204.12.28.0,
|
|
0:03:13
|
and we're learning updates from this neighbor on the link
|
|
0:03:15
|
using the distance of 120.
|
|
0:03:20
|
So, if we look at the end result of this and look at the Show IP Route,
|
|
0:03:25
|
we should see that we have routes installed from OSPF,
|
|
0:03:28
|
we have routes installed from EIGRP and form RIP.
|
|
0:03:33
|
We don't have any external prefixes yet because we just have the internal OSPF routes,
|
|
0:03:38
|
we have the internal EIGRP routes.
|
|
0:03:41
|
Then, again, for RIP, we have no way to distinguish the internal prefixes versus the external ones.
|
|
0:03:49
|
Now, before router 4 even got to this point,
|
|
0:03:52
|
where it was installing the RIP routes and the routing table or the OSPF or EIGRP.
|
|
0:03:57
|
Each of the individual protocols is gonna go through its normal path selection process.
|
|
0:04:02
|
In the case of RIP, we can see this by looking at the Show IP RIP Database.
|
|
0:04:08
|
It should show any prefixes that we're learning.
|
|
0:04:10
|
And based on this, we can figure out which ones are actually gonna get installed in the routing table.
|
|
0:04:16
|
So, we have 8 separate prefixes that are being learned on our Fast Ethernet 0/0 inteface,
|
|
0:04:23
|
which is the 30.0.0.0/16 to 30.1, 30.2, etc.
|
|
0:04:30
|
Also, it says, we have a directly connected interface,
|
|
0:04:34
|
Fast Ethernet 0/0 that is running the process.
|
|
0:04:39
|
This would then imply if I were to redistribute from RIP into OSPF or from RIP into EIGRP,
|
|
0:04:47
|
there should be 9 prefixes that will be included.
|
|
0:04:51
|
The 8 that show up in the routing table as RIP,
|
|
0:04:55
|
when we look at the Show IP route RIP,
|
|
0:05:01
|
So, the 8 subnets were learning there
|
|
0:05:03
|
plus the directly connected interface that is running the protocol.
|
|
0:05:08
|
We'll see that this is gonna be our implicit directly connected redistribution.
|
|
0:05:15
|
The only case that where this directly connected link would not be redistributed
|
|
0:05:20
|
is if we were to manually issue the redistribute command under the OSPF process or under the EIGRP process.
|
|
0:05:27
|
And then exclude interface Fast Ethernet 0/0.
|
|
0:05:32
|
So, the explicit redistribute connecting command, this is gonna override any of the dynamic interfaces
|
|
0:05:39
|
or the interface that are running the dynamic protocols.
|
|
0:05:44
|
Then likewise, for EIGRP, if we were to look at the Show IP EIGRP Topology,
|
|
0:05:51
|
this is showing us the routes that should be installed in the routing table
|
|
0:05:56
|
that have valid, feasible distance values.
|
|
0:06:01
|
So, these are the dynamic routes that are coming from our different neighbors.
|
|
0:06:04
|
In this case, router 5.
|
|
0:06:06
|
Then we also have our connected link that is running the process, 155.28.0.0/24.
|
|
0:06:14
|
So again, just like RIP, the end result to this would be that if I were to redistribute EIGRP into OSPF,
|
|
0:06:21
|
any routes that are in the routing table as EIGRP,
|
|
0:06:26
|
so if we Show IP Route EIGRP,
|
|
0:06:30
|
plus the routes that are in the topology as connected interfaces,
|
|
0:06:34
|
those are the ones that are candidate for the redistribution process.
|
|
0:06:40
|
Then likewise, for OSPF, if we Show IP Route OSPF,
|
|
0:06:45
|
and Show IP OSPF Interface Brief,
|
|
0:06:48
|
the dynamically learned OSPF prefixes plus those two connected interfaces,
|
|
0:06:53
|
those would be candidate to be redistributed from OSPF into RIP
|
|
0:06:57
|
or from OSPF into EIGRP.
|
|
0:07:00
|
So, next, let's look at the redistribution between the OSPF and the RIP process.
|
|
0:07:05
|
First step is taht we go under the global routing process.
|
|
0:07:10
|
So, if we look at our configuration so far,
|
|
0:07:12
|
we have OSPF process ID 1, EIGRP AS 1, and then the global RIP process.
|
|
0:07:19
|
So, we'll say under the RIP process, "I want to redistribute OSPF process number 1."
|
|
0:07:26
|
Again by default, there is no seed metric value.
|
|
0:07:30
|
So I either need to specify this here with the metric
|
|
0:07:33
|
or I could specify the default metric.
|
|
0:07:38
|
So, if I said that the default metric was 5,
|
|
0:07:41
|
this would apply to other none OSPF protocols
|
|
0:07:46
|
becasue with OSPF, I'm manually specifying the particular metric value that should be associated with that.
|
|
0:07:54
|
So really, whichever way that you do the implementation,
|
|
0:07:57
|
it's gonna end up in the same result that the routes should be installed in the RIP database
|
|
0:08:02
|
and they're gonna get whatever seed metric you're either specifying on a particular protocol.
|
|
0:08:07
|
Or it's gonna go back to the default metric value.
|
|
0:08:12
|
Now, without looking at any other routers in the RIP topology,
|
|
0:08:17
|
we should be able to tell at least here locally on router 4,
|
|
0:08:20
|
whether the redistribution was actually successful.
|
|
0:08:24
|
And we can see this by looking at the Show IP RIP Database.
|
|
0:08:30
|
We should now see in addition to our local connected route,
|
|
0:08:35
|
the 8 routes that we were learning from BB3.
|
|
0:08:39
|
We also have a bunch of this prefixes that say, they are redistributed.
|
|
0:08:45
|
So, if we look at this output again, Show IP RIP Database and include just the keyword, "redistributed",
|
|
0:08:52
|
we see that this is gonna be the routes in the routing table as OSPF,
|
|
0:08:58
|
in addition to any connected routes that are runnning the OSPF process.
|
|
0:09:04
|
So, when we compare the Show IP Route OSPF output,
|
|
0:09:07
|
we can see the first prefix, 155.28.7.0.
|
|
0:09:12
|
This did make it into the RIP database.
|
|
0:09:17
|
As did the 9.0, the 37.0, etc.
|
|
0:09:23
|
Additionally, we see 155.28.146.0.
|
|
0:09:28
|
This is not showing up as an OSPF route in the table because this is directly connected.
|
|
0:09:34
|
So, if we Show IP Route Connected, this 146.0, this is being included
|
|
0:09:40
|
as is the 45.0 because these are the two connected interfaces that are running the OSPF process.
|
|
0:09:50
|
Note that this is not going to include serial 0/0/0.1
|
|
0:09:56
|
because although this is a connect prefix, it's not running the OSPF process.
|
|
0:10:04
|
So again, by default, when we redistribute OSPF into RIP is gonna be whatever routes are in the routing table as OSPF
|
|
0:10:11
|
plus the connected links that are running the OSPF process.
|
|
0:10:16
|
Now, if I wanted to include an additional route,
|
|
0:10:19
|
let's say that I want to advertise my loopback interface into RIP,
|
|
0:10:24
|
and I wanna do this via connected redistribution,
|
|
0:10:28
|
I could go under the RIP process
|
|
0:10:31
|
and say redistribute conected and I'll give these a metric value of 2.
|
|
0:10:39
|
If we now look at the result in the RIP database, if we Show IP RIP Database and include the redistributed routes,
|
|
0:10:47
|
we should now see that our loopback is included.
|
|
0:10:53
|
But also the other connected links that were not running OSPF.
|
|
0:10:59
|
So, if we look at the Show IP Route Connected
|
|
0:11:02
|
and compare this to the Show IP OSPF Interface Brief,
|
|
0:11:07
|
the explicit redistribute command is including more than what the OSPF to RIP redistribution wise.
|
|
0:11:19
|
Now, ultimately, whichever method that you choose,
|
|
0:11:22
|
is gonna be dependent on whether or not you want to allow all routes to be redistributed
|
|
0:11:28
|
or whether you want to be very specific as to whic particular prefixes will be advertised.
|
|
0:11:35
|
Now, the case where this could become a problem is if I were to say that on router 4,
|
|
0:11:43
|
I have this link that goes to VLAN 146.
|
|
0:11:50
|
and then I have this link that goes to BB3.
|
|
0:11:56
|
Okay, this is the 204.12.28.0/24 network.
|
|
0:12:04
|
The link connected to BB3, this is running RIP.
|
|
0:12:08
|
The link connected to VLAN 146, this is running OSPF.
|
|
0:12:15
|
So again, when I redistribute from OSPF to RIP,
|
|
0:12:18
|
it's gonna be any routes that are actually learned from the OSPF process.
|
|
0:12:21
|
plus the actual connected interface itself.
|
|
0:12:27
|
Now, if I other connected interfaces on router 6,
|
|
0:12:31
|
let's say the...
|
|
0:12:35
|
Let's say a loopback interface there.
|
|
0:12:38
|
I have loopback...
|
|
0:12:41
|
Loopback 0.
|
|
0:12:43
|
And this is the prefix 150.28.4.0/24.
|
|
0:12:51
|
And I wanna advertise this into the RIP process.
|
|
0:12:56
|
Now, I have other connected interfaces as well.
|
|
0:13:00
|
I have this link that's going to the frame-relay network.
|
|
0:13:03
|
I have this point-to-point link that's going into router 5.
|
|
0:13:07
|
If I simply say redistribute connected under the RIP process,
|
|
0:13:10
|
it's basically going to match all of my connected links.
|
|
0:13:14
|
Which is then the VLAN 46, the loopback, the frame-relay and the point-to-point serial.
|
|
0:13:23
|
Let's also assume in this case that I do not want to redistribute the link that's goint to frame-relay
|
|
0:13:30
|
and the link that's going to router 5.
|
|
0:13:34
|
So, I wanna advertise the loopback to BB3 but I don't wanna advertise these other 2 serial interfaces.
|
|
0:13:42
|
So, this means we would need a separate redistribute statement
|
|
0:13:46
|
and we're gonna match which of the particular prefix that we do want to include.
|
|
0:13:52
|
So, on router 4, the way that we do this, is where the route map.
|
|
0:13:57
|
I'll say the route map is called Connected to RIP.
|
|
0:14:00
|
And by default, this has a permit 10 sequence number.
|
|
0:14:06
|
From here, I could either call an access list or a prefix list
|
|
0:14:10
|
or it could match the connected interface directly.
|
|
0:14:13
|
So, I'll simply say, "Match Interface Loopback 0."
|
|
0:14:19
|
Now, under the RIP process, I'm gonna Redistribute Connected.
|
|
0:14:24
|
I still need to set a seed metric. Let's say metric 2.
|
|
0:14:29
|
but now,I'm gonna filter this redistribution through the route map
|
|
0:14:33
|
connected to RIP.
|
|
0:14:38
|
When we look at the end result of this in the Show IP RIP Database
|
|
0:14:43
|
and we look at the redistributed routes,
|
|
0:14:46
|
we see that the loopback interface was advertised
|
|
0:14:49
|
but the frame-relay interface has now been filtered
|
|
0:14:55
|
and the point-to-point serial that is going to router 5.
|
|
0:14:59
|
We can see this if we compare the RIP database output to the Show IP Route connected.
|
|
0:15:06
|
So, 155.28.0.0, that is not a RIP database.
|
|
0:15:11
|
Nor as 155.28.45.0.
|
|
0:15:16
|
The loopback is the 204 network, that's gonna be in the RIP database because that's actually running the protocol.
|
|
0:15:23
|
There's a network statement that's matching it.
|
|
0:15:26
|
But now notice that the Ethernet that was running OSPF,
|
|
0:15:31
|
this is now being excluded from the RIP redistribution.
|
|
0:15:37
|
Now, this is not necessarily a bad thing.
|
|
0:15:40
|
It just depends on what our end goal of the design is.
|
|
0:15:44
|
If I want to advertise the loopback plus the VLAN 146 interface,
|
|
0:15:49
|
then my current configuration is not going to accomplish that.
|
|
0:15:53
|
What I'm actually doing here is allowing the loopback to be redistributed,
|
|
0:16:02
|
not the connected VLAN 146, not either the connected serials.
|
|
0:16:07
|
But then any dynamic information that is learned form OSPF.
|
|
0:16:13
|
The reason why that these three connected links are being denied,
|
|
0:16:17
|
is that the route map on router 4 has an implicit deny after sequence number 10.
|
|
0:16:28
|
So, just like an access list or a prefix list,
|
|
0:16:31
|
the route map is always gonna end in an implicit deny.
|
|
0:16:35
|
This now means that any interface besides loopback 0 will be denied from being redistributed into the RIP process.
|
|
0:16:45
|
Eventhough when we look at the configuration under the RIP process,
|
|
0:16:50
|
I have two redistribute statements.
|
|
0:16:52
|
One that is going from OSPF to RIP and one from connected to RIP.
|
|
0:16:57
|
Since I am explicitly listening the conected redistribution.
|
|
0:17:01
|
This means it is then going to override the connected links that are running the OSPF process.
|
|
0:17:08
|
Now, in reality, this is the design case that you would want as the default behavior.
|
|
0:17:14
|
Becasue it essentially gives us more control as to what particular routes are advertised into the routing database.
|
|
0:17:22
|
So, if I wanted to advertise the loopback but none of the other connected prefixes,
|
|
0:17:27
|
this is I'm gonna do it with this config.
|
|
0:17:30
|
However, if I want to advertise the loopack plus the interface that was in OSPF,
|
|
0:17:36
|
it means that I would also have to permit that in the connected to route map.
|
|
0:17:43
|
So, I can either do this unde the same sequence number 10.
|
|
0:17:47
|
If we Show Run Section Route Map.
|
|
0:17:52
|
Or I could put an additional sequence after number 10
|
|
0:17:55
|
that's matching that additional interface or matching an access list or a prefix list
|
|
0:18:00
|
that is matching the address information for the link.
|
|
0:18:06
|
So if we look at the Show IP Route.
|
|
0:18:10
|
Show IP Route Connected.
|
|
0:18:13
|
The prefix in question for that link is 155.28.146.0/24.
|
|
0:18:20
|
If I then wanna include this in the connected redistribution,
|
|
0:18:24
|
I could say match interface Fast Ethernet 0/1.
|
|
0:18:28
|
Call an acces list that's matching it or use a prefix list.
|
|
0:18:33
|
So, I'll say IP Prefix List Connected_FA0/1
|
|
0:18:39
|
Permit and then the actual...
|
|
0:18:44
|
Prefix plus the length.
|
|
0:18:47
|
So, 155.28.146.0/24.
|
|
0:18:53
|
Now, as I mentioned, we could also use an access list to do this.
|
|
0:18:57
|
However, the shortcoming of using the ACL
|
|
0:19:00
|
is that we can match only on the address field and not on the subnet mask.
|
|
0:19:06
|
Whereas the prefix list,
|
|
0:19:08
|
as we talked about this before for filtering with the distribute list and RIP or distribute list and EIGRP,
|
|
0:19:14
|
this woould be the preferred method of matching a route.
|
|
0:19:17
|
becasue it gives us the flexibility to match both the address field and the subnet mask at the same time.
|
|
0:19:26
|
So, now that I have the prefix matched,
|
|
0:19:29
|
next step would be to reference it from the route map.
|
|
0:19:32
|
So, I have route map connected to RIP.
|
|
0:19:36
|
I need a new sequence. We'll say Permit 20.
|
|
0:19:39
|
Then match IP Address Prefix List Connected_FA0/1.
|
|
0:19:51
|
Now, the common mistake here to watch out for,
|
|
0:19:54
|
is that when you say Match IP Address.
|
|
0:19:57
|
If I were to say Match IP Address Connected_FA0/1
|
|
0:20:02
|
That would be calling an extended or standard name access list.
|
|
0:20:09
|
So, if I were to say Match IP Address Connected_FA0/1,
|
|
0:20:15
|
this would be calling an ACL, not the prefix list.
|
|
0:20:20
|
If I want to match the prefix list, I need to add that additional keyword,
|
|
0:20:24
|
prefix list in the match IP address prefix list and then the name.
|
|
0:20:29
|
Now, we should be able to see the end result of this if we now look at the Show IP RIP database,
|
|
0:20:35
|
and again look at the redistributed routes.
|
|
0:20:39
|
So, Show IP RIP Database Include Redistributed.
|
|
0:20:43
|
We could see now, not only does it include the loopback
|
|
0:20:47
|
which is the 150.28.4.0. But now, that VLAN 146, which is 155.28.146.0/24.
|
|
0:20:58
|
So, really in the end, it doesn't matter which way you do the implementation.
|
|
0:21:02
|
It's only dependent on whether you want to allow all routes or just a subset of routes.
|
|
0:21:08
|
If you wanna allow everything, then you could just say Redistribute Connected,
|
|
0:21:11
|
or use whatever the interfaces that are running the protocols.
|
|
0:21:16
|
So, if I were to remove under the RIP process here,
|
|
0:21:20
|
if we Show Run Section Router RIP,
|
|
0:21:26
|
and we say No Redistribute Connected,
|
|
0:21:30
|
so the only statement I have now is Redistribute OSPF 1, Metric 1.
|
|
0:21:35
|
If we look at the result of this in the RIP database,
|
|
0:21:39
|
it does include, or will include in a second here when it converges.
|
|
0:21:46
|
It will include the VLAN 146.
|
|
0:21:54
|
So, that's our connected interface running OSPF.
|
|
0:21:57
|
But notice that it doesn't include the loopback.
|
|
0:22:01
|
Because when we look at the Show IP OSPF Interface Brief,
|
|
0:22:04
|
the loopback is not in the OSPF process,
|
|
0:22:07
|
so it implies that it's not gonna get included when we redistribute OSPF to RIP.
|