Troubleshooting Layer 3 IP routing issues

IS-IS issues

IS-IS neighbor establishment failure

Symptom

·     The IS-IS neighbor is down.

·     The IS-IS neighbor relationship flaps.

Common causes

The following are the common causes of this type of issue:

·     IS-IS cannot send or receive hello packets normally, because a device has underlying faults or the link between the two devices fails.

·     The devices at the ends of the link use the same system ID.

·     The interfaces connected by the link use different MTU settings or the effective interface MTU is smaller than the transmitted hello packets.

·     The IP addresses of the interfaces connected by the link are not in the same network segment.

·     The interfaces connected by the link use different authentication modes.

·     The two ends of the link are at mismatching IS-IS levels.

·     When the two devices establish an IS-IS Level-1 neighbor relationship, they use different area addresses.

Troubleshooting flow

Figure 1 shows the troubleshooting flowchart.

Figure 1 Flowchart for troubleshooting IS-IS neighbor establishment failures

 

Solution

1.     Identify whether the IS-IS interface is UP at the physical layer.

Execute the display interface [ interface-type [ interface-number | interface-number.subnumber ] ] command to identify whether the physical state of the IS-IS interface is UP.

¡     If the physical state of the IS-IS interface is DOWN, the interface has failed. You must resolve this issue first.

¡     If the physical state of the IS-IS interface is UP, proceed to step 2.

2.     Check for link failures.

¡     Execute the ping command to identify whether the link fails. If the link is operating properly, proceed to step 3.

To have IS-IS use BFD for link state detection, execute the isis bfd session-restrict-adj command to enable BFD session state-based control of adjacency establishment and maintenance. The IS-IS interfaces will advertise BFD-enabled TLVs in hello packets to each other. If the exchanged BFD-enabled TLVs carry the same information, BFD session state-based control of adjacency establishment and maintenance takes effect. After the BFD session goes down, the interfaces cannot establish an IS-IS adjacency.

¡     Execute the display bfd session command to view the state of the BFD session that monitors the IS-IS link. If the State field displays Down, first resolve link failures. If the State field displays Up, proceed to step 3.

3.     Identify whether the CPU or memory usage is too high.

¡     Execute the display cpu-usage command to check the CPU usage. If the MPU and interface modules on the device have high CPU usage, IS-IS cannot correctly send or receive packets, resulting in neighbor flapping. To resolve this issue, disable unnecessary features. If the CPU usage is not high, proceed to step 4.

¡     Execute the display memory-threshold command, and then view the Current free-memory state field in the command output. This field displays the current memory usage of the system. If this field displays Minor, Severe, or Critical, the free memory resources might be tight. As a result, the device might be unable to receive or send IS-IS packets, or might process IS-IS packets slowly. To resolve this issue, disable unnecessary features. If the current memory usage is normal, proceed to step 4.

4.     Identify whether the state of the IS-IS interface is normal.

a.     Execute the display current-configuration interface interface-type interface-number command to identify whether IS-IS is enabled on the specified interface.

-     If IS-IS is not enabled, execute the isis enable command to enable IS-IS on the associated interface.

-     If IS-IS is enabled, proceed to the next step.

Execute the display isis interface command, and then view the IPv4 state or IPv6 state field to identify whether the IS-IS interface is in normal state.

¡     If the state of the IS-IS interface is Lnk:Up/IP:Dn, the interface is up at the link layer but is down at the network layer. You need to resolve interface faults at the network layer.

¡     If the state of the IS-IS interface is Up, proceed to step 5.

5.     Identify whether IP addresses of the two IS-IS interfaces are in the same network segment.

¡     For IPv4 IS-IS, execute the display interface brief command to view the IPv4 address of each IS-IS interface.

-     If the two IPv4 interface addresses are in different network segments, execute the ip address command on either of the interfaces to adjust its IPv4 address. This operation ensures that the IPv4 addresses of the two IS-IS interfaces are in the same network segment.

-     If the two IPv4 interface addresses are in the same network segment, proceed to step 6.

¡     For IPv6 IS-IS, this check is not required.

6.     Identify whether the two IS-IS interfaces use the same MTU value.

Execute the display interface [ interface-type [ interface-number | interface-number.subnumber ] ] command to view interface MTU information.

¡     If the two IS-IS interfaces use different MTU values, execute the mtu size command on either of the interfaces to adjust its MTU value. This operation ensures that the two IS-IS interfaces use the same MTU value.

