so that it can attempt to reinstall the routes that it is holding in the topology table. Error: EIGRP: DDB not configured on interface
This means that when the routers interface receives an EIGRP hello packet and the router attempts to associate the packet with a DUAL descriptor block (DDB) for that interface, it does not find one that matches. This means that the router is receiving a hello packet on the interface that does not have EIGRP configured. Poison squashed
The router threads a topology table entry as poison in reply to an update (the router set up for poison reverse). While the router is building the packet that contains the poison reverse, the router realizes that it does not need to send it. For example, if the router receives a query for that route from the neighbor, it is currently threaded to poison.
Content 5.7 Troubleshooting OSPF 5.7.1 Mismatched parameters For OSPF to form and maintain neighbor adjacencies, several parameters must match. OSPF neighbors exchange Hello packets periodically to form neighbor relationships. If specific parameters do not match, the neighbor adjacency will not be formed and the routers will not exchange OSPF updates. Most mismatch issues can be seen using the debug ip ospf adj command. Hello/Dead Interval Mismatch
The output of R2 debug ip ospf adj, when the neighbor Hello interval does not match with Router R2, is shown in Figure . R refers to “Received” and C refers to “Configured”. Figure shows the configuration of routers R1 and R2. R2 has the default Hello interval of 10 seconds, whereas R1 has been configured with the Hello interval of 15 seconds. Both the Hello and the Dead intervals must match for routers to form an adjacency. Figure shows the corrected configuration of R1. Figure displays the output of the show ip ospf neighbor command. This shows that after configuring the same Hello interval, OSPF forms an adjacency. Mismatched Authentication Type
The output of R2 debug ip ospf adj indicates that the R2 neighbor is configured for MD5 authentication and that R2 is configured for plain-text authentication. In Figure , the configurations of routers R1 and R2 show that both are using different authentication methods. To fix this problem, both routers must be configured to use the same type of authentication, which can be verified using the show ip ospf neighbor command. Note: Besides the authentication type, the authentication key must also match. Beginning with Cisco IOS 12.0.8, RFC 2328 is now supported, which allows authentication to be configured on a per-interface basis. Prior to this release, authentication was only supported on a per-area basis. Mismatch Area ID
OSPF sends area information in Hello packets. If both sides do not agree that both routers are members of a common area, no OSPF adjacency will be formed. The area information is part of the OSPF protocol header. The output of debug ip ospf adj on R1, as shown in Figure , indicates that R1 is receiving an OSPF packet from R2 and that the OSPF header has area 0.0.0.1. Looking at the configurations on both routers, shown in Figure proves that the two routers are configured for different areas. The solution to this problem is to configure the same area across this common link. To solve this problem, change the area of router R1 to area 1. Using the show ip ospf neighbor command will verify that the routers have formed a neighbor relationship. Mismatched Stub/Transit/NSSA Area Options
When OSPF exchanges Hello packets with a neighbor, one of the things that it exchanges is an optional capability represented by 8 bits. One of the option fields is for the E bit, which is the OSPF stub flag. When the E bit is set to 0, the area with which the route is associated is a stub area, and no external LSAs are allowed in this area. If the E bit does not match on both sides, an adjacency will not be formed. This is called an optional capabilities mismatch. The output of debug ip ospf adj on R1 indicates a stub/transit bit mismatch. Figure verifies the configuration mismatch. The solution would be to configure the routers with the appropriate stub commands. A configuration change on R1 that fixes the problem is shown in Figure . Router R1 is now also a part of the stub area. Using the show ip ospf neighbor command will verify that the routers have formed a neighbor relationship.
Content 5.7 Troubleshooting OSPF 5.7.2 OSPF state issues Routers being neighbors does not guarantee an exchange of link state updates. Neighbor routers must form adjacencies in order for this to happen. Interface type plays a major role in how the adjacencies are formed. For example, neighbors on point-to-point links always become adjacent. Once a router decides to form an adjacency with a neighbor, it starts by exchanging a full copy of its link state database. The neighbor follows suit. After passing through several neighbor states, the routers will become adjacent. The following is a list of the different states that OSPF can be stuck in and some of the possible causes. OSPF Stuck in ATTEMPT
This problem is only valid for NMBA networks in which neighbor statements have been defined. Stuck in ATTEMPT means that a router is trying to contact a neighbor by sending its Hello, but it has not received a response. The output of show ip ospf neighbor indicates this problem exists. The most common possible causes of the problem are: OSPF Stuck in 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 hello packets coming from the neighbor router. The output of the show ip ospf neighbor command indicates that the router is stuck in INIT. The most common possible causes of this problem are: OSPF Stuck in 2-WAY
The 2-WAY state is an indication that the router has seen its own Router ID in the neighbor field of the neighbor hello packet. The reception of a Database Descriptor (DBD) packet from a neighbor in the INIT state will also cause a transition to 2-way state. The OSPF neighbor 2-WAY state is not a cause for concern. On networks that require a DR/BDR election to take place, if all routers are configured with priority 0, there will be no election process. All routers will remain in 2-WAY state, as the show ip ospf neighbor command will indicate. The solution is to make sure at least one router has an ip ospf priority of at least 1. OSPF Stuck in EXSTART/EXCHANGE
OSPF neighbors that are in EXSTART or EXCHANGE state are in the process of trying to exchange DBD packets. The router and its neighbor form a master/slave relationship. The adjacency should continue past this state. If it does not, there is a problem with the DBD exchange, such as MTU mismatch, or the receipt of an unexpected DBD sequence number. The most common possible causes of this problem are: