Problem: OSPF Neighbor List Is Empty

This is the most common problem in OSPF neighbor relationships. The most common causes are related to either misconfiguration or lack of configuration. If the neighbor list is empty, it will not even proceed to form OSPF neighbor relationships.

The most common possible causes of this problem are as follows :

• OSPF is not enabled on the interface.

• Layer 1/2 is down.

• The interface is defined as passive under OSPF.

• An access list is blocking OSPF Hellos on both sides.

• A subnet number/mask has been mismatched over a broadcast link.

• The Hello/dead interval has been mismatched.

• The authentication type (plain text versus MD5) has been mismatched.

• An authentication key has been mismatched.

• An area ID has been mismatched.

• Stub/transit/NSSA area options have been mismatched.

• An OSPF adjacency exists with secondary IP addressing.

• An OSPF adjacency exists over an asynchronous interface.

• No network type or neighbor is defined over NBMA (Frame Relay, X.25, SMDS, and so on).

• 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.

Example 9-1 show ip ospf neighbor Command Output Has an Empty Neighbor List

 R2#  show ip ospf neighbor  R2# 

OSPF Neighbor List Is Empty ‚ Cause: OSPF Not Enabled on the Interface

OSPF can be enabled on a per-interface basis. To enable OSPF on any interface, put a network command under router ospf and include the network address with the wildcard mask. When defining the network statement in OSPF, you should carefully examine the wildcard mask to see the range of addresses it covers. Figure 9-2 shows the flowchart to follow to solve this problem based on this cause.

Figure 9-2. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-2 R2 Configuration with the Wrong Mask

 R2#  interface Loopback0   ip address 131.108.0.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router ospf 1    network 131.108.0.0 0.0.0.255 area 0   ! 

Example 9-3 shows the configuration of Router R2. OSPF is not enabled on the Ethernet interface of R2.

Example 9-3 OSPF Not Enabled on R2's Ethernet 0 Interface

 R2#  show ip ospf interface Ethernet 0  Ethernet0 is up, line protocol is up   OSPF not enabled on this interface 

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.

Example 9-4 Fixing the Configuration on R2 to Include the Proper Network Mask

 R2#  router ospf 1   network 131.108.0.0 0.0.255.255 area 0  

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

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface 131.108.2.1   1    FULL/DR  00:00:38    131.108.1.1     Ethernet0 

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.

OSPF Neighbor List Is Empty ‚ Cause: Layer 1/2 Is Down

OSPF runs at Layer 3 on top of Layer 2. OSPF cannot send or receive any Hellos if Layer 2 is down. One of the causes for OSPF not forming neighbors is that Layers 1 or 2 might be down. If Layer 1 or Layer 2 is down, it's not a problem directly related to OSPF.

Figure 9-3 shows the flowchart to solve this problem.

Figure 9-3. Problem-Resolution Flowchart

Debugs and Verification

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

 R2#  show ip ospf interface Ethernet 0  Ethernet0 is up,  line protocol is down  Internet Address 131.108.1.2/24, Area 0   Process ID 1, Router ID 131.108.1.2, Network Type BROADCAST, Cost: 10   Transmit Delay is 1 sec, State DOWN, Priority 1   No designated router on this network   No backup designated router on this network   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:

• Unplugged cable

• Loose cable

• Bad cable

• Bad transceiver

• Bad port

• Bad interface card

• Layer 2 problem at telco in case of a WAN link

• Missing clock statement in case of back-to-back serial connections

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.

Example 9-7 Verifying That Layer 2 Is Up

 R2#  show ip ospf interface Ethernet 0  Ethernet0 is up,  line protocol is up  Internet Address 131.108.1.2/24, Area 4   Process ID 1, Router ID 131.108.1.2, Network Type BROADCAST, Cost: 10   Transmit Delay is 1 sec, State BDR, Priority 1   Designated Router (ID) 131.108.2.1, Interface address 131.108.1.1   Backup Designated router (ID) 131.108.1.2, Interface address 131.108.1.2   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5     Hello due in 00:00:07   Neighbor Count is 1, Adjacent neighbor count is 1     Adjacent with neighbor 131.108.1.1  (Designated Router)   Suppress hello for 0 neighbor(s) 

