So now that we've seen some of the problems
with not doing summarization, let's
begin by actually looking at summarizing internal routes,
or type III LSAs, in OSPF.
Internal and external summarization
are done differently.
Now, they actually function very similar.
However, there are different restrictions
on when we can do each one, and the command
itself is different for internal versus external.
So as usual, let's take a look at our diagram real quick,
so we can be familiar with what we're
going to be doing in the demonstration.
And then we'll jump into the CLI and see how summarization works
for our internal prefixes.
So in this video, we'll be focusing just
on the internal routes.
So since we're focusing on the internals,
we'll just be looking at those four routes
that we saw earlier, coming from router 10.
These are, of course, coming down to the ABR.
In this case, that's router 6 is acting as the ABR
here for area 200.
Remember that in OSPF, you can only summarize on an ABR.
In this case, that would be router 6, router 1,
or router 3.
Those are the only approaches we have in this topology.
So what we're going to do is, we're
going to take these 4/24 routes that we have right now,
and we are going to summarize them into 1/16 route being
advertised by router 6.
Then we'll, of course, take a look
at the changes that creates on router 7
as far as, once again, causing a failure on router 10,
just for one of the loopbacks, and then
bringing that interface back up.
So we'll take a look at what happens when that route flaps.
So let's jump into the command line.
As usual, we'll start with looking
at what we already have.
So we'll start on router 7 and look at these existing routes,
just to verify that we're getting them
before we do our summarization.
So we'll start with the show IP route OSPF.
We'll look specifically at the anterior area routes.
And what we're looking for are these 100.100 networks.
We can see that right now, we do have 4/24 networks, of course,
only being different in the third octet.
So we're going to be summarizing these to 100.100.0.0/16.
To do this, of course, we have to go to our ABR.
So let's jump up to router 6.
We'll go into configuration mode.
Of course, into our OSPF process.
And then we're going to do the area range command.
Now when we put in the area, this
is going to be the area that the routes are in.
So in this case, it's area 200.
We will be summarizing into all other areas.
So just keep in mind, when you're doing the area range
command, it's always the source area that you're listing,
the one that has the prefixes that we wish to summarize.
Out of area 200, of course, we're doing a range.
This is why we call it the area range command.
And then we put in the network that we actually
want to summarize.
So in this case, it's going to be the 100.100.
And of course, then we put in the mask.
We're going to make this a /16.
There's a few other options we can do on this as well.
So for example, we could set the cost.
Notice the default is to advertise this route.
We're not going to change any of these options right now.
So let's just go ahead and hit Enter.
And let's do a show IP route.
The reason we're doing a show IP route on this device
is, we want to see that it does still, of course,
itself have those 4/24s.
But notice that we now have a /16.
It's listed as a summary, and the next hop is null zero.
This route is referred to as the discard route.
Its purpose is to prevent loops in our OSPF environment.
Say, for example, we had an advertisement of this summary.
And since we're saying that we can get to all of 100.100,
well what if somebody sent a packet to us going to, say
a network that doesn't exist?
So maybe it's going to 100.100.200.0/24.
Well, we don't have a network that's 200/24.
Now normally, what we would do is just discard that traffic,
because we don't have a route for it.
But what if this router happens to also have a default route?
So maybe this is like an internet edge,
and we're default routing to the next hop,
and we're advertising this summary.
Then somebody sends us something that doesn't exist.
We don't have a route for it.
So we send it right back to the default gateway, who of course
routes it right back to us.
We send it right back to the default gateway.
And just like that, we have a loop.
By putting in this summary route to null zero,
this is covering the entire range we're advertising.
And essentially, what we're saying is,
if any traffic shows up for 100.100 dot anything,
if we don't have a more specific route to actually deliver it,
like these 4/24s that we have right now, just discard it.
This way, we're not going to try to send it back
over something like a default.
So again, this is critical for loop prevention.
And as we can see, OSPF puts this discard route
in the routing table for us automatically on the ABR
doing the summarization.
So now let's go back over to router 7
and see what this looks like on a router that's not the ABR.
So on router 7, we'll simply repeat the last command again.
But this time, notice that we have a 100.100.0.0/16 network.
That is, of course, our summary.
So now let's take a look at the effects this is going
to have on our convergence.
Remember, we saw previously that if a network flaps
on router 10, router 7 doesn't have to run Dijkstra.
But it does still have to update the routing table.
So we still saw updates coming in.
Let's go ahead and turn on our debug,
and let's go flap a network on router 10.
Let's just pick on loopback 110.
We'll shut this interface and jump back over to router 7.
Notice that absolutely nothing happened here in our debug.
This is the summary route, protecting us
from root flaps in the other area behind the summary.
And this is one of our main purposes.
Now something else to note while we're here--
if we look back up at our routing table for this summary,
notice that the metric on that summary is currently 3.
Because the next thing we want to look
at is how OSPF calculates the metric for the summary.
So to do this, let's go back over to router 10.
First thing we'll do is no shut the interface.
Then let's change the OSPF cost on some of these interfaces.
Since we're already under interface 110,
let's change this one to say a cost of 20.
We'll go in interface loopback 100.
We'll change this one to a cost of 10.
And then let's go into loopback 120.
We'll make this one to cost of 20 as well.
And we also have a loopback 130.
We'll make that one a cost of 30.
So these are the loopbacks that represent each of our networks.
So what we're doing is, we're setting them
all to different costs so we can see what happens.
Let's go back over to router 7.
Now the first thing to note here on router 7
is that we have, in fact, gotten SPF updates now.
This is because the metric on that route actually changed.
Let's take a look at our routing table again.
Notice that the metric on that route is now 12.
That means that it's actually using the loopback
with a cost of 10, plus there's two links between us and there.
So it's adding 2 to that.
But to summarize what it's doing here,
it's actually using the lowest metric
from the routes that are being summarized.
So of course, we set some to 10, some to 20, some to 30,
and it's using the 10.
It's, of course, also counting the other interfaces involved.
But overall, it's using the lowest cost
of the routes being summarized.
We can, of course, verify this by going back over the router
10, going into our interface loopback
100, which is the one with the lowest cost,
therefore the one that it would currently be using,
and shut this network down.
Now here's sort of a downside that we have to be aware of.
If we come back over here to router 7, notice,
we've gotten another update again.
Now we expected this behavior.
Because if we look at the route now, now it's 22.
So obviously, it has to send an update for that metric change.
But herein lies the problem.
The whole goal, or at least one of the major goals,
of doing this summarization was to prevent this.
We didn't want the device to receive updates
every time a route flaps.
And if they have different metrics,
that may very well still happen.
So one thing we might want to do to fix this
is to actually hard code the metric on the summary.
That way, if the routes behind the summary, particularly,
of course, the one with the lowest metric, were to fail,
we wouldn't still get this update
to we're trying to prevent.
So that might be a good practice that you
want to do in the real world.
To do that, of course, all we have to do
is go back over to router 6, go back to our area range command,
and simply set the cost.
We'll set it to 100.
Now this will, of course, cause one more update
to go into area 0.
So if we go back over to router 7,
we see that once again, we've gotten another update.
But hopefully, this should then be the last one,
regardless of what happens.
So again, if we look at the route now,
we see that it just flat out has a metric of 101, the 100 that's
being advertised plus our cost of 1 to get to router 6 itself.
Now if those networks on router 10 flap,
it won't change anything, even if they're a better cost.
Let's bring that interface back up on router 10.
Remember that this is the one with the best cost.
So theoretically, based on the normal rules,
this should now become the metric.
But of course, we know that it will not.
We see here on router 7 that we did not get an update.
Everything has been quiet, even though we had
a better route come back up.
Now of course, it's still going to have that cost of 101.
This isn't going to change now, regardless of what
those routes behind it do.
In this video, we took a look at how
to summarize internal routes in OSPF.
Some of our key takeaways-- remember,
we can only do this on the ABR.
It uses the area range command to accomplish this.
And by default, it will use the metric
from the lowest cost route that's being
summarized for the summary.
But to help increase stability, we
may want to go ahead and take care of that
ourselves by manually setting a metric on that summary.
I hope this has been informative for you,
and I'd like to thank you you for viewing.