Tag Archives: 3.6b

3.6.b Implement and troubleshoot neighbor relationship

You can use the show ip ospf neighbor command to determine the state of the OSPF neighbor or neighbors.

If the show ip ospf neighbor command reveals nothing at all— or reveals nothing about the particular neighbor you are analyzing— then this router has not seen any “valid” OSPF HELLOs from that neighbor. This means that OSPF either did not receive any HELLO packets from the neighbor or received HELLO packets that failed very basic sanity checks.

● state = down

A neighbor that is discovered dynamically through reception of HELLO packets can fall back to a down state if it is being deleted, for example when OSPF does not receive HELLO packets from the neighbor for period of time longer than the Dead timer interval . Therefore, the down state is transient for such neighbors; they will either advance to higher states or be completely deleted from the table of known neighbors. This is known as being “forgotten”.

Usually, neighbors that are seen in the down state were manually configured with the neighbor command. Manually configured neighbors are always present in the configured neighbor, or if no HELLO packets were heard from the neighbor during the previous Dead timer interval, then the manually configured neighbor will be listed as down.

● state = init

The init state indicates that a router sees HELLO packets from the neighbor, but two-way communication has not been established . A Cisco router includes the Router IDs of all neighbors in the init (or higher) state in the Neighbor field of its HELLO packets. For two-way communication to be established with a neighbor, a router also must see its own Router ID in the Neighbor field of the neighbor’s HELLO packets.

● state = exstart / exchange

OSPF neighbors that are in exstart or exchange state are trying to exchange DBD packets. The router and its neighbor form a master and slave relationship. The adjacency should continue past this state. If it does not, there is a problem with the DBD exchange, such as a maximum transmission unit (MTU) mismatch or the receipt of an unexpected DBD sequence number

● state = 2-way

The 2-way state indicates that the router has seen its own Router ID in the Neighbor field of the neighbor’s HELLO packet. Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state. The OSPF neighbor 2-way state is not a cause for concern (e.g. for broadcast network type).

● state = loading

In the loading state, routers send link-state request packets. During the adjacency, if a router receives an outdated or missing link-state advertisement (LSA), it requests that LSA by sending a link-state request packet. Neighbors that do not transition beyond this state are most likely exchanging corrupted LSAs. This problem is usually accompanied by a %OSPF-4-BADLSA console message. A common problem when using Open Shortest Path First (OSPF) is routes in the database don’t appear in the routing table. In most cases OSPF finds a discrepancy in the database so it doesn’t install the route in the routing table. Often, you can see the Adv Router is not-reachable message (which means that the router advertising the LSA is not reachable through OSPF) on top of the link-state advertisement (LSA) in the database when this problem occurs.
Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 3398-3410).  . Kindle Edition.

http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13699-29.html
http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7112-26.html