Example 9-8 shows the output of show ip ospf neighbor, which shows that OSPF adjacency is FULL.

Example 9-8 Verifying OSPF Adjacency State

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:39    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Interface Is Defined as Passive Under OSPF

When an interface is defined as passive under router OSPF, it suppresses OSPF Hellos. This means that OSPF does not send or receive any Hellos on such interfaces. Therefore, no adjacency is formed .

Figure 9-4 shows a flowchart to solve this problem.

Figure 9-4. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-9 Determining Whether an Interface Is Defined as Passive

 R2#  show ip ospf interface Ethernet 0  Ethernet0 is up, line protocol is up Internet Address 131.108.1.2/24, Area 0 Process ID 1, Router ID 131.108.1.2, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 131.108.1.2, Interface address 131.108.1.2 No backup designated router on this network Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5  No Hellos (Passive interface)  Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) 

Example 9-10 shows the configuration of Router R2. This configuration shows that the Ethernet 0 of R2 is defined as passive.

Example 9-10 The Ethernet 0 Interface of R2 Is Defined as Passive

 R2#  interface Loopback0   ip address 131.108.0.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router ospf 1   passive-interface Ethernet0  network 131.108.0.0 0.0.255.255 area 0 

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 an interface but you do want to advertise that interface.

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.

Example 9-11 Removing the Passive Interface Definition from a Router Interface

  router ospf 1    no passive-interface Ethernet0    network 131.108.0.0 0.0.255.255 area 0  

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

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:37    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Access List Blocking OSPF Hellos on Both Sides

OSPF sends its Hello on a multicast address of 224.0.0.5. All OSPF-enabled interfaces listen to this address. It is very common to implement an access list for security measures at the interface level. Be sure to permit OSPF multicast Hellos' addresses in the access list in this situation; otherwise , the access list might block the OSPF multicast address unknowingly and prevent OSPF from forming neighbors on that interface.

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.

Figure 9-5 shows the flowchart to follow to solve this problem.

Figure 9-5. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-13 Access List Configuration for R1 and R2

 R1#  interface Ethernet0   ip address 131.108.1.1 255.255.255.0   ip access-group 100 in   !    access-list 100 permit tcp any any     access-list 100 permit udp any any    access-list 101 permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5  _____________________________________________________________________________________ R2# interface Ethernet0 ip address 131.108.1.2 255.255.255.0 ip access-group 100 in !  access-list 100 permit tcp any any   access-list 100 permit udp any any  access-list 101 permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5 

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

 R2#  debug ip packet 101 detail  IP packet debugging is on (detailed) for access list 101 IP: s=131.108.1.2 (Ethernet0), d=224.0.0.5, len 68,  access denied, proto=89  

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 address 131.108.1.2 255.255.255.0   ip access-group 100 in   !   access-list 100 permit tcp any any   access-list 100 permit udp any any   access-list 100 permit ip any host 224.0.0.5  

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

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:37    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Mismatched Subnet Number/Mask over a Broadcast Link

OSPF performs the subnet number and mask check on all media except point-to-point and virtual links as specified, by Section 10.5 of OSPF RFC 2328. For purposes of this scenario, the medium is Ethernet and the network type on Ethernet is broadcast. The network mask gets advertised in the Hello packet. In the case of unnumbered point-to-point links and virtual links, the network mask field contains 0.0.0.0. If the subnet mask is different across the Ethernet link, OSPF will not form a neighbor relationship on that link.

Figure 9-6 shows the flowchart to follow to solve this problem.

Figure 9-6. Problem-Resolution Flowchart

Debugs and Verification

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##  debug ip ospf adj  OSPF adjacency events debugging is on R2# OSPF: Rcv hello from 131.108.2.1 area 4 from Ethernet0 131.108.1.1 OSPF:  Mismatched hello parameters  from 131.108.2.1 Dead R 40 C 40, Hello R 10 C 10  Mask R 255.255.255.248 C 255.255.255.0  

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.

