|
0:00:13
|
The next topic we're gonna look at here in OSPF
|
|
0:00:17
|
is how it does its path selection both for intra-area routes, inter-area routes,
|
|
0:00:23
|
and then external routes both the types 1 and 2 and the not-so-stubby types 1 and 2.
|
|
0:00:30
|
Now, at this point, we looked at...
|
|
0:00:31
|
how we enable the process, how we deal with the different issues of adjacencies
|
|
0:00:36
|
running over the different medias.
|
|
0:00:38
|
So, at this point, we should have the databases synchronized
|
|
0:00:41
|
throughout everyone in the topology.
|
|
0:00:45
|
Now, inside the router LSA, we also saw
|
|
0:00:48
|
the devices are gonna be describing all of their attached links,
|
|
0:00:51
|
and what are the cost attributes for those.
|
|
0:00:54
|
So, just like RIP of EIGRP, OSPF is gonna do the path selection
|
|
0:00:59
|
simply based on the lowest end-to-end cost to each of the paths.
|
|
0:01:04
|
Now, per the RFC, the cost value techically isn't defined.
|
|
0:01:09
|
It could be used as a hop count.
|
|
0:01:10
|
Or it could be used as a bandwidth value.
|
|
0:01:12
|
In the case of Cisco's implementation,
|
|
0:01:15
|
they use a reference bandwidth of a hundred megabits per second
|
|
0:01:18
|
to derive the cost of the link.
|
|
0:01:22
|
Now, in today's networks, since we're typically using links that are of a higher speed that a hundred megabits per second,
|
|
0:01:28
|
it would make sense to change the reference bandwidth
|
|
0:01:31
|
so that links that are above a hundred megabits per second all do not have a cost of 1.
|
|
0:01:37
|
So typically, the reference bandwidth would be set to 10 gigabits per second,
|
|
0:01:42
|
or a hundred gigabits per second so that we can tell the difference
|
|
0:01:46
|
between the higher speed links. Like the GigE, the OC48, OC192, etc,
|
|
0:01:51
|
Now, when we go to do the path selection,
|
|
0:01:55
|
we also need to take into account what type of route are we looking at
|
|
0:01:58
|
when we're comparing the different paths.
|
|
0:02:02
|
So, regardless of what the metric or the distance is to a particular destination,
|
|
0:02:06
|
OSPF is always gonna choose the intra-area routes over the inter-area routes,
|
|
0:02:12
|
then over external 1 and 2, and NSSA 1 and 2.
|
|
0:02:19
|
Now, of course, we still will use the longest match routing principle in the routing table
|
|
0:02:24
|
to figure out where the traffic is actually gonna go,
|
|
0:02:27
|
but if we have equal longest matches,
|
|
0:02:30
|
and one of them was an intra-area route, one of them was as external route or an inter-area route,
|
|
0:02:36
|
then, we would always choose the intra-area path.
|
|
0:02:40
|
So, regardless of the metric, regardless of the distance.
|
|
0:02:43
|
There's no way that we can modify this
|
|
0:02:45
|
because we need to make sure that all of the devices in the network
|
|
0:02:48
|
come up with the same shortest path tree
|
|
0:02:50
|
based on the input of the link state database.
|
|
0:02:55
|
Previously, in the examples I was showing,
|
|
0:02:57
|
we were using just a single area in OSPF in the entire diagram.
|
|
0:03:01
|
So now, I've modified this a little bit so that we have a multi-area design,
|
|
0:03:07
|
where over the frame-relay link between routers 1, 2 3, 4, and 5,
|
|
0:03:12
|
we're running area zero.
|
|
0:03:13
|
We also have area zero on the point-to-point serial links between 4 and 5, 1 and 3 and 2 and 3,
|
|
0:03:20
|
then, we see we have some other various areas 1, 2, and 51
|
|
0:03:25
|
that are going to... 51 down at the bottom is the connection between router 2 and BB2.
|
|
0:03:33
|
Then also, router 4 and 6, we have some external routing domains.
|
|
0:03:37
|
Router 4 is running RIP with BB3.
|
|
0:03:39
|
Router 6 is running EIGRP with BB1.
|
|
0:03:42
|
And on both of those points, we're also doing redistribution.
|
|
0:03:46
|
So, let's take a look at the network now from router 5's perspective.
|
|
0:03:51
|
And we'll see how the database has changed
|
|
0:03:53
|
and what principles router 5 is using in order to do its path selection.
|
|
0:03:59
|
So, we could see here on router 5 from the output of the...
|
|
0:04:02
|
Show IP OSPF Interface Brief.
|
|
0:04:05
|
Some of these links are running in area zero,
|
|
0:04:07
|
some of the links are running in area 2.
|
|
0:04:10
|
This means that router 5 is now an area border router
|
|
0:04:13
|
so it should be generating two separate router LSAs.
|
|
0:04:18
|
One for area 2 and one for area zero.
|
|
0:04:22
|
Additionally, any routes that are learned in the area 2 links,
|
|
0:04:26
|
those will be sent into area zero using the LSA type 3,
|
|
0:04:32
|
which is the network summary LSA.
|
|
0:04:35
|
Now, this is considered a summary,
|
|
0:04:37
|
because we are not summarizing the network layer reachability information.
|
|
0:04:42
|
So, the actual prefixes.
|
|
0:04:43
|
But instead what we are summarizing is the topology information.
|
|
0:04:49
|
So, we'll see that when we look at the difference between an intra-area lookup and an inter-area lookup,
|
|
0:04:55
|
for the intra-area lookups, we are gonna run SPF to every destination.
|
|
0:05:00
|
But for the inter-area lookups between the areas, we will use the SPF cost that we derived to the are border router
|
|
0:05:08
|
plus whatever value they are reporting in with the summary LSA.
|
|
0:05:14
|
So, on router 5, now, let's look at the Show IP OSPF Database.
|
|
0:05:19
|
We see, the first portion of the output defines what are the routers in area zero.
|
|
0:05:24
|
These are routers 1 through 5
|
|
0:05:27
|
with these respective number of links in area zero.
|
|
0:05:33
|
So, router 5, we see it has a large number of links,
|
|
0:05:37
|
because we have the frame-relay network configured as point-to-multipoint.
|
|
0:05:41
|
So, each of the adjacencies to routers 1, 2, 3, and 4 count as separate links in the database.
|
|
0:05:48
|
We'll also see that we have the loopback, the point-to-point link to router 4,
|
|
0:05:53
|
plus the actual address on the point-to-point link to router 4,
|
|
0:05:57
|
and our connection to the frame-relay network.
|
|
0:06:01
|
So again, OSPF does separate the difference between a link that is used to connect to an adjacency.
|
|
0:06:06
|
And then one that has the actual prefix assigned to it.
|
|
0:06:12
|
We see, next, we have the summary...
|
|
0:06:14
|
network link states.
|
|
0:06:16
|
These are the inter-area routes that are generated by the area border routers.
|
|
0:06:23
|
Now, notice between the first portion of the output and the second,
|
|
0:06:27
|
we no longer see any network link states.
|
|
0:06:31
|
This means that in area zero,
|
|
0:06:34
|
there are no designated routers on that in any segments.
|
|
0:06:38
|
Because the serial links are running as network type point-to-point.
|
|
0:06:41
|
The frame-relay is running as point-to-multipoint.
|
|
0:06:44
|
None of these are running the designated router or backup designated router election.
|
|
0:06:51
|
So normally, we would see another field between these two that said the network link states,
|
|
0:06:55
|
that would be the designated routers.
|
|
0:06:59
|
So, the summary network link states, this is LSA Type-3.
|
|
0:07:02
|
These are used to describe the inter-area routes.
|
|
0:07:06
|
Now, we see, some of them are duplicates, because we have multiple ABRs
|
|
0:07:10
|
that can reach the same portion of the network.
|
|
0:07:13
|
The first one we see, we have multiple paths to get to router 6's loopback.
|
|
0:07:19
|
One of these is via router 1, one of these is via router 3.
|
|
0:07:25
|
Now, when we actually do the lookup
|
|
0:07:27
|
to get towards router 6's loopback,
|
|
0:07:30
|
router 5 internally is gonna say Show IP OSPF Database.
|
|
0:07:34
|
And look for the summary LSA 150.42.6.6.
|
|
0:07:42
|
It says, inside area zero,
|
|
0:07:45
|
there are two possible paths to reach this destination.
|
|
0:07:49
|
One of them is being originated by...
|
|
0:07:52
|
router 1.
|
|
0:07:53
|
One of them is being originated by router 3.
|
|
0:07:56
|
We see the one that router 1 is advertising has a metric of 2.
|
|
0:08:00
|
Router 3 is advertising a metric of 3.
|
|
0:08:03
|
Based on this output, we really can't tell which path we're actually gonna choose.
|
|
0:08:07
|
We would then need to look at what is the SPF cost inside our own area
|
|
0:08:14
|
in order to reach these area border routers.
|
|
0:08:18
|
This is the behavior that sometimes is describes as OSPF being distance vector,
|
|
0:08:24
|
because this inter-area lookups
|
|
0:08:27
|
do not have full visibility of the end-to-end topology.
|
|
0:08:32
|
So, beyond router 1 and beyond router 3,
|
|
0:08:35
|
they are summarizing the topology information
|
|
0:08:38
|
where we don't know the exact path by path or link by link basis that they're going through
|
|
0:08:43
|
in order to reach this particular destination.
|
|
0:08:46
|
The only thing that router 5 knows
|
|
0:08:49
|
is that router 1 and router 3 are advertising these paths to me,
|
|
0:08:52
|
and they are ABRs that are part of my area zero.
|
|
0:08:56
|
So then, we would look at what is our SPF cost in order to reach 3 and 1.
|
|
0:09:02
|
Add this to whatever the metric that they area advertising,
|
|
0:09:07
|
this would then be the total cost that we would install in the routing table.
|
|
0:09:13
|
So, whichever one is gonna be the shorter
|
|
0:09:15
|
cost of what they are reporting plus our metric to them,
|
|
0:09:19
|
that's what's actually gonna get installed in the routing table.
|
|
0:09:23
|
There's a question here, "So, on this output, the 2 and 3 are the metric to get to the ABRs.
|
|
0:09:28
|
This is the metric that they are reporting in."
|
|
0:09:32
|
So, if I were to look at router 1's routing table,
|
|
0:09:35
|
and say...
|
|
0:09:36
|
Show IP Route 150.42.6.6.
|
|
0:09:43
|
Router 1 is using a metric of 2.
|
|
0:09:46
|
From router 3's perspective, if we Show IP Route....
|
|
0:09:51
|
150.42.6.6.
|
|
0:09:54
|
Router 3 is using a metric of 3.
|
|
0:09:56
|
So, this is what they have locally calculated in their topology
|
|
0:10:00
|
what their end-to-end cost is.
|
|
0:10:02
|
Then, they are advertising this to router 5.
|
|
0:10:06
|
So, from this output of the summary LSA, we don't actually know which path are we gonna choose.
|
|
0:10:11
|
We would then need to correlate this with the advertising router
|
|
0:10:14
|
to figure out what is our cost to get to router 1 and router 3,
|
|
0:10:19
|
add that to the metric that they are reporting,
|
|
0:10:23
|
that would then be out total cost to reach the neighbor.
|
|
0:10:28
|
Now, the way that router 5 does this...
|
|
0:10:31
|
is it first needs to know what is the graph of my network
|
|
0:10:34
|
in order to get to router 2, and...
|
|
0:10:38
|
or not router 2, router 1 and router 3.
|
|
0:10:40
|
So, router 5 is going to be the root of the shortest path tree.
|
|
0:10:45
|
So, it first need to know who are my neighbors that I'm adjacent with.
|
|
0:10:50
|
So internally, router 5 would say, Show...
|
|
0:10:54
|
IP OSPF Database...
|
|
0:10:57
|
for the router LSA that I am generating.
|
|
0:11:04
|
So here, 150.42.5.5, this is the router ID of router 5.
|
|
0:11:11
|
Router 5 says that it is adjacent with router 1.
|
|
0:11:16
|
And it is directly adjacent with router 3.
|
|
0:11:20
|
Since both of these connections are going over the same interface,
|
|
0:11:23
|
we see that they're both gonna have the same metric value of 64.
|
|
0:11:30
|
Since we're directly connected to these neighbors,
|
|
0:11:32
|
essentially, that's where the search is gonna end.
|
|
0:11:35
|
So, we don't need to go any further we know that we are directly connected to them.
|
|
0:11:38
|
This is gonna be the lowest cost to reach these neighbors.
|
|
0:11:41
|
With the metric of 64 on the connected serial link.
|
|
0:11:46
|
So, we would take the result of these.
|
|
0:11:48
|
Add this to what we previously saw in the summary LSA output.
|
|
0:11:54
|
So therefore, whichever is lower of 2 plus 64
|
|
0:12:00
|
versus 3 plus 64,
|
|
0:12:03
|
that's what router 5 should be installing in the table.
|
|
0:12:07
|
So, if we'll now look at the Show IP Route 150.42.6.6,
|
|
0:12:11
|
we should see that the total cost is 66.
|
|
0:12:15
|
And the neighbor we're using to route there is router 1.
|
|
0:12:20
|
So, if we Show...
|
|
0:12:24
|
Show IP Route 150.42.6.6,
|
|
0:12:29
|
it says, "The total metric is 66, and we're routing towards router 1 to get there."
|
|
0:12:35
|
Now, if there more diverse paths in the network,
|
|
0:12:38
|
we don't necessarily have to be using this directly connected link in order to get to router 1.
|
|
0:12:43
|
It's gonna be whatever from router 5's perspective is the shortest path to get to that particular neighbor.
|
|
0:12:50
|
So, we could have a potential case where maybe router 5 is routing to 2,
|
|
0:12:55
|
then, from 2 to 3, then, from 3 to 1 to get to the destination.
|
|
0:13:02
|
It really depends on what is our internal SPF cost to get to the neighbor.
|
|
0:13:07
|
Plus whatever value that they are reporting in.
|
|
0:13:12
|
Now, from a traffic engineering point of view, if we wanted to modify the path selection,
|
|
0:13:16
|
we essentially now have two different options.
|
|
0:13:19
|
We could change the value that router 1 is reporting in,
|
|
0:13:24
|
which right now, it's reporting a value of 2.
|
|
0:13:27
|
And router 3 is reporting a value of 3.
|
|
0:13:30
|
Or we could change our local SPF cost in order to reach them.
|
|
0:13:36
|
As long as the end-to-end metric when we add up all the paths along the way,
|
|
0:13:41
|
is the lowest end-to-end value, that's what we're gonna prefer.
|
|
0:13:46
|
Now, if for some reason, we had a directly connected link
|
|
0:13:48
|
between router 6 and router 5.
|
|
0:13:55
|
And this was running area zero.
|
|
0:13:58
|
We would then always prefer that path
|
|
0:14:01
|
over any other alternate path regardless of what the metric or what the distance is.
|
|
0:14:07
|
Because in the path selection state machine,
|
|
0:14:09
|
OSPF says, "We have to prefer the intra-area routes,
|
|
0:14:13
|
because we're actually doing a full SPF run on those."
|
|
0:14:17
|
For the inter-area routes, we run SPF to get to the ABR,
|
|
0:14:21
|
the, we're assuming that the ABR has run SPF to get to the destination,
|
|
0:14:25
|
or to some other intermediate neighbor that's advertising it to them.
|
|
0:14:31
|
Now, the case where that would be true,
|
|
0:14:33
|
if we were looking at this cost from the perspective of switch 4.
|
|
0:14:38
|
Switch 4 would say that "To get to router 6's loopback, I need to calculate what is my cost to router 5 as the ABR."
|
|
0:14:46
|
Then, router 5 says, "To get to 6, I need to calculate the cost to either 1 or 3.
|
|
0:14:52
|
Whichever is lower plus what they are advertising,
|
|
0:14:56
|
that's the neighbor that I'm gonna forward through."
|
|
0:15:00
|
But the key point being here that for the inter-area lookup,
|
|
0:15:03
|
the routers do not know what is going on in the topology beyond the ABR.
|
|
0:15:09
|
And this is one of the scalability features of OSPF
|
|
0:15:12
|
that the inter-area routing is going to terminate the flooding domain.
|
|
0:15:18
|
So, this means that if there is a change in the cost of router 6's link,
|
|
0:15:22
|
or an alternate path is going towards it,
|
|
0:15:26
|
it doesn't mean that router 5 needs to calculate SPF,
|
|
0:15:29
|
it would just need to take into account what are the new cost values that the ABRs are sending to me.
|
|
0:15:37
|
So, let's say for example that router 1 looses the link that goes to router 6.
|
|
0:15:43
|
This would the means that router 2 would have to withdraw this advertisement to get to 6,
|
|
0:15:48
|
and router 5 will ultimately prefer the only path that's left,
|
|
0:15:51
|
which is the one that's from router 3.
|
|
0:15:56
|
So, from router 5's perspective, let's look at the...
|
|
0:15:59
|
the change in the path.
|
|
0:16:02
|
So right now, if we were to trace 150.42.6.6,
|
|
0:16:08
|
right now, it's going through router 1.
|
|
0:16:10
|
If we look at the Debug IP OSPF SPF,
|
|
0:16:16
|
then, on router 1, I'm gonna shut my link down that is connecting to router 6.
|
|
0:16:22
|
Which is Fast Ethernet 0/0.
|
|
0:16:26
|
We'll see that on router 5,
|
|
0:16:30
|
and this is a very noisy debug. The Debug IP OSPF SPF.
|
|
0:16:34
|
Normally, you would wanna send this to the buffer. Not to the console.
|
|
0:16:41
|
So, this is the actual calculation that is going through for the SPF algorithm.
|
|
0:16:45
|
But if we look at what has changed,
|
|
0:16:49
|
it says that "Router 1 says that there's a change in this particular link state ID."
|
|
0:16:54
|
It says that "Now, to get to...
|
|
0:17:04
|
To get to this prefix, we now have a better path to get to router 3."
|
|
0:17:10
|
But the difference is that we're doing what's known as the "Partial Route Calculation", or a PRC.
|
|
0:17:16
|
We're not actually doing a full SPF run in order to reach them.
|
|
0:17:21
|
Because what has not changed here is the SPF cost to reach the ABRs.
|
|
0:17:27
|
Only what has changed is what is they're reporting into the area.
|
|
0:17:30
|
So, when router 5 looks at the Show IP OSPF Database and looks at its own router LSA,
|
|
0:17:37
|
the cost to 1 is still 64.
|
|
0:17:41
|
And the cost to router 3 is still 64.
|
|
0:17:44
|
The only thing that has changed is what they are reporting into the area.
|
|
0:17:47
|
So now, if we look at the Show IP OSPf Database for the summary LSA of router 6,
|
|
0:17:54
|
we could see that now, in area zero, there's only one possible path.
|
|
0:17:58
|
And this is going through router 3.
|
|
0:18:03
|
So, there is a recalculation that's done.
|
|
0:18:05
|
But it's different than a normal SPF run. It's called a "Partial Route Calculation", or a PRC.
|
|
0:18:11
|
So, if for any inter-area or external change, we're gonna do the partial recalculation.
|
|
0:18:17
|
for any change that is inside the area,
|
|
0:18:20
|
we would have to do a new SPF run.
|
|
0:18:23
|
So, from a scalability point of view,
|
|
0:18:25
|
it's better to design OSPF with the multiple areas,
|
|
0:18:29
|
instead of putting everyone just in a giant area zero.
|
|
0:18:35
|
So, let's now say we wanna change what the path is
|
|
0:18:39
|
that we're using to route to this particular destination.
|
|
0:18:43
|
So, with the previous default...
|
|
0:18:46
|
configuration, router 5 is saying, "I have a cost of 64 to get to router 1.
|
|
0:18:51
|
And router 1 is reporting a cost of 2 in.
|
|
0:18:54
|
Then likewise, I have a cost of 64 to reach router 3
|
|
0:18:57
|
and they're reporting a cost of 3."
|
|
0:19:00
|
Now, configuration wise, there's a lot of different ways that we can influence this.
|
|
0:19:04
|
The ultimate goal is that we're trying to change the cost of what the end-to-end path is between the neighbors.
|
|
0:19:10
|
Now, since the cost is based on the interface's bandwidth,
|
|
0:19:14
|
it implies that if we were to change the bandwidth,
|
|
0:19:16
|
it then would inherently change the cost.
|
|
0:19:19
|
The only disadvantage of doing this with the interface level bandwidth command
|
|
0:19:23
|
is that that statement is used to affect other operations in the network
|
|
0:19:27
|
like QoS calculations.
|
|
0:19:30
|
So typically, if we were doing traffic engineering for OSPF,
|
|
0:19:34
|
it would make more sense just to change the OSPF cost directly,
|
|
0:19:40
|
but technically, we have these other methods to do it.
|
|
0:19:43
|
We could change the bandwidth, which inherently changes the cost.
|
|
0:19:46
|
We could change the cost directly,
|
|
0:19:48
|
we could change the actual calculation,
|
|
0:19:51
|
where auto-cost is changing what the reference bandwidth is.
|
|
0:19:56
|
Where if the reference bandwidth is a hundred megabits per second,
|
|
0:19:59
|
and our interface bandwidth is a hundred megabits per second,
|
|
0:20:02
|
then, the result of that would be a cost of 1.
|
|
0:20:07
|
So, if we wanted to change the calculation to take into account the larger scale links,
|
|
0:20:11
|
let's say that we wanna change the cost so that a 20 GigE link
|
|
0:20:19
|
would be a cost of 1, or...
|
|
0:20:24
|
Right. Let's say, 20 gigabits per second is gonna be a cost of 1. Not 20 GigE, but 20 gigabits per second.
|
|
0:20:32
|
Now, we could just run through the actual calculation and figure out what value is gonna work.
|
|
0:20:37
|
Or we could just use the show commands on the router to kind of work backwards from there,
|
|
0:20:43
|
really, the preference is up to you.
|
|
0:20:45
|
Okay, the difference is that you would have to remember what the...
|
|
0:20:49
|
the calculation is, the cost equals the reference bandwidth over the interface bandwidth.
|
|
0:20:54
|
We could get the same result just by trial and error on the command line.
|
|
0:20:59
|
So, if I were to go to router 5,
|
|
0:21:02
|
and let's say that on...
|
|
0:21:04
|
our Fast Ethernet 0/0 link.
|
|
0:21:08
|
I'm gonna change this to a 20 gig link,
|
|
0:21:13
|
and we'll see what the result of the bandwidth is.
|
|
0:21:17
|
Or result of the cost is.
|
|
0:21:19
|
So, on this link, let's say the bandwidth...
|
|
0:21:22
|
is in kilobits per second. So, 2000 would be 2 megabits per seconds.
|
|
0:21:28
|
20 megs, 200 megs, 2 gigs and 20 gigs.
|
|
0:21:33
|
So, it actually...
|
|
0:21:36
|
It's not gonna support that then...
|
|
0:21:37
|
The...
|
|
0:21:40
|
maximum is 10 gigs then.
|
|
0:21:47
|
Alright. So, that's 1 megabit, 10 megs, 100 megs, 1 gig, and 10 gigs.
|
|
0:21:52
|
So, let's rework this calculation then. Let's say that we want...
|
|
0:21:57
|
a 10 gig link to be a cost of 5.
|
|
0:22:02
|
So then the...
|
|
0:22:05
|
the higher speeds would still have a value that we could go below that.
|
|
0:22:10
|
So first, I'll just change the bandwidth. So, this is now gonna be representative of a 10 gig link.
|
|
0:22:16
|
If we Show IP OSPF Interface Fast Ethernet 0/0 and include the cost.
|
|
0:22:24
|
The cost value right now should be 1.
|
|
0:22:26
|
Because anytime we go above a hundred megabits per second,
|
|
0:22:29
|
everything is gonna be a cost of 1.
|
|
0:22:32
|
So, OSPF doesn't use...
|
|
0:22:34
|
any fractions or decimals for the calculation. It has to be a whole number.
|
|
0:22:40
|
So, under the OSPF process, I'm now gonna change the auto-cost reference bandwidth.
|
|
0:22:45
|
Let's say I'm just gonna send it to be the maximum.
|
|
0:22:50
|
The result of this now...
|
|
0:22:52
|
is that the cost is 429.
|
|
0:22:57
|
So, we know that's gonna be too high. I wanna get it to be a cost of 5.
|
|
0:23:02
|
So, let's say I take the rest of the numbers at the end.
|
|
0:23:05
|
Let's make it...
|
|
0:23:09
|
4 million.
|
|
0:23:11
|
As the round numbers... 4 million? Right.
|
|
0:23:14
|
Okay, so 4 million then is a cost of 400.
|
|
0:23:20
|
So, if we were to cut this in half, let's say, 2 million.
|
|
0:23:25
|
It is a cost of 200.
|
|
0:23:27
|
So, you could work down from there.
|
|
0:23:28
|
You could just look at what is the actual calculation,
|
|
0:23:33
|
but if you see, basically just with trial and error, you can get to whatever value that you need.
|
|
0:23:38
|
Okay, so now, with the reference bandwidth of 50,000 megabits per second,
|
|
0:23:43
|
a 10 gig link would then be a cost of 5.
|
|
0:23:47
|
Now typically, you would want to change this everywhere,
|
|
0:23:50
|
because if you don't, they're not gonna agree on what the topology looks like,
|
|
0:23:54
|
and you could have failures in the SPF calculation.
|
|
0:23:59
|
So, I'll just send this to everyone.
|
|
0:24:03
|
We'll say that...
|
|
0:24:05
|
under the OSPF process,
|
|
0:24:08
|
I'm changing the reference bandwidth.
|
|
0:24:15
|
So typically, in today's networks, you would want to change this.
|
|
0:24:19
|
Because otherwise, anything over a hundred meg is gonna be the same as a cost of 1.
|
|
0:24:24
|
And ideally, you would wanna prefer your gig, or 10 gig links, or OC48
|
|
0:24:28
|
over Fast Ethernet, or over OC3.
|
|
0:24:35
|
So now, if we look at router 5,
|
|
0:24:37
|
and Show IP OSPF Interfaces,
|
|
0:24:40
|
we'll see that the other links that I did not change, these are gonna have much higher cost values now.
|
|
0:24:46
|
So, the point-to-point serial link now is a cost of 32,000.
|
|
0:24:50
|
Same with the frame-relay.
|
|
0:24:54
|
And the Fast Ethernet, this is a cost of 5.
|
|
0:24:57
|
Okay, that's because I changed the bandwidth value.
|
|
0:25:02
|
Now, if we look at the result of this in the database,
|
|
0:25:05
|
let's now say, what is...
|
|
0:25:08
|
the...
|
|
0:25:10
|
the path to the summary LSA?
|
|
0:25:14
|
We can see now that router 1 and 3 are reporting metrics of 501 and 551.
|
|
0:25:21
|
If I look at what my metric is to reach them, it's gonna be the same as before.
|
|
0:25:25
|
It's not gonna be the same value, but it's gonna be the same between the two of them,
|
|
0:25:28
|
because I'm using the same interface to reach both 1 and 3.
|
|
0:25:33
|
So, if I didn't want to route the traffic to 1,
|
|
0:25:36
|
if I wanted to route it to 3, I could simply go to 1,
|
|
0:25:39
|
and then, increase its metric to the path.
|
|
0:25:43
|
So on router 1's link to router 6, I'll say that this has a cost of...
|
|
0:25:50
|
a thousand.
|
|
0:25:51
|
Or we'll actually look what it is currently.
|
|
0:25:55
|
And we'll change it based on that. So, let's say Show IP OSPF Interface Fast Ethernet 0/0,
|
|
0:26:01
|
and look for the cost.
|
|
0:26:03
|
Okay, right now, it's 500.
|
|
0:26:04
|
So, if I say that the IP OSPF cost is a thousand.
|
|
0:26:10
|
Then, we should see now in the summary LSA.
|
|
0:26:14
|
This should change the value that router 1 is advertising.
|
|
0:26:18
|
It's not gonna change my metric to get to 1.
|
|
0:26:21
|
It's changing what's 1's metric is to get to the destination.
|
|
0:26:28
|
So now, we see that router 1 is reporting 1001.
|
|
0:26:34
|
So, if 1001 plus are local metric,
|
|
0:26:38
|
to reach router 1 is higher than 551 plus the local metric,
|
|
0:26:42
|
then, we should start to prefer the alternate path.
|
|
0:26:46
|
So now, if we look at the result in the routing table, let's Show IP Route for 150.42.6.6,
|
|
0:26:57
|
we see that now, we're using router 3.
|
|
0:26:59
|
So, if we trace to the destination,
|
|
0:27:07
|
we see that these packets now go to router 3 first
|
|
0:27:11
|
as opposed to going to router 1.
|
|
0:27:15
|
So, as compared to EIGRP, the path selection is pretty straightforward in OSPF,
|
|
0:27:20
|
because we're simply adding the value on a hop-by-hop basis.
|
|
0:27:23
|
The key point to remember though
|
|
0:27:26
|
is that if it is a different type of route,
|
|
0:27:29
|
there is no way that we can change that.
|
|
0:27:31
|
So, if router 5 had an intra-area route versus an inter-area route,
|
|
0:27:38
|
even if somehow the inter-area route's cost was lower,
|
|
0:27:43
|
then, we would have to still take the intra-area route.
|
|
0:27:48
|
So, it pick the O over the OIA.
|