An important piece of information for any routing protocol is the metric
the term metric refers to how to measure something.
For example, miles and kilometers are metrics that measure distance.
OSPF uses cost as its metric.
It determines that some links are better than others.
Better links cost less to get a packet to its destination.
Each router will run the SPF algorithm
to find the best paths through the network.
OSPF considers the path with the lowest cost to be the best.
The best paths are then offered to the routing table.
This is a pretty good system.
Unfortunately, there's a problem in modern networks.
But before we get to that, we need to understand how OSPF
calculates a links cost, and that is all about bandwidth.
Each link has a bandwidth.
For example, we have four links with bandwidth of ten Meg, 100 Meg.
one gig and ten gig.
In OSPF terms, the higher the bandwidth, the better the link.
There is also a reference bandwith. This, by default, is 100 Meg.
Back in the early days of OSPF 100 Meg was considered
to be a fast link. to calculate the cost of a link,
OSPF divides the reference bandwidth by the link bandwidth,
so the cost of a ten Meg link would be 100 divided by ten, which is ten.
The 100 Meg Link would be 100
divided by 100, which is a cost of one.
Now he's where it gets interesting.
The one gig link is 100 divided by 1000.
This should be 0.1.
But OSPF only uses whole numbers, so this cost turns out to be one.
The same thing happens on the 10Gig link.
Can you see the problem?
Modern networks have links much faster than 100 Meg,
but the cost of them always comes out to one.
Let's go back to the original topology now.
Before I didn't show you the bandwidth of the links, only the costs.
Let's add the bandwidth now.
See how the path that OSPF selected is not the best path?
The best path should use the ten Gig links,
but because the cost of each link is one,
the best path has a total cost of four.
This is a higher cost than the worst path, which has a cost of two.
So we need to do something about this.
The solution here is changing the reference bandwidth.
Let's connect to our router and see how it's done.
Before we change anything, let's check the current reference bandwidth.
There's no guarantee that it's at the default settings
because someone else could have come along and change it for us.
So to do that, we use show IP OSPF.
Here is where we see this value,
and this confirms there's 100 Meg.
Any of Cisco's Routers or switches running IOS
will use 100 Meg by default.
Other vendors and even some of Cisco's datacentre
range of switches may have a different value.
I'm now using show IP route of SPF
to see only the routes that OSPF has learned.
Do you remember which value was the metric?
It's the second value in the square brackets,
so the costs here are two, two and three.
Keep that in mind and we'll see how they change later.
Now, to change the reference bandwidth,
we do this under the router OSPF configuration hierarchy.
The command we use is auto cost
reference bandwidth, then followed by our value.
The value is in megabits per second
all into 1 million, which is a terabit.
I've chosen a really high value as it's much higher than any of our links.
Now, as the router here says, this value needs to be
consistent across all of our routers.
We can then confirm this change with show
IP, ospf
It has definitely been updated,
which is very good.
And looking at the routes
again, we see much higher costs.
So we know the change we've made has worked.
If we make this change to the routers in our topology,
the costs would now look like this.
Big difference, right?
How might this scenario change things?
There are two routers at different sites
connected by a 100 Meg WAN link.
They connected this link with Gigabit0/0 interfaces.
Now, how will this affect OSPF?
Based on the defaults, OSPF will assume
that there is one Gig of bandwidth between these sites.
It has no way of knowing what the service providers limit is.
So it will base the cost on one gig of bandwidth.
This is inaccurate, and depending on the rest of the network,
it may lead to poor routing decisions.
So we can tune this by telling the router the real bandwidth of the link.
Under the interface, we can enter
bandwidth 100.
When we look
at the interface again, we can see that the bandwidth has changed.
Unfortunately, I said it to 100 kilobits and 100 megabits, but you
get the picture, I'm sure.
I want to be clear about one thing, though
the bandwidth command only supplies the router with more information.
It does not change the actual bandwidth of the link.
On occasion, the reference
bandwidth and the bandwidth statement won't meet our needs.
In a case like this, we can set the cost on an interface manually.
We might see this if there's a fault on a link,
and we would prefer to use a more reliable path.
Or maybe it's a backup link, and we only want to use it if necessary
in cases like those, we can set the OSPF cost on the interface to be really high.
This would cause some other path to be preferred.
Under the interface, we can use
the IP OSPF cost command.
In this case, I'm setting the cost to 5000.
You can put these new skills into practice here.
Work out the cost and each link and then the path that
R1 will take to each destination.
Let's go back to network advertisements for a bit.
We need to lock in in some key concepts.
We're going to configure OSPF for the topology shown here.
There are two routers connected with two links.
There is an extra network per router.
The first thing is to get OSPF
running and form an adjacency.
We'll start on R1 using process I.D. ten.
We'll also set a router ID, as a matter of best practice.
Next, we'll use the network command
to enable OSPF on our interfaces.
Notice that the wildcard mask covers both interfaces in a single command.
We're telling the router to enable OSPF on any network interface
with an IP that starts with 172.16.1
He's the key point.
The network command does two things
it enables OSPF on network interfaces identified by the network
and wildcard mask, and it advertises any connected
networks identified by the network and wildcard mask.
So in this case, this means that the router enables
OSPF on the two interfaces that connect to R2.
They will then start sending hello messages.
It also means that 172.16.1.0 /30
and 172.16.1.4 /30 will be advertised.
That's because their networks configured on the local router.
While we're here, let's at our other network.
192.168.10.0 /24 into OSPF.
We'll move over to R2 and repeat the process there
that's starting OSPF.
Setting a router ID.
And adding networks.
Sorry, I added the wrong network there. to remove that config,
We enter the same command with a 'no' in front. Then, I'll add the right command.
That looks better.
The adjacency has come up.
We have another network to add.
Of course.
And to confirm
we can look at the OSPF neighbor list.
Here we have one neighbor, but two neighbor relationships.
We know it's the same router, because of the router I.D.
Let's see these in the routing table.
He's the route learned from R1.
Notice that there's two next hops.
That's because of the two links, each with the same cost.
That's equal cost multi or ECMP in action.
Cisco routers will allow up to four equal cost next hops
per path in the routing table by default.
If the links have different costs, then only the best one is selected.
In a case like this, both the links will share the load.
We can
compare that to the entries in the LSDB.
Notice that there's an entry for each of the two routers.
There's also entries for each of the two links.
The other networks,
192.168.10 and 192.168.20
are not listed here.
The LSDB doesn't include these as they're not paths
through to other networks.
With that in mind, here's an interesting point.
When we use the network command, we do two things.
Enable OSPF on an interface which includes sending and receiving
hello messages and advertise the network
on that interface to other routers.
What if we want to advertise a network,
but we don't want an interface to send hellos?
In our example, let's say we want to advertise one or 192.168.20.0,
but we don't want that interface trying to form an adjacency with another router.
In this
case, we can configure this interface as a passive interface.
This prevents OSPF from sending home messages
on that interface, but it still advertises.
Let's see what would happen if we configured gig0/0 as a passive interface.
That's the link with the 172.16.1.0 network.
Under the router OSPF config.
We use the passive interface command.
Straightaway,
we see that our neighbor relationship over that link drops.
That's because it's no longer active.
So there can't be an adjacency there.
It's easy confirm this by looking at our list of neighbors.
Before, we had two adjacencies, but now there's only one.
If we go over to the routing table,
the route to 192.168.10.0
now only has one next hop.
This leads to an obvious question,
when would we want to use passive interfaces?
Wouldn't it be better to have all possible interfaces working in OSPF?
I'll leave you to think about that one.
When it comes to advertising networks in any routing protocol,
there is one key rule for a router to advertise a network.
It must first be in the routing table.
Now, why is that a rule?
Because when a router advertises a network, it's saying,
I know how to get to this location.
There are two ways a router will know about a network.
one, if it's connected to the router or two, if it's learned
from another source, another source, for example, being a static route.
In both cases, that network will be in the routing table.
The default route, though, is a little special.
It is 0.0.0.0/0
And we will never have an interface with an IP like this.
So how can
we advertise the default route to another router?
first, remember our rule.
It needs to be in the routing table.
There's a small exception to this, which we'll take a look
at later.
In this topology, the simplest option is to add
a static route to R1. As we've seen in other videos.
This uses the IP route command.
For the next hop, we'll use 192.168.10.2.
This would usually be an IP address that your internet
provider would give you.
When we look at the routing table, we now have a default route.
It's type of static that's step one complete
if we look over at R2,
We see that this has not yet made a difference.
There's no default route.
Even though R1 and R2
are OSPF neighbors, R1 does not automatically share the default route.
You've got to tell OSPF to share it.
We do this under router OSPF configuration area.
Then we want to use a magical command,
defaults-information originate.
This command redistributes the default route into OSBF,
allowing it to be advertised.
Redistribution is taking a route from one location
and placing it in another routing protocol.
In this case, we have a static route and we're redistributing it into OSPF.
Redistribution is a much bigger topic that you'll see if you go on
to the CCNP exams. For now, this is just a very small introduction.
If we take a look at the routing table on R2, again,
we'll see that it's got a default route.
The protocol code next to it is interesting.
It says, O*E2
'O' means that it's an OSPF learned route.
The star means it's a default route
and E2 means that this route was redistributed
into OSPF from an external source that is, in this case, a static route.
So whenever you see E1 or E2, you know that
it was redistributed into OSPF.
So we know that the rule is
that networks must be in the routing table to advertise them.
Although I did say there was an exception.
Take a look at quiz question nine.
Put in a little bit of research
of your own and see if you can work out how it's done.
For today's lab, you're going to optimize OSPF. All the routers are working.
But they could be better.
You can take the skills
you've gained over the last few videos and work through it.
I know you can do it.
We've covered OSPF pretty well now. In the next video,
we're going to get started with quality of service.
This is where we can prioritize different traffic types.
I hope to see you there.