If these two posts (38 and 39) are a bit too much for you, try to read them again and next week look at my youtube channel. I should have some video published there showing you these things again but this time in on the command line interface.
Before OSPF routers distribute the routing information among their neighbors, they will go through certain stages of operation as explained in Lesson 38. OSPF packets are utilized to take a router from the DOWN state all the way up to the FULL state of operation. We must then, take a closer look at OSPF packets, especially at the Hello packet without which this magic would not be possible.
OSPF uses five types of packets to communicate (explanation of OSPF packet type can be found in my previous post). They are encapsulated in the OSPF header. The whole packet looks like shown in pic. 1.
Pic. 1 - OSPF Packet Encapsulation.
Icons designed by: Andrzej Szoblik - http://www.newo.pl
OSPF header contains the following pieces of information:
Version - The OSPF version, currently used version is 2. Version 3 is OSPF for IPv6.
Type - The type of OSPF packet (type 1 through type 5).
- Type 1 - Hello
- Type 2 - Database Description
- Type 3 - Link State Request
- Type 4 - Link State Update
- Type 5 - Links State Acknowledgement
Area ID - The 32 bit number representing the area in which the interface operates.
Checksum - The number used to check the integrity of the packet including the header (excluding authentication).
AuType - The type of OSPF packet authentication.
- 0 - no authentication
- 1 - simple password (clear text) authentication
- 2 - MD5 authentication
Authentication - The 64 bit field used for authentication
Hello Packet
In order for OSPF routers to exchange their routing databases, they must first discover themselves using so called Hello protocol and agree on a number of parameters. Hello packet (OSPF Type 1 packet) is used to discover the neighbors and exchange these initial parameters.
The purpose of Hello protocol can be summarized as follows:
- Hello packets are used to discover OSPF neighbors.
- Hello packets advertise certain parameters (some of the must match in order to become the router's neighbor).
- On Broadcast or NBMA networks Hello packets are used to elect DR/BDR roles.
- Hello packets are used as a keepalive mechanism. If the router does not hear the neighbors' Hello packets in a given time (DeadInterval), it considers it down and invalidates information obtained from it.
- Hello packets ensure bidirectional communication. The router must see its own RouterID in the 'neighbor' field of the Hello packet it receives.
Before I explain what must match in the Hello packets for the routers to reach so called 2-way state, let's take a look at the Hello packet structure.
Network Mask - The network mask of the originating interface.
Hello Interval - How often Hello packets are going to be sent.
Options - OSPF options. One of them is a 1 bit flag called: E-bit which denotes the type of area in which the interface operates (1=normal, 0=stub).
Router Priority - Used on Broadcast and NBMA networks to elect DR/BDR. The higher the number, the more likely for the router to become DR and the second highest number becomes BDR. After the election has been accomplished, the number is no longer used to influence DR/BDR role (non-preemptive).
Router Dead Interval - The maximum time before a silent router is declared down (no Hello packet from it in this time).
Designated Router - DR is elected in Broadcast and NBMA network. This field in the Hello packet carries the IP address of the DR on the common subnet (only Broadcast and NBMA networks).
Backup Designated Router - BDR is elected in Broadcast and NBMA network. This is the IP address of DR on the common subnet (only Broadcast and NBMA networks).
Neighbor - The router IDs from which valid Hello packet was received in the last DeadInterval time.2-way State
OSPF-enabled router is a bit picky when it comes to its operation and choosing its neighbors. In order for the OSPF routers to exchange LSAs (information about network reachability), they must reach the 2-way state first which indicates that some mandatory parameters in their Hello packets are identical between them. The OSPF header encapsulates the Hello packet. Below picture shows this encapsulation and the light-red dots indicate the parameters that must match between the neighbors.
Pic. 4 - Hello Packet Encapsulation.
Icons designed by: Andrzej Szoblik - http://www.newo.pl
So, in a nutshell, the following conditions must be met for the two routers to become neighbors:
- The routers must be on common subnet (it's true for all IGP routing protocols).
- The Hello and DeadInterval timers must be identical between the neighbor candidates.
- The area ID, where the OSPF-enabled interfaces of both neighbors operate, must be identical.
- The type of area where the two neighbors must be identical (either normal or stub area).
- The type and authentication password (if used) must match between neighbors.
After achieving bidirectional communication between the routers (2-way), they will enter the ExStart state. During this phase the routers are going to elect the Master and Slave roles to perform the database synchronization in an orderly fashion. During the ExStart state they will also check their MTU size. If it does not match, they will not go any further (no LSA exchange is possible). This is generally not a problem between routers, but if you create configuration between a multilayer switch and a router, this might be a problem if the switch uses larger MTU size than 1500 bytes.
Routers typically use MTU=1500 bytes. On a multilayer switch running OSPF you can check it by issuing the following command:
Switch#show system mtu
If MTU is not 1500 bytes, you can disable MTU check on the interfaces in question:
Router(config-if)#ip ospf mtu-ignore
If all is good, they will eventually reach the Full state.
Before I finish this post I must mention that there are two multicast IP addresses reserved for OSPF communication:
224.0.0.5 = All OSPF speaking routers
224.0.0.6 = AllDRouters (DR/BDR listen on this address).
Unfortunately, sometimes these multicast addresses cannot be used on certain types of media (X.25, Frame-Relay, ATM, which are NBMA types of networks). In such situations, by default, unicast transmission must be used to send OSPF packets (the 'neighbor' statement under OSPF process changes mutlicast into unicast transmissions). But this is beyond the scope of this tutorial. If you want to learn more details you might look at my Advanced Study Blog to see these types of connections put into practice (soon more posts area going to be available).
Wrapping things up, I need to add that some states require a bit more explanation (for instance, DR/BDR election on Broadcast/NBMA networks), but it will be easier to show it practically in my next post which is going to be about implementation of OSPF on two types of network: Broadcast and Point-to-Point. Running OSPF on these types of network fall under CCNA level of expertise.