¡     If the two IS-IS interfaces use the same MTU value, proceed to step 7.

7.     Identify whether IS-IS can receive hello packets.

Execute the display isis packet hello by-interface verbose command to identify whether IS-IS can receive hello packets. If the device cannot receive hello packets, resolve the packet loss issue. If the issue persists, proceed to step 12.

If the device can receive hello packets, continue to perform the following checks:

¡     If the value for the Duplicate system ID field increases over time, a system ID conflict exists and you need to proceed to step 8.

¡     If the value for the Mismatched level (LAN) field increases over time, an IS level mismatch exists and you need to proceed to step 9.

¡     If the value for the Bad area address TLV field increases over time, an area address mismatch exists and you need to proceed to step 10.

¡     If the values for other fields increase over time, proceed to step 12.

8.     Identify whether the devices connected by the link use the same system ID.

Execute the display current-configuration configuration isis command to view the system IDs of the devices.

¡     If their system IDs are identical, change the system ID of either device with the network-entity command.

¡     If their system IDs are different, proceed to step 9.

9.     Identify whether the devices connected by the link have an IS level mismatch.

Identify the IS level of each device and the circuit level of each IS-IS interface.

¡     Execute the display current-configuration | include is-level command to view the IS levels of the two devices connected by the link. If this command does not display the IS level of a device, the IS level of the device is Level-1-2, the default value.

¡     Execute the display current-configuration interface interface-type interface-number | include circuit-level command to view the circuit levels of IS-IS interfaces. If this command does not display the circuit level of an IS-IS interface, the circuit level of the interface is Level-1-2, the default value. The interface can establish both Level-1 and Level-2 adjacencies.

Two IS-IS interfaces can establish an IS-IS neighbor relationship only when their circuit levels meet one of the following requirements:

¡     If the circuit level of the local interface is Level-1, the circuit level of the remote interface must be Level-1 or Level-1-2.

¡     If the circuit level of the local interface is Level-2, the circuit level of the remote interface must be Level-2 or Level-1-2.

¡     If the circuit level of the local interface is Level-1-2, the circuit level of the remote interface can be Level-1, Level-2, or Level-1-2.

Perform one of the following troubleshooting operations accordingly:

¡     If the two devices have an IS level mismatch, execute the is-level command in IS-IS view for either of the devices to adjust its IS level. Alternatively, execute the isis circuit-level command in interface view for the desired interface to adjust its circuit level.

¡     If the IS levels of the two devices are matching, proceed to step 10.

10.     Identify whether the area addresses of the two devices connected by the link are matching.

Execute the display isis command, and then view the Network entity field in the command output to identify whether the area addresses of the devices match. The network entity title (NET) format is X…X.XXXX.XXXX.XXXX.00. The X…X segment represents the area address, the XXXX.XXXX.XXXX segment represents the system ID, and the 00 segment is the SEL.

¡     If two IS-IS devices establish a Level-1 neighbor relationship, they must be in the same area. If they establish an IS-IS Level-2 neighbor relationship, area address check is not required.

When the two devices fail to establish a Level-1 neighbor relationship due to area address inconsistency, execute the network-entity command in IS-IS view for either of the devices to adjust its area address.

¡     If the area addresses of the two devices are matching, proceed to step 11.

11.     Identify whether the two devices connected by the link are in the same IS-IS authentication mode.

Execute the display current-configuration interface-type interface-number | include isis command to view the authentication mode of the IS-IS interface on each device.

If the two IS-IS interfaces are in different authentication modes, execute the isis authentication-mode command on either of the IS-IS interfaces to adjust its authentication mode. This operation ensures that the two IS-IS interfaces are in the same authentication mode.

If the two IS-IS interfaces are in the same authentication mode and still fail to establish a neighbor relationship, verify that they use the same authentication password.

If the issue persists, proceed to step 12.

12.     Collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

Module name: ISIS-MIB

·     isisAdjacencyChange (1.3.6.1.2.1.138.0.17)

Log messages

·     ISIS/3/ISIS_NBR_CHG

IS-IS route learning failure

Symptom

A device cannot learn an IS-IS route.

Common causes

The following are the common causes of this type of issue:

·     IS-IS has advertised the same routes as those advertised by other routing protocols, and the preference of such protocols are higher than that of IS-IS.

