Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Configuring a Multi-Level IS-IS Topology to Control Interarea Flooding

This example shows how to configure a multi-level IS-IS topology.


No special configuration beyond device initialization is required before configuring this example.


Like OSPF, the IS-IS protocol supports the partitioning of a routing domain into multiple areas with levels that control interarea flooding. The use of multiple levels improves protocol scalability, as Level 2 (backbone) link-state PDUs are normally not flooded into a Level 1 area.

An IS-IS Level 2 area is analogous to the OSPF backbone area (0), while a Level 1 area operates much like an OSPF totally stubby area, in that a default route is normally used to reach both inter-level and AS external routes.

Unlike OSPF, IS-IS area boundaries occur between routers, such that a given routing device is always wholly contained within a particular area. Level 1 adjacencies can be formed between routers that share a common area number, while a Level 2 adjacency can be formed between routers that might or might not share an area number.

Figure 1 shows the topology used in this example.

Figure 1: IS-IS Multi-Level Topology IS-IS Multi-Level Topology

CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section #configuration69__isis-multi-level-step-by-step describes the steps on Device R5.

This example has the following characteristics:

  • Device R5 functions as a Level 1/Level 2 router to interconnect the Level 2 backbone area 49.0001 and the Level 1 area 49.0002 containing Device R6 and Device R7.

  • The system ID is based on the devices’ IPv4 lo0 addresses.

  • Loss of any individual interface does not totally disrupt the IS-IS operation.

  • The IPv4 lo0 addresses of all routers are reachable through IS-IS.

  • The link between Device R3 and Device S1 appears in area 49.0001 as an intra-area route. No IS-IS adjacencies can be established on this interface. This is accomplished by configuring the passive statement on Device R3’s interface to Device S1.

  • The loopback addresses of Level 2 devices do not appear in a Level 1 area.

  • There is only one adjacency for each device pairing.




CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R3

Device R4

Device R5

Device R6

Device R7

Device S1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure multi-level IS-IS:

  1. Configure the network interfaces.

    Enable IS-IS on the interfaces by Including the ISO address family on each interface.

  2. Configure two loopback interface addresses.

    One address is for IPv4.

    The other is for the IS-IS area 49.0002 so that Device R5 can form adjacencies with the other Level 1 devices in area 49.0002. Even though Device R5’s NET identifies itself as belonging to the Level 1 area 49.0002, its loopback interface is not configured as a Level 1 interface. Doing so would cause the route to Device R5’s loopback to be injected into the Level 1 area.

  3. Specify the IS-IS level on a per-interface basis.

    Device R5 becomes adjacent to the other routing devices on the same level on each link.

    By default, IS-IS is enabled for IS-IS areas on all interfaces on which the ISO protocol family is enabled (at the [edit interfaces interface-name unit logical-unit-number] hierarchy level). To disable IS-IS at any particular level on an interface, include the disable statement.

    Device R5’s loopback interface is configured to run Level 2 only. If Level 1 operation were enabled on lo0.0, Device R5 would include its loopback address in its Level 1 link-state PDU, which is incorrect for this example in which the loopback addresses of Level 2 devices must not appear in a Level 1 area.

    Unlike OSPF, you must explicitly list the router’s lo0 interface at the [edit protocols isis] hierarchy level, because this interface is the source of the router’s NET, and therefore must be configured as an IS-IS interface. In IS-IS, the lo0 interface operates in the passive mode by default, which is ideal because adjacency formation can never occur on a virtual interface.


From configuration mode, confirm your configuration by entering the show interfaces and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.


Confirm that the configuration is working properly.

Checking Interface-to-Area Associations


Make sure that the interface-to-area associations are configured as expected.


From operational mode, enter the show isis interface command.


The output shows that Device R5’s interfaces have been correctly configured with the ISO family, and that the interfaces have been placed into the correct levels.

You can also see that Device R5 has elected itself as the designated intermediate system (DIS) on its broadcast-capable IS-IS interfaces.

Verifying IS-IS Adjacencies


Verify that the expected adjacencies have formed between Device R5 and its IS-IS neighbors.


From operational mode, enter the show isis adjacency detail command.


These results confirm that Device R5 has two Level 2 adjacencies and two Level 1 adjacencies.

Examining the IS-IS Database


Because Device R5 is a Level 1/Level 2 (L1/L2) attached router, examine the Level 1 link-state database associated with area 49.0002 to confirm that loopback addresses from backbone routers are not being advertised into the Level 1 area.


From operational mode, enter the show isis database detail command.


This display indicates that Device R5’s loopback interface is correctly configured to run Level 2 only. Had Level 1 operation been enabled on lo0.0, Device R5 would have then included its loopback address in its Level 1 link-state PDU.

You can also see that Device R5 has Level 2 link-state PDUs, received from its adjacent neighbors.

Like an OSPF totally stubby area, no backbone (Level 2) or external prefixes are leaked into a Level 1 area, by default. Level 1 prefixes are leaked up into the IS-IS backbone, however, as can be seen in Device R5’s Level 2 link-state PDU.