Example 9-18 Configurations for R1 and R2 Have Different Subnet Masks

 R2#  interface Ethernet0   ip address 131.108.1.2  255.255.255.0   _____________________________________________________________________________________ R1#  interface Ethernet0  ip address 131.108.1.1  255.255.248.0  

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

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:31    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Mismatched Hello/Dead Intervals

OSPF neighbors exchange Hello packets periodically to form and maintain neighbor relation-ships. OSPF advertises the router's Hello and dead intervals in the Hello packets. These intervals must match with the neighbor's; otherwise, an adjacency will not form.

Figure 9-7 shows the flowchart to follow to solve this problem.

Figure 9-7. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-20 Verifying Mismatched Hello Intervals Between OSPF Neighbors

 R2#  debug ip ospf adj  OSPF adjacency events debugging is on R2# OSPF: Rcv hello from 131.108.2.1 area 4 from Ethernet0 131.108.1.1 OSPF:  Mismatched hello parameters  from 131.108.2.1 Dead R 40 C 40,  Hello R 15 C 10  Mask R 255.255.255.0 C 255.255.255.0 

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.

Example 9-21 Hello Interval Configurations for R1 and R2

 R2#  interface Ethernet0  _____________________________________________________________________________________ R1#  interface Ethernet0   ip address 131.108.1.1 255.255.248.0   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.

Example 9-22 Changing Hello Interval to Its Default Value

 R1#  interface Ethernet0   ip address 131.108.1.1 255.255.248.0    no ip ospf hello-interval 15   

Example 9-23 shows that after fixing the Hello and dead intervals, OSPF forms an adjacency.

Example 9-23 Verifying That OSPF Is Forming Neighbors After Matching Hello/Dead Intervals

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:32    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Mismatched Authentication Type

OSPF uses two types of authentication, plain-text (Type 1) and MD5 (Type 2). Type 0 is called null authentication. If the plain-text authentication type is enabled on one side, the other side must also have plain-text authentication. OSPF will not form an adjacency unless both sides agree on the same authentication type.

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.

Figure 9-8 shows the flowchart to follow to solve this problem.

Figure 9-8. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-24 debug Shows Mismatched Authentication Type

 R2#  debug ip ospf adj  OSPF adjacency events debugging is on R2# OSPF: Rcv pkt from 131.108.1.1, Ethernet0 :  Mismatch Authentication type. Input packet   specified type 2, we use type 1  

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.

Example 9-25 Authentication Type Configuration for R1 and R2

 R2#  router ospf 1    area 0 authentication    network 131.108.0.0 0.0.255.255 area 0  _____________________________________________________________________________________ R1#  router ospf 1    area 0 authentication message-digest   network 131.108.0.0 0.0.255.255 area 0 

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.

Example 9-26 Verifying That the Authentication Type Between OSPF Neighbors Is Now Consistent

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:32    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Mismatched Authentication Key

When authentication is enabled, the authentication key also must be configured on the interface. Authentication previously was supported on a per-area basis, but beginning with the specifications in RFC 2328, authentication is supported on a per-interface basis. This feature has been implemented in Cisco IOS Software Release 12.0.8 and later.

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.

Figure 9-9 shows the flowchart to follow to solve this problem.

Figure 9-9. Problem-Resolution Flowchart

Debugs and Verification

Example 9-27 shows the output of debug ip ospf adj, which shows that there is an authentication key mismatch.

Example 9-27 Detecting an Authentication Key Mismatch

 R2#  debug ip ospf adj  OSPF adjacency events debugging is on 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.

Example 9-28 Configuration of R1 and R2

 R2#  interface Ethernet0   ip address 131.108.1.2 255.255.255.0  _____________________________________________________________________________________ R1#  interface Ethernet0   ip address 131.108.1.1 255.255.248.0  ip ospf authentication-key Cisco 

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

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:32    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Mismatched Area ID

OSPF sends area information in the Hello packets. If both sides do not agree that they are members of a common area, no OSPF adjacency will be formed. The area information is a part of the OSPF protocol header.

Figure 9-10 shows the flowchart to follow to solve this problem.

