Problem: OSPF Neighbor Stuck in INIT

‚  < ‚  Free Open Study ‚  > ‚  

When a router receives an OSPF Hello from a neighbor, it sends the Hello packet by including that neighbor's router ID in the Hello packet. If it doesn't include the neighbor's router ID, the neighbor will be stuck in INIT. This is an indication of a problem. The first packet that a router receives will cause the router to go into INIT state. At this point, it is not a problem, but if the router stays in this state for a long time, it's an indication of a problem. It means that the neigh-bor router is not seeing Hellos sent by this router ‚ that's why it is not including the router ID of the router in its Hello packet. The network setup in Figure 9-20 is used here to discuss the stuck in INIT problem.

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

  • An access list on one side is blocking OSPF Hellos.

  • Multicast capabilities are broken on one side (6500 switch problem).

  • Authentication is enabled on only one side (virtual link example).

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

Example 9-63 shows the output of show ip ospf neighbor, which shows stuck in INIT.

Example 9-63 show ip ospf neighbor Command Output Indicates That R2's Neighbor Is Stuck in INIT
 R2#  show ip ospf neighbor  Neighbor ID   Pri  State    Dead Time   Address         Interface  131.108.2.1    1  INIT/-  00:00:33    131.108.1.1     Ethernet0 

OSPF Neighbor Stuck in INIT ‚ Cause: Access List on One Side Is Blocking OSPF Hellos

OSPF uses a multicast address of 224.0.0.5 for sending and receiving Hello packets. If an access list is defined on the interface and OSPF is enabled on that interface, this multicast address must be explicitly permitted in the access list; otherwise , it can produce problems such as stuck in INIT. The stuck in INIT problem occurs only if one side is blocking OSPF Hellos. If both sides are blocking OSPF Hellos, the output of show ip ospf neighbor returns an empty list.

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

Figure 9-23. Problem-Resolution Flowchart

graphics/09fig23.gif

Debugs and Verification

Example 9-64 shows the output of show access-list 101 and debug ip packet 101 detail on R1, where access list 101 is configured to see only the OSPF Hello packets between R1 and R2.

Example 9-64 debug Output Shows That OSPF Hellos Are Denied
 R1#  show access-list 101  Extended IP access list 101     permit ip 131.108.1.0 0.0.0.3 host 224.0.0.5 (8 matches) R1#  debug ip packet 101 detail  IP packet debugging is on (detailed) for access list 101 R1# IP: s=131.108.1.1 (local), d=224.0.0.5 (Ethernet0), len 60, sending broad/multicast, proto =89 IP: s=131.108.1.2 (Ethernet0), d=224.0.0.5, len 82, access denied, proto=89 IP: s=131.108.1.1 (local), d=224.0.0.5 (Ethernet0), len 60, sending broad/multicast, proto =89 IP: s=131.108.1.2 (Ethernet0), d=224.0.0.5, len 82,  access denied  , proto=89 

Example 9-65 shows the configuration of R1. Access list 100 on R1 is permitting only traffic destined for R1 and R2 interface addresses; it denies any other traffic, including OSPF Hellos.

Access list 101 on Router R1 is configured to limit the debug so that it will display only OSPF Hellos going across.

Example 9-65 Access List Configuration on R1 That Blocks OSPF Hellos
 R1#  !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   ip access-group 100 in   !   access-list 100 permit ip any 131.108.1.0 0.0.0.255  
Solution

To fix this problem, allow the OSPF Hellos in access list 100 on R1. The new line allows any packet source from 131.108.1.0 ‚ 255 destined for OSPF multicast address of 224.0.0.5. Example 9-66 shows the modified access list on R1.

Example 9-66 Modified Access List on R1
 R1#   access-list 100 permit ip any 131.108.1.0 0.0.0.255    access-list 100 permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5  

Example 9-67 shows the output of show ip ospf neighbor after fixing the problem.

Example 9-67 show ip ospf neighbor Command Output Verifies That the Access List Now Permits OSPF Multicasts and OSPF Neighbors Are Formed
 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 Stuck in INIT ‚ Cause: Multicast Capabilities Are Broken on One Side (6500 Switch Problem)

This is a specific situation that is valid only in the case of a Catalyst 6500 switch with the multilayer switch feature card (MSFC). The problem is that one side is sending OSPF Hellos that the other side does not receive. The network setup in Figure 9-24 shows how this can be a problem.

Figure 9-24. Network Setup Vulnerable to OSPF Neighbor Stuck in INIT Problem Because of Broken Multicast Capabilities

graphics/09fig24.gif

