Beruflich Dokumente
Kultur Dokumente
l The authentication type (plain text versus MD5) has been mismatched.
l No network type or neighbor is defined over NBMA (Frame Relay, X.25, SMDS, and so on).
l The frame-relay map/dialer map statement is missing the broadcast keyword on both sides.
Figure 9-1 shows two routers running OSPF between each other. The output of show ip ospf
neighbor shows an empty list. In a normal scenario, the output displays the OSPF neighbor status.
This figure is used for most of the causes described in this section.
Figure 9-1. OSPF Network Topology Vulnerable to Empty OSPF Neighbor List
Problem
Example 9-1 shows the output of show ip ospf neighbor, which shows the empty neighbor list.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 2 of 40
R2#
Example 9-2 shows the configuration of Router R2. The configuration shows that the wrong mask is
put under the network statement that includes only loopback 0 into area 0. The network state-ment
is determined in OSPF in exactly the same way that you define an access list. The main idea here is to
include the range of addresses in an area. In Example 9-2, the network statement of 131.108.0.0
with the wildcard mask of 0.0.0.255 will not cover 131.108.1.2; it covers only the range from
131.108.0.0 to 131.108.0.255, as indicated by the wildcard mask.
R2#
interface Loopback0
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 3 of 40
interface Ethernet0
router ospf 1
Example 9-3 shows the configuration of Router R2. OSPF is not enabled on the Ethernet interface of
R2.
Solution
Sometimes, the configuration shows the correct mask and the OSPF neighbor list still shows empty.
This is a very rare case. During network configuration changes under OSPF, a cut and paste of the
OSPF configuration might create this problem. Therefore, you always should look at the output of
show ip ospf interface for that specific interface and see whether OSPF is enabled on that interface.
This type of problem can be corrected by re-entering the network statement.
If OSPF is not enabled on the interface, the interface is incapable of sending or receiving OSPF Hellos.
To correct this problem, change the network mask so that it includes the Ethernet address.
Example 9-4 shows the new configuration that fixes this problem. In this example, the wildcard mask
is 0.0.255.255, which means that it covers the range from 131.108.0.0 to 131.108.255.255.
R2#
router ospf 1
Example 9-5 shows the output of show ip ospf neighbor after applying the correct network mask.
Example 9-5 show ip ospf neighbor Command Output Verifies That OSPF Is
Up After the Correct Network Mask Has Been Configured
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 4 of 40
Beginning with Cisco IOS Software Release 12.0, the output of show ip ospf interface doesn't
display anything if OSPF is not enabled on the interface.
Example 9-6 shows the output of show ip ospf interface for Ethernet 0, which shows that the line
protocol is down.
Example 9-6 show ip ospf interface Command Output Indicates That the
Line Protocol Is Down
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 5 of 40
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Solution
Layers 1 or 2 could be down for several reasons. The list that follows covers some of the most
common things to check to determine whether the interface or line protocol is down:
l Unplugged cable
l Loose cable
l Bad cable
l Bad transceiver
l Bad port
To correct this problem, fix the Layer 2 problem by checking the previously mentioned conditions.
Example 9-7 shows the output of show ip ospf interface for Ethernet 0 after fixing the Layer 2
problem.
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 6 of 40
Example 9-8 shows the output of show ip ospf neighbor, which shows that OSPF adjacency is FULL.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 7 of 40
Example 9-9 shows the output of show ip ospf interface for Ethernet 0 of Router R2. This command
shows that this interface is defined as passive.
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Example 9-10 shows the configuration of Router R2. This configuration shows that the Ethernet 0 of
R2 is defined as passive.
R2#
interface Loopback0
interface Ethernet0
router ospf 1
passive-interface Ethernet0
Solution
To correct this problem, remove the passive-interface command from the OSPF configuration.
Sometimes, the command is entered intentionally so that the router cannot take part in any OSPF
process on that segment. This is the case when you don't want to form any neighbor relationship on
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 8 of 40
Sometimes, the intention is not to send any routes but to receive all routes on that interface, just as
with RIP or IGRP. Remember, defining a passive interface under RIP or IGRP has a different meaning
than defining a passive interface under OSPF or EIGRP. When RIP or IGRP is defined as passive, RIP or
IGRP will not send any routing updates on that interface but will receive all the routing updates on
that interface. In OSPF, a passive interface means "do not send or receive OSPF Hellos on this
interface." So, making an interface passive under OSPF with the intention of preventing the router
from sending any routes on that interface but receiving all the routes is wrong.
Example 9-11 shows the new configuration of Router R2. The passive-interface command is
removed from the configuration.
router ospf 1
no passive-interface Ethernet0
Example 9-12 shows that OSPF is forming adjacency after removing the passive-interface
command.
Example 9-12 Verifying the New Interface Definition Corrects the Problem
This situation happens only when the access list is blocking Hellos on both routers. If only one side is
blocking OSPF Hellos, the output of show ip ospf neighbor will indicate that the neighbor is stuck in
the INIT state. This case is discussed later in this chapter.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 9 of 40
Example 9-13 shows the configuration of both Routers R1 and R2, which shows that the access list is
permitting only incoming TCP and UDP traffic. The inbound access list checks only traffic coming in on
that interface. Because there is an implicit deny at the end of each access list, this access list will
block the OSPF multicast address of 224.0.0.5. Access list 101 in Example 9-13 is defined for
debugging purposes only. This access list looks at the IP packets sourcing from 131.108.1.0–255
addresses destined for OSPF multicast address of 224.0.0.5.
R1#
interface Ethernet0
ip access-group 100 in
_____________________________________________________________________________________
R2#
interface Ethernet0
ip access-group 100 in
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 10 of 40
Example 9-14 shows the output of debug ip packet 101 detail. This debug tracks down the OSPF
Hello packet only on the Ethernet segment. The debug shows that the OSPF Hello packet from Router
R1 is denied on R2.
Example 9-14 debug Shows That the OSPF Multicast Packets Are Being
Denied
Solution
To correct this problem, you must reconfigure the access list to permit OSPF multicast Hellos. Example
9-15 shows the configuration that fixes this problem. In this configuration, OSPF multicast Hellos are
permitted.
Example 9-15 Configuring the Access List to Permit the OSPF Multicast
Address
interface Ethernet0
ip access-group 100 in
Similarly, change the access list on the other side, making sure that the OSPF Hellos are permitted in
the access list. Example 9-16 shows the OSPF neighbor in FULL state after fixing the configuration.
Example 9-16 Verifying That the Reconfigured Access List Has Resolved the
Problem
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 11 of 40
Example 9-17 shows the output of debug ip ospf adj. This debug shows that there is a mis-matched
Hello parameter. The neighbor subnet mask is 255.255.255.252 and Router R2's subnet mask is
255.255.255.0.
Example 9-17 debug ipo ospf adj Command Output Indicates a Mismatched
Hello Parameter
R2#
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 12 of 40
The letter R means "neighbor configuration," and C means "this router configuration." In the case of
different subnet numbers the debug message will be
OSPF: Rcv pkt from 131.108.1.1, Ethernet0, area 0.0.0.1 : src not on the same network
Example 9-18 shows the configuration of both Routers R1 and R2, which shows that both routers'
Ethernets have different subnet masks.
R2#
interface Ethernet0
_____________________________________________________________________________________
R1#
interface Ethernet0
Solution
To fix this problem, change the neighbor's (R1's) subnet mask to match Router R2's, or change the
subnet mask of R2 to match the neighbor's subnet mask. Assume here that you changed the subnet
mask of R1 to 255.255.255.0 to match with R2.
Example 9-19 shows that after fixing the subnet network/mask, adjacency is FULL.
Example 9-19 Verify That Subnet Masks for R1 and R2 Now Match
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 13 of 40
Example 9-20 shows the output of debug ip ospf adj, which indicates that the neighbor's Hello
interval does not match with Router R2's.
R2#
Example 9-21 shows the configuration of both Routers R1 and R2. In R1, the Hello interval is
configured as 15 seconds. In R2, the Hello interval defaults to 10 seconds.
R2#
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 14 of 40
interface Ethernet0
_____________________________________________________________________________________
R1#
interface Ethernet0
ip ospf hello-interval 15
Solution
This example shows a problem when the Hello interval configured for OSPF neighbors doesn't match.
The same problem happens when the dead interval doesn't match between OSPF neighbors. In both
cases, the solution is to change the Hello/dead interval to be consistent between OSPF neighbors.
Unless there are any specific reasons to deviate from the default settings, the Hello and dead intervals
should be kept to their default values.
In Example 9-22, the configuration on R1 is changed so that it uses the default value for the Hello
interval on Ethernet, which is 10 seconds. Removing the Hello interval changes the Hello interval value
back to its default.
R1#
interface Ethernet0
no ip ospf hello-interval 15
Example 9-23 shows that after fixing the Hello and dead intervals, OSPF forms an adjacency.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 15 of 40
In one situation, one side is configured for plain-text or MD5 authentication but the other side is not
configured for any authentication. This situation creates a case of an OSPF neighbor being stuck in
INIT, which is discussed later in this chapter.
Example 9-24 shows the output of debug ip ospf adj, indicating that R2's neighbor is configured for
MD5 authentication and that R2 is configured for plain-text authentication.
R2#
OSPF: Rcv pkt from 131.108.1.1, Ethernet0 : Mismatch Authentication type. Input packet
Example 9-25 shows the configuration of both Routers R1 and R2, indicating that R2 is using plain-
text authentication and R1 is using MD5 authentication.
R2#
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 16 of 40
router ospf 1
area 0 authentication
_____________________________________________________________________________________
R1#
router ospf 1
Solution
To fix this problem, make sure that both sides are using the same authentication type. Example 9-26
shows that after using a consistent authentication type, OSPF forms the adjacency, as indicated by the
FULL state.
If authentication is enabled on one side but not the other, OSPF complains about the mismatch in
authentication type. Sometimes, the authentication key is configured correctly on both sides but
debug ip ospf adj still complains about a mismatched authentication type. In this situation,
authentication-key must be typed again because there is a chance that a space was added during
the authentication key configuration by mistake. Because the space character is not visible in the
configuration, this part is difficult to determine.
Another possible thing that can go wrong is for one side, R1, to have a plain-text key configured and
the other side, R2, to have an MD5 key configured, even though the authentication type is plain text.
In this situation, the MD5 key is completely ignored by R2 because MD5 has not been enabled on the
router. This is equivalent to not having any plain-text key configured under the interface. For more
information on authentication, refer to Chapter 8.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 17 of 40
Example 9-27 shows the output of debug ip ospf adj, which shows that there is an authentication
key mismatch.
R2#
OSPF: Rcv pkt from 131.108.1.1, Ethernet0 : Mismatch Authentication Key - Clear Text
Example 9-28 shows the configuration of R1 and R2. Note that R2 is not configured for any
authentication key, whereas R1 is configured with an authentication key that is causing this problem.
R2#
interface Ethernet0
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 18 of 40
_____________________________________________________________________________________
R1#
interface Ethernet0
Solution
To solve this problem, make sure that both sides have the same kind of authentication key. If the
problem still exists, retype the authentication key; there is a possibility of an added space character
before or after the authentication key.
Example 9-29 shows the output of show ip ospf neighbor after fixing this problem.
Example 9-29 Verifying That OSPF Neighbors Are Up After Using Identical
Authentication Keys
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 19 of 40
Example 9-30 shows the configuration of R2 and R1. Refer back to Figure 9-1; if R1's Ethernet
interface is included in area 0 and R2's Ethernet is included in area 1, it will cause area ID mismatch.
R2#
interface Ethernet0
router ospf 1
_____________________________________________________________________________________
R1#
interface Ethernet0
router ospf 1
Example 9-31 shows the output of debug ip ospf adj on R1, indicating that R1 is receiving an OSPF
packet from R2 and that the OSPF header has area 0.0.0.1 in it. This proves that the other side is
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 20 of 40
configured for area 0.0.0.1 instead of area 0. There is no need to check the other side's configuration
in this case.
R1#
Example 9-32 shows the console log of R2. This log shows that R1 is receiving an OSPF packet that
has area 0.0.0.0 in the OSPF header. Because this router is not configured for area 0, it receives this
message at the console log level. If the neighbor Router R1 is configured with some other area, the
only way to find out about area mismatch is to turn on debug ip ospf adj, as in case of R1.
R2#show log
%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be
Solution
To solve this problem, configure the same area across the link. Example 9-33 shows that the R1
configuration has been changed so that the area ID of R1 now matches R2's.
R1#
interface Ethernet0
router ospf 1
Example 9-34 shows that after fixing this problem, OSPF formed an adjacency.
Example 9-34 Verifying OSPF Neighbors After Fixing the Mismatched Area
ID
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 21 of 40
If one side has the E bit set to 0 and the other side doesn't, OSPF adjacency is not formed. This is
called an optional capability mismatch. One side says that it can allow external routes, and the other
side says that it cannot allow external routes, so OSPF neighbor relationships are not formed.
Example 9-35 shows the configuration of Routers R1 and R2. R2's configuration shows that area 1 is
configured as a stub, but R1's area 1 is configured as a standard area.
R2#
interface Ethernet0
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 22 of 40
router ospf 1
area 1 stub
_____________________________________________________________________________________
R1#
interface Ethernet0
router ospf 1
Example 9-36 shows the output of debug ip ospf adj on R1. This debug shows the problem as a
stub/transit mismatch.
R1#
OSPF: Hello from 131.108.1.2 with mismatched Stub/Transit area option bit
Solution
To solve this problem, make sure that both sides agree on the same type of area. This example talks
about only the stub area, but a similar problem can happen if one side is configured for stub and the
other side is configured as an OSPF NSSA. Another situation is that one side is configured for NSSA
and the other side is configured for a normal area. In any case, whenever there is a mismatched area
type, OSPF adjacency will not be formed.
Example 9-37 shows the debug ip ospf adj output in the case of an NSSA area mismatch.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 23 of 40
R1#
Example 9-38 shows a configuration change on R1 that fixes the problem. Now R1 is also a part of the
stub area.
R1#
interface Ethernet0
router ospf 1
area 1 stub
Example 9-39 shows the output of show ip ospf neighbor after fixing this problem.
Example 9-39 Verifying That OSPF Neighbors Are Up After Fixing the
Mismatch Stub/NSSA Problem
Figure 9-12. Two Routers Connected Through a Switch, with One Side's
Primary Interface IP Address Identical to the Other Side's Secondary
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 24 of 40
Example 9-40 shows the configuration of both R1 and R2. The configuration illustrates that R2 has a
primary and a secondary address configured on its Ethernet interface, and that the subnet number
used for the primary address on R1 is for the secondary address on R2.
R2#
interface FastEthernet0/0
_____________________________________________________________________________________
R1#
interface Ethernet0
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 25 of 40
Example 9-41 shows the output of debug ip ospf adj. This output is exactly the same as the debug
output in case of a mismatched subnet number. This is because, when R1 receives a Hello packet from
R2, the source address will be 131.108.4.2, which is a different subnet than its connected interface.
As a result, R1 will complain.
R2#
OSPF: Rcv pkt from 131.108.1.1, FastEthernet0/0, area 0.0.0.1 : src not on the same
network
Solution
The solution to this kind of problem is to create subinterfaces on R1. This is possible only if the
interface that has the secondary address is Fast Ethernet or Gigabit Ethernet and it is con-nected
through a Layer 2 switch. This can be achieved through an Inter-Switch Link (ISL), in the case of a
Cisco switch, or dot1Q encapsulation, in the case of a different vendor's switch. ISL or dot1Q
encapsulation is used to route between two separate VLANs. The switch port that connects to the Fast
Ethernet interface of R2 is configured as a trunk port, so all the traffic between VLAN 1 and VLAN 2
will go through the router and the router will route between these two VLANs.
Example 9-42 shows the configuration of R1 and a Cisco switch to use an ISL trunk so that it can
create subinterfaces on R2.
R2#
interface FastEthernet0/0
no ip address
full-duplex
interface FastEthernet0/0.1
encapsulation isl 2
interface FastEthernet0/0.2
encapsulation isl 1
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 26 of 40
Example 9-42 shows the example of how to create subinterfaces and how to enable VLAN trunking on
the Cisco Catalyst switch. R1's Fast Ethernet interface is included in VLAN 2, and the subinterface of
R2, FE 0/0.1, also is added in VLAN 2. Also, port 11/10 of the switch that connects to R2 is enabled for
trunking so that it will carry both VLAN 1 and VLAN 2 traffic. Similar configurations can be
implemented in the case of 802.1Q encapsulation. Figure 9-14 shows the logical picture after making
this change. FE 0/0.1 is a subinterface using ISL encapsulation.
After making this change, R2 will form a neighbor relationship with R1 on FE 0/0.1. The other
subinterface, FE 0/0.2, which is in VLAN 1, will form a neighbor relationship with other routers in VLAN
1.
FE 0/0.1 and FE 0/0.2 are logical subinterfaces. This means that both of these subinterfaces are
subsets of one physical interface (FE 0/0) that connects to port 11/10 of the switch. Example 9-43
shows the output of show ip ospf neighbor after making this change.
Figure 9-15 shows the network diagram with the two routers running OSPF between asynchronous
interfaces.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 27 of 40
Example 9-44 shows the configuration of R1 and R2. This configuration shows that asynchronous
default routing is missing from the interface configuration.
R1#
interface Async1
encapsulation ppp
dialer in-band
dialer-group 1
_____________________________________________________________________________________
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 28 of 40
R2#
interface Async1
encapsulation ppp
dialer in-band
dialer-group 1
Solution
In this example, use either async default routing or asyn dynamic routing to solve this problem.
Example 9-45 shows the configurations of R1 and R2 after using async default routing.
R1#
interface Async1
encapsulation ppp
dialer in-band
dialer-group 1
_____________________________________________________________________________________
R2#
interface Async1
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 29 of 40
encapsulation ppp
dialer in-band
dialer-group 1
Example 9-46 shows that OSPF forms neighbor relationships after fixing this problem.
Example 9-46 Verifying That R1 and R2 Are Forming Neighbors After Using
async default routing
Figure 9-17 shows the network diagram with two routers running OSPF in Frame Relay cloud. Frame
Relay is just one example; this problem can be produced in any nonbroadcast network, such as X.25,
SMDS, and so on.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 30 of 40
Example 9-47 shows the output of show interface serial0 on R2. The network type is showing as
nonbroadcast. Any nonbroadcast interface—for example, X.25, SMDS, Frame Relay, and so on—
always shows the network type as nonbroadcast.
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Solution
To solve this problem, configure the neighbor statement under router ospf, as done in Example 9-
48. By configuring the neighbor statement, OSPF starts sending the Hello packet as a unicast instead
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 31 of 40
of a multicast. This is also a useful technique when the multicast cap-abilities of any medium are
broken. Be sure to define the right neighbor address; otherwise, the OSPF Hello packet will not make
it to the neighbor.
R2#
router ospf 1
Other methods to solve this problem include changing the network type to either broadcast or point-
to-multipoint. In this case, OSPF starts sending the multicast Hellos across the link. Example 9-49
shows how to change the network type to broadcast and then shows the output of show interface
serial0 after using the network type broadcast.
R2#
interface Serial 0
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Similarly, changing the network type to point-to-multipoint will make it work. Example 9-50 shows
how to change the network type to point-to-point and then shows the output of show ip ospf
neighbor, which shows that the neighbors are FULL across the serial link after making the change.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 32 of 40
R2#
interface Serial 0
One thing to note here is that both sides should have this broadcast keyword missing from the
frame-relay map or dialer-map configurations to produce this problem. If just one side is missing
the broadcast keyword, the other side will see this router in INIT and the neighbors will never
become adjacent. This case is discussed later in this chapter in the section "Problem: OSPF Neighbor
Stuck in INIT."
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 33 of 40
Example 9-51 shows the output of debug ip packet 100 detail, which indicates that the Hello
packets generated from R1 are not getting across because of encapsulation failure. The access list
here is used only for the debugging purpose. This access list monitors those IP packets that are
sourcing from 131.108.1.1 and 131.108.1.2 and destined for 224.0.0.5.
Example 9-51 Verifying That OSPF Hellos Are Being Dropped Because of
Encapsulation Failure
R1#
proto=
89
IP: s=131.108.1.1 (local), d=224.0.0.5 (Serial0), len 68, encapsulation failed, proto=
89
Example 9-52 shows the configuration of R1 and R2. The configuration shows that the broadcast
keyword is missing from the frame-relay map statements.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 34 of 40
R1#
interface Serial0
encapsulation frame-relay
_____________________________________________________________________________________
R2#
interface Serial0
encapsulation frame-relay
Solution
Example 9-53 shows the modified configurations for R1 and R2 that fixes this problem. Again, the
keyword broadcast must be enabled on both sides. If it is enabled on only one side, it will produce a
stuck in INIT problem, which is discussed later in this chapter.
R1#
interface Serial0
encapsulation frame-relay
_____________________________________________________________________________________
R2#
interface Serial0
encapsulation frame-relay
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 35 of 40
You can use a similar configuration for a dialer interface, as demonstrated in Example 9-54.
Example 9-54 Adding the broadcast Keyword to the dialer map Statements
for R1 and R2
R1#
interface BRI0
encapsulation ppp
_____________________________________________________________________________________
R2#
interface BRI0
encapsulation ppp
Example 9-55 shows that an OSPF adjacency is formed across the serial interface using Frame Relay
encapsulation after fixing this problem.
Example 9-55 Verifying That the New Configurations for R1 and R2 Are
Successful
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 36 of 40
Figure 9-20 shows a network in which two routers are running OSPF. This network setup is used to
produce a stuck in ATTEMPT problem.
Example 9-56 shows the output of show ip ospf neighbor, which indicates that the neighbor is stuck
in ATTEMPT. The neighbor ID field shows N/A, which means that this router doesn't have any
information about the neighbor—that's why this field is showing N/A; otherwise, it would show the
neighbor's router ID.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 37 of 40
In Example 9-57, the output of show ip ospf neighbor indicates that the neighbor is stuck in
ATTEMPT. The neighbor statement is configured, but the neighbor IP address is not correct. Instead
of 131.108.1.1 (as shown in the Figure 9-20), it shows 131.108.1.11.
Example 9-57 show ip ospf neighbor Command Output Indicates That the
Neighbor Is Stuck in ATTEMPT
Example 9-58 shows the configuration of R2, indicating that the neighbor statement also is wrongly
configured.
R2#
router ospf 1
Solution
To fix this problem, configure the proper neighbor statement with the proper IP address. Example 9-
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 38 of 40
R2#
router ospf 1
neighbor131.108.1.1 priority 1
Example 9-60 shows the output of show ip ospf neighbor after fixing the problem.
Example 9-60 Verifying That the New neighbor Statement Has Resolved the
Issue
l A wrong DLCI or VPI/VCI mapping exists in a Frame Relay or ATM switch, respectively.
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 39 of 40
Example 9-61 shows the output of a ping initiated from R2 to R1. The ping shows 100 percent failure.
Because the ping uses ICMP and is a unicast packet, the failure indicates that the unicast connectivity
is broken.
R2#ping 131.108.1.1
.....
R2#
Solution
As mentioned previously, the unicast broken connectivity could be the result of many factors. If it's a
wrong DLCI or VC mapping, be sure to check these mappings and correct those. If it's the access list
that is blocking the unicast connectivity, be sure to permit the necessary unicast IP address in the
access list. Example 9-62 shows the output of show ip ospf neighbor after fixing the unicast
connectivity problem.
Example 9-62 Verifying That Unicast Is Operational Again and That OSPF Is
Forming Neighbors
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019
Problem: OSPF Neighbor List Is Empty Page 40 of 40
mk:@MSITStore:C:\Users\Jayant\Desktop\TCP%20IP%20Working\Cisco%20Press%20... 22/07/2019