Figure 9-10. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-30 Area Configurations for Interfaces on R1 and R2

 R2#  interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router ospf 1    network 131.108.0.0 0.0.255.255 area 1   _____________________________________________________________________________________ R1#  interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router ospf 1   network 131.108.0.0 0.0.255.255 area 0  

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 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.

Example 9-31 Determining the OSPF Neighbor Area Configuration

 R1#  debug ip ospf adj  OSPF adjacency events debugging is on R1# OSPF: Rcv pkt from 131.108.1.2, Ethernet0, area 0.0.0.0  mismatch area 0.0.0.1 in the header  

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.

Example 9-32 Console Logs of R2 Showing Mismatch Area

 R2#  show log  %OSPF-4-ERRRCV:  Received invalid packet: mismatch area ID, from backbone  area must be         virtual-link but not found from 131.108.1.1, Ethernet0 

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.

Example 9-33 Corrected Configuration on R1

 R1#  interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router ospf 1    no network 131.108.0.0 0.0.255.255 area 0   network 131.108.0.0 0.0.255.255  area 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

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:32    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: Mismatched Stub/Transit/NSSA Area Options

When OSPF exchanges Hello packets with a neighbor, one of the things that it exchanges in the Hello packet is an optional capability represented by 8 bits. One of the option fields is for the E bit, which is the OSPF stub area flag. When the E bit is set to 0, the area with which the router is associated is a stub area, and no external LSAs are allowed in this area.

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.

Figure 9-11 shows the flowchart to follow to solve this problem.

Figure 9-11. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-35 Area Configuration for R1 and R2

 R2#  interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router ospf 1    area 1 stub    network 131.108.0.0 0.0.255.255 area  1 _____________________________________________________________________________________ R1#  interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router ospf 1  network 131.108.0.0 0.0.255.255 area 1 

Example 9-36 shows the output of debug ip ospf adj on R1. This debug shows the problem as a stub/transit mismatch.

Example 9-36 debug ip ospf adj Command Output Determines a Stub/Transit Area Option Bit Mismatch

 R1#  debug ip ospf adj  OSPF adjacency events debugging is on R1# OSPF: Rcv hello from 131.108.0.1 area 1 from Ethernet0 131.108.1.2  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.

Example 9-37 debug ip ospf adj Command Output Determines an NSSA Option Bit Mismatch

 R1#  debug ip ospf adj  OSPF adjacency events debugging is on R1# OSPF: Rcv hello from 131.108.0.1 area 1 from Ethernet0 131.108.1.2  OSPF: Hello from 131.108.1.2 with mismatched NSSA option bit  

Example 9-38 shows a configuration change on R1 that fixes the problem. Now R1 is also a part of the stub area.

Example 9-38 Configuration Change on R1 That Fixes the Problem

 R1#  interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router ospf 1    area 1 stub   network 131.108.0.0 0.0.255.255 area 1 

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

 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1   1    FULL/DR  00:00:32    131.108.1.1     Ethernet0  

OSPF Neighbor List Is Empty ‚ Cause: OSPF Adjacency Over Secondary IP Address

This is a very common problem in which a customer might have one Class C address on a LAN segment. When the customer runs out of address space, he gets another Class C address and assigns the new address as a secondary address under the same interface. Everything works fine until two routers must exchange OSPF Hellos/updates and one router's primary IP ad-dress is assigned as the secondary IP address on the other side, as depicted in the network in Figure 9-12. The two routers are connected through a Layer 2 switch.

Figure 9-12. Two Routers Connected Through a Switch, with One Side's Primary Interface IP Address Identical to the Other Side's Secondary

Figure 9-13 shows the flowchart to follow to solve this problem.

Figure 9-13. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-40 R2's FastEthernet0/0 Interface Secondary Address Configuration Matches R1's Ethernet0 Interface Primary Address Configuration

 R2#  interface FastEthernet0/0    ip address 131.108.1.2 255.255.255.0 secondary    ip address 131.108.4.2 255.255.255.0  _____________________________________________________________________________________ R1#  interface Ethernet0   ip address 131.108.1.1 255.255.255.0  

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.

Example 9-41 debug ip ospf adj Command Output Indicates an IP Address Conflict

 R2#  debug ip ospf adj  OSPF adjacency events debugging is on 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.

