‚ < ‚ 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 :
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 INITR2# 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 HellosOSPF 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
Debugs and VerificationExample 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 DeniedR1# 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 HellosR1# ! 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 SolutionTo 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 R1R1# 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 FormedR2# 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
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
Debugs and VerificationExample 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 StateR2# 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 SolutionTo 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 SideWhen 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
Debugs and VerificationExample 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 RouterR2# 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 1R2# router ospf 1 network 131.108.1.0 0.0.0.255 area 1 area 1 authentication SolutionTo 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 ProblemR2# ! 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 ProblemR2# 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 KeywordOSPF 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
Figure 9-28 shows the flowchart to follow to solve this problem. Figure 9-28. Problem-Resolution Flowchart
Debugs and VerificationThe 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 R1R1# 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 KeywordR1# 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 SolutionTo 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 KeywordR1# 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 2This 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
Debugs and VerificationExample 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 R1R1# 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. SolutionThe 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:
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 NonbroadcastR1# 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 HelloR1# 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 IssueR2# 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 ‚ > ‚ |