Multi-Level IS-IS Configuration | JNCIP: Juniper Networks Certified Internet Professional Study Guide

Like OSPF, the IS-IS protocol supports the partitioning of a routing domain into multiple levels. The use of multiple levels will generally improve protocol scalability, as level 2 (backbone) Link State Protocol Data Units (LSPs) are normally not flooded into a level 1 area.

Briefly stated, an IS-IS level 2 area is analogous to the OSPF backbone area (0), while a level 1 area operates much as 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 Intermediate System (IS) is always wholly contained within a particular area. Level 1 adjacencies can only be formed between routers that share a common area number, while a level 2 adjacency can be formed between routers that may or may not share an area number. Juniper Networks M-series routers support the IS-IS protocol strictly for use in building IP routing tables. There is no support for the routing of OSI Connectionless Network Service (CLNS) network layer packets.

We begin our IS-IS configuration example with the network topology shown in Figure 4.1.

click to expand
Figure 4.1: Multi-level IS-IS

Referring to Figure 4.1, you can see that r5 will need to function as a level 1/level 2 router to interconnect the level 2 backbone (area 49.0001) and the level 1 area (49.0002) containing r6 and r7. To complete this configuration example, your IS-IS configuration must meet the following criteria:

The System ID (SysID) must be based on the router’s IPv4 lo0 address.
Loss of any individual interface must not totally disrupt the router’s IS-IS operation.
The IPv4 lo0 addresses of all routers must be reachable via IS-IS.
The link between r3 and T1 must appear in area 49.0001 as an intra-area route. Ensure that no IS-IS adjacencies can be established on this interface.
The loopback addresses of level 2 routers may not appear in a level 1 area.
Only one adjacency per router pairing is permitted.

IS-IS Configuration

We begin by configuring r4 as a level 2 IS-IS router based on the topology shown earlier in Figure 4.1. To enable IS-IS routing on a Juniper Networks router, you must add the iso protocol family to each IS-IS interface, assign your router’s IS-IS address, and enable the IS-IS routing instance. What follows are step-by-step instructions on how to configure IS-IS and confirm its operation.

Configure Interface Support of IS-IS PDUs

The following commands are required to add the iso protocol family to all of r4’s interfaces that are expected to run IS-IS. Failing to include the iso family will cause IS-IS to be disabled on that interface, because such an interface will not be able to send or receive link-level IS-IS PDUs:

[edit interfaces] lab@r4# set so-0/1/0 unit 100 family iso [edit interfaces] lab@r4# set as0 unit 0 family iso

The IS-IS protocol will not operate until you have assigned a NET to one of your router’s interfaces. The term NET is a fancy word for the IS-IS address that will uniquely identify a given router within an IS-IS routing domain. You must assign the NET to the router’s lo0 interface to meet this example’s requirement that “loss of any individual interface must not totally disrupt the router’s IS-IS operation.” You must also ensure that the NET is in some way traceable to the IPv4 address assigned to the router’s lo0 address. The following command correctly configures r4’s NET for this example:

[edit interfaces lo0 unit 0 family iso] lab@r4# set address 49.0001.0100.0000.3004.00

Though perhaps not intuitive, the IS-IS address (NET) that has been assigned to r4 is interpreted as follows:

The Authority and Format Identifier (AFI) value of 49 indicates a private use/locally assigned ISO NET.
The area number is 0001.
The 6-byte System ID (SysID) is set to encode the router’s IPv4 lo0 address in Binary Coded Decimal (BCD) format using three BCD digits for each decimal-delimited portion of corresponding IPv4 address. The resulting SysID is interpreted as 10.0.3.4, which meets the configuration requirements of this example. Although numerous mapping approaches could be used to satisfy the requirements of this example, e.g., 0010.0000.0034, it is highly recommended that you adopt a consistent transcoding algorithm to ensure ease of SysID interpretation, and to help prevent the assignment of a duplicate SysID.
The Selector field is set to 00, which makes this an ISO NET and not a Network Service Access Point Address (NSAPA). You should always specify an all-zeros selector byte for proper IS-IS operation.

The IS-IS related interface configuration of r4 is displayed in Listing 4.1. The highlights call out the recently added IS-IS configuration:

