So with this module and section we move on from the basics
of OSPF and talk about neighborships.
As with other link state routing protocols,
OSPF forms neighborships with its directly connected neighbors.
This allows devices to communicate with each other and become informed
about the networks that are reachable within the network.
With OSPF there are a number of requirements that must
be met for a neighborship to form.
In list form these include that the neighbors must be in the same IPv4 subnet,
neighbors must be in the same area and area type,
neighbor timers must be the same,
neighbors must be configured with the same authentication information,
and neighbors must have a unique router id configured.
Let's touch on these briefly, one at a time.
The first requirement is that they must be in the same IPv4 subnet.
The reason for this is because is when using IPv4,
OSPF uses the configured primary IPv4 address,
and with IPv4 to communicate with another device on a common interface,
they must be in the same subnet.
It is important to note, however,
that this requirement doesn't extend to OSPF when configured with IPv6.
When using an IPv6 version of OSPF,
it uses a device's IPv6 link local address for link communications,
not its global IPv6 address.
Because of this, neighbors are not required to be on the same IPv6 subnet.
The next requirement is that neighbors must be configured into the
same OSPF area and agree on the type of area.
We will go into the different types in a later module,
but at this point all you need to know is that neighbors must agree on
the type of area they are in to form a neighborship.
The next requirement is specific to the timers of OSPF.
Unlike EIGRP, OSPF requires that their timers match between intending neighbors.
With OSPF this references two main timers: the hello
interval and the dead interval.
The hello interval sets the amount of time between hello packets,
and the dead interval sets the amount of time that must go by without
receiving a packet from a neighbor to determine it down.
These timers can be manually configured to different values or
they can be altered by the type of OSPF network type that is by
default assigned to an interface.
For this slide we will show a table of the different OSPF network
types that are supported on Cisco equipment; however,
it should be noted that some of these are Cisco specific and others are not.
For the most part,
similar interface types when connected together will be
assigned to the same network type by default,
and because of this have the same OSPF timers.
But it is important to keep this in mind should neighborship not come up.
Further information on network types will be covered later in the module.
Next we have a requirement for matching authentication configuration.
OSPF supports the ability to configure authentication on an interface.
This ensures that only those neighboring devices that are
known about can form a neighborship.
The information configured on these neighboring devices
must match for a neighborship to form.
The final requirement is that neighbors must have a unique router id.
This value is assigned to the OSPF process when it is configured by
default based on the configured addresses on a device.
It can also be manually configured.
It is usually best to manually configure it.
The knowledge of what this value is will make troubleshooting easier,
as will be shown later.
A neighborship will not form if the same router id is
configured on each neighboring device.
Now let's move into the lab and show some OSPF
neighborships forming and how the referenced restrictions limit the ability to form a neighborship.