OSPF Adjacencies Tshoot

Problem: OSPF Neighbor List is Empty

This is the most common problem in OSPF neighbor relationships. The most common causes are related to either misconfiguration or lack of configuration. If the neighbor list is empty, it will not even proceed to form OSPF neighbor relationships.

Most common possible causes for this problem are:

  • OSPF not enabled on the interface
  • Layer 1/2 is down
  • Interface defined as Passive
    • When interface is defined as passive, it suppresses OSPF Hellos. This means that OSPF does not send or receive any Hellos on such interfaces. Therefore, no adjacency is formed.
  • An ACL blocking Hellos on both sides
  • Subnet mask mismatched
    • OSPF performs the subnet number and mask check on all media except point-to-point and virtual links as specified. The network mask gets advertised in the Hello packet.
    • In the case of unnumbered point-to-point links and virtual links, the network mask field contains 0.0.0.0.
    • If the subnet mask is different across the Ethernet link, OSPF will not form a neighbor relationship on that link.
  • Hello/Dead interval mismatched
  • Authentication Type (plain vs MD5) mismatched
    • OSPF uses two types of authentication, plain-text (Type 1) and MD5 (Type 2). Type 0 is called null authentication.
    • If the plain-text authentication type is enabled on one side, the other side must also have plain-text authentication.
    • OSPF will not form an adjacency unless both sides agree on the same authentication type.
  • Authentication key mismatched
  • Area ID mismatched
    • OSPF sends area information in the Hello packets. The area information is a part of the OSPF protocol header.
    • If both sides do not agree that they are members of a common area, no OSPF adjacency will be formed.
  • Stub/transit/NSSA area options mismatched
    • If one neighbor is configured as a stub area router and another neighbor is not, there will be no adjacency formed because the stub area flags do not match.
  • OSPF adjacency with Secondary IP address
    • OSPF utilizes the primary IP address as the source of all Hello packets sent on that interface. Neighbor relationships will not form based on secondary IP addressing.

Problem: OSPF Neighbor Stuck in INIT

When a router receives an OSPF Hello from a neighbor, it sends the Hello packet by including that neighbor’s router ID in the Hello packet. If it doesn’t include the neighbor’s router ID, the neighbor will be stuck in INIT. This is an indication of a problem.

The first packet that a router receives will cause the router to go into INIT state. At this point, it is not a problem, but if the router stays in this state for a long time, it’s an indication of a problem. It means that the neighbor router is not seeing Hellos sent by this router—that’s why it is not including the router ID of the router in its Hello packet.

Most common possible causes for this problem are:

  • ACL on one side blocking OSPF hellos
  • Authentication is enabled on only one side
  • Hellos getting lost on one side at Layer 2

OSPF sends Hello packets to the multicast address of 224.0.0.5. If an access list is configured that doesn’t explicitly permit this address, it will be denied. The Hellos cannot get through the access list and the neighbor is stuck in INIT state. The stuck in INIT problem occurs only if one side is blocking OSPF Hellos. If both sides are blocking OSPF Hellos, the output of show ip ospf neighbor returns an empty list.

When authentication is used, it must be enabled on both sides; otherwise, one side will show the neighbor stuck in the INIT state. The router that has authentication enabled will reject all the nonauthenticated packets, and the adjacency will show stuck in INIT. Hellos from the nonauthenticating router will be dropped.

This situation happens when there is a problem on the Layer 2 media.

When R1 sends the Hello, R2 never receives it. Because R2 never saw Hellos from R1, the neighbor list of R2 will be empty. However, R1 sees the Hellos from R2, which does not list R1 as a valid neighbor; so, R1 declares this neighbor in the INIT state.

R1 keeps sending OSPF Hellos but never receives any Hellos from R2. This means that R2’s Hellos are getting lost in the middle because the debug shows that R2 is sending as well as receiving OSPF Hellos.

The debug is done on both sides, and it is clear that both sides are sending Hellos but R1 Hellos never get across. Most likely, the Frame Relay cloud or other Layer 2 medium is dropping this multicast packet. This also can be verified by using a sniffer on the wire.

Problem: OSPF Neighbor Stuck in 2-WAY

It is normal in broadcast media to have a 2-WAY state because not every router becomes adjacent on broadcast media. Every router enters into FULL state with the DR and the BDR.

Example: There are only two routers on Ethernet; both are configured with priority 0. Priority 0 means that this router will not take part in DR/BDR election process. This configuration is useful when there are “low-end” routers on the segment and the desire is not to make those low-end routers DRs. For this purpose, you should configure priority 0.

By default, the priority is set to 1. A router with the highest priority on a segment wins a DR election. If all priorities are kept to the default, the router with the highest router ID becomes the DR. If all the routers on an Ethernet segment are configured with priority 0, no routers on the segment will be in FULL state with any other router. This creates problems. At least one router on the segment must have a priority that is not set to 0.