Listing 4.1: r4 IS-IS Interface Configuration

[edit] lab@r4# show interfaces as0 aggregated-sonet-options {     minimum-links 2;     link-speed oc3; } unit 0 {      family inet {         address 10.0.2.10/30;     }      family iso; } [edit] lab@r4# show interfaces so-0/1/0  dce; hold-time up 30 down 30; encapsulation frame-relay; lmi {      n392dce 2;      n393dce 3;      t392dce 25;      lmi-type itu; } unit 100 {     dlci 100;      family inet {         address 10.0.2.6/30;     }      family iso; } [edit] lab@r4# show interfaces lo0 unit 0 {      family inet {          address 10.0.3.4/32;      }     family iso {         address 49.0001.0100.0000.3004.00;      } } [edit] lab@r4#  show interfaces fxp0 unit 0 {     family inet {          address 10.0.1.4/24;      } }

Warning

To help guard against inadvertent use of IS-IS on the OoB management network, you should avoid adding the iso family to the router’s fxp0 interface. If you are using configuration groups to expedite the addition of protocol families, you must use caution to ensure either that the configuration group does not “catch” the fxp0 interface or that you explicitly disable IS-IS on the fxp0 interface when making use of the interface all option shown in this chapter. IGP adjacency formation over the OoB network can be disastrous because your routers will be inclined to forward traffic over the fxp0 subnet (because of the lower metric associated with this path), in conjunction with the fact that transit traffic is not supported over the fxp0 interface. Can you say “black hole”?

Configure r4’s IS-IS Routing Instance

The following commands are used to enable the main IS-IS instance and to correctly associate r4’s IS-IS capable interfaces with IS-IS level 2 operation. Unlike OSPF, you must explicitly list the router’s lo0 interface under the [edit protocols isis] stanza, as this interface is the source of the router’s NET, and therefore must be configured as an IS-IS interface. The lo0 interface will operate in the passive mode by default, which is ideal because adjacency formation can never occur on a virtual interface anyway.

[edit protocols isis] lab@r4# set interface lo0 level 1 disable [edit protocols isis] lab@r4# set interface as0 level 1 disable [edit protocols isis] lab@r4# set interface so-0/1/0.100 level 1 disable

By disabling level 1 IS-IS operation on r4’s area 49.0001 interfaces, you ensure that at most one adjacency (level 2) can be formed between each router pair in area 49.0001. The JUNOS software default is to enable interface operation at both levels 1 and 2, which would result in two adjacencies forming, and subsequent point loss on your exam because the criteria for this example limits you to one adjacency per router pairing. The resulting configuration of r4’s main IS-IS routing instance is shown here:

[edit protocols isis] lab@r4# show interface so-0/1/0.0 {    level 1 disable;  }  interface as0.0 {    level 1 disable;  } interface lo0.0 {    level 1 disable;  }

Verify IS-IS on r4

After committing the initial IS-IS configuration, we can display the state of r4’s IS-IS interfaces to confirm their proper configuration and level assignment. The results indicate that r4’s as0, so-0/1/0.100, and lo0 interfaces are enabled for IS-IS operation at level 2 only. As expected, no Designated Intermediate System (DIS) has been elected because of the lack of broadcast interface types on r4:

lab@r4> show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric as0.0                 2   0x1 Disabled          Point to Point         10/10 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/1/0.100          2   0x1 Disabled          Point to Point         10/10 lab@r4>

In the absence of other IS-IS routers, we expect to find that r4 has no neighbors and, therefore, no adjacencies:

lab@r4> show isis adjacency lab@r4>

As predicted, r4 currently has no IS-IS adjacencies. We can obtain additional information about the default IS-IS timers and source of the router’s NET by using the detail switch, as shown next:

lab@r4> show isis interface detail IS-IS interface database: as0.0   Index: 10, State: 0x6, Circuit id: 0x1, Circuit type: 2   LSP interval: 100 ms, CSNP interval: disabled   Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router     2             0       64     10         9        27 lo0.0   Index: 3, State: 0x7, Circuit id: 0x1, Circuit type: 0   LSP interval: 100 ms, CSNP interval: disabled, Sysid: r4   Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router     2             0       64      0 Passive so-0/1/0.100   Index: 11, State: 0x6, Circuit id: 0x1, Circuit type: 2   LSP interval: 100 ms, CSNP interval: disabled   Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router     2             0       64     10         9        27