·     The route is not selected as an optimal route, because it is redistributed into IS-IS and its preference  is low.

·     The route is not selected as an optimal route, because it is redistributed into IS-IS and is of a different cost type.

·     The device and the advertisement source device are in different IS-IS cost styles.

·     The device and the advertisement source device does not establish a normal IS-IS neighbor relationship.

·     The device and the advertisement source device are configured with the same system ID.

·     LSP authentication fails.

·     Some LSPs are lost because the device has underlying faults or the link between the two devices fails.

·     The device cannot receive the LSPs from the advertisement source device, because the LSP length has exceeded the maximum length of LSPs that the device can receive.

Troubleshooting flow

Figure 2 shows the troubleshooting flowchart.

Figure 2 Flowchart for troubleshooting IS-IS route learning failures

 

Solution

1.     Identify whether the IS-IS routing table contains the desired IS-IS route.

Execute the display isis route command to view the IS-IS routing table.

¡     If the IS-IS route exists in the IS-IS routing table, execute the display ip routing-table ip-address [ mask | mask-length ] verbose command to check for routes with protocol preference higher than that for IS-IS routes.

-     If such routes exist, adjust the configuration according to the network plan.

-     If such routes do not exist, proceed to step 7.

¡     If the IS-IS route does not exist in the IS-IS routing table, proceed to step 2.

2.     Identify whether the desired IS-IS route is advertised.

Execute the display isis lsdb verbose local command on the advertisement source device to identify whether the device has advertised LSPs that carry the IS-IS route.

¡     If no LSPs carry the IS-IS route, check for incorrect IS-IS configurations on the advertisement source device. For example, you can check whether the related interface is enabled with IS-IS. If the IS-IS route is an external route redistributed into IS-IS, execute the display ip routing-table protocol protocol verbose command, and then view the State field of the route. If this field contains Inactive, the external route is inactive. IS-IS does not advertise inactive routes. In this situation, adjust the configurations related with external routes to ensure that the State field of the route contains Active and Adv.

¡     If an LSP that carries the IS-IS route exists, proceed to step 3.

3.     Identify whether the desired IS-IS route is of the same cost type as other redistributed routes with the same destination address.

When multiple devices advertise routes to the same destination through route redistribution and these external routes need to form a load balancing relationship, make sure these routes are of the same cost type after redistribution by IS-IS. The cost value for a redistributed route varies by its cost type:

¡     If the cost type is external, the cost value equals the original cost value plus 64 when IS-IS advertises the route in LSPs.

¡     If the cost type is internal, the cost value equals the original cost value when IS-IS advertises the route in LSPs.

By default, the cost type is external for external routes redistributed by H3C devices. If the cost type of external routes redistributed by non-H3C devices is not external, the cost values for routes with the same destination address will be different. As a result, IS-IS neighbors will select the route with the lowest cost value as the optimal route. In this case, adjust the cost type of redistributed external routes to ensure that the external routes redistributed by devices from various vendors are all of the same cost type. To adjust the cost type of external routes redistributed by an H3C device:

On the device that advertises the desired IS-IS route, execute the display current-configuration configuration isis command to view the route redistribution configuration for IS-IS.

Execute the import-route command to adjust the cost type of external routes redistributed into IS-IS.

In situations other than those mentioned above, proceed to step 4.

4.     Identify whether the IS-IS database has been synchronized.

On the device that cannot learn the IS-IS route, execute the display isis lsdb command to identify whether the device has received an LSP that contains the IS-IS route from the advertisement source device.

¡     If the desired LSP does not exist in the LSDB, check for link failures. If no link failures are found, execute the display isis command, and then view the LSP length receive field to determine whether the related LSP is too long for the device to receive. When the value of this field exceeds the maximum LSP length supported by the device, use the lsp-length originate command on the advertisement source to change the maximum length of generated LSPs. Make sure the maximum length of LSPs generated by the advertisement source equals the minimum IS-IS interface MTU within the current area.

¡     If the desired LSP exists in the LSDB, but the following conditions exist, the system ID of the advertisement source device conflicts with that of another device:

-     The value for the Seq Num field of the LSP is different from that on the advertisement source device. To view the value for the Seq Num field of the LSP on the advertisement source device, use the display isis lsdb local verbose command.

-     The value for the Seq Num field of the LSP keeps increasing.

In this situation, find the device that uses the same system ID as the advertisement source device, and then change the system ID of either device.