Example 9-42 Creating Subinterfaces on R2

 R2#  interface FastEthernet0/0   no ip address   full-duplex   !   interface FastEthernet0/0.1    encapsulation isl 2    ip address 131.108.1.2 255.255.255.0   interface FastEthernet0/0.2    encapsulation isl 1    ip address 131.108.4.2 255.255.255.0  cat-5k-1> (enable)  set trunk 11/10 on   Port(s)  11/10 trunk mode set to on  

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.

Figure 9-14. Logical Figure of Subinterfaces After 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.

Example 9-43 OSPF Forming Neighbors After Creating Subinterface

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State    Dead Time  Address       Interface  131.108.2.1  1    FULL/DR  00:00:32   131.108.1.1   FastEthernet0/0.1  

OSPF Neighbor List Is Empty ‚ Cause: OSPF Adjacency over Asynchronous Interface

You must enable asynchronous default or dynamic routing when OSPF is enabled between two routers over asynchronous interface. When async default routing is enabled, the router always sends routing packets over an asynchronous interface. In case of interactive asynchronous connections for which users have to type ppp to establish the PPP session, the async dynamic routing command can be used, but then users must type ppp /routing to enable routing over the asynchronous interface. An inability to do this causes OSPF not to form any adjacency over the asynchronous link.

Figure 9-15 shows the network diagram with the two routers running OSPF between asynchronous interfaces.

Figure 9-15. OSPF Running Between Asynchronous Interfaces

Figure 9-16 shows the flowchart to follow to solve this problem.

Figure 9-16. Problem-Resolution Flowchart

Debugs and Verification

Example 9-44 shows the configuration of R1 and R2. This configuration shows that asynchronous default routing is missing from the interface configuration.

Example 9-44 Verifying That Asynchronous Default Routing Is Missing on the Asynchronous Interfaces of R1 and R2

 R1#  interface Async1   description ASYNC LINE TO R2   ip address 131.108.1.1 255.255.255.0   encapsulation ppp   async mode dedicated   dialer in-band   dialer map ip 131.108.1.2 name Router2 broadcast   dialer-group 1   ppp authentication chap  _____________________________________________________________________________________ R2#  interface Async1   description ASYNC LINE TO R1   ip address 131.108.1.2 255.255.255.0   encapsulation ppp   async mode dedicated   dialer in-band   dialer map ip 131.108.1.1 name Router2 broadcast   dialer-group 1  ppp authentication chap 

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.

Example 9-45 Configuring R1 and R2 to Use async default routing

 R1#  interface Async1   description ASYNC LINE TO R2   ip address 131.108.1.1 255.255.255.0   encapsulation ppp    async default routing    async mode dedicated   dialer in-band   dialer map ip 131.108.1.2 name Router2 broadcast   dialer-group 1   ppp authentication chap  _____________________________________________________________________________________ R2#  interface Async1   description ASYNC LINE TO R1   ip address 131.108.1.2 255.255.255.0   encapsulation ppp    async default routing    async mode dedicated   dialer in-band   dialer map ip 131.108.1.1 name Router2 broadcast   dialer-group 1  ppp authentication chap 

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

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State    Dead Time  Address       Interface  131.108.2.1  1    FULL/-   00:00:32   131.108.1.1   Async1  

OSPF Neighbor List Is Empty ‚ Cause: No Network Type or Neighbor Defined over NBMA

This is a classic problem of NBMA networks. OSPF or any other routing protocol will not be capable of sending or receiving any Hello packet unless you configure a neighbor statement or change the network type to broadcast or point-to-multipoint. When the neighbor statement is configured, it triggers OSPF Hellos and neighbor relationships are formed. Changing the network type also changes the interface behavior; in the case of the broadcast network type, OSPF starts sending and receiving the OSPF Hellos. Chapter 8 provides a detailed explanation of OSPF network types.

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.

Figure 9-17. OSPF over Nonbroadcast Media

Figure 9-18 shows the flowchart to follow to solve this problem.