This display confirms that the lo0 interface is the source of the router’s NET, that no adjacencies have been formed, and that the default (non–Designated Intermediate System [DIS]) hello and hold timers are being used on all interfaces except lo0, which does not use them because of its passive mode of operation.

IS-IS Timers

Unlike OSPF, IS-IS will permit adjacency formation between systems that have been configured to use different hello timers. The hold interval is used to inform the remote system how long the adjacency can be considered valid in the absence of received hello LSPs. By default, the hold value is three times the configured hello interval, but both parameters can be set independently. The default ratio means that an adjacency can be maintained even if two out of three hello packets are lost. JUNOS software will automatically reduce an interface’s hold and hello intervals by ²/₃ rds (3-second hellos and 9-second hold time) should the router be elected the DIS for the network that attaches to that interface. This enables the rapid detection of DIS failures. The IS-IS hold times at each level are unrelated to each other, so you may configure an interface’s level 1 and level 2 timers differently with no ill effects.

The last step in confirming IS-IS operation on r4 is to examine the LSDB:

lab@r4# run show isis database IS-IS level 1 link-state database: LSP ID                       Sequence Checksum Lifetime Attributes r4.00-00                         0x8   0xa284      1195 L1 L2   1 LSPs IS-IS level 2 link-state database: LSP ID                       Sequence Checksum Lifetime Attributes r4.00-00                         0xc   0xbab3      1195 L1 L2   1 LSPs

Many exam candidates are surprised to find their router contains a level 1 database entry when they know that all of the router interfaces have been set to run level 2 only. The lone level 1 LSP is the result of disabling level 1 operation on the router’s interfaces but not in the IS-IS routing instance itself. This LSP can never leave your router, and no level 1 LSPs can be received from other routers in the routing domain until IS-IS level 1 operation is enabled on at least one interface. A detailed examination of the LSDB confirms that the level 1 LSP is not advertising any prefixes (as yet, no interfaces are enabled for level 1 operation), and also confirms that the level 2 LSP is advertising the route to all three of r4’s IS-IS subnetworks:

[edit] lab@r4# run show isis database detail IS-IS level 1 link-state database: r4.00-00 Sequence: 0x8, Checksum: 0xa284, Lifetime: 818 secs IS-IS level 2 link-state database: r4.00-00 Sequence: 0xd, Checksum: 0xb8b4, Lifetime: 1176 secs   IP prefix:                   10.0.2.4/30 Metric:         10 Internal   IP prefix:                   10.0.2.8/30 Metric:         10 Internal   IP prefix:                   10.0.3.4/32 Metric:          0 Internal

If the presence of this LSP serves as a distraction, you can disable IS-IS level 1 in the routing instance by issuing a set protocols isis level 1 disable command. This command is not used here because r4 is expected to require level 1 capabilities at a later point in this chapter’s examples.

Configure r5 for IS-IS Operation

Though not shown here, r5’s IS-IS configuration begins with the addition of the iso family to its as1, at-0/2/1.35, fe-0/0/0, fe-0/0/1, and lo0 interfaces using the commands that were shown for r4 in the section "Configure Interface Support of IS-IS PDUs" earlier in this chapter. The following commands define the correct interface and area associations needed by r5, which functions as a L1/L2 router in this example:

[edit protocols isis] lab@r5# set interface lo0 level 1 disable [edit protocols isis] lab@r5# set interface at-0/2/1.35 level 1 disable [edit protocols isis] lab@r5# set interface as1 level 1 disable [edit protocols isis] lab@r5# set interface fe-0/0/0 level 2 disable [edit protocols isis] lab@r5# set interface fe-0/0/1 level 2 disable

The resulting multi-level configuration for r5 is shown next:

[edit protocols isis] lab@r5# show interface fe-0/0/0.0 {    level 2 disable;  }  interface fe-0/0/1.0 {    level 2 disable;  } interface at-0/2/1.35 {    level 1 disable;  }  interface as1.0 {    level 1 disable;  } interface lo0.0 {    level 1 disable;  }

An alternative, but equally functional, configuration for r5 makes good use of the interface all keyword to save some typing:

