Miscellaneous IS-IS Knobs

You should be familiar with all IS-IS options and available knobs before attempting your lab examination, because the evolving nature of the test will make it hard to predict when you will need to enable what might be considered a corner-case knob. The following section will demonstrate how some of the remaining IS-IS configuration parameters may be deployed in a lab scenario based on Figure 4.3. Traffic Engineering (TE)–related OSPF options are beyond the scope of the JNCIP examination and are therefore not covered in this book.

To complete this section, you must perform the following tasks:

• Ensure that r2 cannot reach destinations outside of area 49.0003 while keeping all its IS-IS adjacencies up and without modifying its routing-options stanza.

• Configure r6 with a level 1 priority of 0.

• Ensure that r5 never generates a non-0 selector byte LSP for the 10.0.8.8/30 network.

• Configure the r3-r5 ATM link so that flooded LSPs are spaced at least 300 milliseconds apart.

The first configuration task requires that we determine how r2 is currently forwarding traffic into other areas:

lab@r2> show route 10.0.2.0 inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0            *[IS-IS/15] 03:21:43, metric 10, tag 1                       > to 10.0.4.9 via fe-0/0/1.0                         to 10.0.4.1 via fe-0/0/2.0 

As expected, r2 is using the default route produced by detecting the presence of a L1/L2- attached router to route to destinations outside of its level 1 area. There may be times, such as during a Denial of Service (DoS) attack, that you will not want a level 1 router to be able to forward traffic based on a default route. To prevent r2 from being able to reach inter-area destinations in accordance with the provided criteria, you must stop r2 from installing this default route without affecting the status of its IS-IS adjacencies. The following command is used to tell the router to ignore the presence of the attached bit in level 1 LSPs, which blocks the installation of the IS-IS default route:

[edit] lab@r2# set protocols isis ignore-attached-bit 

The results are confirmed by verifying that r2 no longer displays a default route for inter- area destinations:

lab@r2> show route 10.0.2.0 lab@r2>

The second and third configuration tasks relate to one another and are made difficult by the somewhat cryptic wording of the requirements. A reader who possesses a detailed understanding of the IS-IS protocol will realize that only an IS-IS DIS can generate non-0 selector byte LSPs as part of its pseudonode functionality. So to meet this requirement, you must ensure that r5 can never be elected as the IS-IS DIS for the 10.0.8.8/30 subnet, despite the need to set r6’s DIS priority to 0!

This seemingly insurmountable task can only be accomplished by setting r5’s priority to 0 and then manually assigning a MAC address to r5’s fe-0/0/0 interface that is numerically lower than the MAC address in use by r6’s fe-0/1/0 interface (or vice versa). Simply modifying r5’s fe-0/0/0 interface priority will not suffice for this task, because the resulting priority tie with r6 will simply be resolved based on their burned-in MAC addresses. Though you may get lucky and find that r5 happens to lose the MAC address–based DIS election in your test bed, you would likely still lose points on the actual JNCIP exam for not taking the necessary precautions that would have allowed you to forsake the services of that fleeting mistress known as luck.

The following commands set the level 1 priority of r5’s fe-0/0/0 interface to 0, and assigns a new MAC address that is numerically lower than r6’s fe-0/1/0 MAC address, which in this test bed happens to be 00:90:69:32:11:3a:

[edit protocols isis] lab@r5# set interface fe-0/0/0 level 1 priority 0 [edit interfaces fe-0/0/0] lab@r5# set mac 00.00.00.00.00.11 

The level 1 priority of r6 is now set to 0 with the following command. You can opt for a global change, as demonstrated here, or the explicit setting of the level 1 priority associated with its fe-0/1/0 interface:

[edit] lab@r6# set protocols isis interface all level 1 priority 0 

To confirm the expected behavior, we verify that r5 has not been elected the DIS on its fe- 0/0/0 interface. Alternatively, we can examine the level 1 area’s database to confirm that r5 has not generated a pseudonode LSP for the 10.0.8.4/30 subnet. Both approaches are shown here:

[edit] lab@r5# run show isis interface fe-0/0/0 IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric fe-0/0/0.0            1   0x2 r6.02             Disabled                5/5

As required, r6 has won the DIS election, despite its priority setting of zero.