This situation is produced when the command set protocolfilter enabled is entered on the 6500 switch. By default, the protocol filter is disabled. Enabling this command begins altering the multicast frame to and from MSFC and port adapter within the FlexWan module of the 6500 switch. Figure 9-25 shows the flowchart to follow to solve this problem.

Figure 9-25. Problem-Resolution Flowchart

graphics/09fig25.gif

Debugs and Verification

Example 9-68 shows the output of show ip ospf neighbor. The neighbor is stuck in INIT, and the switch in the middle is 6500 with MSFC, as shown in Figure 9-24.

Example 9-68 OSPF Neighbor Stuck in INIT State
 R2#  show ip ospf neighbor  Neighbor ID  Pri  State   Dead Time  Address     Interface 131.108.2.1  1 x  INIT/-  00:00:33   131.108.1.1 FastEthernet0/0 
Solution

To fix this problem, disable the protocol filter on 6500 switch as follows:

 CAT6k(enable)  set protocolfilter disable  

Example 9-69 shows the OSPF neighbors in FULL state after fixing this problem.

Example 9-69 Verifying That the OSPF Neighbors Are Up After the Protocol Filter on the 6500 Switch Has Been Disabled
 R2#  show ip ospf neighbor  Neighbor ID  Pri  State   Dead Time  Address     Interface 131.108.2.1    1  FULL/DR 00:00:33   131.108.1.1 FastEthernet0/0 

OSPF Neighbor Stuck in INIT ‚ Cause: Cause: Authentication Is Enabled Only on One Side

When authentication is used, it must be enabled on both sides; otherwise, one side will show the neighbor stuck in the INIT state. The router that has authentication enabled will reject all the nonauthenticated packets, and the adjacency will show stuck in INIT. The other side will not detect any problem because the authentication is turned on, so it will simply ignore the authentication in a packet and treat it as a normal packet.

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

Figure 9-26. Problem Resolution Flowchart

graphics/09fig26.gif

Debugs and Verification

Example 9-70 shows the output of debug ip ospf adj on R2 indicating that Router R2 has plain-text authentication enabled but R1 is sending packets without any authentication. As a result, R2 rejects those packets. This is an example of plain-text authentication. In cases of MD5 authentication, the debug output will say we use type 2.

Example 9-70 debug ip ospf adj Command Output Indicates an Authentication Type Mismatch on the Neighboring Router
 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 0, we use type 1  

Example 9-71 shows the configuration of R2. The configuration shows that R2 is using plain-text authentication in area 1. This problem will reproduce with or without defining the authentication key under the interface. If the keys are not defined, the router uses a default key.

Example 9-71 R2 Uses Plain-Text Authentication in Area 1
 R2#  router ospf 1   network 131.108.1.0 0.0.0.255 area 1   area 1 authentication  
Solution

To fix this problem, enable authentication on both sides and define the authentication key on both sides. Example 9-72 shows the new configuration for both R1 and R2 that fixes this problem.

Example 9-72 Configuring Authentication on Both Routers to Resolve the Problem
 R2#  !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   ip ospf authentication-key cisco   !   router ospf 1   network 131.108.1.0 0.0.0.255 area 1    area 1 authentication   _____________________________________________________________________________________ R1#  !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0    ip ospf authentication-key cisco    !   router ospf 1   network 131.108.1.0 0.0.0.255 area 1   area 1 authentication  

Example 9-73 shows the neighbor state after fixing this problem.

Example 9-73 show ip ospf neighbor Command Output Verifies That the Authentication Fix 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:33   131.108.1.1 Ethernet0  

Similar problems occur in a virtual link situation. When authentication is enabled on backbone routers, it is a very common mistake not to enable authentication on the router that is connected to two different areas. This router becomes a virtual ABR after creating a virtual link; therefore, authentication must be enabled for area 0 on that router even though area 0 is not manually configured on it.

OSPF Neighbor Stuck in INIT ‚ Cause: The frame-relay map/dialer-map Statement on One Side Is Missing the broadcast Keyword

OSPF uses a multicast address of 224.0.0.5 to send and receive OSPF Hellos. If one side is incapable of sending or receiving Hellos, the OSPF neighbor will be stuck in the INIT state. The important thing to note here is that only one side suffers from this multicast prob-lem. R1 sees the neighbor in INIT state but can see the neighbor Hellos without any problem. When R1 sends the Hello to R2, it never reaches R2 because Layer 2 is incapable of sending any broadcast or multicast packets. This is because of the lack of the broadcast keyword in frame-relay map statement on R1. A similar problem can occur in the case of ISDN or dialer interface when the dialer map statement is configured without the broadcast keyword.

Figure 9-27 shows the network setup for the discussion of this problem.

Figure 9-27. Network Topology Used to Produce OSPF Neighbor Stuck in INIT Problem

graphics/09fig27.gif

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

