|
0:00:12
|
In our next section here, we're gonna look at the different filtering capabilities of OSPF
|
|
0:00:17
|
from the stub areas to the manual LSA 3 filter
|
|
0:00:21
|
that is gonna be used to control the different types of link state advertisements that can pass between areas.
|
|
0:00:27
|
And in the case of the LSA 3 filter,
|
|
0:00:30
|
the specific routes that are going to pass between areas.
|
|
0:00:34
|
Now, as I mentioned before, the big issue with OSPF and filtering
|
|
0:00:37
|
is that everyone in the area needs to have the same copy of the link state database
|
|
0:00:43
|
in order to get the same result of the SPF calculation,
|
|
0:00:46
|
which is the Shortest Path Tree, or the SPT.
|
|
0:00:50
|
So, this means that we cannot do filtering within the area,
|
|
0:00:54
|
but we could potentially do it between areas
|
|
0:00:57
|
as long as everyone inside of that link state area has the same copy of the database.
|
|
0:01:04
|
Now, the stub areas are one feature that can be used to accomplish this,
|
|
0:01:08
|
but we'll see, it is not used to filter on a per-route basis.
|
|
0:01:12
|
Instead, it is used to filter on a per-link state advertisement type basis.
|
|
0:01:19
|
Up to this point, we looked at LSAs 1 through 5,
|
|
0:01:22
|
where LSA 1 is the router LSA
|
|
0:01:25
|
that is the router describing all of its directly attached links,
|
|
0:01:29
|
and LSA 2 is the network LSA
|
|
0:01:33
|
that is generated by the designated router to described its attached adjacencies.
|
|
0:01:40
|
Both of these two together make up the intra-area routes.
|
|
0:01:44
|
This is what we see as the capital O when we look at the Show IP Route Output.
|
|
0:01:49
|
The inter-area routes are described by LSAs 3 and 4,
|
|
0:01:55
|
where LSA 3 is the summary
|
|
0:01:59
|
of the routing information where we're moving the intra-area routes to an inter-area route,
|
|
0:02:05
|
where LSA 4 is the inter-area reachability, or an ASBR.
|
|
0:02:10
|
So, we have the network summary versus the ASBR summary.
|
|
0:02:13
|
These two together are making up the inter-area routes, or the OIA.
|
|
0:02:20
|
Type-5 external LSAs, those are the E1 and the E2 routes.
|
|
0:02:25
|
Those are the ones that are generated anytime we do redistribution into OSPF,
|
|
0:02:30
|
and then lastly, we have Type-7,
|
|
0:02:33
|
which is the not-so-stubby area external route,
|
|
0:02:36
|
which are denoted as the N1 or N2 in the routing table.
|
|
0:02:41
|
Now, when we're doing the stub area definitions,
|
|
0:02:45
|
one thing to keep in mind
|
|
0:02:47
|
is that all routers in the area need to agree on the stub flag.
|
|
0:02:51
|
So, either the area is a normal area,
|
|
0:02:55
|
it is a stub area, or it is an NSSA.
|
|
0:03:00
|
The specific types of the stub in NSSA whether it is totally stubby or not,
|
|
0:03:04
|
where there's totally, totally stubby or not,
|
|
0:03:07
|
that would be applied on the ABR only.
|
|
0:03:11
|
That is not a negotiated option.
|
|
0:03:14
|
So, as long as everyone in area 1 agrees that it's stub,
|
|
0:03:17
|
and everyone in area 2 agree that it's NSSA, that's the overall key point.
|
|
0:03:22
|
Now, the first of these four we'll look at is the regular stub area,
|
|
0:03:27
|
which is mainly used to remove the LSA Type-5 advertisements, which are the external routes.
|
|
0:03:35
|
Since we are removing the paths to the external routes,
|
|
0:03:39
|
it also means that we could remove the path to the ASBR.
|
|
0:03:43
|
So, we saw it previously in our particular topology
|
|
0:03:47
|
that switch 4 was trying to reach a destination
|
|
0:03:50
|
that was located in the EIGRP domain.
|
|
0:03:54
|
So, if we look at switch 4, and we do a...
|
|
0:03:59
|
ping for 200.0.0.1,
|
|
0:04:03
|
we see, we're able to reach those external destinations.
|
|
0:04:06
|
If we do a traceroute to these, to 200.0.0.1,
|
|
0:04:12
|
the...
|
|
0:04:14
|
Oh, that's not from the right router.
|
|
0:04:15
|
That's router 6. We wanna see this from...
|
|
0:04:19
|
switch 4.
|
|
0:04:21
|
So, switch 4, let's ping 200.0.0.1.
|
|
0:04:25
|
Okay, we are able to reach it.
|
|
0:04:26
|
If we trace to 200.0.0.1,
|
|
0:04:33
|
this is going from us, to switch 2, to router 5, to router 3,
|
|
0:04:44
|
from router 3 to switch 1,
|
|
0:04:48
|
from switch 1 to router 6,
|
|
0:04:50
|
and then finally, out to the final destination.
|
|
0:04:53
|
So in this case,
|
|
0:04:53
|
we do have specific reachability information about the external routes.
|
|
0:04:57
|
They came from the redistribution that router 6 was performing,
|
|
0:05:01
|
and then, also the summarization that router 6 was doing.
|
|
0:05:04
|
So, we see that when we look in the routing table,
|
|
0:05:06
|
if we Show IP Route 200.0.0.1,
|
|
0:05:10
|
this is a Type-5 external LSA,
|
|
0:05:14
|
which is external number 2, this is the E2 route.
|
|
0:05:21
|
It's a /22 prefix, the metric is 20.
|
|
0:05:23
|
The metric to reach the ASBR is 33,233. The ASBR itself is router 6.
|
|
0:05:32
|
But if we look at the physical topology here,
|
|
0:05:35
|
regardless of whether switch 4 was using a specific match to this destination
|
|
0:05:41
|
or if it was using just a default route,
|
|
0:05:44
|
there's only one ABR that we could possibly forward through, which is router 5.
|
|
0:05:51
|
So, in this type of design, it would be more efficient
|
|
0:05:55
|
to remove the specific reachability information,
|
|
0:05:59
|
and from router 5 into area 2, simply advertise a default route.
|
|
0:06:07
|
This is what the overall goal of the stub area types are.
|
|
0:06:11
|
So, for any physical places in the network
|
|
0:06:13
|
that we can remove routes from the database,
|
|
0:06:16
|
but end up in the same forwarding capabilities,
|
|
0:06:20
|
then, it would be more efficient to replace them
|
|
0:06:21
|
with just default routes and have the same end result.
|
|
0:06:27
|
The only case typically where we would not want to do this
|
|
0:06:30
|
is when there are multiple exit points out of the area
|
|
0:06:34
|
by removing the different LSA types,
|
|
0:06:37
|
it's gonna give us less visibility
|
|
0:06:40
|
as to the different diverse paths that we could choose from.
|
|
0:06:44
|
So, for example, if area 1 was configured as a stub area,
|
|
0:06:48
|
we have router 1 and router 3 as the different exit points,
|
|
0:06:53
|
we could potentially route to get to router 2 this way,
|
|
0:06:58
|
where it may be physically closer to go to router 3.
|
|
0:07:01
|
So, anytime we are removing the subnets and replacing it with shorter matches,
|
|
0:07:06
|
we're loosing visibility about the diversity of the paths in the network.
|
|
0:07:10
|
But on outer 5, this is not gonna matter because it's the only physical path
|
|
0:07:15
|
that switch 2 and switch 4 could go through
|
|
0:07:19
|
in order to reach that particular destination.
|
|
0:07:24
|
Now, when we configure this type of stub area,
|
|
0:07:28
|
the ABR which is router 5 is gonna remove the external Type-5 routes,
|
|
0:07:37
|
and also the Type-4 LSAs which are the announcement to the ASBR.
|
|
0:07:44
|
We're gonna keep our inter-area destinations, which are LSA Type-3.
|
|
0:07:49
|
But we are gonna replace the number 5, and then number 4 with a default route.
|
|
0:07:56
|
So, if we can end up in the same forwarding result
|
|
0:07:59
|
by using the default versus the longer matches,
|
|
0:08:03
|
then, it's gonna make more sense just to use the default route.
|
|
0:08:08
|
So first, let's look at the database on switch 4 and Show IP OSPF Database.
|
|
0:08:17
|
If we were to compare this to switch 2,
|
|
0:08:20
|
it should be identical.
|
|
0:08:22
|
Because they're both within the same area.
|
|
0:08:27
|
So whether we're looking at...
|
|
0:08:29
|
switch 2 or switch 4,
|
|
0:08:32
|
we could see everything is the same with the exception of the age value.
|
|
0:08:36
|
So, the age is gonna be based on the internal counter
|
|
0:08:39
|
how long ago do we receive the update.
|
|
0:08:42
|
But everything else in the topology,
|
|
0:08:43
|
the check sum, the sequence number, the tag values,
|
|
0:08:46
|
all of that is the same.
|
|
0:08:50
|
Next thing we're gonna do is change
|
|
0:08:53
|
this particular area, which is area number 2...
|
|
0:08:59
|
to a stub area. So, everyone in the area will say, "Area 2 is stub."
|
|
0:09:05
|
This will be on router 5, switch 2, and switch 4.
|
|
0:09:18
|
Area 2 stub.
|
|
0:09:21
|
We should see that this is gonna cause the adjacencies to go down,
|
|
0:09:24
|
and then return because we have to do new flooding of the different LSAs.
|
|
0:09:29
|
If we now look at the result of the routing table on switch 4,
|
|
0:09:34
|
and Show IP Route OSPF,
|
|
0:09:38
|
we see that we still have our intra-area routes, which are the O routes.
|
|
0:09:44
|
We still see that we have our inter-area routes, which are the OIAs,
|
|
0:09:51
|
but we will not see anything that is an E1 or an E2.
|
|
0:09:57
|
So, if we now look at the path to get to 200.0.0.1,
|
|
0:10:02
|
we don't have a specific match to that anymore.
|
|
0:10:05
|
Instead, this has now been replace by a default route that router 5 is generating.
|
|
0:10:14
|
However, if we look at the end result of the forwarding,
|
|
0:10:18
|
when we do a traceroute from switch 2 to the destination,
|
|
0:10:22
|
nothing is changed here.
|
|
0:10:25
|
So, the packets are still going from switch 4 to switch 2,
|
|
0:10:28
|
to router 5, to router 3, to switch 1, to router 6,
|
|
0:10:31
|
and then out to the final destination.
|
|
0:10:34
|
The only difference is that when we look at the OSPF database now
|
|
0:10:39
|
and compare this to the previous output that we showed on switch 2,
|
|
0:10:45
|
switch 2 previously had these Type-5 LSAs.
|
|
0:10:49
|
Now, the Type-5 is gone.
|
|
0:10:53
|
The only thing we have is the Type-1,
|
|
0:10:55
|
which is the routers in our area,
|
|
0:10:58
|
Type-2 which is the designated routers in our area,
|
|
0:11:02
|
and Type-3, which is the inter-area routes.
|
|
0:11:06
|
Also notice now that we have the link 0.0.0.0 generated by router 5.
|
|
0:11:13
|
This is our default route that the ABR is advertising.
|
|
0:11:19
|
So essentially, router 5 took anything
|
|
0:11:20
|
that was previously an external route.
|
|
0:11:24
|
If we Show IP Route Include the E1 or E2.
|
|
0:11:29
|
All of these paths have now been replaced by just the default.
|
|
0:11:34
|
But from switch 4's perspective,
|
|
0:11:36
|
we should be able to reach any of these like the 30.0.0.1,
|
|
0:11:41
|
the 51.51.51.51.
|
|
0:11:46
|
Any of those external paths, we ultimately should be able to reach,
|
|
0:11:49
|
because we're simply replacing their more specific route with a less specific default.
|
|
0:11:56
|
So, the configuration of this is pretty straightforward.
|
|
0:11:58
|
It's just one command on all the routers of the area.
|
|
0:12:01
|
It's more of a design issue to choose whether you want stub areas or not
|
|
0:12:05
|
depending on the diversity of paths out of the area.
|
|
0:12:10
|
Now, our next area type would be the totally stubby area
|
|
0:12:14
|
that take out previous filter and goes one step further
|
|
0:12:18
|
by not only removing the Type- 5 and 4 LSAs,
|
|
0:12:22
|
which are the external routes and the ASBR summary.
|
|
0:12:27
|
We're also gonna remove the inter-area routes, which are the OIA routes.
|
|
0:12:32
|
And replace this all with the default route.
|
|
0:12:37
|
If we were to look at the forwarding result of this on area 2,
|
|
0:12:41
|
if I'm trying to reach the loopback of router 1,
|
|
0:12:44
|
I'm still gonna follow the same path transiting through router 5
|
|
0:12:48
|
regardless of whether I'm using a default route,
|
|
0:12:51
|
or I'm using the specific match.
|
|
0:12:54
|
So, in this physical topology,
|
|
0:12:55
|
area 2 would be a good candidate not only to be a stub area,
|
|
0:13:00
|
but to be a totally stubby area.
|
|
0:13:04
|
When we look at the result of the database change on switch 4,
|
|
0:13:08
|
we'll see that all of these external routes,
|
|
0:13:11
|
or excuse me, the summary routes,
|
|
0:13:14
|
which is the LSA number 3.
|
|
0:13:19
|
All of these are then gonna be replaced with just the default.
|
|
0:13:27
|
So, on the ABR, which is router 5.
|
|
0:13:30
|
Under the OSPF process, we'll specific that area 2 is still a stub area,
|
|
0:13:36
|
but now, it is totally stubby.
|
|
0:13:39
|
So, we'll say, Area 2 Stub No Summary.
|
|
0:13:47
|
If we now look at the result of the...
|
|
0:13:50
|
database,
|
|
0:13:53
|
Show IP OSPF Database,
|
|
0:13:55
|
we'll see that the size of it is severely reduced.
|
|
0:14:00
|
So, the only routes we're now gonna have in the routing table
|
|
0:14:02
|
will be ones that are in our own area
|
|
0:14:06
|
plus a default route to reach any of the other areas.
|
|
0:14:11
|
But again, if we look at the result of forwarding,
|
|
0:14:14
|
if I were to trace to get to router 1's loopback,
|
|
0:14:18
|
or router 3's loopback,
|
|
0:14:22
|
it doesn't matter what inter-area destination we're reaching,
|
|
0:14:27
|
we always have to transit through router 5.
|
|
0:14:31
|
So, as long as the devices in area zero maintain the full reachability information,
|
|
0:14:37
|
then, any of the non-transit areas can reduce
|
|
0:14:40
|
their information down to a default route,
|
|
0:14:42
|
plus their intra-area reachability information.
|
|
0:14:48
|
So again, configuration wise,
|
|
0:14:49
|
this is the Area 2 Stub No Summary command on the ABR
|
|
0:14:54
|
plus the Area 2 Stub command on the other routers in area 2.
|
|
0:14:59
|
Now, the potential issue that we could run into
|
|
0:15:01
|
with either the stub area or the totally stubby area
|
|
0:15:05
|
is that since we are filtering out the Type-5 externals,
|
|
0:15:10
|
it would not be valid to have a stub area
|
|
0:15:12
|
that has other external information
|
|
0:15:15
|
being redistributed into it.
|
|
0:15:18
|
So, in our design, if we had on switch 4
|
|
0:15:21
|
some other link that goes down to an external domain,
|
|
0:15:25
|
let's say, we have...
|
|
0:15:28
|
EIGRP routes that are being learned.
|
|
0:15:31
|
Switch 4 would not be able to redistribute these into the area.
|
|
0:15:35
|
Because everyone in area 2 is now disallowed
|
|
0:15:37
|
from installing Type-5 LSAs in the database.
|
|
0:15:42
|
So, this is where the not-so-stubby area comes in.
|
|
0:15:45
|
We're still gonna be filtering out the external route plus the ASBR summaries.
|
|
0:15:52
|
So we're filtering out Type-5 and Type-4.
|
|
0:15:55
|
But we're allowing the generation of an NSSA external route, which is LSA Type-7.
|
|
0:16:03
|
In the routing table, these would appear as the N1 or the N2 routes.
|
|
0:16:10
|
Now, just like the stub area,
|
|
0:16:12
|
everyone on the NSSA must agree on this.
|
|
0:16:16
|
In our case, we're gonna configure this in area 1,
|
|
0:16:20
|
where router 1, router 3, switch 3, switch 1, and router 6,
|
|
0:16:25
|
they all need to agree that area 1 is an NSSA.
|
|
0:16:32
|
We'll also see that with the default configuration,
|
|
0:16:37
|
when we specify area 1 as an NSSA,
|
|
0:16:41
|
the area border routers will not automatically originate a default route.
|
|
0:16:46
|
And there is a specific reason as to why that's gonna happen.
|
|
0:16:50
|
We'll take a look at in a minute why we would not want them
|
|
0:16:54
|
to automatically generate default information.
|
|
0:17:02
|
So next, let's go to the routers that are in area 1.
|
|
0:17:06
|
And we'll specify them as area 1 being an NSSA.
|
|
0:17:10
|
Ultimately, this should still allow router 6 to perform the redistribution
|
|
0:17:15
|
from EIGRP into OSPF,
|
|
0:17:17
|
but it's gonna filter switch 3 and switch 1
|
|
0:17:21
|
from having external information about the RIP domain,
|
|
0:17:24
|
or this area 51 that's redistributing routes in from router 2.
|
|
0:17:33
|
So first on router 1,
|
|
0:17:36
|
we'll say, under the OSPF process,
|
|
0:17:38
|
we want area 2, or area 1 to be an NSSA.
|
|
0:17:49
|
Router 3 is gonna say the same thing.
|
|
0:17:56
|
Router 6.
|
|
0:18:02
|
Switch 1 and switch 3.
|
|
0:18:19
|
If we now look at the change in the OSPF database on switch 3,
|
|
0:18:24
|
and we Show IP OSPF Database.
|
|
0:18:29
|
We'll see that we no longer have Type-5 external routes,
|
|
0:18:34
|
but we will have Type-7 external routes
|
|
0:18:38
|
that are generated by any ASBRs that are within our area.
|
|
0:18:44
|
In this case, this is the 200 route
|
|
0:18:47
|
that router 6 is redistributing from EIGRP, and then summarizing.
|
|
0:18:53
|
So, if we now look at the Show IP OSPF Database
|
|
0:18:56
|
for the NSSA external route 200.0.0.0,
|
|
0:19:02
|
we see, it's essentially the same logic as the Type-5 LSA.
|
|
0:19:08
|
But this is specifically for the not-so-stubby area.
|
|
0:19:15
|
Here, it says that router 6 is the originator.
|
|
0:19:20
|
This is the prefix, this is the mask.
|
|
0:19:24
|
The metric type is 2, which means that this is an N2 route.
|
|
0:19:28
|
N2 route is analogous to an E2 route of Type-5 LSAs.
|
|
0:19:35
|
Metric value is 20.
|
|
0:19:37
|
The forwarding address is router 6's loopback.
|
|
0:19:42
|
So, this means that we would need to know how to get towards router 6
|
|
0:19:46
|
in order to send traffic to this destination.
|
|
0:19:50
|
Now, we'll see that this is a little bit different from the Type-5 LSA,
|
|
0:19:55
|
because the Type-5 LSA usually has the forwarding address as all zeros.
|
|
0:20:01
|
If the forwarding address is all zeros,
|
|
0:20:03
|
it means you route towards the ASBR in order to reach the destination.
|
|
0:20:12
|
So, we'll see in second here why the NSSA external does not use an all zero value.
|
|
0:20:18
|
Now, if we look in the routing table and Show IP Route OSPF,
|
|
0:20:23
|
we'll see that we still have our intra and inter-area routing information.
|
|
0:20:29
|
We don't have any E1 or E2, but we do have this N2.
|
|
0:20:35
|
Which goes to 200.0.0.1.
|
|
0:20:40
|
Now, we will see that we cannot reach this external destinations from the other areas now.
|
|
0:20:47
|
Because the ABR of the not-so-stubby area
|
|
0:20:51
|
does not automatically originate the default.
|
|
0:20:55
|
We can configure it to originate the default if we want it to.
|
|
0:20:59
|
So example, on router 1, we could say,
|
|
0:21:01
|
Area 1 NSSA Default Information Originate.
|
|
0:21:05
|
But it's not gonna do this for us automatically.
|
|
0:21:09
|
The reason why is that in the previous stub areas,
|
|
0:21:15
|
which is the stub, and the totally stub,
|
|
0:21:18
|
the default route was advertised as what type of LSA?
|
|
0:21:27
|
Let's look at switch 4 and see
|
|
0:21:28
|
what type of default route is it installing from router 5.
|
|
0:21:36
|
If we look at the Show IP Route...
|
|
0:21:39
|
OSPF.
|
|
0:21:43
|
The default is Type-3.
|
|
0:21:46
|
Okay, it's a Type-3 LSA. It means it's an inter-area default route.
|
|
0:21:54
|
Now, if the ABRs of the NSSA...
|
|
0:21:58
|
were to originate a default route
|
|
0:22:03
|
that is LSA 3,
|
|
0:22:07
|
what this would prevent would be the ability
|
|
0:22:10
|
to redistribute a default route from EIGRP as LSA 7.
|
|
0:22:20
|
The reason why, recall that when we're looking at the path selection for OSPF,
|
|
0:22:26
|
we always have to prefer the intra-area routes over the inter-area routes
|
|
0:22:34
|
over the E1, E2, N1, and N2.
|
|
0:22:39
|
In our case, the not-so-stubby routes
|
|
0:22:42
|
are basically the least preferable routes.
|
|
0:22:46
|
If we were to have a default route that was an N1 or N2 type
|
|
0:22:52
|
versus a default route that is an LSA 3,
|
|
0:22:57
|
it wouldn't matter what the cost value is, or what the distance was,
|
|
0:23:02
|
we would always prefer the Type-3 LSA over the Type-7.
|
|
0:23:10
|
So, with the not-so-stubby area,
|
|
0:23:13
|
it stops the area border router from generating the Type-3 LSA default.
|
|
0:23:18
|
We can manually configure it to originate a Type-7 default if we wanted to.
|
|
0:23:26
|
So, on router 3 or router 1,
|
|
0:23:29
|
we could say...
|
|
0:23:32
|
Area 1 NSSA Default Information Originate.
|
|
0:23:34
|
This is going to advertise the default route as well.
|
|
0:23:39
|
Now, this would also give us a choice
|
|
0:23:41
|
as to what particular exit point we wanna reach,
|
|
0:23:44
|
or we wanna use to get reachability to the external destinations.
|
|
0:23:49
|
So, if we wanna use router 3 as the exit point to get towards the RIP domain,
|
|
0:23:55
|
so, route traffic in this direction,
|
|
0:23:57
|
then, we could have router 3 originate the default route but not router 1.
|
|
0:24:04
|
So, it's not really a function
|
|
0:24:06
|
that we don't want reachability to the destinations.
|
|
0:24:09
|
It's just that we want more granular control
|
|
0:24:11
|
over how the traffic is actually gonna forward.
|
|
0:24:15
|
So, if we were to go to router 3,
|
|
0:24:18
|
and say under the OSPF process,
|
|
0:24:21
|
Area 1 NSSA...
|
|
0:24:26
|
Default Information Originate.
|
|
0:24:29
|
When we look at the routing table inside that area,
|
|
0:24:37
|
we'll see that now, there is a default route that is a Type-7 LSA.
|
|
0:24:42
|
So, it's an N2 route.
|
|
0:24:45
|
If we were to also have an inter-area route that was LSA Type-3,
|
|
0:24:51
|
we would then be preferring that over the Type-7 LSA.
|
|
0:24:57
|
Now, from outside the not-so-stubby area, if we were to go to router 5,
|
|
0:25:02
|
and look at the routing table, or look at the database,
|
|
0:25:06
|
we'll see that that NSSA external, which is the 200.0.0.0,
|
|
0:25:13
|
this is being changed into a normal Type-5 default
|
|
0:25:18
|
for devices outside of the NSSA.
|
|
0:25:24
|
This means that from router 5's perspective,
|
|
0:25:27
|
it does not know that area 1 is an NSSA.
|
|
0:25:30
|
This sees this as a regular Type-5 default route. Or Type-5 external route.
|
|
0:25:38
|
Now, when we look at the details behind the prefix,
|
|
0:25:42
|
if we Show IP OSPF Database for the external LSA 200.0.0.0,
|
|
0:25:49
|
notice that the forwarding address has been maintained
|
|
0:25:55
|
as the prefix was originated from area 1 into area 0.
|
|
0:26:02
|
This then means whatever our forwarding path is to reach router 6,
|
|
0:26:08
|
that's the path that the traffic towards the external route is gonna forward.
|
|
0:26:14
|
We will see that there could be potential cases
|
|
0:26:17
|
where the ABR that is doing the advertisement of the route
|
|
0:26:22
|
is not actually the one that is receiving the traffic for the destination.
|
|
0:26:28
|
So, with the Type-7 to Type- 5 translation,
|
|
0:26:31
|
we're decoupling the control plane advertisement of the actual prefix
|
|
0:26:36
|
from the data plane forwarding to the actual destination.
|
|
0:26:40
|
So, in other words, it means that we could be learning the route from router 3,
|
|
0:26:43
|
but then, we're actually sending the traffic towards router 1.
|
|
0:26:47
|
It depends ultimately how we change
|
|
0:26:49
|
our forwarding to get towards this address.
|
|
0:26:53
|
Now, our 4th type here,
|
|
0:26:55
|
the not-so-totally-stubby area
|
|
0:26:58
|
is then a combination of the totally stubby area and the NSSA.
|
|
0:27:03
|
Where not only are we stopping the external Type-5 routes,
|
|
0:27:08
|
the ASBR summaries, which are the Type-4 LSAs.
|
|
0:27:11
|
Then, we're also removing all of the inter-area routes.
|
|
0:27:17
|
This is still allowing us to do redistribution.
|
|
0:27:20
|
We can generate the Type-7 LSAs.
|
|
0:27:24
|
And the ABR will automatically originate an inter-area default route, which is Type-3.
|
|
0:27:32
|
So, in a totally NSSA design,
|
|
0:27:36
|
we could not have a case where we are using
|
|
0:27:38
|
the default route towards the external routing domain.
|
|
0:27:42
|
So again, if router 6 is redistributing a default route,
|
|
0:27:47
|
but router 2 says that this is NSSA No Summary,
|
|
0:27:54
|
it means that traffic that matches default destination would have to go through router 1.
|
|
0:28:00
|
Never to router 6.
|
|
0:28:03
|
Because we would always prefer the OIA route
|
|
0:28:06
|
over the N1 or the N2.
|
|
0:28:09
|
So, in this case, if we were to go to router 3,
|
|
0:28:13
|
we'll say under the OSPF process,
|
|
0:28:15
|
Area 1 is an NSSA.
|
|
0:28:18
|
But we want No Summary Routes as well.
|
|
0:28:23
|
Where the summary routes is referring to the LSA Type-3 network summary LSAs.
|
|
0:28:32
|
So now, if we look at the result to this change on switch 3,
|
|
0:28:36
|
and look at the OSPF database,
|
|
0:28:39
|
we'll see now that all of our inter-area destinations have been removed,
|
|
0:28:45
|
and now, they're replaced by default routes.
|
|
0:28:48
|
We have a default route that's coming both from router 1 and from router 3.
|
|
0:28:53
|
We're now gonna choose whatever our closest path to the ABR is
|
|
0:28:59
|
in order to get to the default destination.
|
|
0:29:02
|
Now, notice router 3 is also still originating that Type-7...
|
|
0:29:08
|
external default route.
|
|
0:29:10
|
This is because now, if I say, Show Run Section Router OSPF,
|
|
0:29:17
|
it's still gonna have that old command in there
|
|
0:29:18
|
that was Area 1 NSSA Default Information Originate.
|
|
0:29:22
|
So normally, you wouldn't do both of these at the same time.
|
|
0:29:25
|
You would do one or the other.
|
|
0:29:34
|
So, if we Show Run...
|
|
0:29:37
|
Section Router OSPF,
|
|
0:29:45
|
we have area 1 NSSA. I now wanna say Area 1 NSSA No Summary.
|
|
0:29:55
|
Now, if we look at the database, we should see
|
|
0:29:56
|
that there are two default routes that are Type-3 LSAs.
|
|
0:30:08
|
From router 1 and router 3 respectively.
|
|
0:30:11
|
And then also, we have our own Type-7
|
|
0:30:13
|
that we are redistributing from router 6.
|
|
0:30:16
|
So, when we now look at the routing table,
|
|
0:30:20
|
we have the matches to our intra-area destinations,
|
|
0:30:25
|
which would be the VLAN 7, the VLAN 67.
|
|
0:30:31
|
We have the NSSA external,
|
|
0:30:34
|
which is our N2 route.
|
|
0:30:37
|
Then, we have the default route that us an inter-area default
|
|
0:30:41
|
going either to router 1 or to router 3.
|
|
0:30:46
|
So, it depends on our path selection to the ABR.
|
|
0:30:48
|
So now, if I were to trace how do I get to the RIP domain,
|
|
0:30:54
|
we see we're using router 3 as the exit point
|
|
0:30:56
|
So essentially, for anything that is outside of our area now,
|
|
0:31:00
|
like, let's say router 5's loopback,
|
|
0:31:03
|
all of its traffic is gonna forward to router 3.
|
|
0:31:07
|
Because it's the closer ABR from the perspective of our default route.
|
|
0:31:14
|
So, the packets go from...
|
|
0:31:17
|
switch 3 to switch 1, then from switch 1 to router 3.
|
|
0:31:23
|
Now, if we were to go to switch 1,
|
|
0:31:26
|
and look at the Show IP Route OSPF,
|
|
0:31:30
|
we see that the default route is being installed by router 3,
|
|
0:31:34
|
via router 3 as opposed to the one via router 1.
|
|
0:31:40
|
If I wanted to prefer the path through router 1 instead of through 3,
|
|
0:31:46
|
I have a couple different options here.
|
|
0:31:49
|
I could either just change my normal path selection to get to router 3.
|
|
0:31:54
|
So maybe I'll say, this link has a cost of 9.9.9.9.
|
|
0:31:57
|
So, it's gonna be much worst to go this way versus that way.
|
|
0:32:03
|
Or I could specify when they originate the default route,
|
|
0:32:08
|
what is the particular cost value that it's gonna get?
|
|
0:32:12
|
and if we look at router 3 under the OSPF process,
|
|
0:32:16
|
this is what the area 1 default cost command is for.
|
|
0:32:23
|
So, it's specifically within the scope of a stub area
|
|
0:32:27
|
when we are originating a default route into the stub area,
|
|
0:32:30
|
what is the local cost that we're gonna use?
|
|
0:32:32
|
So, if I say that it's something high, 999999,
|
|
0:32:39
|
then, ideally,
|
|
0:32:41
|
the other routers would prefer to go to router 1 versus router 3.
|
|
0:32:48
|
So now, when switch 3 does these traces,
|
|
0:32:51
|
it should be using router 1 as the ABR exit point, not this router 3.
|
|
0:33:04
|
So again, if we look at our configuration here,
|
|
0:33:11
|
everyone in area 1 says that area 1 is an NSSA.
|
|
0:33:15
|
Both router 1 and router 3, the ABRs,
|
|
0:33:17
|
they're saying No Summary,
|
|
0:33:20
|
which is stopping the inter-area routes.
|
|
0:33:24
|
It's then replacing this with a default.
|
|
0:33:30
|
Then, router 3 is saying, "The default cost is very high."
|
|
0:33:34
|
So, I entered al those nines
|
|
0:33:36
|
that must have not been a valid input.
|
|
0:33:38
|
So, change it to 69.59.
|
|
0:33:43
|
But still, this is gonna be much higher than the path is through router 1.
|
|
0:33:50
|
So, there's a lot of detailed traffic engineering
|
|
0:33:52
|
that you can use the stub areas for.
|
|
0:33:55
|
Beyond just using them for filtering out the routes
|
|
0:33:59
|
that are in the database and in the routing table.
|
|
0:34:02
|
So, let's say now in this case that...
|
|
0:34:04
|
Right now, we have router 1 being used as the...
|
|
0:34:10
|
As the router for the default route.
|
|
0:34:13
|
But let's say that for the inter-area destinations,
|
|
0:34:17
|
I wanna go out to router 3 for the OIAs,
|
|
0:34:23
|
but then, for the external destinations,
|
|
0:34:26
|
I wanna go to router 1.
|
|
0:34:31
|
Now, we know that we can't really change
|
|
0:34:32
|
the cost values in order to get that to happen.
|
|
0:34:35
|
Because if I change the link level cost,
|
|
0:34:38
|
it's going to affect all destinations
|
|
0:34:39
|
that are using that path for transit.
|
|
0:34:44
|
So, how could I get switch 3 to forward
|
|
0:34:46
|
the traffic towards the RIP domain
|
|
0:34:48
|
up this way through router 1?
|
|
0:34:52
|
Where if I'm going through area zero or area 2,
|
|
0:34:55
|
go this way through router 3?
|
|
0:34:58
|
How could I do this through the longest match routing principle?
|
|
0:35:04
|
What if router 1
|
|
0:35:06
|
was only advertising a default route,
|
|
0:35:10
|
but router 3 was advertising the inter-area subnets.
|
|
0:35:18
|
So, when we're defining whether the stub
|
|
0:35:20
|
or NSSA is total stubby, or not-so-totally stubby,
|
|
0:35:25
|
not all of the ABRs need to agree on this.
|
|
0:35:29
|
As long as everyone agrees on the stub flag itself,
|
|
0:35:32
|
which is either the stub or the NSSA,
|
|
0:35:35
|
it's up to the individual ABRs to control
|
|
0:35:38
|
whether they want to generate the summary routes or not.
|
|
0:35:43
|
So, on router 3, we could say...
|
|
0:35:45
|
that area 1 is a regular NSSA.
|
|
0:35:50
|
So, this means I would be stopping the routes,
|
|
0:35:54
|
but I would be allowing the inter-area routes to pass.
|
|
0:35:59
|
Then, on router 1, I'll say that area 1 is an NSSA,
|
|
0:36:04
|
but I don't wanna generate the summary LSAs,
|
|
0:36:09
|
which means that router 1 would not send the inter-area routes,
|
|
0:36:13
|
but it would send a default route.
|
|
0:36:18
|
Now, for some reason,
|
|
0:36:18
|
router 3 goes down, we loose that exit path,
|
|
0:36:21
|
router 1 is still a viable exit,
|
|
0:36:24
|
because it is advertising the default route.
|
|
0:36:30
|
Then likewise, if router 1 were to go down,
|
|
0:36:33
|
we would need some method to try to prefer router 3 as the default exit point.
|
|
0:36:39
|
So, if we go back to router 3,
|
|
0:36:42
|
I'll say that under the OSPF process here,
|
|
0:36:47
|
the NSSA is not No Summary.
|
|
0:36:51
|
It's kind of a double negative there.
|
|
0:36:53
|
So, if we Show Run Section Router OSPF,
|
|
0:37:03
|
I'll no Area 1 NSSA Default Information Originate.
|
|
0:37:09
|
So, this means that router 3 is advertising what in the area 1?
|
|
0:37:16
|
It's advertising inter-area routes.
|
|
0:37:20
|
A default route of Type-7,
|
|
0:37:24
|
but no Type-5 or Type-4 LSAs.
|
|
0:37:30
|
So, it's getting rid of the ASBR summaries
|
|
0:37:31
|
and it's getting rid of the external routes.
|
|
0:37:34
|
On router 1,
|
|
0:37:38
|
if we Show Run Section Router OSPF,
|
|
0:37:47
|
router 1 says Area 1 NSSA No Summary.
|
|
0:37:51
|
It means that it is stopping the Type-5 externals.
|
|
0:37:56
|
The Type-4 ASBRs summary.
|
|
0:38:00
|
And it's stopping the inter-area routes,
|
|
0:38:04
|
but advertising an LSA Type-3 default.
|
|
0:38:09
|
So now, if we were to look on switch 1 and we Show IP OSPF Database.
|
|
0:38:20
|
We see that the inter-area destinations
|
|
0:38:24
|
are now being installed via router 3.
|
|
0:38:29
|
We also have an inter-area default route
|
|
0:38:35
|
that's being installed via router 1.
|
|
0:38:39
|
So, router 1 is preferred for default.
|
|
0:38:41
|
Router 3 is preferred for everything else.
|
|
0:38:45
|
However, if router 1 were to go down,
|
|
0:38:48
|
we have the Type-7 external default that's being originated by router 3.
|
|
0:38:56
|
So, this design would be able to survive either a failure of 1 or 3,
|
|
0:39:01
|
and still be able to get traffic out to any destination.
|
|
0:39:05
|
But now, when we look at the actual transit path,
|
|
0:39:08
|
from switch 3,
|
|
0:39:09
|
if we were to trace an inter-area destination,
|
|
0:39:14
|
we go through router 3.
|
|
0:39:17
|
If we trace an external destination like 30.0.0.1,
|
|
0:39:22
|
we go through router 1.
|
|
0:39:25
|
Because based on the route type preference,
|
|
0:39:28
|
in the OSPF path selection,
|
|
0:39:30
|
we always have to choose the Type-3 LSA over the Type-7 LSA.
|
|
0:39:37
|
Now, if router 1 were to go down,
|
|
0:39:40
|
so if this link to router 6 gets removed,
|
|
0:39:45
|
6 should detect this almost immediately
|
|
0:39:48
|
because we're doing those sub-second hellos.
|
|
0:39:54
|
Now, if we trace the route again to 30.0.0.1,
|
|
0:39:58
|
the traffic is rerouted to router 3.
|
|
0:40:04
|
If router 2 comes back,
|
|
0:40:10
|
once it re-converges we should see this external destination
|
|
0:40:16
|
is gonna go through router 1 again.
|
|
0:40:29
|
Which it is.
|
|
0:40:30
|
So, once its re-converge,
|
|
0:40:33
|
now, we're using router 1 as the default exit point.
|
|
0:40:35
|
For the inter-area destinations,
|
|
0:40:38
|
we're now using router 3.
|
|
0:40:42
|
But if router 3 were to go down,
|
|
0:40:52
|
then, for the inter-area destinations,
|
|
0:40:55
|
now, we would fall back to our default route,
|
|
0:40:58
|
which means we're using router 1.
|
|
0:41:01
|
So, it's gonna always reachability in either case,
|
|
0:41:05
|
but based on the longest match routing principle,
|
|
0:41:08
|
we can control what particular ABR
|
|
0:41:11
|
we wanna use to reach either the external routes
|
|
0:41:13
|
versus the inter-area routes.
|
