6.1. OSPF Database Synchronization Everything you have seen about OSPF so far shows that it is a highly structured protocol. Knowing the importance of reliable and accurate database synchronization, it is no surprise that a rather complex state machine, called the neighbor state machine, manages the OSPF synchronization procedure. In a nutshell, the neighbor state machine drives the following steps in the synchronization process: 1. | When two neighbors decide to become adjacent, one of the neighbors becomes the master and the other the slave. The master controls the rest of the synchronization process, called database exchange.
| 2. | Each neighbor describes all of the LSAs in its database to the other.
| 3. | If a router finds, during the description process, that its neighbor has an LSA that it does not, or has a more recent copy of an LSA that it has, it requests a full copy of the LSA from the neighbor.
| 4. | When all necessary LSAs have been exchanged and both neighbors are satisfied that their databases are identical, they end the exchange process and are fully adjacent. Only then can the link between them be used for forwarding packets.
|
This section first looks at the packets OSPF uses for database exchange, and then examines the neighbor state machine in detail. 6.1.1. OSPF Packets Used in Database Synchronization Four of the five OSPF packet types are used for database exchange: Database Description (type 2) packets Link State Request (type 3) packets Link State Update (type 4) packets Link State Acknowledgment (type 5) packets
You already have seen, in Chapter 5, how Update packets are used to send complete LSAs from one neighbor to another, and how Acknowledgment packets carry LSA headers to explicitly acknowledge the receipt of LSAs for reliable flooding. Although the formats of these two packets were shown in Chapter 5, they are repeated in Figures 6.1 and 6.2 for your reference. Figure 6.1. The OSPF Update message format. 
Figure 6.2. The OSPF Acknowledgment message format. 
The Database Description packet (Figure 6.3), like the Acknowledgment packet, carries only the headers of the LSAs that completely describe both the LSA and the instance of the LSA. An OSPF router can describe all of the LSAs in its database by originating DD packets. Figure 6.3. The OSPF Database Description message format. 
Interface MTU specifies the largest unfragmented packet that can be sent from the originating interface. If the MTUs do not match, the neighbors do not become adjacent. Otherwise, one neighbor might send messages larger than the other neighbor can receive. Options is the same Options field that is included in Hello packets and all LSAs to describe the originator's optional capabilities. This field has already been mentioned briefly in previous chapters; its format and use are described fully in the next section.
LS databases are often too large for all of their LSAs to be described by a single DD packet. Therefore, two bits indicate to the receiving neighbor whether the DD packet is one of a sequence: I (Init) indicates, when set to 1, that this DD packet is the first in a series. M (More) indicates, when set to 1, that there are more DD packets to follow. So the I and M bits are used as follows: If a single DD packet describes all LSAs, the two bit values are I=1, M=0. If there is a series of DD packets, the first in the series has I=1, M=1; the last DD packet has I=0, M=0; and any packets between the first and last have I=0, M=1. MS (Master/Slave) indicates whether the originating neighbor is the Master (MS =1) or Slave (MS = 0) during the database exchange. The Master/Slave relationship is described in Section 6.1.5. DD Sequence Number is used, along with the I and M bits, when a series of DD packets describes a database. The use of the DD sequence number is also described in Section 6.1.5.
If during database exchange an OSPF router sees, in the received DD packets, that its neighbor has an unknown LSA or a more recent copy of a known LSA, the router sends a Link State Request packet (Figure 6.4) to ask for a full copy of the LSA. More than one LSA can be requested in a single LS Request packet, and more than one LS Request packet can be sent if a large number of LSAs are needed. The neighbor then sends an Update packet containing the requested LSAs. Figure 6.4. The OSPF Link State Request message format. 
Notice that the LS Request packet does not carry the full LSA header but just the LS Type, LS ID, and Advertising Router fields of the LSA. In other words, it requests the LSA but not the specific instance of the LSA. The receiving neighbor then sends the most recent copy of the LSA. This covers a situation in which a more recent LSA might have been received and installed in the database between the time the neighbor described the LSA in a DD packet and the time it received a LS Request packet for the LSA. The neighbor will send the more recent copy. 6.1.2. The Options Field The OSPF Options field is an 8-bit collection of flags specifying optional capabilities of the originating router. With the introduction of the Database Description packet in the previous section, you have now encountered all of the OSPF entities in which the Options field appears: Figure 6.5 shows the Options field. Seven of the bits are currently used as flags; the eighth bit, marked with an asterisk (*) in the illustration, is unused as of this writing. The originating router only sets bits representing capabilities it supports. Any bit representing an option that the router does not support is considered unknown by the router, and the router sets that bit to 0 in all Options fields it originates. Figure 6.5. The OSPF Options field. 
The bits of the Options field are briefly described here for general reference, but the descriptions might not be meaningful to you until you read the chapters describing the individual options: O indicates support for Opaque LSAs, described in Chapter 10. Briefly, Opaque LSAs allow OSPF to be extended for applications it was not originally intended for, such as traffic engineering, as described in Chapter 1. The O bit is only set in DD packets, and only by routers supporting Opaque LSAs. As a result, the capability is accounted for during the database exchange process. Opaque LSAs are then flooded only to Opaque-capable routers. DC indicates, when set, that the originating router supports the Demand Circuit capability and its associated DoNotAge LSAs, as described in Chapter 8. This capability is designed for use when a link between two neighbors incurs some usagebased cost. By configuring the OSPF interface to treat the link as a demand circuit, Hello packets and refreshed LSAs are suppressed across the link to avoid keeping the link up and incurring unnecessary charges. A router supporting DoNotAge LSAs sets the DC bit in all of the LSAs it originates. It also sets the DC bit in Hellos and DD packets sent across the link designated as a demand circuit. If the router receives Hellos or DD packets with the bit cleared, indicating that the neighbor either does not support the option or is not configured for it, the router reverts to normal Hello and refresh procedures. If a router that does not support Demand Circuit capability receives an Options field with the DC bit set, it ignores the bit. EA indicates support for the External Attributes (type 8) LSAs. This capability has never come into general use and is now considered obsolete. N/P is used to support Not-So-Stubby Areas, as described in Section 7.3.4. In Hello packets, this bit is the N bit and indicates, when set, support for NSSA (type 7) LSAs. If the N bit is set, the E bit (indicating support for type 5 LSAs) must be cleared. If neighbors do not agree on the setting of these bits, Hellos are dropped and no adjacency is formed. In NSSA LSA headers, the bit is the P bit and tells the NSSA ABR to translate the type 7 LSA into a type 5 LSA. MC indicates, when set, support for Multicast OSPF (MOSPF). An MOSPF router sets the MC bit in its Hello and DD packets and in all of its LSAs. However, the bit is only informational in the Hello packets. The capability is noted from the DD packets during database exchange, and MOSPF Group Membership (type 6) LSAs are flooded only to MOSPF-capable routers. E indicates, when set, that the originating router supports external routing capability. When the bit is cleared, the originating router does not accept AS-External (type 5) LSAs. This capability is used in the configuration of stub areas, as described in Section 7.3.4. The bit is always set in AS-External LSAs, and is always set in DD packets and LSAs associated with area 0 and with nonstub areas. However, it is set in these LSAs and DD packets for informational purposes only. Where the flag has effect is in the Hello packet. If the value of the E bits conflict between neighborsthat is, one neighbor is sending Hellos with the bit set and the other neighbor sends Hellos with the bit clearedthe Hellos are not accepted and an adjacency is not formed. T indicates, when set, support for ToS routing. This capability was never put into general use and is now obsolete.
6.1.3. The OSPF Neighbor Data Structure When an OSPF router first discovers a neighbor on a link through receipt of a Hello, it initializes a neighbor data structure for this neighbor. The neighbor data structure, or neighbor table, contains all of the information the router needs to know about the neighbor. Some of the information is gleaned from the neighbor's received Hellos and DD packets, and some of the information comes from the router's own internal processes concerning the neighbor. The specific entries in the neighbor data table are as follows: State records the router's view of the state of the neighbor, according to its own neighbor state machine, as described in Section 6.1.6. Note that this is not the same as the "state" entry of the interface data structure, which indicates only the interface state and its relation to other OSPF interfaces. Inactivity Timer is a timer whose period is RouterDeadInterval, as defined for the interface connecting to the link on which the neighbor resides. Whenever a Hello is received from the neighbor, the timer is reset. Expiration of the timer triggers an event in the neighbor state machine that causes the neighbor state to be changed to Down. Master/Slave specifies the results of the master/slave selection, as described in Section 6.1.5. This status is relevant to the database exchange process. DD Sequence Number is the sequence number of the DD packet currently being sent to the neighbor, for database exchange. Last Received Database Description Packet is used to determine, during database exchanges with the neighbor, whether a DD packet received from the neighbor is a duplicate. It records the values of the Sequence Number and Options fields and the settings of the I, M, and MS flags of the last DD packet received from the neighbor. Neighbor ID is the RID of the neighbor, learned from the neighbor's Hello packets or in some cases manually configured (such as with NBMA or virtual networks). Neighbor Priority is the value of the Router Priority field of Hellos received from the neighbor, and is used for DR/BDR election. Neighbor IP Address is the IP address of the neighbor's interface to the attached network, and is learned from the source IP address of Hellos received from the neighbor. This address is used when OSPF packets must be unicast to the neighbor. If the neighbor is the DR for the attached network, this address is used as the Link ID in Router LSAs for the attached network. Neighbor Options are the neighbor's optional capabilities, learned from its Hellos and from the DD packets during database exchange. Neighbor's Designated Router is the address of the DR (from the neighbor's perspective) carried in the neighbor's Hellos, and is only relevant on broadcast and NBMA networks. Neighbor's Backup Designated Router is the address of the BDR (from the neighbor's perspective) carried in the neighbor's Hellos. Again, this is only relevant to broadcast and NBMA links.
Figure 6.6 shows an example of a display of a neighbor table. You can readily see that it displays mostalthough not allof the entries in the neighbor data structure.
6.1.4. LSA Lists for Database Exchange and Flooding In addition to the information described in the previous section, the neighbor data structure includes three lists. All three are lists of LSAs, and are populated only during the database exchange or flooding. Link State Transmission List is a list of LSAs that have been flooded but not yet acknowledged. The LSAs on this list are retransmitted every RxmtInterval, until they are acknowledged or until the adjacency is destroyed. Database Summary List is a list of all of the LSAs in the LS database pertinent to the area shared with the neighbor when the router begins the database exchange. This list comprises all of the LSAs that are to be described to the neighbor in DD packets. Link State Request List is a list of LSAs received in the neighbor's DD packets that are either unknown to this router or are more recent than this router's copy of the LSA. These are the LSAs that are requested from the neighbor in Link State Request packets. When a full copy of a requested LSA is received from the neighbor in an Update packet, the LSA is removed from the list.
6.1.5. Database Exchange Management: Masters and Slaves The reliable exchange of database information is too important to be done haphazardly. So when two OSPF neighbors are comparing LSAs, one of the neighbors manages the exchange. It does not really matter which neighbor is the manageror masteras long as both neighbors agree on which one is the master. The master is the neighbor with the higher RID, and the neighbor with the lower RID becomes the slave. The responsibilities of the master are: To send the first DD packet To increment the sequence numbers of the DD packets. The Slave cannot increment the sequence numbers. To ensure that only one DD packet at a time is outstanding To retransmit a DD packet when necessary. A Slave cannot retransmit a DD packet.
To understand how the master is determined, imagine two neighboring routers, RA and RB. Immediately after establishing 2-way communication with RB and deciding to form an adjacency with it, RA sends an empty DD packeta DD packet containing no LSA headersto RB. RA sets the sequence number of the packet to some unique value; RFC 2328 suggests basing it on the time-of-day clock, but an OSPF implementation can use some other means to choose a beginning sequence number. The I, M, and MS bits are all set, indicating that this is the initial packet in a series, there are more to follow, and that RA claims to be the master. When RB receives the empty DD packet, it examines RA's RID in the packet header. If RA's RID is higher than its own, RB knows that it is the master, and if lower, RB knows that it is the slave. One of two things then happens: If RB determines that it is the slave it responds by sending a DD packet listing its LSAs, beginning the database exchange process. The sequence number of the packet is the same as sequence number of the DD packet received from RA, and the MS bit is cleared, indicating that this router is the slave and RA is the master. The I bit is set if this is the first DD packet RB has sent, and the M bit is set or cleared depending on whether RB needs to send subsequent DD packets to describe all of its LSAs. If RB determines that it is the master it sends an empty DD packet with its own beginning sequence number and the I, M, and MS bits set. RA then acknowledges that it is the slave by sending a DD packet with RA's initial sequence number and with the MS bit cleared. This acknowledging DD packet contains LSA headers from RA's database, beginning the database exchange process, and the M bit indicates whether RA needs to send more DD packets to complete the description of its database. In this case, the I bit is cleared, because this is not the first DD packet RA sent.
Both RA and RB could, after establishing 2-way communication, send empty DD packets more or less simultaneously, both claiming to be the master. In this case, both will know upon reception of the other's DD packet which of them is master and which is slave. It is up to the slave to begin the database exchange by sending a populated DD packet whose sequence number and MS bit acknowledge its neighbor as the master. The complete database exchange is described in Section 6.1.6. For now, it is enough to understand that the master, once determined, manages the process. Only the master can increment the sequence number, so when it sends a DD packet with sequence number X, the slave implicitly acknowledges the receipt of the master's DD packet by sending its own DD packet, with sequence number X. Only when the master receives the slave's DD packet X can it send another DD packet with a sequence number of X+1. These rules make the database exchange a poll/response process in which the master polls and the slave responds. Is the DR Always the Master? Because the highest RID is used as a tiebreaker during DR election when the router priorities are equal, you might be lead to assume that the DR is always the master when a DROther must synchronize its database with the DR. And the responsibilities of the DR on broadcast and NBMA networks might reinforce this assumption. But in fact, it is quite possible for a DROther to be the master and the DR to be the slave when the two are exchanging databases. Remember that an OSPF DR cannot be preempted. So, for example, a router newly attaching to an Ethernet link can have a higher RID than the existing DR but cannot automatically replace the DR. But its higher RID does mean that it will be the master and the DR will be the slave. |
6.1.6. The OSPF Neighbor State Machine With all the necessary components that support the database exchange process described, we can now look at the various states an OSPF router can be in, the events that cause a change from one state to another, and the actions the router takes when a state change occurs. The full set of these states, events, and actions is the OSPF neighbor state machine, and is described in depth in Section 10.3 of RFC 2328. Keep in mind that an OSPF router maintains separate state for each of its neighbors, and that the state describes the router's perception of its present relationship with that neighbor. Two neighbors mightparticularly before full adjacency is establishedshow different states for each other. The OSPF neighbor states are: Down is the initial state of a neighbor conversation. This state indicates that no Hellos have been heard from the neighbor during the last RouterDeadInterval. Hellos are not sent to dead neighbors except on NBMA networks, where Hellos are sent to dead neighbors at some rate well below that of the Hello interval. This reduced rate, called PollInterval, is typically 2 minutes. Attempt is relevant only to NBMA networks where the neighbors have been manually configured and indicates that the router should be aggressive in attempting to get a response from the neighbor, by sending Hellos every HelloInterval rather than every PollInterval. Init indicates that the router has seen a Hello from the neighbor but has not yet seen its own RID in the neighbor's Hello. (Bidirectional communication is not yet established.) The router includes the RIDs of all neighbors in this state or higher in its own Hellos sent on the associated interface. 2-Way indicates that bidirectional communication is established with the neighbor, by the router seeing its RID in the neighbor's Hellos. Routers must be in this state or higher to be eligible for DR/BDR election. ExStart indicates that the database exchange process has begun. When in this state the neighbors determine their master/slave relationship and the initial sequence number for DD packet exchange. Neighbors in this state or higher are considered adjacent, although they are not fully adjacent until synchronization is completed. Exchange indicates that the router is describing its database to the neighbor by sending DD packets, containing the headers of all LSAs in the Database Summary list. The router can also send link state Request packets, requesting copies of LSAs on the Link State Request list, while in this state. Neighbors in this state or higher are included when the router floods LSAs. Loading indicates that the router has finished describing its database to its neighbor but has not yet finished requesting LSAs from the neighbor or has not yet received all LSAs on its Link State Request list. Full indicates that the neighbor is fully adjacent and that the adjacency will appear in Router and Network LSAs.
Figure 6.7 shows a typical succession of state changes as two neighbors discover each other and then synchronize their databases to become fully adjacent.[1] The OSPF network type between the two neighbors in this example is broadcast. [1] This example is based on an example given in RFC 2328, Section 10.10 and expanded upon in the author's CCIE Professional Development: Routing TCP/IP, Volume I, Cisco Press, 1998, pp. 445447.
Figure 6.7. An example of neighbor discovery and database synchronization resulting in a full adjacency. 
The following steps are shown in the example: 1. | RA becomes active on the network and sends a Hello packet to announce its presence. The DR field is set to 0.0.0.0, and the Neighbor field is empty, indicating that RA is not yet aware of any neighbors.
| 2. | When RB receives the Hello, it creates a neighbor data structure for RA. It sets RA's state to Init, because the Hello does not include RB's RID in its Neighbor field. When RB sends a Hello, it includes RA's RID (10.0.0.1) in the Neighbor field. In this example, RB is the DR for the network, so it includes its interface address (10.1.1.2) in the DR field.
| 3. | When RA receives the Hello from RB, it creates a neighbor data structure for RB. Because it sees its own RID in the Neighbor field of the Hello, it knows that bidirectional communication is established. It could, at this point, set RB's state to 2-Way. But because RB is the DR RA must synchronize its database with it. So it sets RB's state to ExStart, indicating that it is beginning the master/slave selection, and populates the Database Summary list with the LSAs to be described to RB. It sends an empty DD packet with its idea of an initial sequence number (X) and the MS bit set. As the first of multiple DD packets, the I and M bits are also set.
| 4. | When RB receives RA's initial DD packet, it transitions RA's state to ExStart, populates its Database Summary list with LSAs to be described to RA, and sends its own empty DD packet. RB's RID is higher than RA's, so it knows it is the master and sets the MS bit accordingly and sends its initial sequence number (Y). The I and M bits are set to indicate that this is the first of multiple DD packets from this router.
| 5. | When RA receives RB's initial DD packet, it sees that RB is the master. With master/slave selection complete, database exchange can begin, so RA changes RB's state to Exchange. It sends a DD packet to RB with RB's initial sequence number and the MS bit cleared, to indicate that RA is the slave. This DD packet is populated with as many LSA headers from the Database Summary list as it will hold. In this example, multiple DD packets are needed to describe RA's complete database, so the M bit is set to indicate more DD packets to follow. I is cleared, because this is no longer the initial packet.
| 6. | When RB receives the DD packet from RA, it changes RA's state to Exchange. If the received DD packet describes any LSAs that RB needs, those LSAs are added to the Link State Request list. It then sends a DD packet to RA with LSAs from its Database Summary list. As the master, it is responsible for incrementing the sequence number to Y+1. And as with RA, RB cannot describe all of its LSAs in a single DD packet so the M bit is set. The LSAs that are described in this DD packet are added to the Link State Retransmission list and the Retransmit timer is started.
| 7. | When RA receives RB's DD packet, it clears the LSAs it sent in its last DD packet from the Database Summary list. If RB describes any LSAs RA needs, the LSAs are added to the Link State Request list. RA then sends a new DD packet with the next set of LSAs from its Database Summary list. By setting the sequence number to Y+1, RA also acknowledges in this packet the receipt of RB's last DD packet and the LSAs it contained.
| 8. | When RB receives RA's DD packet with sequence number Y=1, it clears the retransmit timer for the LSAs it described in its last DD packet and removes the LSAs from its Link State Retransmission list. RB then sends the next set of LSAs to be described in a new DD packet with sequence number Y+2. With this packet, all LSAs in RB's Database Summary list have been described, so the M bit of this packet is cleared to indicate the end of the sequence.
| 9. | When RA receives RB's final DD packet with M = 0, it knows that RB has finished describing its database. But RA has LSAs on its Link State Request list that have not yet been requested from RB, so its sets the state of RB to Loading. RA then sends a DD packet with sequence number Y+2 to acknowledge receipt of the last packet from RB. This DD packet contains the last of the LSAs on RA's Database Summary list, so the M bit of this packet is cleared.
| 10. | When RB receives RA's final DD packet, it clears the acknowledged LSAs from its Link State Retransmission list. There are no LSAs on its Link State Request list, so RB knows all of the LSAs in RA's database and changes RA's state to Full. But RA still has LSAs on its Link State Request list, so it sends link state Request packets to RB. RB responds by sending the complete LSAs in link state Update packets. When RA has received all of the LSAs it needs, indicated by an empty Link State Request list, it changes RB's state to Full.
|
In the example of Figure 6.7, state changes occur only after the receipt of a packet. The actual events causing the state changes are discoveries or changes of information included in the packets. Not all events causing state changes, however, are associated with the receipt of a packet. Events causing changes to a higher state are: HelloReceived A Hello has been received from the neighbor. Start Hellos should be sent to neighbors at the Hello interval. This event is only generated for neighbors on NBMA networks. 2-WayReceived The router sees its RID in the neighbor's Hello, indicating that bidirectional communication is established. NegotiationDone The master/slave negotiation is done. ExchangeDone Both routers have finished describing their databases in DD packets. BadLSRequest A Link State Request packet has been received requesting an LSA that is not in the database, indicating an error in the database exchange process. LoadingDone The Link State Request list is emptied after database exchange process. AdjOK? This is a decision point for whether an adjacency should be established and maintained with the neighbor.
Figure 6.8 shows the relationship between states and these events that cause upward state changes. Figure 6.8. The events causing changes from a state to a higher state in OSPF. 
Other events can cause a change to a lower state. These events are mostly caused by an error, a failure, or a timer expiration and can occur when the neighbor is in any number of states: SeqNumberMismatch A DD packet has been received that either has an unexpected (nonsequential) sequence number, an improperly set I bit, or an Options field value that is different from the Options field in the last received DD packet. This event causes the database exchange process to be abandoned and restarted at the ExStart state. 1-Way Bidirectional communication with the neighbor is lost, as indicated by the reception of a Hello from the neighbor in which the receiving router's RID is not in the Neighbor list. If the neighbor state is 2-Way or greater, the neighbor state is changed to Init. KillNbr Communication with the neighbor is impossible, and results in a change of the neighbor state to Down. InactivityTimer No Hellos have been seen from the neighbor in the last Router-DeadInterval; the state of the neighbor is changed to Down. LLDown A lower-level protocol indicates that the neighbor is unreachable, resulting in a change of the neighbor state to Down.
6.1.7. Troubleshooting: Reading OSPF Log Entries and Debug Output OSPF database synchronization is not always as clear-cut as it is described in the preceding section. For example, Link State Requests and Updates can be exchanged while DD packets are still being exchanged. And interface states can influence neighbor state transitions. But intimately understanding what is happening when routers are forming full adjacencies will greatly enhance your OSPF troubleshooting skills. If an adjacency refuses to come up, the most likely culprits should be checked first: Are the interface addresses configured correctly? Can you ping the neighbor's interface? Are the interfaces configured in the same area? If authentication is used (Chapter 9), is it configured consistently on both sides? Do the passwords or keys match? Are OSPF options configured consistently? Are timers configured consistently? Is there an MTU mismatch?
If the answer to all of the above questions is "yes," and the adjacency still does not come up, it is time to dig deeper into what is happening between the neighbors. This means using whatever OSPF troubleshooting tools are available to you on the routers to record and decipher the conversation between the neighbors. Such tools can show exactly where the adjacency or database synchronization process failed, and will either tell you explicitly the cause of the failure or give you enough information for you to deduce the cause. Figure 6.9 shows a log file resulting from tracing OSPF events, packets, and states on a Juniper router. The log file (and the debug output in the next example) has been edited to eliminate extraneous information, such as Hellos to and from other neighbors. Figure 6.9. A traceoptions log (JUNOS) of a full OSPF adjacency being established.[View full width] jeff@Juniper6> show log ospf_state Dec 28 05:28:49 OSPF Interface fe-4/0/0.0 event Up Dec 28 05:28:49 OSPF interface fe-4/0/0.0 state  changed from Down to Waiting Dec 28 05:28:49 OSPF trigger router LSA build for area 0.0.0.0 Dec 28 05:28:49 OSPF built router LSA, area 0.0.0.0 Dec 28 05:28:50 OSPF sent Hello 192.168.7.1 -> 224 .0.0.5 (fe-4/0/0.0) Dec 28 05:28:50 Version 2, length 44, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:28:50 checksum 0x3d70, authtype 0 Dec 28 05:28:50 mask 255.255.255.0, hello_ivl 10 , opts 0x2, prio 128 Dec 28 05:28:50 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 28 05:28:51 OSPF rcvd Hello 192.168.7.2 -> 224 .0.0.5 (fe-4/0/0.0) Dec 28 05:28:51 Version 2, length 44, ID 192.168 .254.8, area 0.0.0.0 Dec 28 05:28:51 checksum 0x3ded, authtype 0 Dec 28 05:28:51 mask 255.255.255.0, hello_ivl 10 , opts 0x2, prio 1 Dec 28 05:28:51 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 28 05:28:51 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed from Down to Init Dec 28 05:28:51 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed by event HelloRcvd Dec 28 05:28:52 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed from Init to 2Way Dec 28 05:28:52 RPD_OSPF_NBRUP: OSPF neighbor 192 .168.7.2 (fe-4/0/0.0) state changed from Init to 2Way due to Two way communication established Dec 28 05:28:52 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed by event 2WayRcvd Dec 28 05:28:52 OSPF Interface fe-4/0/0.0 event NeighborChange Dec 28 05:29:29 OSPF Interface fe-4/0/0.0 event WaitTimer Dec 28 05:29:29 OSPF interface fe-4/0/0.0 state changed from Waiting to DR Dec 28 05:29:29 OSPF trigger router LSA build for area 0.0.0.0 Dec 28 05:29:29 OSPF trigger network LSA build for fe-4/0/0.0 Dec 28 05:29:29 OSPF DR is 192.168.254.6, BDR is 192.168.254.8 Dec 28 05:29:29 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed from 2Way to ExStart Dec 28 05:29:29 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed by event AdjOK? Dec 28 05:29:29 OSPF trigger router LSA build for area 0.0.0.0 Dec 28 05:29:29 OSPF sent DbD 192.168.7.1 -> 192 .168.7.2 (fe-4/0/0.0) Dec 28 05:29:29 Version 2, length 32, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:29:29 checksum 0x881b, authtype 0 Dec 28 05:29:29 options 0x42, i 1, m 1, ms 1, seq 0xc0a0ae8e, mtu 1500 Dec 28 05:29:29 OSPF built router LSA, area 0.0.0.0 Dec 28 05:29:30 OSPF sent Hello 192.168.7.1 -> 224 .0.0.5 (fe-4/0/0.0) Dec 28 05:29:30 Version 2, length 48, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:29:30 checksum 0xef65, authtype 0 Dec 28 05:29:30 mask 255.255.255.0, hello_ivl 10 , opts 0x2, prio 128 Dec 28 05:29:30 dead_ivl 40, DR 192.168.7.1, BDR 192.168.7.2 Dec 28 05:29:31 OSPF rcvd DbD 192.168.7.2 -> 192 .168.7.1 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 32, ID 192.168 .254.8, area 0.0.0.0 Dec 28 05:29:31 checksum 0xdc16, authtype 0 Dec 28 05:29:31 options 0x42, i 1, m 1, ms 1, seq 0x1b32, mtu 1500 Dec 28 05:29:31 OSPF now slave for nbr 192.168.7.2 Dec 28 05:29:31 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed from ExStart to Exchange Dec 28 05:29:31 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed by event NegotiationDone Dec 28 05:29:31 In sequence Dec 28 05:29:31 OSPF sent DbD 192.168.7.1 -> 192 .168.7.2 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 192, ID 192 .168.254.6, area 0.0.0.0 Dec 28 05:29:31 checksum 0x3a37, authtype 0 Dec 28 05:29:31 options 0x42, i 0, m 0, ms 0, seq 0x1b32, mtu 1500 Dec 28 05:29:31 OSPF rcvd DbD 192.168.7.2 -> 192 .168.7.1 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 212, ID 192 .168.254.8, area 0.0.0.0 Dec 28 05:29:31 checksum 0x34fe, authtype 0 Dec 28 05:29:31 options 0x42, i 0, m 1, ms 1, seq 0x1b33, mtu 1500 Dec 28 05:29:31 In sequence Dec 28 05:29:31 Database copy is older Dec 28 05:29:31 Database copy is older Dec 28 05:29:31 OSPF rcvd LSReq 192.168.7.2 -> 192 .168.7.1 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 84, ID 192.168 .254.8, area 0.0.0.0 Dec 28 05:29:31 checksum 0xb70b, authtype 0 Dec 28 05:29:31 OSPF sent LSReq 192.168.7.1 -> 192 .168.7.2 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 48, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:29:31 checksum 0x3b5d, authtype 0 Dec 28 05:29:31 OSPF rcvd LSUpdate 192.168.7.2 -> 192.168.7.1 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 96, ID 192.168 .254.8, area 0.0.0.0 Dec 28 05:29:31 checksum 0x9970, authtype 0 Dec 28 05:29:31 adv count 2 Dec 28 05:29:31 OSPF LSA Router 192.168.254.8 192 .168.254.8 from 192.168.7.2 newer than db Dec 28 05:29:31 OSPF LSA Router 192.168.254.8 192 .168.254.8 newer, delayed ack Dec 28 05:29:31 OSPF LSA Network 192.168.7.1 192 .168.254.6 from 192.168.7.2 newer than db Dec 28 05:29:31 Our LSA Dec 28 05:29:31 Removed from LSREQ list Dec 28 05:29:31 Removed from LSREQ list Dec 28 05:29:31 OSPF sent DbD 192.168.7.1 -> 192 .168.7.2 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 32, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:29:31 checksum 0xdc1e, authtype 0 Dec 28 05:29:31 options 0x42, i 0, m 0, ms 0, seq 0x1b33, mtu 1500 Dec 28 05:29:31 OSPF sent LSUpdate 192.168.7.1 -> 192.168.7.2 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 200, ID 192 .168.254.6, area 0.0.0.0 Dec 28 05:29:31 checksum 0xd628, authtype 0 Dec 28 05:29:31 adv count 5 Dec 28 05:29:31 OSPF rcvd DbD 192.168.7.2 -> 192 .168.7.1 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 32, ID 192.168 .254.8, area 0.0.0.0 Dec 28 05:29:31 checksum 0xdc1a, authtype 0 Dec 28 05:29:31 options 0x42, i 0, m 0, ms 1, seq 0x1b34, mtu 1500 Dec 28 05:29:31 In sequence Dec 28 05:29:31 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed from Exchange to Full Dec 28 05:29:31 RPD_OSPF_NBRUP: OSPF neighbor 192 .168.7.2 (fe-4/0/0.0) state changed from Exchange to Full due to DBD exchange complete Dec 28 05:29:31 OSPF trigger router LSA build for area 0.0.0.0 Dec 28 05:29:31 OSPF trigger network LSA build for fe-4/0/0.0 Dec 28 05:29:31 OSPF neighbor 192.168.7.2 (fe-4/0 /0.0) state changed by event ExchangeDone Dec 28 05:29:31 OSPF sent LSUpdate 192.168.7.1 -> 224.0.0.5 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 60, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:29:31 checksum 0xb25, authtype 0 Dec 28 05:29:31 adv count 1 Dec 28 05:29:31 OSPF rcvd LSUpdate 192.168.7.2 -> 224.0.0.5 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 140, ID 192 .168.254.8, area 0.0.0.0 Dec 28 05:29:31 checksum 0x9f55, authtype 0 Dec 28 05:29:31 adv count 4 Dec 28 05:29:31 OSPF LSA Summary 192.168.254.9 192 .168.254.8 from 192.168.7.2 newer than db Dec 28 05:29:31 OSPF LSA Summary 192.168.254.9 192 .168.254.8 newer, delayed ack Dec 28 05:29:31 OSPF LSA Summary 192.168.9.0 192 .168.254.8 from 192.168.7.2 newer than db Dec 28 05:29:31 OSPF LSA Summary 192.168.9.0 192 .168.254.8 newer, delayed ack Dec 28 05:29:31 OSPF LSA Summary 192.168.8.0 192 .168.254.8 from 192.168.7.2 newer than db Dec 28 05:29:31 OSPF LSA Summary 192.168.8.0 192 .168.254.8 newer, delayed ack Dec 28 05:29:31 OSPF LSA ASBRSum 192.168.254.9 192 .168.254.8 from 192.168.7.2 newer than db Dec 28 05:29:31 OSPF LSA ASBRSum 192.168.254.9 192 .168.254.8 newer, delayed ack Dec 28 05:29:31 OSPF sent DbD 192.168.7.1 -> 192 .168.7.2 (fe-4/0/0.0) Dec 28 05:29:31 Version 2, length 32, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:29:31 checksum 0xdc1d, authtype 0 Dec 28 05:29:31 options 0x42, i 0, m 0, ms 0, seq 0x1b34, mtu 1500 Dec 28 05:29:32 OSPF rcvd LSUpdate 192.168.7.2 -> 224.0.0.5 (fe-4/0/0.0) Dec 28 05:29:32 Version 2, length 64, ID 192.168 .254.8, area 0.0.0.0 Dec 28 05:29:32 checksum 0x60e6, authtype 0 Dec 28 05:29:32 adv count 1 Dec 28 05:29:32 OSPF LSA Router 192.168.254.8 192 .168.254.8 from 192.168.7.2 newer than db Dec 28 05:29:32 OSPF LSA Router 192.168.254.8 192 .168.254.8 newer, delayed ack Dec 28 05:29:32 OSPF sent LSAck 192.168.7.1 -> 224 .0.0.5 (fe-4/0/0.0) Dec 28 05:29:32 Version 2, length 124, ID 192 .168.254.6, area 0.0.0.0 Dec 28 05:29:32 checksum 0x51dc, authtype 0 Dec 28 05:29:32 OSPF rcvd Hello 192.168.7.2 -> 224 .0.0.5 (fe-4/0/0.0) Dec 28 05:29:32 Version 2, length 48, ID 192.168 .254.8, area 0.0.0.0 Dec 28 05:29:32 checksum 0xefe4, authtype 0 Dec 28 05:29:32 mask 255.255.255.0, hello_ivl 10 , opts 0x2, prio 1 Dec 28 05:29:32 dead_ivl 40, DR 192.168.7.1, BDR 192.168.7.2 Dec 28 05:29:32 OSPF Interface fe-4/0/0.0 event NeighborChange Dec 28 05:29:32 OSPF interface fe-4/0/0.0 state changed from DR to DR Dec 28 05:29:32 OSPF DR is 192.168.254.6, BDR is 192.168.254.8 Dec 28 05:29:33 OSPF sent Hello 192.168.7.1 -> 224 .0.0.5 (fe-4/0/0.0) Dec 28 05:29:33 Version 2, length 48, ID 192.168 .254.6, area 0.0.0.0 Dec 28 05:29:33 checksum 0xef65, authtype 0 Dec 28 05:29:33 mask 255.255.255.0, hello_ivl 10 , opts 0x2, prio 128 Dec 28 05:29:33 dead_ivl 40, DR 192.168.7.1, BDR 192.168.7.2
|
The log records the establishment of a full adjacency with a neighbor. At first glance, this pages-long log seems daunting. But with the knowledge you have gained concerning interface and neighbor states, events changing those states, and the packets and lists used for building an adjacency, you can follow what is going on. For that reason, the following text offers no explanation about what the log reveals, but instead challenges you to find your own answers. Here is the pertinent information: Router's RID: 192.168.254.6 Router's interface address: 192.168.7.1 Router's physical interface: fe-4/0/0.0 Neighbor's RID: 192.168.254.8 Neighbor's interface address: 192.168.7.2
As you read the log, pay attention to the timestamps, and be sure to differentiate between interface state changes and neighbor state changes. Consider the following: First break the log down by state changes. Beginning with the discovery of neighbor 192.168.254.8, how much time passes before the neighbor is fully adjacent? Notice that the neighbor state goes from Init to 2-Way and then to ExStart, rather than from Init to ExStart as in the example of the previous section. Examine the log entries for these state changes, and see whether you can find an explanation for this. (Hint: Pay attention to the interface state changes.) How long does the actual database exchange process take? Was there an existing DR or BDR on the network when synchronization began?
All router vendors have their own way of providing troubleshooting information, and the formats can vary widely. But if you understand the underlying protocol and its mechanisms, you should be able to adapt to any record of a protocol event with little effort. The neighboring router of the Juniper router in Figure 6.9 is a Cisco Systems router, and its physical interface connecting to the network is E0. Figure 6.10 shows the output from an IOS debug of OSPF adjacency, event, and packet over roughly the same time period covered in Figure 6.9. Figure 6.10. A debug output (IOS) of the same adjacency establishment, from the viewpoint of the other neighbor.[View full width] Dec 28 05:28:50: OSPF: rcv. v:2 t:1 l:44 rid:192 .168.254.6 aid:0.0.0.0 chk:3D70 aut:0 auk: from Ethernet0 Dec 28 05:28:50: OSPF: Rcv hello from 192.168.254 .6 area 0 from Ethernet0 192.168.7.1 00:42:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up Dec 28 05:28:51: OSPF: Interface Ethernet0 going Up Dec 28 05:28:51: OSPF: Build router LSA for area 0 , router ID 192.168.254.8, seq 0x800001D9 Dec 28 05:28:51: OSPF: Build router LSA for area 20, router ID 192.168.254.8, seq 0x800001D4 Dec 28 05:28:52: OSPF: 2 Way Communication to 192 .168.254.6 on Ethernet0, state 2WAY Dec 28 05:28:52: OSPF: End of hello processing Dec 28 05:29:01: OSPF: rcv. v:2 t:1 l:48 rid:192 .168.254.6 aid:0.0.0.0 chk:7EBA aut:0 auk: from Ethernet0 Dec 28 05:29:29: OSPF: rcv. v:2 t:2 l:32 rid:192 .168.254.6 aid:0.0.0.0 chk:881B aut:0 auk: from Ethernet0 Dec 28 05:29:29: OSPF: Rcv DBD from 192.168.254.6 on Ethernet0 seq 0xC0A0AE8E opt 0x42 flag 0x7 len 32 mtu 1500 state 2WAY Dec 28 05:29:29: OSPF: Nbr state is 2WAY Dec 28 05:29:30: OSPF: rcv. v:2 t:1 l:48 rid:192 .168.254.6 aid:0.0.0.0 chk:EF65 aut:0 auk: from Ethernet0 Dec 28 05:29:30: OSPF: Rcv hello from 192.168.254 .6 area 0 from Ethernet0 192.168.7.1 Dec 28 05:29:30: OSPF: End of hello processing Dec 28 05:29:31: OSPF: end of Wait on interface Ethernet0 Dec 28 05:29:31: OSPF: DR/BDR election on Ethernet0 Dec 28 05:29:31: OSPF: Elect BDR 192.168.254.8 Dec 28 05:29:31: OSPF: Elect DR 192.168.254.6 Dec 28 05:29:31: OSPF: Elect BDR 192.168.254.8 Dec 28 05:29:31: OSPF: Elect DR 192.168.254.6 Dec 28 05:29:31: DR: 192.168.254.6 (Id) BDR : 192.168.254.8 (Id) Dec 28 05:29:31: OSPF: Send DBD to 192.168.254.6 on Ethernet0 seq 0x1B32 opt 0x42 flag 0x7 len 32 Dec 28 05:29:31: OSPF: rcv. v:2 t:2 l:192 rid:192 .168.254.6 aid:0.0.0.0 chk:3A37 aut:0 auk: from Ethernet0 Dec 28 05:29:31: OSPF: Rcv DBD from 192.168.254.6 on Ethernet0 seq 0x1B32 opt 0x42 flag 0x0 len 192 mtu 1500 state EXSTART Dec 28 05:29:31: OSPF: NBR Negotiation Done. We are the MASTER Dec 28 05:29:31: OSPF: Send DBD to 192.168.254.6 on Ethernet0 seq 0x1B33 opt 0x42 flag 0x3 len 212 Dec 28 05:29:31: OSPF: Database request to 192.168 .254.6 Dec 28 05:29:31: OSPF: sent LS REQ packet to 192 .168.7.1, length 60 Dec 28 05:29:31: OSPF: rcv. v:2 t:3 l:48 rid:192 .168.254.6 aid:0.0.0.0 chk:3B5D aut:0 auk: from Ethernet0 Dec 28 05:29:31: OSPF: rcv. v:2 t:2 l:32 rid:192 .168.254.6 aid:0.0.0.0 chk:DC1E aut:0 auk: from Ethernet0 Dec 28 05:29:31: OSPF: Rcv DBD from 192.168.254.6 on Ethernet0 seq 0x1B33 opt 0x42 flag 0x0 len 32 mtu 1500 state EXCHANGE Dec 28 05:29:31: OSPF: Send DBD to 192.168.254.6 on Ethernet0 seq 0x1B34 opt 0x42 flag 0x1 len 32 Dec 28 05:29:31: OSPF: rcv. v:2 t:4 l:200 rid:192 .168.254.6 aid:0.0.0.0 chk:D628 aut:0 auk: from Ethernet0 Dec 28 05:29:31: OSPF: rcv. v:2 t:4 l:60 rid:192 .168.254.6 aid:0.0.0.0 chk:B25 aut:0 auk: from Ethernet0 Dec 28 05:29:31: OSPF: rcv. v:2 t:2 l:32 rid:192 .168.254.6 aid:0.0.0.0 chk:DC1D aut:0 auk: from Ethernet0 Dec 28 05:29:31: OSPF: Rcv DBD from 192.168.254.6 on Ethernet0 seq 0x1B34 opt 0x42 flag 0x0 len 32 mtu 1500 state EXCHANGE Dec 28 05:29:31: OSPF: Exchange Done with 192.168 .254.6 on Ethernet0 Dec 28 05:29:31: OSPF: Synchronized with 192.168 .254.6 on Ethernet0, state FULL Dec 28 05:29:32: OSPF: Build router LSA for area 0 , router ID 192.168.254.8, seq 0x800001DA Dec 28 05:29:32: OSPF: rcv. v:2 t:5 l:124 rid:192 .168.254.6 aid:0.0.0.0 chk:51DC aut:0 auk: from Ethernet0 Dec 28 05:29:33: OSPF: rcv. v:2 t:1 l:48 rid:192 .168.254.6 aid:0.0.0.0 chk:EF65 aut:0 auk: from Ethernet0 Dec 28 05:29:33: OSPF: Rcv hello from 192.168.254 .6 area 0 from Ethernet0 192.168.7.1 Dec 28 05:29:33: OSPF: Neighbor change Event on interface Ethernet0 Dec 28 05:29:33: OSPF: DR/BDR election on Ethernet0 Dec 28 05:29:33: OSPF: Elect BDR 192.168.254.8 Dec 28 05:29:33: OSPF: Elect DR 192.168.254.6 Dec 28 05:29:33: DR: 192.168.254.6 (Id) BDR : 192.168.254.8 (Id) Dec 28 05:29:33: OSPF: End of hello processing Dec 28 05:29:34: OSPF: rcv. v:2 t:4 l:120 rid:192 .168.254.6 aid:0.0.0.0 chk:B658 aut:0 auk: from Ethernet0
|
Again, segment the entries by state changes. Match events in this debug output with the log entries in Figure 6.9. The clocks of the two routers are not synchronized, and might vary by a second or two. But identify matching events between the two router outputs. Do the time periods match? Try drawing a graph of exchanges and state changes between the two routers, similar to the graph in Figure 6.7, using the information in Figures 6.9 and 6.10.
6.1.8. Troubleshooting: Comparing OSPF LS Databases Routing problemsincorrect forwarding of packetsin modern OSPF or IS-IS networks almost always have a mundane cause such as a link failure or a router misconfiguration. The source of the problem can usually be discovered by analysis of the information in the routing and forwarding tables. Rarely is a routing problem the result of inconsistent LS databases in an area, because an unresolved inconsistency during database synchronization should cause an adjacency failure and the path between the routers involved is not considered in routing decisions. However, unsynchronized LS databases do occur. They likely are the result of a bad or buggy OSPF implementation. This section demonstrates how to compare databases, for those rare occasions when no more obvious cause for your routing problems can be found. You should start by comparing summaries of the databases, to ensure that they both have the same number of each type of LSA. As with the examples in the previous section, outputs will vary from router vendor to router vendor, but the information is the same as long as you know what you are looking for. Figures 6.11 and 6.12 show database summaries from a Juniper and Cisco router, respectively (the same neighbors that that were used in the example in the previous section). Comparing the two summaries, you can see that the databases for area 0 match: Figure 6.11. A JUNOS summary of a link state database.jeff@Juniper6> show ospf database summary Area 0.0.0.0: 4 Router LSAs 4 Network LSAs 10 Summary LSAs 1 ASBRSum LSAs Externals: 2 Extern LSAs
|
Figure 6.12. An IOS summary of a link state database.[View full width] Cisco8#show ip ospf database database-summary OSPF Router with ID (192.168.254.8) (Process ID 1) Area 0 database summary LSA Type Count Delete Maxage Router 4 0 0 Network 4 0 0 Summary Net 10 0 0 Summary ASBR 1 0 0 Type-7 Ext 0 0 0 Opaque Link 0 0 0 Opaque Area 0 0 0 Subtotal 19 0 0 Area 20 database summary LSA Type Count Delete Maxage Router 2 0 0 Network 1 0 0 Summary Net 13 0 0 Summary ASBR 0 0 0 Type-7 Ext 0 0 0 Opaque Link 0 0 0 Opaque Area 0 0 0 Subtotal 16 0 0 Process 1 database summary LSA Type Count Delete Maxage Router 6 0 0 Network 5 0 0 Summary Net 23 0 0 Summary ASBR 1 0 0 Type-7 Ext 0 0 0 Opaque Link 0 0 0 Opaque Area 0 0 0 Type-5 Ext 2 0 0 Opaque AS 0 0 0 Total 37 0 0 Cisco8#
|
The router in Figure 6.12 also has a LS database for area 20, because it is an ABR. But the information in that portion of the summary is irrelevant to us; the interfaces connecting the two neighbors are in area 0. Even if the number of each type of LSA matches between the databases, an instance of one or more LSAs in the two databases may be inconsistent. You can check this by adding the checksums of all LSAs in each database: If the LSA instances are all the same, the sum of checksums will be equal. If the checksums are not equal, a one-by-one comparison of the checksums of each LSA will reveal the culprit. Figures 6.13 and 6.14 show the LSA headers of the two neighbors in the previous example. Adding the checksums of the LSAs specific to area 0, both databases produce a sum of 0x6C0D: Router LSA checksum total = 0x2938A. Network LSA checksum total = 0x24718. Network Summary checksum total = 0x5F5AE. ASBR Summary checksum = 0x7BBD.
The sum of the two AS-External checksums is 0x12406. Of course, with just two LSAs comparing the individual checksums is easier than comparing their sums. In fact, it is debatable whether it is easier to compare sums of checksums or just compare checksums one by one even in larger databases. The problem is that in large-scale networks, the link state databases are likely to be very much longer than these examples and either method of comparing checksums is going to be tedious and error-prone. Adding to the difficulties, if a database refresh takes place between the time you capture the first database display and the time you capture the second, the checksums will change and your sums will not matcheven though there is no real inconsistency between the databases. Fortunately, there is a solution. If you are managing a large OSPF network, you are likely using some SNMP-based management software. Some OSPF MIBs return the sums of checksums, saving you the tedium of hand calculating them: ospfAreaLsaCksumSum returns the sum of checksums for an area, not including AS-External LSAs. ospfExternLsaCksumSum returns the sum of AS-external (type 5) LSA checksums.
Unfortunately, mismatched sums of checksums only indicate a synchronization problem. This information does not show the cause or reveal which LSAs do not match. But you probably do not need to know more than that the databases are out of sync. If you've confirmed that much, try manually breaking and then restarting the adjacency, allowing the neighbors to resynchronize. If the problem does not go away (and stay away), a call to your vendor's support team is needed for in-depth analysis of what is probably an implementation problem. |