[edit protocols isis] lab@r5# show interface fe-0/0/0.0 {    level 2 disable;  }  interface fe-0/0/1.0 {    level 2 disable;  }  interface all {    level 1 disable;  }

Many operators feel that this alternative configuration “contradicts itself” in that intuition tells them that the interface all level 1 disable statement should affect all interfaces, and thereby cause problems with r5’s Fast Ethernet interfaces, which are supposed to operate at level 1. This author likes to view the apparent quandary from a "longest match" perspective, in that the router will always override less specific configurations, such as interface all, with more specific information such as interface fe-0/0/0 level 2 disable. In this case, the fe-0/0/0 statement is more specific than the all keyword, so the router does the right thing by enabling level 1 only on the Fast Ethernet interfaces and level 2 only on all other interfaces. You should pay extra attention to the show isis interfaces command results when using this approach. You may find the router is running IS-IS on an unintended interface, such as fxp0, due to the non-specific nature of the all keyword.

Verify IS-IS on r5

After committing r5’s IS-IS configuration, we expect to see an adjacency to r4, and the correct interface-to-area associations as demonstrated next:

[edit] lab@r5# run show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric as1.0                 2   0x1 Disabled          Point to Point          10/10 at-0/2/1.35           2   0x1 Disabled          Point to Point          10/10 fe-0/0/0.0            1   0x2 r5.02             Disabled                10/10 fe-0/0/1.0            1   0x3 r5.03             Disabled                10/10 lo0.0                 0   0x1 Disabled          Passive                 0/0

These results confirm that r5’s interfaces have been correctly configured with the iso family, and that the interfaces have been placed into the correct levels as stipulated by Figure 4.1, shown earlier. You can also see that r5 has elected itself as the DIS on its two broadcast-capable IS-IS interfaces. We now confirm the r4-to-r5 IS-IS adjacency:

[edit] lab@r5# run show isis adjacency detail r4    Interface: as1.0, Level: 2, State: Up, Expires in 23 secs    Priority: 0, Up/Down transitions: 1, Last transition: 00:11:13 ago    Circuit type: 2, Speaks: IP, IPv6    IP addresses: 10.0.2.10

These results confirm that r5 has a single level 2 adjacency to r4, whose IP address is 10.0.2.10. Because r5 is a L1/L2 attached router, we can now 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. The contents of r5’s LSDB are shown in Listing 4.2.

Listing 4.2: The Contents of r5’s IS-IS LSDB

[edit] lab@r5# run show isis database detail IS-IS level 1 link-state database: r5.00-00  Sequence: 0x5, Checksum: 0x62c, Lifetime: 1123 secs    IP prefix:                     10.0.8.8/30 Metric:       10 Internal    IP prefix:                     10.0.8.4/30 Metric:       10 Internal IS-IS level 2 link-state database: r4.00-00  Sequence: 0x71, Checksum: 0xa9d4, Lifetime: 566 secs    IS neighbor:                         r5.00  Metric:      10    IP prefix:                     10.0.2.4/30 Metric:       10 Internal    IP prefix:                     10.0.2.8/30 Metric:       10 Internal    IP prefix:                     10.0.3.4/32 Metric:        0 Internal r5.00-00  Sequence: 0x6, Checksum: 0x10f1, Lifetime: 1123 secs    IS neighbor:                         r4.00  Metric:      10    IP prefix:                     10.0.2.8/30 Metric:       10 Internal    IP prefix:                     10.0.2.0/30 Metric:       10 Internal    IP prefix:                     10.0.8.8/30 Metric:       10 Internal    IP prefix:                     10.0.8.4/30 Metric:       10 Internal    IP prefix:                     10.0.3.5/32 Metric:       0 Internal  0x2   0x831   28

This display indicates that r5’s loopback interface has been correctly configured to run level 2 only. Had level 1 operation been enabled on lo0, r5 would have then included its loopback address in its level 1 LSP, thus violating the configuration requirements given for this example. You can also see that r5 has two level 2 LSPs, one of which was received from its adjacent neighbor, r4. It should be noted that 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 by the 10.0.8.x/30 prefixes in r5’s level 2 LSP. Based on these results, we find that both r4 and r5 have been correctly configured for this example.

