|
0:00:13
|
Our next section here for OSPF summarization,
|
|
0:00:17
|
the key to remember is that since OSPF is a link state protocol,
|
|
0:00:23
|
then all of the routers within the same area have to have the same link state database.
|
|
0:00:29
|
Now, from a summarization or filtering point of view,
|
|
0:00:32
|
this means that any type of modification of the routing information,
|
|
0:00:37
|
can only happen between areas
|
|
0:00:39
|
or when external information is originated. So, during redistribution.
|
|
0:00:45
|
So, when the case of summarization, we have two different types.
|
|
0:00:47
|
We have inter-area summaries and we have external summaries.
|
|
0:00:53
|
Inter-area summaries are going to be for summarizing LSA type 3s,
|
|
0:00:58
|
which are the network summary LSAs.
|
|
0:01:01
|
Specifically, this is implemented with the area range command in the area border router.
|
|
0:01:07
|
Where either we're summarizing routes as they go in to area zero
|
|
0:01:11
|
or as they come from area zero going into another non-transit area.
|
|
0:01:17
|
For the external redistribution or the external summary,
|
|
0:01:20
|
this is gonna be at redistribution on the ASPR with the summary address command.
|
|
0:01:26
|
We'll also see that in a not so stubby area,
|
|
0:01:31
|
the ABR can summarize type 7 information as it is being generated as type 5.
|
|
0:01:39
|
because that technically counts as a redistribution
|
|
0:01:41
|
from the type 7 LSA into the type 5 LSA.
|
|
0:01:46
|
So, again, there's only basically two places you can do this.
|
|
0:01:48
|
On the ABR, with the area range,
|
|
0:01:51
|
or in the ASBR with the summary address.
|
|
0:01:54
|
Now, regardless of what type of summary we generate,
|
|
0:01:57
|
just like EIGRP or BGP,
|
|
0:02:00
|
the process will automatically generate the discard route.
|
|
0:02:04
|
Where the discard route is the match for the summary
|
|
0:02:07
|
that is pointing to null zero.
|
|
0:02:10
|
So, again, the idea behind that is if we loose one of the subnets that make up the summary
|
|
0:02:16
|
and we received packets that are going to one of those destinations.
|
|
0:02:20
|
We're going to drop them locally instead of forwarding it on to a shorter match, like a default route.
|
|
0:02:28
|
This would then mean, if we did want to use default routing,
|
|
0:02:32
|
for subnets that are inside of one of our summaries,
|
|
0:02:35
|
we would have to remove the null route
|
|
0:02:38
|
with the no discard internal or the no discard route external command
|
|
0:02:43
|
under the OSPF process.
|
|
0:02:47
|
Now, we'll also see that summarization can be used for traffic engineering
|
|
0:02:51
|
based on the longest match routing principle.
|
|
0:02:54
|
So, regardless of what the metric is or the distance is towards a particular destination,
|
|
0:02:59
|
the router's always gonna choose the path that has the most bits in common with the destination,
|
|
0:03:05
|
which is the longest match.
|
|
0:03:07
|
So, this means that if we were to summarize on multiple ABRs, or multiple ASBRs,
|
|
0:03:14
|
whichever one is advertising the longer match,
|
|
0:03:18
|
would be the one that is preferred for those particular destinations.
|
|
0:03:22
|
So, in our particular case, we have router 1 and router 3
|
|
0:03:27
|
as ABRs between area 0 and area 1.
|
|
0:03:31
|
And in area 1, we're advertising a couple of different interfaces.
|
|
0:03:36
|
We have the VLAN 7 interface of switch 1.
|
|
0:03:39
|
We have the VLAN 9 interface of switch 3.
|
|
0:03:44
|
Specfically, these prefixes are 155.42.7.0/24
|
|
0:03:53
|
and 155.42.9.0/24,
|
|
0:04:00
|
which means that the closest summary that we could do that would encompass both of these,
|
|
0:04:05
|
would be 155.42.0.0, with the range of 0 to 15.
|
|
0:04:18
|
So, again, if we take 255 minus 15
|
|
0:04:22
|
is 240.
|
|
0:04:24
|
Which would be 255.255.240.0,
|
|
0:04:33
|
which means, this is the actual prefix, 155.42.0.0/20.
|
|
0:04:42
|
So, as we know, there's a lot of address space that's inside the summary that were not...
|
|
0:04:46
|
that we don't actually have but we are advertising.
|
|
0:04:49
|
So, this means that if one of these ABRs receives traffic for, let's say, 155.42.6.0,
|
|
0:04:59
|
it means that they would null router those packets,
|
|
0:05:02
|
unless they had a match that is longer than /20.
|
|
0:05:07
|
And this is gonna be true both of the internal summaries and the external summaries.
|
|
0:05:12
|
So, next, let's look at router 1 and router 3 in the command line.
|
|
0:05:16
|
And we'll see, what is their current view of those VLAN 7 and VLAN 9 prefixes?
|
|
0:05:21
|
Since they are routers in area 1,
|
|
0:05:25
|
and those prefixes are originated in the area 1,
|
|
0:05:27
|
they should be learned as intra-area routes.
|
|
0:05:33
|
So, if we look at router 1,
|
|
0:05:36
|
and say Show IP Route to 155.42.7.0,
|
|
0:05:44
|
or 9.0,
|
|
0:05:47
|
we see that both of these routes are intra-area
|
|
0:05:52
|
that are originated by router, or switch 1 and switch 3 respectively.
|
|
0:05:58
|
As we go beyond router 1,
|
|
0:06:01
|
let's say to router 5 and look at the same view.
|
|
0:06:04
|
If we Show IP Route for 155.42.7.0 and 9.0,
|
|
0:06:14
|
we see that these are now inter-area routes that are being originated by router 3.
|
|
0:06:23
|
So, router 3 is the ABR that is closest to us for those particular destinations.
|
|
0:06:29
|
The reason why again is we change the path selection on router 1
|
|
0:06:33
|
so that it is advertising a higher metric.
|
|
0:06:37
|
If we were to look in the database,
|
|
0:06:39
|
we should have multiple matches for both of these routes.
|
|
0:06:42
|
If we Show IP OSPF Database,
|
|
0:06:46
|
for the summary LSAs 155.42.7.0 or 9.0,
|
|
0:06:54
|
we would see in area 0,
|
|
0:06:57
|
which is where we are learning them,
|
|
0:06:58
|
router 1 is orginating route and router 3 is orginating a route.
|
|
0:07:02
|
So, let's now say that for this particular destination,
|
|
0:07:07
|
actually both of this destinations, the VLAN 7 and the VLAN 9,
|
|
0:07:11
|
from router 5's perspective, we want traffic to go to router 1.
|
|
0:07:16
|
But for other destinations inside area 1,
|
|
0:07:20
|
let's say the VLAN 79 or the VLAN 67, we want those packets to route to router 3.
|
|
0:07:31
|
Now, at this point, if we look at any of the inter-area routes on router 5,
|
|
0:07:35
|
and we Show IP Route include OIA,
|
|
0:07:43
|
we see that pretty much everything we are routing to get through router 3,
|
|
0:07:50
|
with the exception of this VLAN 146 interface that router 1 has directly connected.
|
|
0:07:57
|
So, we already are routing to router 3 for,
|
|
0:08:02
|
let's say the VLAN 67 segment.
|
|
0:08:11
|
And then the VLAN 7 and the VLAN 9.
|
|
0:08:16
|
So, I now wanna change the path selection,
|
|
0:08:19
|
that for this 7.7 or 9.9, I wanna forward this traffic to router 1.
|
|
0:08:26
|
But for the other destinations, I still wanted to go to router 3.
|
|
0:08:31
|
the problem with using an IGP to implement a traffic engineering
|
|
0:08:36
|
is that we cannot make changes on a per prefix basis.
|
|
0:08:40
|
Whereas in BGP, this is very straightforward.
|
|
0:08:43
|
All we need to do is match the route
|
|
0:08:45
|
and then apply some attribute like the local preference or the AS path.
|
|
0:08:49
|
But in OSPF, there's no way that we can make like a route map that says,
|
|
0:08:54
|
"Match this prefix and change the cost."
|
|
0:08:57
|
So, if we change the cost on the inteface,
|
|
0:08:59
|
it is then inheretly gonna change the path selection for any route that was using that intercae.
|
|
0:09:05
|
So, instead in IGP, the next best thing we have is to use the longest match routing principle.
|
|
0:09:12
|
If I were to configure router 3 to advertise the /20,
|
|
0:09:17
|
and router 1 to advertise both of the /24's,
|
|
0:09:23
|
it would imply that I would always choose router 1
|
|
0:09:27
|
because router 1 has the longer match to these paths.
|
|
0:09:31
|
Then if for some reason that router 1 looses its link to area 1,
|
|
0:09:35
|
I'm still able to reroute this traffic to router 3.
|
|
0:09:40
|
So, not only as the summarization used to hide the reachability information.
|
|
0:09:47
|
So, it cuts down on the amount of routes in the database and in the routing table.
|
|
0:09:51
|
But we can also use it for traffic engineering based on this longest match principle.
|
|
0:09:59
|
So, on router 3, let's go to the...
|
|
0:10:03
|
the global process.
|
|
0:10:04
|
Router OSPF 1.
|
|
0:10:07
|
And these routes are gonna be coming from area 1. So this is an area 1 range.
|
|
0:10:13
|
The summary that we're generating is 155.42.0.0 255.255.240.0.
|
|
0:10:25
|
We could see that also change the specific cost value for the prefix
|
|
0:10:32
|
if we said not advertise, this would be a filter for LSA type 3s.
|
|
0:10:40
|
Why would say that I want to basically suppress the subnets and the aggregate?
|
|
0:10:46
|
But in this case, I'm using it just for summarization.
|
|
0:10:49
|
So, now, if we were to look at router 5, and say Show IP OSPF Database,
|
|
0:10:55
|
for the summary LSA 155.42.0.0,
|
|
0:11:01
|
we see that now from router 3,
|
|
0:11:03
|
we are learning this network with this mask.
|
|
0:11:10
|
We dont' see this originated by router 1 because only router 3 did the summarization.
|
|
0:11:17
|
When we look at the routing table and look at those inter-area routes,
|
|
0:11:23
|
we see we have the /20 that is via router 3.
|
|
0:11:29
|
But we have the individual subnets that are now via router 1.
|
|
0:11:35
|
So, eventhough the cost value was higher to go through router 1 for these destinations,
|
|
0:11:43
|
we have to choose router 1 because that is the longest match.
|
|
0:11:47
|
The one that's coming from router 3 is a /20 versus the /24s.
|
|
0:11:51
|
So, no, if we were to trace to this destinations, to 155.42.7.7 or 9.9,
|
|
0:12:02
|
these packets should then go through router 1.
|
|
0:12:07
|
But if we were to look at anything else, let's say the 67.7,
|
|
0:12:14
|
this is gonna go to router 3.
|
|
0:12:20
|
Now, if we look at the local routing table on 3,
|
|
0:12:24
|
and Show IP Route OSPF,
|
|
0:12:27
|
we'll see that for the summary, OSPF is generating the route to null 0.
|
|
0:12:35
|
In EIGRP, the way that we remove this was to set the administrative distance of the summary to be 255.
|
|
0:12:43
|
In OSPF, we can simply say, "No discard route internal" or "No discard route external".
|
|
0:12:51
|
So, the only problem with this is that if we received packets for some destination that matches the /20,
|
|
0:12:59
|
we would then not be able to use our default route or any shorter match, like a /19, /18.
|
|
0:13:07
|
If for some reason, in our design, it's very specific that we do want to fallback to a shorter match,
|
|
0:13:12
|
then we would want to remove the null route.
|
|
0:13:16
|
So, under the routing process, we would say, "No discard route for internal summaries."
|
|
0:13:23
|
Which then if we Show IP Route 155.42.0.0 255.255.240.0,
|
|
0:13:33
|
we don't have the match for that.
|
|
0:13:36
|
Router 3 should be advertising it if we look at router 5.
|
|
0:13:42
|
Okay, we do have that match in the table.
|
|
0:13:43
|
But now, router 3 is not generating the null route.
|
|
0:13:48
|
So, if we Show IP Route include null, then null route's gone.
|
|
0:13:54
|
If we go back to the process in revert to the default config,
|
|
0:13:59
|
which is discard route internal and discard route external,
|
|
0:14:03
|
we see now the summaries in the table.
|
|
0:14:09
|
So, this null route again, it should not affect traffic flows that are going to longer match destinations.
|
|
0:14:16
|
So, in our case, anything that is actually going to 155.42.7.0,
|
|
0:14:23
|
since we already have the /24, the null route is never going to be referenced.
|
|
0:14:30
|
The null route is only used in the case that I don't have a longer match inside the aggregate,
|
|
0:14:35
|
then router 3 is gonna drop the traffic.
|
|
0:14:40
|
So, if we were to go to, let's say router 5 and we ping 155.42...
|
|
0:14:52
|
let's see what don't we have. Let's say 15.1.
|
|
0:14:58
|
We see that we're getting ICMP unreachable back.
|
|
0:15:02
|
And if we were to debug ICMP,
|
|
0:15:08
|
we should see this unreachable messages coming from router 3.
|
|
0:15:13
|
So, when router 3 sends the packet to the null interface,
|
|
0:15:17
|
it automatically generates an ICMP unreachable.
|
|
0:15:20
|
Okay, host unreachable, it just means that it doesn't know where to send a packet.
|
|
0:15:27
|
now, we could disable this behavior of the unreachables.
|
|
0:15:32
|
This is where we actually go to interface null 0.
|
|
0:15:36
|
And the only command that you can do here is no IP unreachable.
|
|
0:15:42
|
So, for some reason, you want to drop the packets that are going to null 0
|
|
0:15:46
|
but not generate ICMP unreachable when you do that.
|
|
0:15:51
|
Then we would say "No IP unreachable under null 0 itself."
|
|
0:15:56
|
So, it's kind of an odd configure.
|
|
0:15:58
|
It's the only thing that you can do at that interface, interface null 0.
|
|
0:16:02
|
Now, form router 5, when I send the pings,
|
|
0:16:07
|
we see that we don't get an unreachable back from router 3.
|
|
0:16:13
|
We'll see later in the security section, there are some reasons why you would want to do this.
|
|
0:16:18
|
It's mainly to prevent against mapping attacks of the network.
|
|
0:16:22
|
To see destinations does that the router does or does not have in its routing table.
|
|
0:16:27
|
So, next, let's look at the external summarization.
|
|
0:16:30
|
Again, this is gonna be on an ASBR that is doing redistribution
|
|
0:16:34
|
when we're generating either an external 1 or 2 or an N1 or N2 route.
|
|
0:16:41
|
N1 an N2, that's gonna be if we're inside a not so stubby area.
|
|
0:16:46
|
In this particular design, this would be on either router 4 or router 6,
|
|
0:16:52
|
who are redistributing from EIGRP into OSPF and from RIP into OSPF.
|
|
0:17:00
|
So, let's look at router 6.
|
|
0:17:03
|
And if we Show IP Route EIGRP,
|
|
0:17:07
|
we see that we're recieving four subnets from the backbone router.
|
|
0:17:12
|
200.0.0, 200.0.1, 0.2, and 0.3
|
|
0:17:17
|
If we look at the configuration under OSPF,
|
|
0:17:22
|
we have a redistribute statement that's saying EIGRP process 10,
|
|
0:17:24
|
we're gonna redistribute that plus the subnets.
|
|
0:17:28
|
Which means now, router 6 should be generating a type 5 LSA
|
|
0:17:34
|
or the external LSA, describing these particular destinations.
|
|
0:17:40
|
So, to verify whether the redistribution is actually working,
|
|
0:17:44
|
we could look at the Show IP OSPF Database,
|
|
0:17:47
|
and see if we see type 5 external routes
|
|
0:17:55
|
that are originated by routing 6, which in this case, they are.
|
|
0:18:01
|
So, these type 5's, these are either the the E1 or the E2 routes.
|
|
0:18:11
|
Router 6 is the originator of this.
|
|
0:18:14
|
These are the actual prefixes: 200.0.0.0, 200.0.1.0, 2.0 and 3.0.
|
|
0:18:22
|
If we look at the details behind these, we can Show IP OSPF Database,
|
|
0:18:28
|
for the external routes, 200.0.0.0 or any of the other matches.
|
|
0:18:37
|
Router 6 says that I am the advertising router.
|
|
0:18:40
|
So, that's the person who did the redistribution.
|
|
0:18:44
|
The metric type is 2 which means that this is an E2 route by default.
|
|
0:18:50
|
The metric value is 20.
|
|
0:18:53
|
That's the default metric for redistribution.
|
|
0:18:55
|
The forwarding address is 0.0.0.0.
|
|
0:19:00
|
This means that for anyone in my area,
|
|
0:19:05
|
that want to route in this particular destination,
|
|
0:19:08
|
they should route the same path that they used to reach my router ID.
|
|
0:19:14
|
So, me as the node of the database, everyone in area 1,
|
|
0:19:19
|
they should have already ran OSPF to get to me.
|
|
0:19:23
|
So, if we were to look at this from switch 3's perspective,
|
|
0:19:26
|
switch 3 should already know that the SPF path to get to router 6
|
|
0:19:30
|
is to switch 1 and then to router 6.
|
|
0:19:35
|
So, there's no reason I need to do a separate calculation for the external route.
|
|
0:19:41
|
Again, this is similar to the inter-area routing
|
|
0:19:45
|
where with the inter-area rouiting,
|
|
0:19:46
|
the ABR is generating a network summary LSA,
|
|
0:19:50
|
saying to the routers in the area,
|
|
0:19:52
|
"You don't need to know the full path to the destination because I have already run SPF on it."
|
|
0:19:59
|
So, as long as you have a loop-free path to me,
|
|
0:20:02
|
I have a loop-free path to the destination,
|
|
0:20:04
|
which means that end-to-end, we don't have to worry about the traffic looping.
|
|
0:20:09
|
Same cases happening here in with the external routes.
|
|
0:20:12
|
Router 6 is saying, "I'm gonna assume that my external path, like through EIGRP is valid."
|
|
0:20:18
|
If you have a loop-free path to me, then just use that same exact path
|
|
0:20:23
|
to get to the external routes and you're gonna be fine.
|
|
0:20:28
|
So, if we were to look at, let's say switch 3,
|
|
0:20:33
|
and we Show IP Route for 200.0.0.0,
|
|
0:20:40
|
we see that this is an OSPF external type 2 route.
|
|
0:20:45
|
It was originated by router 6.
|
|
0:20:48
|
The metric value is 20 by default and the forward metric is 100.
|
|
0:20:58
|
What is the forward metric mean here?
|
|
0:21:01
|
This is the intra-area SPF cost that switch 3 is using to reach the ASBR.
|
|
0:21:10
|
So, if we were to look at Show IP OSPF Database, look at my own router LSA,
|
|
0:21:17
|
I would see that the combination of paths that I need to go through to get to router 6
|
|
0:21:21
|
is a total metric of 100.
|
|
0:21:25
|
So, you see this sometimes described that the external type 2 routes
|
|
0:21:29
|
dont' take into account the path to the ASBR.
|
|
0:21:33
|
Technically, they do.
|
|
0:21:34
|
That's what the forward metric is used for here.
|
|
0:21:39
|
Now, for external routes, if you end up in the case where you have two equal matches,
|
|
0:21:45
|
both with the same redistribution metric,
|
|
0:21:49
|
So, if I had two router that were both had a metric of 20 here,
|
|
0:21:53
|
then we would look at what is the closest path to the ASBR.
|
|
0:21:58
|
Which is represented by the forward metric.
|
|
0:22:01
|
Now, if we were to look at this in an inter-area perspective,
|
|
0:22:05
|
let's say, we look at it form router 5's perspective.
|
|
0:22:09
|
And on router 5, we say,
|
|
0:22:12
|
Show IP OSPF Database for the external route 200.0.1.0,
|
|
0:22:21
|
it's basically, gonna tell us the same thing.
|
|
0:22:24
|
So, this LSA 5 is normally gonna go everywhere in the OSPF network.
|
|
0:22:29
|
It says that router 6 is the advertising router.
|
|
0:22:34
|
Router 6 is telling us, "Use the metric of 20."
|
|
0:22:36
|
"And use itself to get there."
|
|
0:22:40
|
So, anytime the forward address is 0.0.0.0,
|
|
0:22:44
|
it means that you're gonna use the route to the advertising router.
|
|
0:22:50
|
So, now, router 5 needs to look up in the database and figure out,
|
|
0:22:54
|
"Is that advertising router 150.42.6.6, part of my area?"
|
|
0:23:01
|
So, it's gonna check for a router LSA.
|
|
0:23:03
|
Let's say Show IP OSPF Database for the router 150.42.6.6.
|
|
0:23:16
|
Since nothing shows up here,
|
|
0:23:19
|
what does this mean about the relationship between the router 5 and router 6?
|
|
0:23:23
|
If router 5 does not have a router LSA about 150.42.6.6,
|
|
0:23:30
|
it means there not on the same area.
|
|
0:23:33
|
So, now, router 5 needs to try to do an inter-area look up on the ASBR.
|
|
0:23:39
|
This is what the LSA type 4 is used for. The ASBR summary.
|
|
0:23:44
|
So, if we now look at the Show IP OSPF Database,
|
|
0:23:48
|
we'll see that there's a new category between the summary network link state and the type 5 external,
|
|
0:23:54
|
that is my ABRs describing their paths to the ASBR in other areas.
|
|
0:24:05
|
So, now, we have router 1 and router 3 telling me they have reachability to router 6.
|
|
0:24:13
|
Since router 6 has reachability to the final destinations,
|
|
0:24:17
|
router 3 and 1 have reachability to router 6, and I have reachability to routers 1 and 3,
|
|
0:24:25
|
I will assume that I can forward to whoever is the closer ABR,
|
|
0:24:29
|
and they will route my traffic towards the ASBR.
|
|
0:24:35
|
So, again, this is the distance vector-type logic of OSPF.
|
|
0:24:39
|
But we're not actually doing a full SPF run on the external route.
|
|
0:24:43
|
We already have a shortest path tree to get to router 1 and 3.
|
|
0:24:48
|
So, that's what we're going to infer the path to the ASBR through.
|
|
0:24:54
|
So, now, if we look at the Show IP OSPF Database for the ASBR summary of 150.42.6.6,
|
|
0:25:08
|
it says that both router 1 and router 3
|
|
0:25:14
|
are advertising a metric of 1000 and 550 respectively.
|
|
0:25:20
|
Now, we know what the cost of the route itself was.
|
|
0:25:24
|
The cost was 20 by default.
|
|
0:25:27
|
If we now look at the actual routing table and Show IP Route for 200.01.0,
|
|
0:25:36
|
the metric of 20 is what router 6 was originating.
|
|
0:25:41
|
The forward metric is then comprised of my SPF path to get to router 3
|
|
0:25:50
|
plus the metric that 3 is advertising.
|
|
0:25:54
|
So, it's the same type of logic as an inter-area route look up.
|
|
0:25:59
|
but now, we're adding one more step which is this ASBR summary.
|
|
0:26:05
|
Where again router 6 is saying to router 1 and 3,
|
|
0:26:11
|
"I am in your area and I'm redistributing these routes."
|
|
0:26:16
|
"So, if you can get to me, you can get to the external routes."
|
|
0:26:19
|
Then router 1 and 3 are saying to 5,
|
|
0:26:24
|
"6 can get to these external routes. I can get to 6."
|
|
0:26:29
|
"Choose whatever the shortest path to me is and then I'll get you to the destination."
|
|
0:26:34
|
If we were then to look at this from switch 4's perspective,
|
|
0:26:38
|
we would see a new ASBR summary, generated by who?
|
|
0:26:47
|
Generated by its ABR, who in this case is router 5.
|
|
0:26:54
|
So, the key with OSPF here is that different routers will have different views in the topology
|
|
0:27:00
|
depending on what particular areas they're praticipating in.
|
|
0:27:04
|
It's only if every device was in the same exact area that the ropology would be the same.
|
|
0:27:11
|
This is the reason why we're able to do summarization.
|
|
0:27:14
|
Why we're able to do filtering between the areas or at the external boundary.
|
|
0:27:21
|
Because as long as we make sure the database agrees in area 1,
|
|
0:27:24
|
then it doesn't have to look the same to area 0.
|
|
0:27:27
|
And as long as area 0, its database is the same, it doesn't have to look the same to area 2.
|
|
0:27:33
|
So, lastly, if we look at switch 4 and say Show IP OSPF Database,
|
|
0:27:42
|
we see that router 6 is advertising these routes.
|
|
0:27:48
|
To get to router 6, we're gonna go to router 5.
|
|
0:27:52
|
Then from 5's perspective, it's saying,
|
|
0:27:54
|
"To get to router 6, I'm gonna go to either 1 or 3."
|
|
0:28:01
|
So, either 1 or 3, you can get to 6.
|
|
0:28:04
|
Then 6 knows how to get to the final destination.
|
|
0:28:07
|
So, the keypoint being here that if you're trying to apply traffic engineering to these external destinations,
|
|
0:28:12
|
you do need to take into account the transit path along the way.
|
|
0:28:17
|
Not just the redistribution metric.
|
|
0:28:20
|
The only case that the redistribution metric is gonna matter,
|
|
0:28:23
|
is that if there are multiple ASBR's originating the same route.
|
|
0:28:30
|
So, let's say for example that switch 1 also had a link to BB1.
|
|
0:28:36
|
And they were running EIGRP.
|
|
0:28:40
|
If switch 1 did redistribution and router 6 did redistribution,
|
|
0:28:45
|
then the metric value that they set is gonna matter.
|
|
0:28:49
|
So, whether we set it to 20 or 30 or 100.
|
|
0:28:53
|
But otherwise, everyone is gonna fall back to the default metric towards the ASBR
|
|
0:29:01
|
or towards the ABR that is advertising reachability to the ASBR.
|
|
0:29:08
|
Now, if we were to change this to external type 1s,
|
|
0:29:11
|
it makes it a little bit easier to read what is the full metric along the path.
|
|
0:29:15
|
Because the routers do not separate it into the forward metric versus the metric.
|
|
0:29:22
|
So, if I look on switch and say, "What's my total route to 200.0.3.0?"
|
|
0:29:30
|
This metric of 20 is what router 6 is advertising.
|
|
0:29:35
|
The metric of 33233.
|
|
0:29:37
|
This is my metric to get to router 6.
|
|
0:29:41
|
So, now, back to our summarization, on router 6, we have those four routes
|
|
0:29:47
|
that are coming from the external neighbor. We wanna summarize these all into a single path.
|
|
0:29:54
|
Okay, we can summarize these to 200.0.0.0/22.
|
|
0:30:01
|
So, under the OSPF process of router 6, we'll say Summary Address.
|
|
0:30:08
|
It's 200.0.0.0, with the mask of 255.255.2...
|
|
0:30:17
|
52...
|
|
0:30:20
|
.0
|
|
0:30:21
|
If we now look at the Show IP Route include null.
|
|
0:30:27
|
We see we have the /22.
|
|
0:30:31
|
If we now look at switch 4 and look at the mask of this destination,
|
|
0:30:39
|
now, it says that it is a /22 as opposed to the /24.
|
|
0:30:45
|
But notice that it's inhereting the same attributes.
|
|
0:30:48
|
The metric type is 2, the original metric is 20.
|
|
0:30:53
|
Then the forward metric to the ASBR is the same.
|
|
0:31:01
|
So, the anything that's chenging here is that we're combining multiple subnets into an aggregate.
|
|
0:31:09
|
Now, for traffic engineering towards this destination,
|
|
0:31:12
|
it would be a little bit harder to implement this
|
|
0:31:17
|
because to change how switch 4 is routing to the EIGRP domain,
|
|
0:31:22
|
we would have to change how router 1 routes to 6 or how 3 routes to 6.
|
|
0:31:28
|
Or how 5 routes to 1 to get to 6 or how 5 routes to 3 to get to 6.
|
|
0:31:36
|
So, you'll see with OSPF, a lot of the times,
|
|
0:31:37
|
it's near impossible to get the traffic engineering that you want,
|
|
0:31:41
|
without changing pretty much the entire forwarding domain.
|
|
0:31:46
|
The only case that this is really gonna work out
|
|
0:31:49
|
is if you can use that longest match routing principle.
|
|
0:31:53
|
But in our case here, router 6 is the one doing the redistribution.
|
|
0:31:57
|
So, we don't have an option to do summarization on anyone else on the network.
|
|
0:32:02
|
This would only be valid if maybe we did like static routing on router 1 versus router 3.
|
|
0:32:08
|
Redistributed static and then do the summarization there.
|
|
0:32:13
|
Then we would be able to control what's the path to the individual subnets.
|