Unit 1: Network Infrastructure
This will allow you to demonstrate your networking skills, knowledge, and abilities, with a focus on enterprise-level switching, routing, and multicast components that support cross-platform (inter)operability and integration with the most recent software-defined technologies.

OSPF Neighbor Forming Process

When OSPF is turned on for a router interface, a Link State Database (LSD) is created and all interfaces that are running OSPF are added to it so that it can be used in Link State Advertisements (LSAs). OSPF then starts the process of finding neighbors and setting up connections.

Now, let’s take a closer look at both the neighbor find and adjacency forming processes:

 

Figure A. R1 sends an initial OSPF Hello packet. R2 responds with an OSPF Reply Hello packet.

OSPF Hello Messages Sending and Receiving

Every poll interval, which is 10 seconds for Peer-to-Peer (P2P) networks and 30 seconds for Non-Broadcast-Multiple-Access (NBMA) networks by default, an OSPF router sends a Hello packet to all routers connected to its interfaces using the multicast address 224.0.0.5. It does this while it looks for possible OSPF neighbors. The Hello message includes a list of details needed to set up an OSPF neighbor relationship between two routers that are next to each other. The following is a list of the details that are in the Hello messages:

  • Router ID for OSPF. OSPF sets or chooses automatically the router’s ID, which is looked at below.
  • Hello Interval Timer. The frequency at which Hello packets are sent.
  • Timers for dead intervals. Sets the time in seconds that we should wait for hello packets before declaring the neighbor dead.
  • Subnet Mask
  • Router Priority. This is used to help find the Designated Router (DR). What’s more important comes first. If Priority is set to 0, the router will not become a DR or BDR.
  • List of the network’s OSPF neighbors that can be reached.
  • Area ID
  • DR & BDR’s IP addresses (if exists)
  • Authentication Password (if configured)

When an OSPF neighbor router (R2) gets the Hello message, it checks the previous list.

Before two routers may be considered neighbors, they must first satisfy the characteristics listed below:

  • They need to be on the same IP network or area.
  • The Hello Interval and Dead Interval timers need to be the same.
  • The Area ID for router ports that connect two routers must be the same.
  • The type of area (normal or small area) must be the same.
  • If an authentication password is used, it must be the same

Hello, Mismatch in Parameters

If some of the items don’t match, like the Hello/Dead interval, Subnetmask, Area ID, etc., then a Bouncing Relation case happens. This is because the possible neighbor (R2) keeps flapping on the router’s OSPF topology, which means that the Hello message information doesn’t match.

The Router ID can be an IP address, a name, or a number. OSPF will pick the highest interface’s IP address as the Router ID by default. Interfaces that go down (like Ethernet interfaces that start to disconnect) can mess up the OSPF process. Because of this, you should always either set the Router ID to a suitable value for the OSPF network or assign a suitable IP address to a Loopback interface (a virtual interface that is always “Up”).

Checking for a Match in Hello Parameters—Hello Message Replies

R2 will respond to R1 with a Reply Hello packet if it gets an OSPF Hello message and all of the required Hello parameters are equal.

With the Reply Hello function, the router R1 (the one that initially issued the Hello message) can check to see if the nearby router R2 is indeed in its neighbor list.

  • If nearby router R2 is already on the list of known neighbors, then R1 will reset its dead timer and use the Keep Alive method, which are the Reply Hello messages, to communicate with R2.
  • When a router discovers a new neighbor, it will update its OSPF neighbor database to include R2, even if R2 isn’t already there. The Keep Alive mechanism will be activated by all subsequent OSPF Hello and Hello Reply messages.

Setting up a master-slave relationship

It is necessary to establish a hierarchical order of exchanging information in order to identify which router sends DataBase Descriptor (DBD) updates first (Master) while the other router (Slave) listens. This is done when a neighbor relation is built between two routers that are running OSPF. Following the transmission of the DataBase Descriptor (DBD) packets by the Master, the Database Descriptor (DBD) packets are then transmitted by the Slave.

On the other hand, if priority is not defined, OSPF will use the router ID as a reference. OSPF chooses the master router based on the highest priority, which can be manually configured.

The Designated Router (DR) doesn’t have to be the leader; it’s just a router priority-based relationship that sets up how neighbors can share data, but it doesn’t change the roles of the DR and BDR.

Data Base Descriptor (DBD) Acknowledgement and Review for Exchange

To keep faults from spreading due to a flood of updates, OSPF neighbors follow a strict process when they share routing information and changes. This process happens in the following order:

 

No Attachment Found
No Attachment Found