Configure r3 for IS-IS Operation

The following commands are entered on r3 to complete the configuration of the level 2 backbone area. Once again, you may assume that r3’s interfaces have been configured with the iso family and the correct NET, as demonstrated previously for r4:

[edit protocols isis] lab@r3# set interface at-0/1/0.35 level 1 disable [edit protocols isis] lab@r3# set interface lo0 level 1 disable [edit protocols isis] lab@r3# set interface so-0/2/0.100 level 1 disable [edit protocols isis] lab@r3# set interface fe-0/0/2 passive [edit protocols isis] lab@r3# set interface fe-0/0/2 level 1 disable

The resulting IS-IS configuration for r3 is shown next:

[edit protocols isis] lab@r3# show interface fe-0/0/2.0 {    passive;    level 1 disable;  }  interface at-0/1/0.35 {    level 1 disable;  } interface so-0/2/0.100 {    level 1 disable;  }  interface lo0.0 {    level 1 disable;  }

By setting r3’s fe-0/0/2 interface to passive, you ensure that no adjacencies can be formed over the interface and that the route to 172.16.0.12/30 will be injected into area 49.0001 as an internal route. Failing to set this interface as passive would result in loss of points on the JNCIP exam because there is no other way to correctly advertise the 172.16.0.12/30 route as an IS-IS internal prefix while also preventing adjacency formation. It is a good idea to disable level 1 operation on r3’s fe-0/0/2 interface, even though it’s passive, because this interface is associated with a level 2–only router and such configuration will keep r3’s database tidy.

Verify IS-IS on r3

With the IS-IS backbone configured, you will expect to see that r3 has formed a single level 2 adjacency to each of its neighbors, and that the link to T1 is correctly reported in its level 2 LSP. You start by confirming the correct interface and IS-IS level configuration:

lab@r3> show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric at-0/1/0.35           2   0x1 Disabled          Point to Point         10/10 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/2/0.100          2   0x1 Disabled          Point to Point         10/10

The results leave something to be desired in that r3’s fe-0/0/2 interface is not listed as an IS-IS interface. This could be the result of the interface being down, the lack of IS-IS instance configuration, or the lack of the iso family on the correct logical unit. A quick look at the interface’s status confirms that the lack of family iso on the device’s logical unit 0 is the cause of the problem:

[edit] lab@r3# run show interfaces terse fe-0/0/2 Interface       Admin Link Proto Local                 Remote fe-0/0/2        up    up  fe-0/0/2.0      up    up   inet  172.16.0.13/30

The following command adds the iso family to the correct logical unit on interface fe-0/0/2:

[edit interfaces] lab@r4# set fe-0/0/2 unit 0 family iso

The results are now confirmed:

[edit] lab@r3# run show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric at-0/1/0.35           2   0x1 Disabled          Point to Point         10/10 fe-0/0/2.0            0   0x2 Disabled          Passive                10/10 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/2/0.100          2   0x1 Disabled          Point to Point         10/10

You now confirm the correct IS-IS adjacency status for area 49.0001:

lab@r3> show isis adjacency Interface             System         L State        Hold (secs) SNPA at-0/1/0.35           r5             2 Up                   22 so-0/2/0.100          r4             2 Up                   25

Good, r3 has the required level 2 adjacencies to both r4 and r5 as required. Next, confirm the presence of the 172.16.0.12/30 route as an IS-IS level 2 route. We start by confirming the route’s presence in r3’s level 2 LSP:

[edit] lab@r3# run show isis database r3 detail IS-IS level 1 link-state database: r3.00-00 Sequence: 0x12, Checksum: 0x53cd, Lifetime: 789 secs IS-IS level 2 link-state database: r3.00-00 Sequence: 0x15, Checksum: 0xb78a, Lifetime: 1052 secs    IS neighbor:                         r4.00  Metric:      10    IS neighbor:                         r5.00  Metric:      10    IP prefix:                  172.16.0.12/30 Metric:       10 Internal    IP prefix:                     10.0.2.4/30 Metric:       10 Internal    IP prefix:                     10.0.2.0/30 Metric:       10 Internal    IP prefix:                     10.0.3.3/32 Metric:        0 Internal