[edit] lab@r5# run show isis database r5 detail IS-IS level 1 link-state database: r5.00-00 Sequence: 0x1b, Checksum: 0x63a3, Lifetime: 3597 secs    IS neighbor:                         r5.03  Metric:       5    IS neighbor:                         r6.02  Metric:       5    IP prefix:                     10.0.2.0/23 Metric:       10 External    IP prefix:                     10.0.8.8/30 Metric:        5 Internal    IP prefix:                     10.0.8.4/30 Metric:        5 Internal r5.03-00  Sequence: 0x9, Checksum: 0x1db, Lifetime: 3597 secs    IS neighbor:                         r7.00  Metric:       0    IS neighbor:                         r5.00  Metric:       0 IS-IS level 2 link-state database: . . . 

As expected, the only level 1, non-zero selector byte LSP generated by r5 refers to the 10.0.8.8/30 subnet by virtue of the neighbor report that includes r5 and r7. These results confirm that the requirements of this configuration task have been met.

Tip 

You may want to flush the IS-IS LSDB with the clear isis database command before you conduct your LSP analysis to ensure that stale LSPs, which can serve to add confusion, are no longer present.

The last requirement in this section is to configure the ATM interface between r3 and r5 so that flooded LSPs are spaced by at least 300 milliseconds. Controlling the rate of LSP flooding can be desirable on slow links, or when the device at the other end has processing limitations, because LSPs that are spaced too closely may be lost in such situations. The following command, entered on both r3 and r5, does the trick:

[edit protocols isis] lab@r5# set interface at-0/2/1.35 lsp-interval 301 

To confirm, we examine the interface’s IS-IS parameters, being sure to compare the ATM interface’s settings to the default LSP interval in use by its other point-to-point interface:

lab@r5> show isis interface detail IS-IS interface database: as1.0   Index: 13, 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             1       64     10         9        27 at-0/2/1.35   Index: 9, State: 0x6, Circuit id: 0x1, Circuit type: 2   LSP interval: 301 ms , CSNP interval: disabled   Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router     2             1       64     10         9        27 . . . 

A Monkey in Your Wrench?

A JNCIP candidate may be expected to demonstrate the ability to reverse engineer the configuration of an attached device by virtue of not being given the required details of its configuration. By way of example, consider the case where you must establish an adjacency to the OSPF router when its configuration is not made available to you. In such a situation, you will need to deploy various diagnostic utilities, such as protocol tracing or traffic monitoring, to determine the OSPF parameters that must be added to r6 and r7 for compatibility with the OSPF router (as shown earlier in Figure 4.3). The following example shows a candidate starting with a “bare bones” OSPF configuration that is intended only to enable OSPF protocol tracing:

[edit protocols ospf] lab@r6# show traceoptions {    file test;    flag hello detail;    flag error detail;  }  area 0.0.0.0 {    interface fe-0/1/3.0;  }

The results obtained from the trace file make it clear that the OSPF router is in area 1 and that authentication is not being used. The various time-stamps and tracing output also make the detection of the 8-second hello interval setting possible:

May 18 20:58:29 OSPF packet ignored: area mismatch (0.0.0.1) from 172.16.40.1 May 18 20:58:29 OSPF rcvd Hello 172.16.40.1 -> 224.0.0.5 (fe-0/1/3.0) May 18 20:58:29   Version 2, length 44, ID 192.168.0.1, area 0.0.0.1 May 18 20:58:29    checksum 0x676d, authtype 0 May 18 20:58:29   mask 255.255.255.0, hello_ivl 8 , opts 0x2, prio 128 May 18 20:58:29   dead_ivl 32, DR 172.16.40.1, BDR 0.0.0.0 May 18 20:58:32 OSPF sent Hello 172.16.40.2 -> 224.0.0.5 (fe-0/1/3.0) May 18 20:58:32   Version 2, length 44, ID 10.0.9.6, area 0.0.0.0 May 18 20:58:32    checksum 0x1507, authtype 0 May 18 20:58:32    mask 255.255.255.0, hello_ivl 10, opts 0x2, prio 128 May 18 20:58:32    dead_ivl 40, DR 172.16.40.2, BDR 0.0.0.0 May 18 20:58:36 OSPF packet ignored: area mismatch (0.0.0.1) from 172.16.40.1 May 18 20:58:36 OSPF rcvd Hello 172.16.40.1 -> 224.0.0.5 (fe-0/1/3.0) May 18 20:58:36   Version 2, length 44, ID 192.168.0.1, area 0.0.0.1 May 18 20:58:36   checksum 0x676d, authtype 0 May 18 20:58:36   mask 255.255.255.0, hello_ivl 8, opts 0x2, prio 128 May 18 20:58:36    dead_ivl 32, DR 172.16.40.1, BDR 0.0.0.0