In various cases, routes may end up missing, and you need to be able to determine why the routers would not become neighbor. This article discusses the various ways that you can identify the issues in EIGPR and OSPF to solve the problem.
EIGRP Neighbor Verification Checks
Any two EIGRP routers that connect to the same data link, and their interfaces have been enabled for EIGRP and are not passive, will at least consider becoming neighbors. To quickly and definitively know which potential neighbors have passed all the neighbor requirements for EIGRP, just look at the output of the show ip eigrp neighbors command. This command lists only neighbors that have passed all the neighbor verification checks.
If the show ip eigrp neighbors command does not list one or more expected neighbors, the first problem isolation step should be to find out if the two routers can ping each others’ IP addresses on the same subnet. If that works, start looking at the list of neighbor verification checks, as relisted for EIGRP here in the table below. The table summarizes the EIGRP neighbor requirements, while noting the best commands with which to determine which requirement is the root cause of the problem.
By default, routers do not attempt EIGRP authentication, which allows the routers to form EIGRP neighbor relationships. If one router uses authentication, and the other does not, they will not become neighbors. If both use authentication, they must use the same authentication key to become neighbors.
EIGRP K-values, refers to the EIGRP metric components and the metric calculation. These K values are variables that basically enable or disable the use of the different components in the EIGRP composite metric. Cisco recommends leaving these values at their default settings, using only bandwidth and delay in the metric calculation. The K-value settings must match before two routers will become neighbors; you can check the K-values on both routers with the show ip protocols command .
OSPF Neighbor Troubleshooting
Similar to EIGRP, the show ip ospf neighbor command lists all the neighboring routers that have met all the requirements to become an OSPF neighbor. The example below lists the output of a show ip ospf neighbor command. All routers sit on the same LAN subnet, in area 0, with correct configurations, so all three routers form a valid OSPF neighbor relationship.
First, note that the neighbor IDs, listed in the first column, identify neighbors by their router ID (RID). For this example network, all four routers use an easily guessed RID. Further to the right, the Address column lists the interface IP address used by that neighbor on the common subnet.
A brief review of OSPF neighbor states can help you understand a few of the subtleties of the output in the example. A router’s listed status for each of its OSPF neighbors—the neighbor’s state—should settle into either a 2-way or full state under normal operation.
For neighbors that do not need to directly exchange their databases, typically two non designated router (DR) routers on a LAN, the routers should settle into a 2-way neighbor state. In most cases, two neighboring routers need to directly exchange their full link-state databases (LSDB) with each other. As soon as that process has been completed, the two routers settle into a full neighbor state.
If the show ip ospf neighbor command does not list one or more expected neighbors, you should confirm, even before moving on to look at OSPF neighbor requirements, that the two routers can ping each other on the local subnet. But if the two neighboring routers can ping each other, and the two routers still do not become OSPF neighbors, the next step is to examine each of the OSPF neighbor requirements. The table below summarizes the requirements, listing the most useful commands with which to find the answers .
Finding Area Mismatches
The debug ip ospf adj command helps troubleshoot mismatched OSPF area problems and authentication problems. The first highlighted messages in the example lists shorthand about a received packet (“Rcv pkt”). The example below shows mismatch error that R1 received from other router. The rest of the message mentions R1’s area (0.0.0.0), and the area claimed by the other router (0.0.0.1). Note that these messages list the 32-bit area number as a dotted-decimal number.
Finding OSPF Hello and Dead Timer Mismatches
As you may know, EIGRP allows neighbors to use a different Hello timer but in OSPF, Hello and Dead timers must be the same in both routers in order for them to become neighbor. The example below shows the easiest way to find the mismatch, using the show ip ospf interface command. This command lists the Hello and Dead timer for each interface, as highlighted in the example.
The debug ip ospf hello command can also uncover this problem because it lists a message for each Hello that reveals the Hello/dead timer mismatch, as shown in Example.
Mismatched OSPF Network Types
OSPF defines a concept for each interface called a network type. The OSPF network type tells OSPF some ideas about the data link to which the interface connects. In particular, the network type tells a router:
- Whether the router can dynamically discover neighbors on the attached link (or not)
- Whether to elect a DR and BDR (or not)
Serial interfaces that use some point-to-point data link protocol, like HDLC or PPP, default to use an OSPF network type of point-to-point. Ethernet interfaces default to use an OSPF network type of broadcast. Both types allow the routers to dynamically discover the neighboring OSPF routers, but only the broadcast network type causes the router to use a DR/BDR.
The show ip ospf interface command lists an interface’s current OSPF network type. Example below shows router R1 with a network type of “broadcast” on its G0/0 interface .
Mismatched MTU Settings
The MTU size defines a per-interface setting used by the router for its Layer 3 forwarding logic, which defines the largest network layer packet that the router will forward out each interface. For instance, the IPv4 MTU size of an interface defines the maximum size IPv4 packet that the router can forward out an interface.
Routers often use a default mtu size of 1500 bytes, with the ability to set the value as well. The ip mtu size interface subcommand defines the IPv4 mtu setting, and the ipv6 mtu size command sets the equivalent for IPv6 packets.
In an odd twist, two OSPFv2 routers can actually become OSPF neighbors, and reach 2-way state, even if they happen to use different IPv4 mtu settings on their interfaces. However, they fail to exchange their LSDBs. Eventually, after trying and failing to exchange their LSDBs, the neighbor relationship also fails.