- [Instructor] In this video, we want to talk
about some fundamental concepts surrounding OSPF.
First, OSPF is an open standard.
Now, we could argue
that today, EIGRP is also an open standard
after Cisco started opening it up
to the industry back around 2010 is
when they started doing that,
but OSPF, it's always been an open standard
and therefore it seems
to be the most popular interior gateway protocol
we're going to run into,
especially in mixed vendor environments.
And while EIGRP was a distance-vector, specifically,
an advanced distance-vector routing protocol,
OSPF has a link state routing protocol.
Here's the difference?
Think about what a vector is.
A vector gives you magnitude and direction.
You know how far away something is and you know
in which direction you need to go to get there.
So with EIGRP, we know the metric
to get to a destination network,
we know the next hop IP address
to get to that destination network,
but that's about it.
We don't know how all the routers
in our network are interconnected
and all the link speeds between each of those routers.
We don't have a map of the network.
OSPF does, OSPF being link state routing protocol has a map
of the network.
And that map is stored
in what's called a link state database.
And then the OSPF router is going to run the Dijkstra algorithm
on that link state database
to calculate the shortest path
to get to this destination network.
That's exactly what's happening
with your car's navigation system,
or your smartphones navigation system.
Those navigation systems run
the Dijkstra algorithm on a map.
You've got different roadways you could take
to get to your destination address,
what's going to assign a cost to those different roadways?
The interstate might have a lower cost than a back road,
that's what OSPF can do.
OSPF can calculate the cost using these different paths.
Now, let's consider some terminology we need
to understand when we're talking about OSPF.
Much like EIGRP used Hello messages
to establish neighborships
and to make sure the neighbor was still there,
so does OSPF.
OSPF also has its Hello protocol
that it can use to establish neighborships
and make sure the neighbor is still there.
And coming up in a few moments,
we're going to discuss the concept of a Designated Router
and we'll talk about how the Designated Router is elected.
Well, Hello messages carry information
that will be used to elect that Designated Router.
And when I think of OSPF, I think of working a jigsaw puzzle
and when you work a jigsaw puzzle,
maybe you're doing that with a couple of other people,
you have pieces of the puzzle,
they have pieces of the puzzle,
but you can collaborate with them,
and each of you provide information,
you provide your puzzle pieces
and you put them all together,
and when you're done, you've got to a complete picture,
you've got the complete puzzle.
It's really very similar with OSPF.
With OSPF, the puzzle pieces in this analogy are LSAs,
Link State Advertisements.
An LSA is a piece of information
about this overall map of the topology,
the link state database.
And once all the routers communicate what they know
and you put all that information together,
then we can construct a full link state database
on which we can run that Dijkstra algorithm.
But here's a common mistake people make
with the terminology.
They think of sending an LSA packet.
That's not correct.
Think of an LSA, simply as information.
The packet that carries that information,
that's an LSU, a Link State Update.
So the LSA, that's the information itself,
but it's carried in an LSU packet.
And sometimes you're working a puzzle
and you get close to the end
and you seem to be missing a piece,
does anybody have this piece?
And you look around and you look
on the floor, maybe somebody dropped it
and hopefully somebody is going to say,
"Oh yeah, I found it",
and they'll give you the missing piece, you plug it in
and then you've got the full puzzle worked.
With OSPF, we might have a router that has a missing piece
to its link state database.
If it does, it can request that missing piece
by sending out an LSR, a Link State Request.
And hopefully, one of its neighbors,
it has that missing piece of information
and it will be able to provide it using an LSU,
a Link State Update.
And we want to make sure
that the sender of the LSU knows that we got it,
so we will respond to the receipt of a Link State Update
by sending a Link State Acknowledgement.
And much like the IGRP could form a neighborship,
OSPF conform neighborships,
but in addition to just forming a neighborship,
we can take it a step further and we can form an adjacency.
And there's a distinction
between a neighborship and an adjacency.
First of all, if we're a neighbor,
then we're on the same network link,
we're on the same network segment as our neighbor,
and we're going to send Hello messages back and forth
to the multicast group address of 224.0.0.5.
And if we're in adjacency, we take that a step further.
If we're an adjacency, we are neighbors,
that's where it starts.
We begin as neighbors, but we go a step further.
I compare this to the neighbors
that I live next to.
Where I live, it's in a fairly rural area
and there are only two houses anywhere near our house
and I've got these two neighbors.
Now, one neighbor we don't know very much honestly,
I probably would not recognize their face
if I saw them in public, but I know what car they drive,
and I can wave at them as they go by
and they wave at me, we say hello,
just like OSPF neighbors say hello, and that's all we do.
Our other neighbor, we've exchanged information.
We've been to their house, they've been to our house,
we've worked on projects together,
we call, we text, we've got a much tighter relationship.
So we are neighbors, but beyond just being neighbors,
we've exchanged the information.
That's like an OSPF adjacency.
An OSPF adjacency is a neighborship,
but it goes beyond that and we exchange the information
that's going to be used to build this link state database.
But there are some requirements for two routers
to become OSPF neighbors.
First, they have to be in the same area.
Now let's define that term.
An OSPF area is a chunk of the network that we've defined.
We might have 500 routers in our entire corporate network,
but maybe we've grouped 100 routers into areas zero,
and we've grouped another 100 routers
into area one and so on.
And each of those areas,
they're going to have their own link state database
and we're going to run the Dijkstra algorithm
on that link state database for that area.
And in the early days of OSPF, that was one
of the reasons you would create multiple areas is
to reduce the impact that the Dijkstra algorithm would have
on your router's processor, if it were trying to run
on a really, really large link state database.
We're going to talk in a few moments
about how that's not a big concern any longer,
but you might see an OSPF network that is broken up
into different areas.
Well, to be a neighbor with another router,
you've got to be in the same area.
You have to have interfaces in the same area.
As we're going to see, a router can have different interfaces
in different areas.
And if we have OSPF authentication configured,
and we're going to talk about that later in this section,
then obviously we've got to have
matching authentication parameters.
And we mentioned that you had to be on the same subnet,
the same network link to establish a neighborship
and your timers have to match.
We're going to have hello and dead timers
that we'll talk about later in this section.
And even though with EIGRP, it was a good idea,
it was a best practice to have matching timers,
they didn't have to match.
They worked a little bit differently than they do with OSPF.
With OSPF, they have to match.
And we're going to define some different types of areas later
in this section.
We're going to have beyond just a regular area.
We're going to have a stub area,
we'll have a totally stubby area,
a not-so-stubby area, and a totally not-so-stubby area.
Well, all of the router interfaces in an area,
they've got to have matching stub flags,
in other words, they have to agree
on what kind of area they're participating in.
And to be a neighbor,
you've got to have a matching maximum transmission unit,
a matching MTU, which defaults 1500 bytes.
If you've got mismatched MTUs, you'll probably find yourself
in the EXSTART/EXCHANGE state.
That's a telltale sign that this neighborship
that you're trying to establish
and failing to do so,
that neighborship has a mismatched MTU.
And if we think about this difference once again,
of neighbors and adjacencies,
we might wonder why not just make everybody adjacencies,
after all we're exchanging more information,
why would I just say hello to another router
when I could exchange information with that router?
And the answer is scalability.
In this example, we've only got six routers
and they each have an interface on this subnet.
If we formed an adjacency between every router,
we would have a lot of adjacencies.
Here's the formula.
It would be n,
where n is the number of routers, X n - 1,
and we take that product and we divide by two.
So here we just have six routers.
6 X 6 - 1, that's 6 X 5, that's 30, divide by 2, that's 15.
We've got 15 adjacencies that we would have to establish.
And that's only with six routers.
What if I had 10 routers?
That will be 10 X 9, 90 divide by 2,
that's 45 adjacencies.
You see how this doesn't scale well?
So to address that scalability issue,
what we can do is we can designate a router
in this subnet as a Designated Router or a DR.
And if it goes down, we want to have a backup,
so we have a backup Designated Router within this subnet.
And then the other routers,
they only have to form adjacencies with the DR and the BDR.
That's going to dramatically reduce the number
of adjacencies that we have to have,
especially when we have lots of routers
that have interfaces on the same subnet.
And we mentioned earlier that when we send Hello messages,
those Hello messages are going to go to 224.0.0.5,
that was for IPv4.
With IPv6, we would go to the multicast group
of FF02::5, and that will go
to all OSPF speaking routers.
However, what if I just want to communicate
with the DR and the BDR?
Then I would use a different multicast group.
For IPv4, I would use
multicast group 224.0.0.0.6,
and with IPv4, I would use multicast group FF02::6
Now let's discuss, how does a DR become a DR?
How does it get elected as a DR?
Let's discuss the election process.
The first thing to understand
is we can have different OSPF router priorities
and the higher router priority wins.
How do we communicate our router priority with a neighbor?
We send that inside of a Hello packet,
and by default all of our routers have
an OSPF priority of one.
So it's a tie to begin with.
If we want to cause a router to be elected,
we can inflate its priority value.
In interface configuration mode,
we can say ip ospf priority,
and then we give a priority value.
We might do that if we have a router
that's got some extra process or power available,
we think it would make a good DR,
and then maybe we give a slightly lower priority,
but still greater than one to the router we want
to be the BDR.
If there's a router, though, that's really taxed as it is,
you don't want it handling the responsibilities
of a Dr or BDR, you don't want it to participate
in the this election,
then what you can do is use this command
to say, I don't want to participate.
You can set the priority to zero,
and that will prevent the router
from participating in this DR election.
What if we have a tie though?
We said by default, we do have a tie,
everybody has a priority of one.
Well, the tiebreaker is the highest OSPF router ID wins.
And we can configure that router ID
in OSPF router configuration mode
with the command router-id and then we specify the ID,
which looks like an IPv4 address,
like the router ID might be 1.1.1.1 for R1
and 2.2.2.2 for R2 and so on.
But if we didn't take the time to do that
if we did not configure a router ID,
then we take a look at the loopback interfaces on a router
and the loopback interface
that has the highest IP address,
well, that IP address, that becomes the router ID.
What if we don't have any loopback interfaces though,
what happens then?
Then we look at all of our interfaces
that are in the upstate,
in whichever interface has the highest IP address and is up,
we say that that is our router ID.
And that's the way we elect a DR into BDR.
And we mentioned earlier that we had this concept of an area
and an area was going to contain the link state database
and we could take a large enterprise network
and we could break that up into different areas,
and then when we're running this Dijkstra algorithm,
that calculation only has to be done within an area.
And one of the original intents for this, as we mentioned,
was to reduce the router process or burden
that we might experience by running the Dijkstra algorithm
on a really, really large area.
So Cisco used to have a design guideline that said,
if your network exceeds 50 routers,
that's when you need to create another area.
So if you had 60 routers,
Cisco would recommend that you have two areas.
However, that recommendation,
that many people still look to today,
that recommendation was made way back in the 1990s
and it was based
on the really old Cisco 2500 series router.
That's a really old router
with a really low powered processor by today's standards.
Now we've got second
and third generation ISR routers,
where orders of magnitude more powerful
than those older 2500 series routers.
By the way, I still use the 2500 series router
as an access server,
that's the way I can get to the console port
on my switches and routers,
but I would not want to run OSPF on it
in a really large network,
but if you've got really powerful routers,
yeah, you don't really need to stop at 50 routers.
When I worked at Disney World, we had over 500 routers,
we were running EIGRP,
but I wouldn't have any hesitation on the modern routers
of having all 500 plus routers be in the same OSPF area.
Is there ever a time you want to break things up
into different areas?
I think so.
One reason is for simplicity of troubleshooting.
For example, you might have a data center
and in this data center,
you've got lots of different networks,
so you've got lots of different rack servers
and they're on lots and lots of different subnets,
you might run out of VLANs,
so you have to use VXLAN identifiers,
there's a lot of networks
that you're trying to keep track of.
And while the doctor algorithm could probably handle that
for a large data center combined
with your enterprise network, for simplicity,
I probably don't want all those data center networks showing
up in my enterprise topology
because I'm trying to filter out,
okay, I don't pay attention to those
because they're in the data center,
I want to focus on these enterprise networks.
By having them in different areas,
it can make it easier to troubleshoot the portion
of the network that you need to troubleshoot.
So I might break things up if I had a data center
or if I had some third party device that natively ran OSPF
that I might not trust, honestly, I might have concerns
that it could corrupt our OSPF link state database,
I might put those third party devices
that aren't really proven, I might put them
in their own areas, just for safety,
just for link state database stability.
And here we've got three areas.
We've got areas zero and if we have more than one area,
we must have an area zero,
and this is called a backbone area.
And this backbone area must be directly adjacent
to all of our other areas.
Notice that area two and area one,
they're connected directly to areas zero.
And the routers that sit at the border
of these areas, notice R3 and R7,
they each have one or more interfaces
in areas zero and one or more interfaces in some other area.
There's a special name for routers like that,
they're called ABRs, area border routers.
And they have a couple of link state databases.
If they're connected to two areas,
there's a link state database for each area.
Now that's a look at some of the fundamentals of OSPF.
In our next video,
let's take a closer look at the OSPF timers.