No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Bidirectional Import of Routing Information Between IS-IS and OSPF Causes Routing Loops After Cutover

Publication Date:  2012-07-27 Views:  4 Downloads:  0

Issue Description

The networking is briefly described as follows: Two core routers (NE80Es) connect to two S3528Gs, constituting a square. The two NE80Es also connect to two NE40s, constituting another square. Thus, the biplane architecture is formed. Service devices are attached to the S3528Gs and NE40s for mutual communications. Because the S3528G does not support IS-IS, OSPF is deployed between the NE80Es and S3528Gs, and IS-IS between the NE80Es and NE40s. To implement route interworking, run the import route command on both NE80Es to enable the import of routing information of IS-IS to OSPF and that of OSPF to IS-IS. For details about the networking, see the appendix.
For network consolidation, NE40s need to be cut over to another network. To implement the cutover, close all interconnecting ports of an NE40 to isolate the NE40. After that, the routing information of loopback0 of the NE40 is still visible in the routing tables of the two NE80Es (In normal cases, the NE80Es should not receive routing information sent from the NE40). In addition, the next hop of such routing information in NE80E-1 directs to NE80E-2, and the next hop of such routing information in NE80E-2 directs to NE80E-1, thus forming routing loops. 

Alarm Information


Handling Process

Disable bidirectional import of routing information or configure the routing policy to prevent the import of IP addresses with specified IP prefixes during cutover. Then routing loops disappear. 

Root Cause

The loops are caused by the network topology instead of hardware failure. When NE40-2 is isolated by closing all its interconnecting ports, NE40-1 senses that the link of the neighbor, NE40-2, is Down. Then NE40-1 sends LSP packets, requesting the neighbor (NE80E-1) to update routing entries. NE80E-1 also sends the update notification to NE80E-2. In this manner, route convergence is completed.
Because bidirectional import of routing information is configured, although NE80E-1 receives the notification from the IS-IS neighbor for canceling routes, the routing table of NE80E-1 still contains the routing entry of the destination IP address imported from OSPF to IS-IS (The next hop of the entry is NE80E-2, different from the next hop of the entry that is to be canceled according to the notification of NE40-1. Therefore, they are taken as two routes). Because the destination IP address is still in the IS-IS routing table, NE80E-1 notifies the entry to NE80E-2 through IS-IS. NE80E-2 imports the entry to OSPF and notifies the route to NE80E-1 through OSPF. That explains why NE40-2 is isolated, but its routing information is still available in the routing tables of NE80Es, thus forming loops. In the case of no interference, the loops will proceed for all time. 


During network planning, do not configure the bidirectional import of routing information between IS-IS and OSPF, especially on two devices on the same network. If interworking between IS-IS and OSPF is required, consider configuring the default route in OSPF to direct the traffic to the device where protocols converge.