Figure 9-28. Problem-Resolution Flowchart

graphics/09fig28.gif

Debugs and Verification

The output of debug ip packet 100 detail in Example 9-74 indicates that the Hello packets generated from R1 are not getting across because of an encapsulation failure.

Example 9-74 Encapsulation Failure Is Preventing Hello Packets from Being Propagated from R1
 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-75 shows the configuration of R1 and R2. The configuration shows that the broadcast keyword is missing from the frame-relay map statement on R1. R2, however, has the correct frame-relay map statement.

Example 9-75 Configurations for R1 and R2; R1 Omits the broadcast Keyword
 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 broadcast  
Solution

To fix this problem, make sure that the broadcast keyword is configured in all frame-relay map or dialer-map statements. Example 9-76 shows the new configurations of R1 and R2 to fix the problem.

Example 9-76 Correcting the frame-relay map Statement on R1 to Include the broadcast Keyword
 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  

Example 9-77 shows that OSPF adjacency is formed across the serial interface using Frame Relay encapsulation after fixing this problem.

Example 9-77 show ip ospf neighbor Command Output Indicates That the Problem Has Been Resolved
 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/BDR  00:00:32   131.108.1.1   Serial0 

OSPF Neighbor Stuck in INIT ‚ Cause: Hellos Are Getting Lost on One Side at Layer 2

This situation happens when there is a problem on the Layer 2 media; for example, the Frame Relay switch is blocking the multicast traffic for some reason. When R1 sends the Hello, R2 never receives it. Because R2 never saw Hellos from R1, the neighbor list of R2 will be empty. However, R1 sees the Hellos from R2, which does not list R1 as a valid neighbor; so, R1 declares this neighbor in the INIT state.

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

Figure 9-29. Problem-Resolution Flowchart

graphics/09fig29.gif

Debugs and Verification

Example 9-78 shows the debug ip packet detail output on both R1 and R2. This debug is turned on against access list 100, which shows that R1 is sending and receiving OSPF Hellos but R2 is only sending and not receiving any OSPF Hellos.

Example 9-78 debug Output Shows That R2 Is Sending but Not Receiving Any OSPF Hellos from R1
 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  _____________________________________________________________________________________ R2#  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) R2#  debug ip packet 100 detail  IP packet debugging is on (detailed) for access list 100 R1#  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, sending broad/multicast,   proto=89  

R1 keeps sending OSPF Hellos but never receives any Hellos from R2. This means that R2's Hellos are getting lost in the middle because the debug shows that R2 is sending as well as receiving OSPF Hellos.

Solution

The debug is done on both sides, and it is clear that both sides are sending Hellos but R1 Hellos never get across. Most likely, the Frame Relay cloud or other Layer 2 medium is dropping this multicast packet. This also can be verified by using a sniffer on the wire.

The solution for this problem is to fix the Layer 2 multicast capabilities, which is out of the scope of this book. One possible workaround in this situation has the following steps:

Step 1. Change the network type on both sides to nonbroadcast.

Step 2. Configure the neighbor statement on one router.

Example 9-79 shows the new interface configuration that is used so that a neighbor statement can fix this problem. Basically, the interface has been defined as nonbroadcast, so a neighbor statement can be defined. When a neighbor statement is defined, OSPF sends a unicast Hello packet. This configuration always works when the multicast capabilities of any Layer 2 media are broken.

Example 9-79 Changing the Network Type on Both Sides to Nonbroadcast
 R1#  interface Serial0   ip address 131.108.1.1 255.255.255.0   encapsulation frame-relay    ip ospf network non-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 non-broadcast    frame-relay map ip 131.108.1.1 16 broadcast  

Example 9-80 shows the OSPF configuration that configures the neighbor statement so that OSPF sends unicast Hello packets.

Example 9-80 Configuring neighbor Statement So That OSPF Sends a Unicast Hello
 R1#  router ospf 1   network 131.108.1.0 0.0.0.255 area 1   neighbor 131.108.1.2  

This solution is a workaround for the Layer 2 problem, but it doesn't fix the original Layer 2 problem. By changing the network type to nonbroadcast, as done in Example 9-79, OSPF will send and receive Hellos as unicast instead of multicast. So, if any issues occur with multicast at Layer 2, changing the network type to nonbroadcast and configuring a neighbor statement causes OSPF to form neighbors on a medium whose multicast capabilities are broken.

Example 9-81 shows that the OSPF adjacency is formed across the serial interface using the neighbor command with a nonbroadcast network type.

Example 9-81 Verifying That Using a Nonbroadcast Network Type Resolves the OSPF Neighbor Stuck in INIT Caused by a Layer 2 Issue
 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  
‚  < ‚  Free Open Study ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net