Figure 9-18. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-47 Determining the Network Type on R2's Serial0 Interface

 R2#  show ip ospf interface serial0  Serial0 is up, line protocol is up   Internet Address 131.108.1.2/24, Area 1  Process ID 1, Router ID 131.108.1.2, Network Type  NON_BROADCAST  , Cost: 64   Transmit Delay is 1 sec, State DR, Priority 1   Designated Router (ID) 131.108.1.2, Interface address 131.108.1.2   No backup designated router on this network   Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5     Hello due in 00:00:00  Neighbor Count is 0, Adjacent neighbor count is 0  Suppress hello for 0 neighbor(s) 

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 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.

Example 9-48 OSPF Configuration with neighbor Statement

 R2#  router ospf 1   network 131.108.0.0 0.0.255.255 area 1   neighbor 131.108.1.1 priority 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.

Example 9-49 Verifying That the Broadcast Network Type Configuration Is Allowing OSPF to Form an Adjacency

 R2#  interface Serial 0    ip ospf network broadcast   R2#  show ip ospf interface serial0  Serial0 is up, line protocol is up   Internet Address 131.108.1.2, Area 1   Process ID 1, Router ID 131.108.1.2,  Network Type BROADCAST  , Cost: 64 Transmit Delay is 1 sec, State BDR, Priority 1   Designated Router (ID) 131.108.2.1, Interface address 131.108.1.1   Backup Designated router (ID) 131.108.1.2, Interface address 131.108.1.2   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5     Hello due in 00:00:05   Neighbor Count is 1, Adjacent neighbor count is 1     Adjacent with neighbor 131.108.2.1  (Designated Router)   Suppress hello for 0 neighbor(s) 

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.

Example 9-50 Verifying That the Point-to-Multipoint Network Type Configuration Is Allowing OSPF to Form Adjacency

 R2#  interface Serial 0   ip ospf network point-to-multipoint    R2#show ip ospf neighbor   Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/-   00:01:42   131.108.1.1   Serial0  

OSPF Neighbor List Is Empty ‚ Cause: Frame Relay/Dialer Interface Missing the broadcast Keyword on Both Sides

OSPF uses multicast Hellos to form adjacencies. Other routing protocols ‚ for example, RIP and EIGRP ‚ also use broadcasts or multicasts to form neighbor relationships. In the case of Frame Relay or dialer interfaces, you must enable the broadcast keyword in frame-relay or dialer-map statements on both ends to propagate OSPF Hellos. These maps statements are valid only if the interfaces are multipoint in nature. For example, by default, Frame Relay interfaces are multipoint. Also, the BRI interface is multipoint because it is capable of dialing more than one number.

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."

Figure 9-19 shows the flowchart to follow to solve this problem.

Figure 9-19. Problem-Resolution Flowchart

Debugs and Verification

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#  show access-list 100  Extended IP access list 100     permit ip 131.108.1.0 0.0.0.3 host 224.0.0.5 (8 matches) R1#  debug ip packet 100 detail  IP packet debugging is on (detailed) for access list 100 R1# IP: s=131.108.1.2 (Serial0), d=224.0.0.5, len 64, rcvd 0, proto=89 IP: s=131.108.1.1 (local), d=224.0.0.5 (Serial0), len 68, sending broad/multicast, 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.

Example 9-52 Configurations for R1 and R2 Reveal Missing broadcast Keywords

 R1#  interface Serial0   ip address 131.108.1.1 255.255.255.0   encapsulation frame-relay   frame-relay map ip 131.108.1.2 16  _____________________________________________________________________________________ R2#  interface Serial0   ip address 131.108.1.2 255.255.255.0   encapsulation frame-relay   frame-relay map ip 131.108.1.1 16  

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.

Example 9-53 Adding the broadcast Keyword to the frame-relay map Statements for R1 and R2

 R1#  interface Serial0   ip address 131.108.1.1 255.255.255.0   encapsulation frame-relay   ip ospf network broadcast   frame-relay map ip 131.108.1.2 16 broadcast  _____________________________________________________________________________________ R2#  interface Serial0   ip address 131.108.1.2 255.255.255.0   encapsulation frame-relay   ip ospf network broadcast   frame-relay map ip 131.108.1.1 16 broadcast  

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   ip address 131.108.1.1 255.255.255.0   encapsulation ppp   dialer map ip 131.108.1.2    broadcast    name R2 76444  _____________________________________________________________________________________ R2#  interface BRI0   ip address 131.108.1.2 255.255.255.0   encapsulation ppp  dialer map ip 131.108.1.1  broadcast  name R1 76555 

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

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/DR   00:00:32   131.108.1.1   Serial0  