As required, the 172.16.0.12/30 prefix is being reported as an internal level 2 route. The last confirmation is to verify that other backbone routers have correctly installed this route. The following command is issued on r5:

 [edit] lab@r5# run show route protocol isis 172/8 inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.12/30       *[IS-IS/18] 14:19:29, metric 20, tag 2                       > to 10.0.2.2 via at-0/2/1.35

As expected, r5 has installed the route as an IS-IS level 2 internal route as indicated by the tag 2 value (which denotes level 2) and the preference setting of 18.

Area 49.0002 Configuration

The following commands correctly configure r6 for operation as an IS-IS level 1 router in area 49.0002. You begin by configuring its interfaces with the iso family and the router’s NET:

[edit interfaces] lab@r6# set fe-0/1/0 unit 0 family iso [edit interfaces] lab@r6# set fe-0/1/1 unit 0 family iso [edit interfaces lo0 unit 0] lab@r6# set family iso address 49.0002.0100.0000.9006.00

The IS-IS routing instance for r6 is now configured. Because r6 is strictly a level 1 router, we disable all level 2 processing and save some typing by using interface all, as shown:

[edit protocols isis] lab@r6# set level 2 disable [edit protocols isis] lab@r6# set interface all

The IS-IS configuration of r6 is shown below:

[edit protocols isis] lab@r6# show level 2 disable; interface all;

The configuration of r7 is not shown here because it is virtually identical to that of r6 except for interface-naming specifics.

Area 49.0002 Verification

After committing the level 1 IS-IS configuration on both r6 and r7, we expect to find that a level 1 adjacency has formed between them:

lab@r6> show isis adjacency Interface             System         L State        Hold (secs) SNPA fe-0/1/1.0             r7            1 Up                    8

With the level 1 adjacency confirmed up, we next verify proper DIS election on the broadcast interface between r6 and r7:

lab@r6> show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric fe-0/1/0.0            1   0x2 r6.02             Disabled                10/10 fe-0/1/1.0            1   0x3 r7.02             Disabled                10/10 lo0.0                 0   0x1 Passive           Disabled                0/0

The display indicates that r7 has won the DIS election on the 10.0.8.0/30 subnet. We confirm this by verifying that r7 has generated a pseudonode LSP for the broadcast network with r6 listed as the only neighbor:

lab@r6> show isis database r7 detail IS-IS level 1 link-state database: r7.00-00 Sequence: 0x3, Checksum: 0x7247, Lifetime: 539 secs    IS neighbor:                         r7.02  Metric:       10    IP prefix:                     10.0.9.7/32 Metric:        0 Internal    IP prefix:                     10.0.8.8/30 Metric:       10 Internal    IP prefix:                     10.0.8.0/30 Metric:       10 Internal r7.02-00  Sequence: 0x1, Checksum: 0xfdbc, Lifetime: 539 secs    IS neighbor:                         r6.00  Metric:        0    IS neighbor:                         r7.00  Metric:        0 IS-IS level 2 link-state database:

This display confirms that r7 is acting as the pseudonode for the 10.0.8.0/30 subnet, as indicated by its generation of an LSP with a non-zero selector field. Because all level 2 IS-IS processing has been disabled in r6 and r7, we find that the level 2 database is empty as expected.

Verify Overall IS-IS Operation

The spot checks performed thus far have returned the expected results for each of the two IS-IS areas in the configuration example outlined earlier in Figure 4.1, but the astute reader will have noticed that the command outputs displayed in the previous section indicate that r5 has not yet formed the required level 1 adjacencies to the routers in area 49.0002. The lack of an adjacency to the L1/L2-attached r5 results in the absence of the default route needed by level 1 routers to reach other areas:

lab@r7> show route protocol isis inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.4/30          *[IS-IS/15] 00:26:23, metric 20, tag 1                        > to 10.0.8.1 via fe-0/3/0.0 10.0.9.6/32          *[IS-IS/15] 00:26:23, metric 10, tag 1                        > to 10.0.8.1 via fe-0/3/0.0 iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

Troubleshooting Adjacency Problems

The lack of an IS-IS adjacency between r5 and area 49.0002 routers could be the result of physical layer problems. This possibility is quickly eliminated through a quick round of ping testing, however:

