The different types of packets sent by OSPF routers are contained in the common 24-byte OSPF header. While delving into the specifics of the OSPF header is beyond the scope of the CCNA exam requirements, it is still important to have a basic understanding of the fields contained within this header and what they are used for. Figure 39.6 below illustrates the common 24-octet OSPF header:
Figure 39.6 – The OSPF Packet Header
The 8-bit Version field specifies the OSPF version. The default value for this field is 2. However, when OSPFv3 is enabled, this field is also set to 3. OSPFv3 was described in detail in the Day 13 module.
The 8-bit Type field is used to specify the OSPF packet type. The five main OSPF packet types, which are described in detail later in this module, are as follows:
- Type 1 = Hello packet
- Type 2 = Database Description packet
- Type 3 = Link State Request packet
- Type 4 = Link State Update packet
- Type 5 = Link State Acknowledgement packet
The 16-bit Packet Length field is used to specify the length of the protocol packet. This length includes the standard OSPF header.
The 32-bit Router ID field is used to specify the IP address of the router from which the packet originated. On Cisco IOS devices, this field will contain the highest IP address of all physical interfaces configured on the device running OSPF. If Loopback interfaces are configured on the device, the field will contain the highest IP address of all configured Loopback interfaces. Alternatively, this field can also contain a manually configured router ID if one has been explicitly configured or specified by the administrator.
NOTE: When the router ID has been selected, it will never change unless the router is reloaded, the interface that the IP address was derived from is shut down or removed, or the OSPF process is reset using the clear ip ospf process privileged EXEC command on the router.
The 32-bit Area ID field is used to identify the OSPF area of the packet. A packet can belong only to a single OSPF area. If the packet is received via a virtual link, then the Area ID will be the OSPF backbone, or Area 0. Virtual links are described in detail later in this module.
The Checksum field is 16-bits long and indicates the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit Authentication Data field. If the packet’s length is not an integral number of 16-bit words, the packet is padded with a byte of zero before being checksummed.
The 16-bit Authentication (Auth) Type field identifies the type of authentication used. This field is valid only for OSPFv2 and may contain one of the following three codes:
- Code 0 – This means that there is null (no) authentication; this is the default
- Code 1 – This means that the authentication type is plain text
- Code 2 – This means that the authentication type is Message Digest 5 (MD5)
Finally, the 64-bit Authentication Data field is for the actual authentication information or data, if authentication has been enabled. It is important to remember that this field is valid only for OSPFv2. If plain text authentication is being used, this field contains the authentication key. However, if MD5 authentication is being used, this field is redefined into several other fields, which are beyond the scope of the CCNA exam requirements. Figure 39.7 below shows the different fields as they appear in a wire capture of an OSPF packet:
Figure 39.7 – OSPF Packet Header Wire Capture
Within the OSPF packet header, the 8-bit Type field is used to specify the OSPF packet type. Again, the five OSPF packet types are as follows:
- Type 1 = Hello packet
- Type 2 = Database Description packet
- Type 3 = Link State Request packet
- Type 4 = Link State Update packet
- Type 5 = Link State Acknowledgement packet
OSPF Hello Packets
Hello packets are used to discover other directly connected OSPF routers and to establish OSPF adjacencies between OSPF routers. OSPF uses Multicast to send Hello packets for Broadcast and Point-to-Point network types. These packets are addressed to the AllSPFRouters Multicast group address 224.0.0.5. For Non-Broadcast links (e.g., Frame Relay), OSPF uses Unicast to send Hello packets directly to statically configured neighbours.
NOTE: By default, all OSPF packets (i.e., Multicast and Unicast) are sent with an IP TTL of 1. This limits these packets to the local link. In other words, you cannot establish an OSPF adjacency with another router that is more than one hop away. This is also applicable to EIGRP.
OSPF Hello packets are also used on Broadcast links to elect a DR and a BDR. The DR listens specifically to the Multicast address 224.0.0.6 (AllDRRouters). The DR and the BDR were described in detail previously in this module. Figure 39.8 below illustrates the fields contained within the OSPF Hello packet:
Figure 39.8 – OSPF Hello Packet
The 4-byte Network Mask field contains the subnet mask of the advertising OSPF interface. The network mask is checked only on Broadcast media. Unnumbered Point-to-Point interfaces and virtual links, both of which will be described later in this module, set this value to 0.0.0.0.
The 2-byte Hello field displays the value of the Hello interval, which is the number of seconds between two Hello packets, requested by the advertising router. Possible values range from 1 to 255. By default, the Hello interval is 10 seconds on Broadcast and Point-to-Point media and 30 seconds on all other media.
The 1-byte Options field is used by the local router to advertise optional capabilities. Each bit in the Options field represents a different function. Going into them is outside the scope of the CCNA exam requirements.
The 1-byte Router Priority field contains the priority of the local router. By default, this field has a value of 1. The value is used in the election of the DR and the BDR. Possible values range from 0 to 255. The higher the priority, the higher the chances the local router will become the DR. A priority value of 0 means that the local router will not participate in the DR or the BDR election.
The 4-byte Router Dead Interval field shows the value of the dead interval. The dead interval is the time (seconds) before a neighbour router is declared dead. This value is requested by the advertising router. The default value for the dead interval is four times the value of the Hello interval, which would be a default of 40 seconds on Broadcast and Point-to-Point interfaces and 120 seconds on all other types of media.
The 4-byte Designated Router field lists the IP address of the DR. A value of 0.0.0.0 is used when no DR has been elected, for example, on a Point-to-Point link or when a router has been explicitly configured not to participate in this election.
The 4-byte Backup Designated Router field identifies the BDR and lists the interface address of the current BDR. A value of 0.0.0.0 is used when no BDR has been elected.
Finally, the (Active) Neighbor field is a variable length field that displays the router ID of all OSPF routers for which a Hello packet has been received on the network segment.
Database Description Packets
Database Description packets are used during the database exchange when each OSPF router advertises its local database information. These packets are commonly referred to as DBD packets or as DD packets. The first DBD packet is used for the Master and Slave election for database exchange. The DBD packet also contains the initial sequence number selected by the Master. The router with the highest router ID becomes the Master and initiates database synchronisation. This is the only router that can increment the sequence number. The Master router begins the database exchange and polls the Slave for information. The Master and Slave election is held on a per-neighbour basis.
It is important to understand that the Master and Slave election process is not the same as the DR and BDR election process. This is commonly incorrectly assumed. The Master and Slave election process is based solely on the router with the highest IP address; however, the DR/BDR election process may be determined using either the IP address or the priority value.
Assume, for example, two routers named R1 and R2 are beginning the adjacency establishment process. R1 has a RID of 1.1.1.1, while R2 has a RID of 2.2.2.2. The network administrator has configured R1 with an OSPF priority value of 255 to ensure that this router will be elected the DR. During the Master and Slave determination process, R2 will be elected master by virtue of the higher RID. However, the priority value configured on R1 results in R1 being elected the DR. In essence, the DR (R1) can be the Slave during the Master and Slave election process.
After the Master and Slave have been elected, DBD packets are used to summarise the local database by sending LSA headers to the remote router. The remote router analyses these headers to determine whether it lacks any information within its own copy of the LSDB. The OSPF Database Description packet is illustrated in Figure 39.9 below:
Figure 39.9 – OSPF Database Description Packet
Within the DBD packet, the 2-byte Interface MTU field contains the MTU value, in octets, of the outgoing interface. In other words, this field contains the largest data size that can be sent through the associated interface (in bytes). When the interface is used on a virtual link, the field is set to a value of 0x0000. In order for an OSPF neighbour adjacency to be established successfully, the MTU must be the same on all routers. If you change this value on one router, you must configure the same value on all other routers on the same subnet (or use the ip ospf mtu-ignore command).
NOTE: The interface MTU values for EIGRP do not have to be the same in order for an EIGRP neighbour relationship to be established successfully.
The 1-byte Options field contains the same options contained within the OSPF Hello packet. For brevity, these options will not be described again.
The Database Description or Flags field is a 1-byte field that provides an OSPF router with the capability to exchange multiple DBD packets with a neighbour during an adjacency formation.
The 4-byte DBD Sequence Number field is used to guarantee that all DBD packets are received and processed during the synchronisation process through the use of a sequence number. The Master router initialises this field to a unique value in the first DBD packet, with each subsequent packet being incremented by 1. The sequence number is incremented only by the Master.
Finally, the variable length LSA Header field carries the LSA headers describing the local router’s database information. Each header is 20 octets in length and uniquely identifies each LSA in the database. Each DBD packet may contain multiple LSA headers.
Link State Request Packets
Link State Request (LSR) packets are sent by OSPF routers to request missing or out-of-date database information. These packets contain identifiers that uniquely describe the requested Link State Advertisement. An individual LSR packet may contain a single set of identifiers or multiple sets of identifiers to request multiple LSAs. LSR packets are also used after database exchange to request LSAs that were seen during the database exchange that the local router does not have. Figure 39.10 below illustrates the format of the OSPF LSR packet:
Fig. 39.10 – OSPF Link State Request Packet
The 4-byte Link State Advertisement Type field contains the type of LSA being requested. It may contain one of the following fields:
- Type 1 = Router Link State Advertisement
- Type 2 = Network Link State Advertisement
- Type 3 = Network Summary Link State Advertisement
- Type 4 = ASBR Summary Link State Advertisement
- Type 5 = AS External Link State Advertisement
- Type 6 = Multicast Link State Advertisement
- Type 7 = NSSA External Link State Advertisement
- Type 8 = External Attributes Link State Advertisement
- Type 9 = Opaque Link State Advertisement – Link Local
- Type 10 = Opaque Link State Advertisement – Area
- Type 11 = Opaque Link State Advertisement – Autonomous System
NOTE: Some of the LSAs listed above are described in detail in the following sections.
The 4-byte Link State ID field encodes information specific to the LSA. The information that is contained in this field depends upon the type of LSA. Finally, the 4-byte Advertising Router field contains the RID of the router that first originated the LSA.
Link State Update Packets
Link State Update (LSU) packets are used by the router to advertise LSAs. LSU packets may be Unicast to an OSPF neighbour in response to a received LSR from that neighbour. Most commonly, however, they are reliably flooded throughout the network to the AllSPFRouters Multicast group address 224.0.0.5 until each router has a copy. The flooded updates are then acknowledged in the LSA Acknowledgement packet. If the LSA is not acknowledged, it will be retransmitted every five seconds, by default. Figure 39.11 below shows an LSU sent to a neighbour in response to an LSR:
Figure 39.11 – Unicast LSU Packet
Figure 39.12 below illustrates an LSU that is reliably flooded to the Multicast group address 224.0.0.5:
Figure 39.12 – Multicast LSU Packet
The LSU is comprised of two parts. The first part is the 4-byte Number of LSAs field. This field displays the number of LSAs carried within the LSU packet. The second part is one or more Link State Advertisements. This variable-length field contains the complete LSA. Each type of LSA has a common header format along with specific data fields to describe its information. An LSU packet may contain a single LSA or multiple LSAs.
Link State Acknowledgement Packets
The Link State Acknowledgement (LSAck) packet is used to acknowledge each LSA and is sent in response to LSU packets. By explicitly acknowledging packets with LSAcks, the flooding mechanism used by OSPF is considered reliable.
The LSAck contains the common OSPF header followed by a list of LSA headers. This variable-length field allows the local router to acknowledge multiple LSAs using a single packet. LSAcks are sent using Multicast. On Multi-Access networks, if the router sending the LSAck is a DR or a BDR, then LSAcks are sent to the Multicast group address 224.0.0.5 (AllSPFRouters). However, if the router sending the LSAcks is not a DR or a BDR device, then LSAck packets are sent to the Multicast group address 224.0.0.6 (AllDRRouters). Figure 39.13 below illustrates the format of the LSAck:
Figure 39.13 – Link State Acknowledgement Packet
In conclusion, it is important to remember the different OSPF packet types and what information they contain. This not only will benefit you in the exam but also will aid you in understanding the overall operation of OSPF as a protocol.
In Cisco IOS software, you can use the show ip ospf traffic command to view OSPF packet statistics. This command shows the total count for the sent and received OSPF packets, and then segments this further to the individual OSPF process and, finally, to the interfaces enabled for OSPF routing under that process. This command can also be used to troubleshoot OSPF adjacency establishment and is not as processor intensive as debugging. The information printed by this command is illustrated in the following output:
| R4#show ip ospf traffic |
OSPF statistics:
Rcvd: 702 total, 0 checksum errors
682 hello, 3 database desc, 0 link state req
12 link state updates, 5 link state acks
Sent: 1378 total
1364 hello, 2 database desc, 1 link state req
5 link state updates, 6 link state acks
OSPF Router with ID (4.4.4.4) (Process ID 4)
OSPF queue statistics for process ID 4:
InputQ UpdateQ OutputQ
Limit 0 200 0
Drops 0 0 0
Max delay [msec] 4 0 0
Max size 2 2 2
Invalid 0 0 0
Hello 0 0 1
DB des 2 2 1
LS req 0 0 0
LS upd 0 0 0
LS ack 0 0 0
Current size 0 0 0
Invalid 0 0 0
Hello 0 0 0
DB des 0 0 0
LS req 0 0 0
LS upd 0 0 0
LS ack 0 0 0
Interface statistics:
Interface Serial0/0
OSPF packets received/sent
Invalid Hellos DB-des LS-req LS-upd LS-ack Total
Rx: 0 683 3 0 12 5 703
Tx: 0 684 2 1 5 6 698
OSPF header errors
Length 0, Auth Type 0, Checksum 0, Version 0,
Bad Source 0, No Virtual Link 0, Area Mismatch 0,
No Sham Link 0, Self Originated 0, Duplicate ID 0,
Hello 0, MTU Mismatch 0, Nbr Ignored 0,
LLS 0, Unknown Neighbor 0, Authentication 0,
TTL Check Fail 0,
OSPF LSA errors
Type 0, Length 0, Data 0, Checksum 0,
Interface FastEthernet0/0
OSPF packets received/sent
Invalid Hellos DB-des LS-req LS-upd LS-ack Total
Rx: 0 0 0 0 0 0 0
Tx: 0 682 0 0 0 0 682
OSPF header errors
Length 0, Auth Type 0, Checksum 0, Version 0,
Bad Source 0, No Virtual Link 0, Area Mismatch 0,
No Sham Link 0, Self Originated 0, Duplicate ID 0,
Hello 0, MTU Mismatch 0, Nbr Ignored 0,
LLS 0, Unknown Neighbor 0, Authentication 0,
TTL Check Fail 0,
OSPF LSA errors
Type 0, Length 0, Data 0, Checksum 0,
Summary traffic statistics for process ID 4:
Rcvd: 703 total, 0 errors
683 hello, 3 database desc, 0 link state req
12 link state upds, 5 link state acks, 0 invalid
Sent: 1380 total
1366 hello, 2 database desc, 1 link state req
5 link state upds, 6 link state acks, 0 invalid