Problem: OSPF Neighbor Stuck in ATTEMPT

This problem is valid only for NMBA networks in which neighbor statements are defined. Stuck in ATTEMPT means that a router is trying to contact a neighbor by sending its Hello but hasn't received any response. The state of ATTEMPT itself is not a problem because this is a normal state that a router goes through in NBMA mode; however, if a router is stuck in this state for a long time, it's an indication of a problem. Chapter 8 discusses the ATTEMPT state in greater detail.

The most common possible causes of this problem are as follows:

• Misconfigured neighbor statement

• Unicast broken on NBMA

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.

Figure 9-20. Network Setup Vulnerable to 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.

Example 9-56 OSPF Neighbors Stuck in ATTEMPT State

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State             Dead Time  Address       Interface N/A           0  ATTEMPT/DROTHER  00:01:57   131.108.1.1   Serial0 

OSPF Neighbor Stuck in ATTEMPT ‚ Cause: Misconfigured neighbor Statement

OSPF sends a unicast packet on NBMA interfaces if neighbor statements manually are configured under the router ospf configuration. This neighbor statement defines the destination IP address of the OSPF packet. If the neighbor statement is not correct, OSPF cannot send the packet to the right neighbor. It is very common to make a configuration mistake, so if the neighbor doesn't come up after a while, check the neighbor statement either in the OSPF configuration or in the output of show ip ospf neighbor. If the neighbor shows in ATTEMPT state, this router is trying to contact a neighbor by sending the Hello packet, but it has not received any response from the neighbor.

Figure 9-21 shows the flowchart to follow to solve this problem.

Figure 9-21. Problem-Resolution Flowchart

Debugs and Verification

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

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State             Dead Time  Address       Interface  N/A            0  ATTEMPT/DROTHER   00:01:57   131.108.1.11  Serial0  

Example 9-58 shows the configuration of R2, indicating that the neighbor statement also is wrongly configured.

Example 9-58 R2's Configuration Has an Incorrect neighbor Statement

 R2#  router ospf 1   network 131.108.0.0 0.0.255.255 area 1  neighbor  131.108.1.11  priority 1 

Solution

To fix this problem, configure the proper neighbor statement with the proper IP address. Example 9-59 shows the new configuration of R2 that fixes this problem.

Example 9-59 Configuring the Proper neighbor Statement on R2 to Correct the Problem

 R2#  router ospf 1   network 131.108.0.0 0.0.255.255 area 1  neighbor  131.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

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/DR   00:01:42   131.108.1.1   Serial0  

OSPF Neighbor Stuck in ATTEMPT ‚ Cause: Unicast Connectivity Is Broken on NBMA

OSPF sends unicast Hellos over NBMA interfaces if neighbor statements manually are con-figured. If the unicast connectivity is broken, OSPF will never form any adjacencies. OSPF tries to contact neighbors every Hello interval (that is, every 30 seconds) by default over NBMA interfaces. If it does not receive any reply from the neighbor, it will show that the neighbor is stuck in ATTEMPT. Many possible reasons can exist for broken unicast connectivity. You should consider the following causes for a broken unicast connectivity, assuming that Layer 2 is up:

• A wrong DLCI or VPI/VCI mapping exists in a Frame Relay or ATM switch, respectively.

• An access list is blocking the unicast.

• NAT is translating the unicast.

Figure 9-22 shows the flowchart to follow to solve this problem.

Figure 9-22. Problem-Resolution Flowchart

Debugs and Verification

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.

Example 9-61 ping Failure Indicates a Connectivity Problem

 R2#  ping 131.108.1.1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.1.1, timeout is 2 seconds: .....  Success rate is 0 percent (0/5)  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

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface 131.108.2.1  1    FULL/DR   00:01:42   131.108.1.1   Serial0