lab@r6> ping 10.0.8.6 PING 10.0.8.6 (10.0.8.6): 56 data bytes 64 bytes from 10.0.8.6: icmp_seq=0 ttl=255 time=0.529 ms 64 bytes from 10.0.8.6: icmp_seq=1 ttl=255 time=0.451 ms  ^C --- 10.0.8.6 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.451/0.490/0.529/0.039 ms

These results indicate that physical layer connectivity between r6 and r5 is not the cause of the adjacency problem. Next, reconfirm that r5 has the necessary level 1 configuration:

lab@r5> show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric as1.0                 2   0x1 Disabled          Point to Point          10/10 at-0/2/1.35           2   0x1 Disabled          Point to Point          10/10 fe-0/0/0.0            1   0x2 r5.02             Disabled                10/10 fe-0/0/1.0            1   0x3 r5.03             Disabled                10/10 lo0.0                 0   0x1 Disabled          Passive                 0/0

The fact that both r5 and r6 have elected themselves as the DIS for the 10.0.8.4/30 subnet provides an indication that we are experiencing some type of "ships in the night" issue that results in each router ignoring the other’s level 1 IS-IS packets.

As with the OSPF protocol, IS-IS tracing, with special attention placed on hello packet exchanges (and any error messages that may be occurring), is one of the best ways to troubleshoot adjacency formation problems. The following traceoptions configuration has been added to r6.

[edit protocols isis] lab@r6# show traceoptions file isis; flag hello detail; flag error detail;

The result of monitoring the isis trace file is shown in Listing 4.3:

Listing 4.3: IS-IS Tracing

[edit protocols isis] lab@r6# run monitor start isis [edit protocols isis] lab@r6# *** isis *** May 17 17:24:43 Sending L1 LAN IIH on fe-0/1/0.0 May 17 17:24:43     max area 0, circuit type l1 May 17 17:24:43     No candidates for DR May 17 17:24:43     hold time 27, priority 64, circuit id r6.02 May 17 17:24:43      speaks IP May 17 17:24:43      speaks IPv6 May 17 17:24:43     IP address 10.0.8.5 May 17 17:24:43     area address 49.0002 (3) May 17 17:24:44 Received L1 LAN IIH, source id 0100.0000.3005 on fe-0/1/0.0 May 17 17:24:44     intf index 2 addr 0.90.69.69.70.0, snpa 0:90:69:69:70:0 May 17 17:24:44     max area 0, circuit type l1, packet length 43 May 17 17:24:44     hold time 27, priority 64, circuit id 0100.0000.3005.02 May 17 17:24:44      speaks IP May 17 17:24:44      speaks IPV6 May 17 17:24:44      IP address 10.0.8.6 May 17 17:24:44     area address 49.0001 (3) May 17 17:24:44 ERROR: IIH from 0100.0000.3005 with no matching areas, interface  fe-0/1/0.0 May 17 17:24:44      local area  49.0002 May 17 17:24:44     remote area 49.0001 (3) . . .

The trace output identifies the problem rather explicitly in this case. A level 1 router can only form an adjacency with routers in the same area, and r5 is identifying itself as belonging to area 49.0001. To resolve the problem, we reassign r5’s NET using the following commands:

[edit interfaces lo0 unit 0 family iso] lab@r5# delete address [edit interfaces lo0 unit 0 family iso] lab@r5# set address 49.0002.0100.0000.3005.00

The results are now confirmed:

[edit interfaces lo0 unit 0 family iso] lab@r5# run show isis adjacency Interface             System         L State        Hold (secs) SNPA as1.0                 r4             2 Up                   25 at-0/2/1.35           r3             2 Up                   22 fe-0/0/0.0            0100.0000.9006 1 New                  23  0:a0:c9:69:c5:27 fe-0/0/1.0            r7             1 Up                   24  0:60:94:51:c4:27

Excellent! The level 1 adjacencies are now forming correctly. It should be noted that even though r5’s NET identifies itself as belonging to the level 1 area 49.0002, its lo0 interface has not been configured as a level 1 interface. This is important, because doing so would cause the route to r5’s loopback to be injected into the level 1 area in violation of the configuration requirements specified in this example.

Verify Multi-Level Operation