¡     If the desired LSP exists in the LSDB, but the following conditions exist, LSPs might be discarded during transmission due to link failures:

-     The value for the Seq Num field of the LSP is different from that on the advertisement source device. To view the value for the Seq Num field of the LSP on the advertisement source device, use the display isis lsdb local verbose command.

-     The value for the Seq Num field of the LSP remains unchanged.

In this situation, check for underlying faults on the device and identify whether the intermediate links between the device and the advertisement source device fail.

¡     If the following conditions exist, proceed to step 5:

-     The desired LSP exists in the LSDB.

-     The value for the Seq Num field of the LSP is the same as that on the advertisement source device. To view the value for the Seq Num field of the LSP on the advertisement source device, use the display isis lsdb local verbose command.

5.     Identify whether the device and the advertisement source device use the same cost style.

Execute the display isis command on the device and the advertisement source device separately, and then view the value for the Cost style field to identify whether the two devices use the same cost style. They can learn routes from each other only if their cost styles are the same.

¡     If the two devices use different cost styles, execute the cost-style command in IS-IS view for either of the devices to change its cost style.

¡     If the two devices use the same cost style, proceed to step 6.

6.     Identify whether all devices along the path between the device and the advertisement source device have established IS-IS neighbor relationships correctly.

Execute the display isis peer command on each device to check for abnormal IS-IS neighbor relationships.

¡     If some neighbor relationships are established incorrectly, resolve this issue as described in “IS-IS neighbor establishment failure.”

¡     If all neighbor relationships are established correctly, proceed to step 7.

7.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

N/A

IS-IS route flapping

Symptom

An IS-IS route is repeatedly added and deleted.

Common causes

The following are the common causes of this type of issue:

·     The IS-IS neighbor flaps.

·     The MPLS LSP tunnel flaps.

·     The two devices that have established an IS-IS neighbor relationship redistribute the same external route, and the external route has a lower protocol precedence than IS-IS.

·     The local and remote devices are configured with the same system ID.

Troubleshooting flow

Figure 3 shows the troubleshooting flowchart.

Figure 3 Flowchart for troubleshooting IS-IS route flapping

 

Solution

1.     View the route flapping details.

Execute the display ip routing-table ip-address verbose command to view the route flapping details as follows:

¡     If the TunnelID field of the IS-IS route changes before and after route flapping, identify whether the MPLS LSP tunnel flaps.

Execute the display mpls lsp verbose command, and then view the Last Chg Time field to view the time when the state of the LDP LSP changed most recently. If the time is close to the time when the display mpls lsp verbose command is executed, MPLS LSP tunnel flapping exists.

In this situation, check for and troubleshoot LSP flapping issues. You can see the solution to LDP LSP flapping issues or sudden TE tunnel state changes (from up to down).

¡     If the Cost or Interface field of the IS-IS route changes, check for IS-IS neighbor flapping along the route.

¡     If the Age field is set to 0 and the counter is reset frequently for an IS-IS route in the routing table, the route might sometimes appear and sometimes disappear. In this situation, you can execute the display isis lsdb verbose command to find the LSP that carries the IS-IS route. Record the LSP ID of the LSP, and then the display isis lsdb verbose lsp-id command to view the update status of this LSP.

-     If the LSP always carries the IS-IS route, check for IS-IS neighbor flapping along the route.

-     If the value for the Seq Num field of the LSP keeps increasing and a significant content change exists before and after the LSP update, check for devices configured with the same system ID in the network.

-     If the value for the Seq Num field of the LSP keeps increasing and the IS-IS route is intermittently present before and after the LSP update, locate the device that generated this LSP, and then perform step 2 on that device.

¡     If the Protocol field of the IS-IS route changes, proceed to step 2.

2.     Check the route redistribution configuration for IS-IS.

If the IS-IS route is an external route redistributed into IS-IS, execute the display ip routing-table ip-address verbose command on the device into which the route was redistributed. This command displays the route flapping details.

¡     If the IS-IS route is not active and another IS-IS route with the same destination address is in Active state in the routing table, it indicates that other IS-IS devices in the network have advertised the same route. To resolve this issue, perform one of the following operations:

-     Adjust the route preference according to the network plan.

-     Configure a route filtering policy on the IS-IS device that redistributes the external route to control the routes flushed to the IP routing table.

¡     In other situations, proceed to step 3.

3.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

N/A