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:
- Misconfigured neighbor statement
- Unicast
connectivity is broken on NBMA, which could be due to a wrong
DLCI, an access list, or NAT translating the unicast.
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: - An access list on one side is blocking OSPF
Hellos.
- Multicast capabilities are broken on one side
(switch problem).
- Authentication is enabled on only
one side.
- The frame-relay map/dialer map statement on
one side is missing the broadcast keyword.
- Hellos are
getting lost on one side at Layer 2.
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:
- Mismatched interface MTU.
- Duplicate Router
IDs on neighbors.
- Inability to ping across with more
than certain MTU size.
- Broken unicast connectivity,
which could be due to a wrong DLCI, an access list, or NAT