The proper operation of the level 1 area is confirmed with the following command, the results of which indicate the presence of the required default route to the L1/L2-attached router and the absence of level 2 router loopback addresses:

 [edit protocols isis] lab@r6# run show route protocol isis inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0          *[IS-IS/15] 00:03:58, metric 10, tag 1                      > to 10.0.8.6 via fe-0/1/0.0 10.0.8.8/30        *[IS-IS/15] 00:03:58, metric 20, tag 1                      > to 10.0.8.6 via fe-0/1/0.0                        to 10.0.8.2 via fe-0/1/1.0 10.0.9.7/32        *[IS-IS/15] 00:55:25, metric 10, tag 1                      > to 10.0.8.2 via fe-0/1/1.0 iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

This author has found that issuing the following command on a L1/L2-attached router provides a quick check on the overall operation of an IS-IS network by confirming the presence of each IS-IS router and the setting of its SysID. The idea is similar to the verification of router LSAs on an OSPF ABR:

lab@r5> show isis hostname IS-IS hostname database: System Id      Hostname                                         Type 0100.0000.3003 r3                                               Dynamic 0100.0000.3004 r4                                               Dynamic 0100.0000.3005 r5                                               Static  0100.0000.9006 r6                                               Dynamic 0100.0000.9007 r7                                               Dynamic

As required, all five routers are present and the unique assignment of SysID values is confirmed. The last check is to verify connectivity to the loopback address of level 2 routers from within the level 1 area:

lab@r7> traceroute 10.0.3.3 traceroute to 10.0.3.3 (10.0.3.3), 30 hops max, 40 byte packets  1 10.0.8.9 (10.0.8.9) 0.357 ms 0.258 ms 0.215 ms  2 10.0.3.3 (10.0.3.3) 0.915 ms 1.124 ms 0.877 ms lab@r7> traceroute 10.0.3.4 traceroute to 10.0.3.4 (10.0.3.4), 30 hops max, 40 byte packets  1 10.0.8.9 (10.0.8.9) 0.330 ms 0.244 ms 0.218 ms  2 10.0.3.4 (10.0.3.4) 0.445 ms 0.368 ms 0.355 ms

The traceroutes to both r3 and r4 succeed as we had hoped, confirming the correct operation of your multi-level IS-IS configuration.

IS-IS Adjacencies and IP Addressing

The IS-IS protocol carries IP routing information in an opaque manner using Type Length Values (TLVs) that act as extensions to the IS-IS routing protocol. This point is significant because the opacity of these IP-related TLVs will allow an IS-IS adjacency to form across a subnet with IP addressing problems. In general, most individuals are more familiar with the operation of OSPF than IS-IS, and such readers may find this behavior unexpected, as the OSPF protocol will not form an adjacency when IP parameters are mismatched. The key point is that IS-IS adjacency formation does not validate the interface IP–related configuration, and this can lead to some tricky troubleshooting problems as demonstrated here. In this example, r6 has had its IP address changed from the correct setting of 10.0.8.5/30 to the incorrect value of 10.0.10.5/30. This change does not affect IS-IS adjacency formation, and connectivity to r5’s 10.0.8.6 address is still possible, albeit with a less-than-optimal route:

[edit] lab@r6# show interfaces fe-0/1/0 unit 0 {     family inet {         address 10.0.10.5/30;     }     family iso; } [edit] lab@r6#  run show isis adjacency Interface           System       L State      Hold (secs) SNPA fe-0/1/0.0          r5           1 Up                  22  0:90:69:69:70:0 fe-0/1/1.0          r7           1 Up                   7  0:a0:c9:6f:7b:1a [edit] lab@r6#  run traceroute 10.0.8.6 traceroute to 10.0.8.6 (10.0.8.6), 30 hops max, 40 byte packets   1  10.0.8.2 (10.0.8.2)  0.197 ms  0.123 ms  0.096 ms   2  10.0.8.6 (10.0.8.6)  0.488 ms  0.435 ms  0.410 ms

Though not required by the IS-IS specification or the IP-related RFCs, newer versions of JUNOS software have been modified to prevent the establishment of an IS-IS adjacency when IP parameters are mismatched. This modified behavior is nice, but should not be counted on because of the version-specific nature of this feature.