Solution: Remove the priority 0 on at least one router so that router becomes a DR and forms a FULL adjacency.

Problem: OSPF Neighbor Stuck in EXSTART/EXCHANGE

In this state, the router elects a master and a slave and the initial sequence number. The whole database also is exchanged during this state. If a neighbor is stuck in EXSTART/EXCHANGE for a long time, it is an indication of a problem.

Most common possible causes:

  • Mismatched interface MTU
  • Duplicate router IDs on neighbors
  • Inability to ping across with more than certain MTU size
  • Broken unicast connectivity due to ACLs or NAT translating the unicast

The interface MTU of both sides of an OSPF neighbor relationship must match; otherwise, the neighbor relationship will not form.

When OSPF sends a DBD packet to elect a master and a slave, the router with the highest router ID becomes the master. This happens in the EXSTART process. If there is any problem with election, the router will be stuck in the EXSTART/EXCHANGE state.

If a neighbor router has the same router ID as the local router, no neighbor relationship will form. The router ID must be unique within the entire internetwork.

Issue: R2 is sending a DBD packet with a flag of 7, saying, “I am the master.” R2 also receives a DBD from R1 saying, “I am the master.” R2 compares R1’s router ID and sees that it is not higher than its own, so it sends the DBD packet to R1 saying, “I am the master.” So, both routers keep fighting for the master status and the router gets stuck in the EXSTART state.

Note: Cisco IOS Software Release 12.0 and later provide a warning message, OSPF-3-DUP_RTRID, that warns if there is a duplicate router ID.

When OSPF begins forming an adjacency with its neighbor, it goes through several states.

  • In EXSTART state, OSPF determines which will be the master and which will be the slave.
  • After the routers decided this, they start exchanging the LSA header in the form of DBD packets. If the database is huge, OSPF uses the interface MTU and tries to send as much data as possible up to the limit of the interface MTU.
  • If there is a problem with Layer 2 accepting large packets that are within the interface MTU range, the OSPF adjacency will be stuck in the EXCHANGE state.

Is the neighbor reachable through ping with a large MTU size? Neighbor must be able to accept the largest MTU size packet it can handle; otherwise, it’s a Layer 2.

The debug shows that R2 keeps retransmitting the DBD packets every 5 seconds, which is a default, and is not receiving any reply. Also note that the length of this packet is 1274 and the flag value is 3; this means that R2 is a master.

When R1 pings R2 with an MTU equal to or greater than 1200, the ping never reaches the other side. This indicates a problem at Layer 2. R1 can ping R2 when using a 100-byte datagram, but the ping starts failing when the datagram size is greater than 1200 bytes.

Solution

One way to narrow this problem is to connect the two devices directly instead of going through switches and so forth, to see whether the problem is with the Layer 2 devices or with the router itself. If connecting routers back to back doesn’t fix the problem, there is a possibility of bad hardware. Most times, it turns out to be a problem in the middle.

When OSPF routers begin exchanging database information with each other, they send a unicast packet to each other in EXSTART/EXCHANGE state. This happens only if the network type is not a point-to-point link. In cases of a point-to-point link, OSPF sends all multicast packets. If unicast connectivity is broken, OSPF neighbor remains in EXSTART state.

Possible issues:

  • ACL blocking unicast
    • If an access list is configured on a router, make sure that it’s not blocking the unicast packet.
  • NAT translating the unicast
    • If NAT is misconfigured, it will start translating the unicast packet coming toward it, which will break the unicast connectivity.

Example: When R2 sends a unicast packet to R1, R1 tries to translate that packet and R2 never receives the ping reply. The main thing to watch for is the access list in NAT. If the access list is permitting everything, this problem will occur.

To solve this problem, change access list and permit only those IP address that require translation.

Problem: OSPF Neighbor Stuck in Loading

When a neighbor is stuck in the LOADING state, the local router has sent a link-state request packet (LSR) to the neighbor requesting an outdated or missing LSA and is waiting for an update from its neighbor. If a neighbor doesn’t reply or a neighbors’ reply never reaches the local router, the router will be stuck in the LOADING state.

Most common possible causes:

  • Mismatched MTU
  • Corrupted link-state request packet

When a link-state request packet is corrupted, the neighbor discards the packet and the local router never receives the response from the neighbor. This causes the OSPF neighbor to be stuck in the LOADING state.

Link-state request packets usually become corrupted because of the following reasons:

  • A device between the neighbors, such as a switch, is corrupting the packet.
  • The sending router’s packet is invalid. In this case, either the sending router’s interface is bad or the error is caused by a software bug.
  • The receiving router is calculating the wrong checksum. In this case, either the receiving router’s interface is bad or the error is caused by a software bug. This is the least likely cause of this error message.

Solution

Most of the time, this problem is fixed by replacing hardware. This could be a simple bad port on the switch or a bad interface card on the sending/receiving router.

Tags:

Leave a Reply