Case Study: IS-IS | JNCIP: Juniper Networks Certified Internet Professional Study Guide

The following case study simulates a typical JNCIP-level IS-IS configuration scenario. You should refer to the criteria listing and the information in Figure 4.4, the case study topology, in order to complete the IS-IS case study. It is assumed that you will be adding the IS-IS related configuration on top of the interface configuration that was left from the case study at the end of Chapter 2, 'Interface Configuration and Testing.' You should therefore first remove any protocol, policy, family iso interface statements, and any static route-related configuration resulting from the examples given in this chapter from all your routers before beginning the case study. Ideally you will start the case study by reloading your Chapter 2 baseline configuration using load override.

click to expand
Figure 4.4: IS-IS case study topology

It is expected that a JNCIP candidate will be able to complete this case study in approximately one hour, with the result being an IS-IS IGP that exhibits no serious operational problems. Sample IS-IS configurations from all seven routers are provided at the end of the case study for comparison with your own configurations. Multiple solutions are sometimes possible, so differences between the provided examples and your own configurations do not always indicate that mistakes have been made. Because you are graded on the overall functionality of your IGP and its conformance to the specified configuration criteria, various operational mode commands are included so that you may compare the behavior of your network to a known good example.

To complete this case study, your IS-IS configuration must meet the following criteria:

lo0 addresses are reachable through IS-IS for all routers with an IS-IS SysID based on the lo0 address. Backbone router lo0 addresses must not be injected into area 49.0002 or 49.0001.
Backbone area routes must be summarized into area 49.0001.
The subnet between r3 and T1 must appear in area 49.0003 as an internal route. Ensure that no adjacencies can be established on this subnet.
Redistribute the 10.0.5/24 route into the backbone such that area 49.0002-attached routers see a metric of at least 100.
r5 and r6 must use a level 1 priority of 0.
Ensure that r7 never functions as a pseudonode when its adjacencies are up.
Summarize all routes (internal and external) into the backbone area.
You may not modify or view the OSPF router's configuration.
All areas must use hello authentication based on md5 with a secret of jnx. The backbone area must also authenticate LSPs using a simple password of jnx.
Configure r6 and r7 to advertise the IS-IS default route to the OSPF router. Ensure that the OSPF router can load balance over the default route.
Configure r6 and r7 to redistribute OSPF routes learned from the OSPF router into IS-IS.
Except for r5, ensure that no single router or link failure will isolate r1, r2, or the OSPF router.
Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 5.
No static routes and no loops.
Set the level 1 preference in area 49.0001 to 155.
You must not have suboptimal routing between r6, r7, and the OSPF router.
Configure the network to keep LSPs that are up to 3600 seconds old.
Only one adjacency is permitted between any two routers.

In this case study, the OSPF router is preconfigured and its configuration cannot be modified or viewed. You may assume, however, that it is configured to run OSPF, and that it has the policy statements needed to redistribute the 192.168.0-3/24 static routes into OSPF should an adjacency be formed.

IS-IS Case Study Analysis

Each configuration requirement for the case study will now be matched to one or more valid router configurations and the commands that can be used to confirm that the router is operating within all specified case study guidelines. We begin with these four criteria, as they serve to establish baseline IS-IS operation in each area:

lo0 addresses are reachable through IS-IS for all routers with an IS-IS SysID based on the lo0 address. Backbone router lo0 addresses must not be injected into area 49.0002 or 49.0001.
Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 5.
Configure the network to keep LSPs that are up to 3600 seconds old.
Only one adjacency is permitted between any two routers.

To get basic IS-IS connectivity going, you must add the iso family to the correct logical units on all IS-IS interfaces, assign the router's NET to its lo0 address, and correctly configure the interface to level associations so that no interfaces are running at both levels 1 and 2. The following captures show typical IS-IS configurations from key routers throughout the network, starting with r4:

[edit] lab@r4# run show interfaces terse Interface       Admin Link Proto Local                 Remote fe-0/0/0        up     down fe-0/0/1        up     up  fe-0/0/1.0      up    up   inet  10.0.4.9/30                                 iso   . . . so-0/1/0        up     up  so-0/1/0.100    up    up   inet  10.0.2.6/30                                 iso  so-0/1/1        up     up  so-0/1/1.0      up    up    soagg --> as0.0 so-0/1/2        up     up  so-0/1/2.0      up    up    soagg --> as0.0 so-0/1/3        up     down as0             up     up  as0.0           up    up   inet  10.0.2.10/30                                iso  fxp0            up     up  fxp0.0          up    up   inet  10.0.1.4/24     fxp1            up     up  fxp1.0          up    up   tnp   4               lo0             up    up  lo0.0           up    up   inet  10.0.3.4            --> 0/0                            iso   49.0002.0100.0000.3004.00 . . .

The IS-IS routing instance for r4 is shown next:

[edit] lab@r4# show protocols isis reference-bandwidth 500m; lsp-lifetime 3600; interface fe-0/0/1.0 {    level 2 disable;  }  interface all {    level 1 disable;  }

r4's configuration has the required iso family interface assignments, NET, and the correct interface-to-level associations, which in this case was achieved by disabling level 1 on all interfaces with the exception of interface fe-0/0/1. Care must be taken to ensure that you do not configure backbone router lo0 interfaces to operate at level 1 in order to meet the requirement that backbone lo0 addresses are not to be injected into area 49.0002 or 49.0001. The automatic metric requirement is achieved by assigning reference bandwidth of 500Mbps, and the default LSP lifetime is set to 3600 seconds as required. Correct interface-to-level mapping and the automatically calculated metric values are confirmed by displaying IS-IS interface status:

[edit] lab@r4# run 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          1/1 fe-0/0/1.0            1   0x2 r2.02             Disabled                5/5 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/1/0.100          2   0x1 Disabled          Point to Point          3/3

The configuration of routers in level 1 areas will be similar to the example shown next, which is taken from r7:

[edit] lab@r7# run show interfaces terse Interface       Admin Link Proto Local                 Remote . . .     fe-0/3/0        up     up  fe-0/3/0.0      up    up   inet  10.0.8.2/30                                 iso  fe-0/3/1        up     up  fe-0/3/1.0      up    up   inet  10.0.8.10/30                                iso  . . . lo0             up     up  lo0.0           up    up   inet  10.0.9.7            --> 0/0                            iso   49.0001.0100.0000.9007.00 . . .

The routing instance for a level 1 router r7 is configured as shown next:

[edit] lab@r7# show protocols isis reference-bandwidth 500m; lsp-lifetime 3600; interface all {    level 2 disable;  }

The correct interface-to-level mappings are now confirmed on r7:

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

At this stage, you should have the required number and type (either level 1 or level 2) of adjacencies between all seven routers. To quickly confirm, we verify that we have the expected number of SysIDs on a few strategic routers:

[edit] lab@r3# run show isis hostname IS-IS hostname database: System Id      Hostname                                         Type 0100.0000.3003 r3                                               Static  0100.0000.3004 r4                                               Dynamic 0100.0000.3005 r5                                               Dynamic 0100.0000.6001 r1                                               Dynamic 0100.0000.6002 r2                                               Dynamic

r3 has hostname entries that correctly reflect area 49.0003 and 49.0002 routers, as expected. We confirm area 49.0001 by performing the same command on r6:

[edit] lab@r6# run show isis hostname IS-IS hostname database: System Id      Hostname                                         Type 0100.0000.3005 r5                                               Dynamic 0100.0000.9006 r6                                               Static  0100.0000.9007 r7                                               Dynamic

A test to confirm that backbone routers see IS-IS routes to all loopback addresses is now performed:

[edit protocols isis] lab@r3# run show route protocol isis | match /32 10.0.3.4/32     *[IS-IS/18] 00:39:09, metric 3, tag 2 10.0.3.5/32     *[IS-IS/18] 00:39:09, metric 3, tag 2 10.0.6.1/32     *[IS-IS/15] 00:39:09, metric 5, tag 1 10.0.6.2/32     *[IS-IS/15] 00:39:09, metric 5, tag 1 10.0.9.6/32     *[IS-IS/18] 00:37:32, metric 8, tag 2 10.0.9.7/32     *[IS-IS/18] 00:36:27, metric 8, tag 2

As expected, there are six IS-IS routes on r3 that represent the loopback addresses of all remote routers. These results indicate that baseline IS-IS functionality is working as needed for the remaining configuration tasks. You will now add authentication as per this requirement:

All areas must use hello authentication based on md5 with a secret of jnx. The backbone area must also authenticate LSPs using a simple password of jnx.

Backbone authentication is now added and confirmed. The authentication-related additions to a typical backbone router configuration are highlighted next:

 [edit protocols isis] lab@r5# show reference-bandwidth 500m; level 2 {     authentication-key "$9$jEkmTOBEhrv"; # SECRET-DATA     authentication-type simple; # SECRET-DATA } interface fe-0/0/0.0 {     level 2 disable;      level 1 {          hello-authentication-key "$9$H.fz1IcSeW"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } } interface fe-0/0/1.0 {      level 2 disable;      level 1 {          hello-authentication-key "$9$EORSlM2gJZjq"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } } interface all {      level 1 disable;      level 2 {          hello-authentication-key "$9$5znCyrvMX-"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } }

Backbone authentication is confirmed by verifying the status of adjacencies (hello authentication) and the presence of IS-IS routes (LSP authentication):

[edit protocols isis] lab@r4# run show isis adjacency Interface             System         L State        Hold (secs) SNPA as0.0                 r5             2 Up                   20 fe-0/0/1.0            0100.0000.6002 1 Down                 24  0:a0:c9:b2:f8:cb so-0/1/0.100          r3             2 Up                   25 [edit protocols isis] lab@r4# run show isis route | match /32 10.0.3.3/32        2      55      3 int  so-0/1/0.100 r3                 10.0.3.5/32        2      55      1 int  as0.0        r5

A working authentication configuration for a typical level 1 router is shown here with authentication-related additions highlighted:

[edit protocols isis] lab@r1# show reference-bandwidth 500m; interface all {    hello-authentication-key "$9$MexL7Vji.mT3"; # SECRET-DATA    hello-authentication-type md5; # SECRET-DATA    level 2 disable;  }

Hello authentication in level 1 areas can be confirmed by verifying the correct adjacency status:

[edit] lab@r2# run show isis adjacency Interface             System         L State        Hold (secs) SNPA fe-0/0/1.0            r4             1 Up                    25  0:90:69:6b:30:1 fe-0/0/2.0            r3             1 Up                    19  0:90:69:6d:98:1 fe-0/0/3.0            r1             1 Up                   25  0:a0:c9:6f:7b:84

Results such as these indicate that hello authentication has been correctly configured in level 1 areas. We next examine a working configuration example for the following case study requirements:

Backbone area routes must be summarized into area 49.0001.
The subnet between r3 and T1 must appear in area 49.0003 as an internal route. Ensure that no adjacencies can be established on this subnet.

The summarization and leaking of routes into area 49.0001 requires the use of policy and the definition of an aggregate route, as shown next in the configuration of r5, which highlights the configuration additions needed for this task:

[edit] lab@r5# show routing-options static {    route 10.0.200.0/24 next-hop 10.0.1.102;  }  aggregate {    route 10.0.2.0/23;  }

The policy needed to advertise an aggregate route into a level 1 area is shown here:

[edit] lab@r5# show policy-options policy-statement summ {     term 1 {         from {             protocol aggregate;             route-filter 10.0.2.0/23 exact;         }         to level 1;         then accept;     } }

The export policy must be applied to IS-IS as export for it to have any effect:

[edit] lab@r5# show protocols isis export export summ;

The correct operation of route summarization and leaking is easily confirmed on area
49.0001 routers:

[edit] lab@r6# run show route 10.0.2/23 inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.2.0/23          *[IS-IS/160] 00:02:56, metric 15, tag 1                       > to 10.0.8.6 via fe-0/1/0.0

Setting r3's fe-0/0/2 interface to passive ensures the 172.16.0.12/30 prefix is advertised into the backbone area as an internal route while also guarding against IS-IS adjacency formation:

[edit protocols isis] lab@r3# show interface fe-0/0/2 passive; level 1 disable;

It is a good idea to explicitly disable level 1 operation on this interface because its specific mention in the configuration results in its not being affected by the presence of the interface all level 1 disable clause. To confirm proper behavior, we verify that the route to 172.16.0.12/ 30 is present in the backbone as an IS-IS internal level 2 route:

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

Correct operation can also be verified by examining r3's level 2 LSP:

[edit] lab@r5# run show isis database r3 detail IS-IS level 1 link-state database: IS-IS level 2 link-state database: r3.00-00 Sequence: 0x2b, Checksum: 0x475a, Lifetime: 3551 secs. . .    IP prefix:                     10.0.2.0/30 Metric:        3 Internal    IP prefix:                  172.16.0.12/30 Metric:        5 Internal    IP prefix:                     10.0.4.0/30 Metric:        5 Internal    IP prefix:                    10.0.4.12/30 Metric:       . . .

These results confirm that backbone routers are correctly seeing the 172.16.0.12/30 prefix as an internal level 2 IS-IS route, in accordance with the case study criteria. The correct LSP's lifetime, currently at 3551 seconds, is also highlighted here. We now address the following criteria:

Redistribute the 10.0.5/24 route into the backbone while ensuring that area 49.0002- attached routers see a metric of at least 100.
Except for r5, ensure that no single router or link failure will isolate r1, r2, or the OSPF router.

Achieving these requirements will involve the use of wide metrics for all level 1 area 49.0002 routers (including r3 and r4), and a route redistribution policy on both r1 and r2. Both routers must redistribute the prefix to ensure that a router failure will not sever communications between the OSPF router and the 10.0.5/24 prefix. Keep in mind that while this example is taken from r1, r2 will require similar modifications:

[edit] lab@r1# show protocols isis export direct; reference-bandwidth 500m; lsp-lifetime 3600; level 1 wide-metrics-only; interface all {     hello-authentication-key "$9$MexL7Vji.mT3"; # SECRET-DATA     hello-authentication-type md5; # SECRET-DATA     level 2 disable; } [edit] lab@r1# show policy-options policy-statement direct {     term 1 {          from {             protocol direct;             route-filter 10.0.5.0/24 exact;         }          then {             metric 101;             accept;         }     }

The results are confirmed on r3, where we expect to see both r1 and r2 as viable next hops and a metric greater than 100 for the 10.0.5/24 route:

[edit protocols isis] lab@r3# run show route 10.0.5/24 inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24         *[IS-IS/15] 00:01:34, metric 106, tag 1                        to 10.0.4.14 via fe-0/0/0.0                      > to 10.0.4.2 via fe-0/0/1.0

The use of wide metrics in area 49.0002 results in the automatic redistribution of the 10.0.5/24 prefix into the backbone area because the route will no longer be seen as an external prefix by the attached routers. Therefore, an IS-IS export policy is not required on r3 and r4 for this particular aspect of the case study. You must take care, however, to ensure that subsequent export policy applications to r3 and r4 correctly take this prefix into account. The following command confirms the route's presence in the backbone:

[edit] lab@r5# run show route 10.0.5/24 inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24          *[IS-IS/18] 00:01:21, metric 64, tag 2                        > to 10.0.2.10 via as1.0

The use of narrow metrics, which support the route type attribute, would have necessitated a route-leaking policy on area 49.0002's attached routers to ensure the route injection into the backbone area. The route's presence in r5, and the correct metric value displayed by area 49.0002 routers, confirms that the requirements for redistributing the 10.0.5/24 route have been met. Next, we will examine the configuration needed to meet the following criteria:

r5 and r6 must use a level 1 priority of 0.
Ensure that r7 never functions as a pseudonode when its adjacencies are up.
Set the level 1 preference in area 49.0001 to 155.

With r5 and r6 set to a level 1 priority of 0, you will need to ensure that r7's priority is also set to 0 and that its MAC addresses are numerically lower than those used by r5 or r6 to prevent it from being elected a DIS. The following configuration prevents r7 from becoming the DIS, and correctly sets the IS-IS level 1 internal route preference in accordance with the case study requirements. The route preference and level 1 priority configuration is also needed on r5 and r6:

[edit] lab@r7# show protocols isis reference-bandwidth 500m; lsp-lifetime 3600; level 1 preference 155; interface all {    hello-authentication-key "$9$j5kmTOBEhrv"; # SECRET-DATA    hello-authentication-type md5; # SECRET-DATA    level 2 disable;    level 1 priority 0;  }

The following highlights call out r7's new MAC addresses:

[edit] lab@r7# show interfaces fe-0/3/0 mtu 4000; mac 00.00.00.00.00.11; unit 0 {     family inet {         address 10.0.8.2/30;     }     family iso; } [edit] lab@r7# show interfaces fe-0/3/1 mac 00.00.00.00.00.22; unit 0 {     family inet {         address 10.0.8.10/30;     }     family iso; }

The OSPF-to-IS-IS redistribution tasks must be completed before the level 1 preference modification can be confirmed. Viewing r7's IS-IS adjacencies and interface specifics to confirm the correct priority settings on r5, r6, and r7, and to verify that r7 is not functioning as a DIS, can be performed right away:

[edit] lab@r7# run show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric fe-0/3/0.0            1   0x2 r6.03             Disabled                5/5 fe-0/3/1.0            1   0x3 r5.03             Disabled                5/5 lo0.0                 0   0x1 Passive           Disabled                0/0

These results confirm that r7 is currently not functioning as a DIS on any of its IS-IS interfaces. The following command allows you to confirm the required priority setting on r6 and r5:

[edit] lab@r7# run show isis adjacency detail r6  Interface: fe-0/3/0.0, Level: 1, State: Up, Expires in 8 secs  Priority: 0, Up/Down transitions: 3, Last transition: 00:08:03 ago  Circuit type: 1, Speaks: IP, IPv6, MAC address: 0:a0:c9:69:c1:e4  LAN id: r6.03, IP addresses: 10.0.8.1 r5  Interface: fe-0/3/1.0, Level: 1, State: Up, Expires in 7 secs  Priority: 0, Up/Down transitions: 5, Last transition: 00:08:04 ago  Circuit type: 1, Speaks: IP, IPv6, MAC address: 0:90:69:69:70:1  LAN id: r5.03, IP addresses: 10.0.8.9

The confirmation of the correct priority setting on r5 and r6, coupled with the knowledge that r7's level 1 interfaces have also had their MAC addresses manually set, confirms that the requirements for this configuration task have been met.

The following case study criteria will now be addressed:

You may not modify or view the OSPF router's configuration.
Configure r6 and r7 to advertise the IS-IS default route to the OSPF router. Ensure that the OSPF router can load balance over the default route.
Configure r6 and r7 to redistribute OSPF routes learned from the OSPF router into IS-IS.
Ensure that no single router or link failure will isolate r1, r2, or the OSPF router.
You must not have suboptimal routing between r6, r7, and the OSPF router.

The OSPF-to-IS-IS redistribution task is made somewhat complex by the fact that you are not able to view or modify the OSPF router's configuration. To complete this task, you will need to perform a fair bit of reverse engineering, or develop some really good psychic skills! The following trace configuration will be used to get the ball rolling on r7, which should tell you something about this author's belief in ESP:

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

After committing, monitor the trace file for clues to the OSPF router's configuration, which are highlighted next:

lab@r7# run monitor start ospf [edit] lab@r7# *** ospf *** May 22 23:31:22 OSPF sent Hello 172.16.40.6 -> 224.0.0.5 (fe-0/3/3.0) May 22 23:31:22   Version 2, length 44, ID 10.0.9.7, area 0.0.0.0 May 22 23:31:22    checksum 0xe81c, authtype 0 May 22 23:31:22   mask 255.255.255.252, hello_ivl 10, opts 0x2 , prio 128 May 22 23:31:22   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 May 22 23:31:23 OSPF packet ignored: area mismatch (0.0.0.2) from 172.16.40.5 May 22 23:31:23 OSPF rcvd Hello 172.16.40.5 -> 224.0.0.5 (fe-0/3/3.0) May 22 23:31:23   Version 2, length 44, ID 192.168.0.1, area 0.0.0.2 May 22 23:31:23    checksum 0x6061, authtype 1 May 22 23:31:23    mask 255.255.255.252, hello_ivl 10, opts 0x8, prio 128 May 22 23:31:23   dead_ivl 40, DR 172.16.40.5, BDR 0.0.0.0

The highlighted entries reveal that the OSPF router is in area 2, and that it has been configured for simple password-based authentication (type 1). Though not overtly obvious, you can also detect that the OSPF router is coding the options field with 0x08 while r7 is sending a 0x02. Knowing that the options field is used by OSPF to indicate area types and options, and knowing that r6 is set to area 0, which must be a transit area, you can assume that the OSPF router has been set to consider area 2 as some type of non-transit area such as a stub or NSSA. To obtain the correct authentication secret, you must perform traffic monitoring using the detail switch:

[edit] lab@r7# run monitor traffic interface fe-0/3/3 detail Listening on fe-0/3/3 23:40:57.778943 In 172.16.40.5 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.0.1   area 0.0.0.2 auth "pass^@^@^@^@" mask 255.255.255.252 int 10 pri 128 dead 40 dr   172.16.40.5 nbrs [tos 0xc0] [ttl 1] (id 12499) 23:40:59.147114 Out 172.16.40.6 > 224.0.0.5: OSPFv2-hello 44: rtrid 10.0.9.7   backbone E mask 255.255.255.252 int 10 pri 128 dead 40 dr 172.16.40.6 nbrs [tos   0xc0] [ttl 1] (id 8628) ^C 2 packets received by filter 0 packets dropped by kernel

Armed with this information, we reconfigure r7 using the correct area and authentication parameters. In this case, we take a guess and decide to configure the area as a stub, based on the previously noted settings in the OSPF options field:

[edit protocols ospf] lab@r7# delete area 0 [edit protocols ospf] lab@r7# set area 2 authentication-type simple [edit protocols ospf] lab@r7# set area 2 interface fe-0/3/3 [edit protocols ospf] lab@r7# set area 2 stub [edit protocols ospf] lab@r7# set area 2 interface fe-0/3/3 authentication-key  pass

The modified configuration is displayed:

[edit protocols ospf] lab@r7# show traceoptions {    file ospf;    flag hello detail;    flag error detail;    flag packets detail;  }  area 0.0.0.2 {    stub;    authentication-type simple; # SECRET-DATA    interface fe-0/3/3.0 {      authentication-key "$9$6vcM/pBIRSeMXhS"; # SECRET-DATA    }  }

After committing, you look for the required OSPF adjacency:

[edit protocols ospf] lab@r7# run show ospf neighbor [edit protocols ospf] lab@r7#

No joy. OK, so perhaps instead of being a stub area, area 2 is set to operate as a NSSA? It's easy enough to find out by making the following change:

[edit protocols ospf] lab@r7# set area 2 nssa [edit protocols ospf] lab@r7# commit commit complete

The OSPF adjacency status is again checked:

[edit protocols ospf] lab@r7# run show ospf neighbor   Address         Interface             State      ID              Pri  Dead 172.16.40.5      fe-0/3/3.0             Full      192.168.0.1      128   39

Great! The adjacency is up, which means r7 should now be receiving the routes that need to be redistributed into IS-IS. This policy statement matches on the 192.168.x/24 routes and advertises them into IS-IS when applied as export to IS-IS:

[edit] lab@r6# show protocols isis export export ospf-isis; [edit] lab@r6# show policy-options policy-statement ospf-isis {      term 1 {          from {             route-filter 192.168.0.0/22 longer;         }          then accept;      }      term 2 {          from {             route-filter 0.0.0.0/0 exact;         }          then reject;      } }

Term 2, which rejects the re-advertisement of the default route (in the case that it is coupled through the OSPF router), is not really needed because the default export policy will not redistribute OSPF routes into IS-IS. Still, it never hurts to be extra safe when dealing with route redistribution, so its inclusion is highly recommended. The OSPF export policy needed to redistribute the IS-IS default route to the OSPF router should look something like the following:

[edit] lab@r6# show policy-options policy-statement isis-ospf term 1 {    from {       route-filter 0.0.0.0/0 exact;    }    then accept;  }

After applying the ospf-isis and isis-ospf export policies to r6, the reason for requiring the change to the IS-IS level 1 preference in area 49.0001 becomes obvious. Changing the IS-IS level 1 preference as directed will cause r6 or r7 to prefer the default route being re-advertised by the OSPF router, which in turn will result in an extra hop when forwarding packets to the 10.0.5/24 subnet from either r6 or r7. Such a situation is shown next, where we see that r7 has chosen the OSPF default route over the IS-IS default route. At the time of this capture, both r6 and r7 have been configured to redistribute the IS-IS default into OSPF.

In this example, r6 has chosen the IS-IS default as the active route, while r7 has been fooled into accepting the OSPF default that is coupled through the OSPF router due to the level 1 preference modification:

[edit] lab@r6# run show route | match 0.0.0.0/0 0.0.0.0/0 *[IS-IS/155] 01:08:38, metric 5, tag 1 [edit] lab@r7# run show route | match 0.0.0.0/0 inet.0: 21 destinations, 28 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0             *[OSPF/150] 00:01:50, metric 5, tag 1                        > to 172.16.40.5 via fe-0/3/3.0                        [IS-IS/155] 01:09:32, metric 5, tag 1                        > to 10.0.8.9 via fe-0/3/1.0

Because r7 has chosen the OSPF default, the isis-ospf export policy will have no effect because the currently active default route was learned through OSPF and, as such, will not be redistributed back into OSPF. This situation would result in point loss on the JNCIP exam both for having suboptimal routing and for the fact that the OSPF router cannot load balance over the default route because only r6 will be listed as the default route's next hop, as shown next:

lab@ospf> show route inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0           *[OSPF/150] 00:03:19, metric 5, tag 1                       > to 172.16.40.2 via fe-0/0/0.0

Because you cannot apply import policy to block the reception of the default route from the OSPF router, your only real choice here is to adjust the OSPF AS external route preference so that r6 and r7 once again prefer the IS-IS default route, which has a preference of 155 in this example. It is worth noting that the 192.168.x/24 routes being redistributed into IS-IS as level 1 externals will not cause problems if the preference associated with OSPF external routes is numerically lower, and therefore more preferred, than the default IS-IS level 1 external preference value of 160. So the OSPF external preference on r6 and r7 should be set to a value that is higher than 155 but lower than 160.

Based on the modified IS-IS level 1 preference value, setting the OSPF external preference to 159 on both r6 and r7 allows us to keep the default IS-IS level 1 external preference:

[edit] lab@r6# set protocols ospf external-preference 159

After committing the change, r6 and r7 once again prefer the IS-IS default route to the OSPF default route, so both routers correctly export the IS-IS default into OSPF. This produces the required load-balancing behavior at the OSPF router and eliminates the suboptimal routing issue:

lab@ospf> show route inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0           *[OSPF/150] 00:00:43, metric 5, tag 1                        to 172.16.40.2 via fe-0/0/0.0                       > to 172.16.40.6 via fe-0/0/1.0

The last issue with the OSPF redistribution task is the need to somehow advertise the 172.16.40.0/29 prefixes used by the OSPF domain into area 49.0001. This can be accomplished by running passive IS-IS on these interfaces, or by modifying the IS-IS export policy so that it also redistributes these routes. The latter approach is reflected in this modified IS-IS export policy, which uses the longer match type to catch both of the OSPF subnets in a single route filter term:

[edit policy-options policy-statement ospf-isis] lab@r6# show term 1 {      from {          route-filter 192.168.0.0/22 longer;          route-filter 172.16.40.0/29 longer;      }      then accept; } term 2 {      from {         route-filter 0.0.0.0/0 exact;      }      then reject; }

With the modified IS-IS export policy on both r6 and r7, we expect to see that r5 can load balance to the 192.168.x/24 routes, which indicates that both level 1 routers are correctly redistributing the OSPF routes into IS-IS:

[edit] lab@r5# run show route 192.168.0/24 inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24      *[IS-IS/160] 00:00:03, metric 5, tag 1                     > to 10.0.8.5 via fe-0/0/0.0                       to 10.0.8.10 via fe-0/0/1.0 192.168.0.1/32      *[IS-IS/160] 00:00:03, metric 6, tag 1                     > to 10.0.8.5 via fe-0/0/0.0                       to 10.0.8.10 via fe-0/0/1.0

With the mutual route redistribution apparently working, traceroutes are performed to confirm the required OSPF router to 10.0.5/24 subnet reachability:

lab@ospf> traceroute 10.0.5.1 traceroute to 10.0.5.1 (10.0.5.1), 30 hops max, 40 byte packets  1 172.16.40.6 (172.16.40.6) 0.211 ms 0.167 ms 0.113 ms  2 10.0.8.9 (10.0.8.9) 0.333 ms 0.304 ms 0.279 ms  3 *^C

Well, these results are certainly less than stellar. A quick look at r3 sheds some light on the nature of the problem:

lab@r3> show route 192/8 lab@r3>

The absence of the redistributed routes in the backbone results from the JUNOS software IS-IS implementation's default policy of not leaking level 1 external prefixes into the level 2 backbone. This is remedied with the highlighted policy modification made to r5's IS-IS export policy:

[edit policy-options policy-statement summ] lab@r5# show term 1 {     from {         protocol aggregate;         route-filter 10.0.2.0/23 exact;     }      to level 1;      then accept; } term 2 {     from {         protocol isis;          level 1;         external;     }      to level 2;      then accept; }

After the change is committed, the traceroute is retested:

lab@ospf> traceroute 10.0.5.1 traceroute to 10.0.5.1 (10.0.5.1), 30 hops max, 40 byte packets  1 172.16.40.6 (172.16.40.6) 0.191 ms 0.123 ms 0.095 ms  2 10.0.8.9 (10.0.8.9) 0.351 ms 0.293 ms 0.277 ms  3 10.0.2.10 (10.0.2.10) 0.413 ms 0.695 ms 0.381 ms  4 10.0.4.10 (10.0.4.10) 0.362 ms 0.701 ms 0.383 ms  5 10.0.5.1 (10.0.5.1) 0.363 ms 0.700 ms 0.379 ms

Since the OSPF router is currently forwarding through r7, it is wise to also confirm the forwarding path from r6:

[edit] lab@r6# run traceroute 10.0.5.1 traceroute to 10.0.5.1 (10.0.5.1), 30 hops max, 40 byte packets  1 10.0.8.6 (10.0.8.6) 0.360 ms 0.297 ms 0.233 ms  2 10.0.2.10 (10.0.2.10) 0.528 ms 0.495 ms 0.358 ms  3 10.0.4.10 (10.0.4.10) 0.357 ms 0.647 ms 0.372 ms  4 10.0.5.1 (10.0.5.1) 0.362 ms 0.683 ms 0.373 ms

The results indicate that IS-IS-to-OSPF route redistribution is working in accordance with the specified criteria. Before you consider this task complete, you should verify forwarding paths between r6, r7, and the OSPF router:

[edit] lab@r7# run traceroute 10.0.9.6 traceroute to 10.0.9.6 (10.0.9.6), 30 hops max, 40 byte packets  1 172.16.40.5 (172.16.40.5) 0.269 ms 0.196 ms 0.112 ms  2 10.0.9.6 (10.0.9.6) 0.198 ms 0.185 ms 0.157 ms

The extra hop through the OSPF router is not good. This situation exists because both r6 and r7 are advertising a stub route to the interface that is sourcing their RID, and this stub route is being coupled through the OSPF router with a better preference than the IS-IS route for the same prefix:

[edit] lab@r7# run show route 10.0.9.6 inet.0: 21 destinations, 24 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.9.6/32        *[OSPF/10]  00:08:42, metric 2                     > to 172.16.40.5 via fe-0/3/3.0                     [IS-IS/160] 00:36:16, metric 5, tag 1                      > to 10.0.8.1 via fe-0/3/0.0

While this issue could be resolved with preference adjustments, the cleanest fix is to manually configure the RID on both r6 and r7 as shown next:

[edit] lab@r6# set routing-options router-id 10.0.9.6

After the change, you confirm that forwarding is now optimal:

[edit] lab@r7# run traceroute 10.0.9.6 traceroute to 10.0.9.6 (10.0.9.6), 30 hops max, 40 byte packets  1 10.0.9.6 (10.0.9.6) 0.201 ms 0.133 ms 0.100 ms

The forwarding problems caused by the automatic route advertisement for the interface used to provide the OSPF router ID could have easily been missed. This example should emphasize the need for JNCIP candidates to constantly check and re-check their work because of the difficulties of actually being able to predict this type of behavior.

To complete this case study, the following task must now be addressed:

Summarize all routes (internal and external) into the backbone area.

Summarization of level 1 routes will require the local definition of one or more aggregate routes, and a corresponding policy that will block specific prefixes while advertising the aggregates into level 2 only. The following changes to r3 and r4 address the summarization of area 49.0002's routes:

[edit] lab@r3# show routing-options static {    route 10.0.200.0/24 next-hop 10.0.1.102; }  aggregate {    route 10.0.4.0/22;  }  [edit] lab@r3# show policy-options policy-statement summ {    term 1 {       from {          route-filter 10.0.5.0/24 exact;       }       to level 2;       then accept;    }    term 2 {       from {          protocol aggregate;          route-filter 10.0.4.0/22 exact;       }       to level 2;       then accept;    }    term 3 {       from {          route-filter 10.0.4.0/22 longer;       }       to level 2;       then reject;    }  }

In this policy, term 3 negates the default IS-IS policy of exporting IS-IS level 1 internals to level 2, which serves to suppress the more specific routes associated with area 49.0002. The second term is carefully written to ensure that the aggregate for area 49.0002 is injected only into the backbone area. The ordering of terms is significant in this policy because term 3 will match and subsequently reject the 10.0.5/24 route if it is processed before term 1. The summ policy must be applied to r3 and r4 as an IS-IS export before it will have any effect:

[edit] lab@r3# show protocols isis export export summ;

The results are verified by checking the backbone to confirm the presence of the aggregate and the absence of the more specific contributing routes, except the 10.0.5/24 prefix, which must be leaked into the backbone:

[edit] lab@r5# run show route 10.0.4/22 inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22        *[IS-IS/165] 00:04:29, metric 11, tag 2                      > to 10.0.2.10 via as1.0 10.0.5.0/24        *[IS-IS/18] 00:04:40, metric 64, tag 2                      > to 10.0.2.10 via as1.0

Load-balancing from r5 to area 49.0002 is not occurring because of the metric differences between r3's at-0/1/0 and r4's as0 interfaces, which are using metrics of 3 and 1, respectively. Load-balancing could be achieved by adjusting the metrics of these links, but this is not a requirement in this case study.

Summarizing the routes from area 49.0001 requires the same technique, but care must be taken to also include an aggregate for the 192.168.x/24 routes originating in the OSPF router because the summarization requirements apply to both internal and external IS-IS routes. The following capture highlights the changes needed on r5 to correctly summarize area 49.0001 routes:

lab@r5# show routing-options aggregate route 10.0.2.0/23; route 10.0.8.0/21; route 192.168.0.0/22; [edit] lab@r5# show policy-options policy-statement summ {      term 1 {          from {             protocol aggregate;             route-filter 10.0.2.0/23 exact;         }         to level 1;         then accept;     }      term 2 {          from {             route-filter 10.0.8.0/21 longer;             route-filter 192.168.0.0/22 longer;         }          to level 2;          then reject;      }     term 3 {         from {             protocol aggregate;             route-filter 10.0.8.0/21 exact;             route-filter 192.168.0.0/22 exact;         }          to level 2;          then accept;      } }

The results are now confirmed on a backbone router:

lab@r3> show route 10.0.8.0 inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.0/21        *[IS-IS/165] 00:02:32, metric 13, tag 2                      > to 10.0.2.1 via at-0/1/0.35 lab@r3> show route 192/8 inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/22      *[IS-IS/165] 00:02:36, metric 13, tag 2                       > to 10.0.2.1 via at-0/1/0.35

These results confirm that summarization into the IS-IS backbone has been correctly configured. Before calling it quits, it is recommended that you once again verify the required connectivity between the 10.0.5/24 subnet and the OSPF router:

lab@ospf> traceroute 10.0.5.2 traceroute to 10.0.5.2 (10.0.5.2), 30 hops max, 40 byte packets  1 172.16.40.6 (172.16.40.6) 0.207 ms 0.121 ms 0.093 ms 2 10.0.8.9 (10.0.8.9) 0.344 ms 0.290 ms 0.277 ms  3 *^C

This is a good example of why assumptions should never be made in the JNCIP lab! Though not necessarily by design, you are likely to find that the layered nature of the configuration tasks can result in the need to modify existing configurations, which in turn can lead to the 'breaking' of previously confirmed network functionality. In this case, the modification of r5's policy, which was intended to achieve the case study's summarization requirements, failed to take into account the prefixes associated with the OSPF subnets, thereby making the routes unreachable for backbone routers. The highlighted changes to r5's IS-IS export policy resolves the remaining issue:

[edit] lab@r5# show routing-options aggregate route 10.0.2.0/23; route 10.0.8.0/21; route 192.168.0.0/22; route 172.16.40.0/29; [edit] lab@r5# show policy-options policy-statement summ {      term 1 {          from {              protocol aggregate;              route-filter 10.0.2.0/23 exact;         }          to level 1;          then accept;      }      term 2 {          from {             route-filter 10.0.8.0/21 longer;         }          to level 2;          then reject;      }      term 3 {          from {              protocol aggregate;              route-filter 10.0.8.0/21 exact;              route-filter 192.168.0.0/22 exact;              route-filter 172.16.40.0/29 exact;         }         to level 2;         then accept;     } }

This author has opted to summarize the OSPF subnets because the case study requirements make it clear that both internal and external IS-IS routes are to be summarized, and it is better to be safe than sorry. With the modified policy in place on r5, connectivity to the 10.0.5/24 subnet is restored and the goals of this case study achieved:

lab@ospf> traceroute 10.0.5.2 traceroute to 10.0.5.2 (10.0.5.2), 30 hops max, 40 byte packets  1 172.16.40.6 (172.16.40.6) 0.193 ms 0.122 ms 0.093 ms  2 10.0.8.9 (10.0.8.9) 0.332 ms 0.291 ms 0.277 ms  3 10.0.2.10 (10.0.2.10) 0.336 ms 0.308 ms 0.305 ms  4 10.0.5.2 (10.0.5.2) 0.254 ms 0.232 ms 0.217 ms

IS-IS Case Study Configurations

The modified configuration stanzas needed to complete the IS-IS case study are provided in Listings 4.4 through 4.10 for all routers in the test bed, with the IS-IS related changes highlighted.

Listing 4.4: r1 IS-IS Related Configuration

[edit] lab@r1# show interfaces fe-0/0/1 {     vlan-tagging;     unit 200 {         vlan-id 200;         family inet {             address 10.0.4.14/30;         }         family iso;     } } fe-0/0/2 {                   fastether-options {         source-filtering;         source-address-filter {             00:a0:c9:6f:70:0d;         }     }      unit 0 {          family inet {              address 10.0.4.5/30;         }          family iso;     } } fxp0 {      unit 0 {          family inet {              address 10.0.1.1/24;         }     } } lo0 {      unit 0 {          family inet {              address 10.0.6.1/32;         }         family iso {             address 49.0002.0100.0000.6001.00;         }     } } [edit] lab@r1# show policy-options policy-statement direct {      term 1 {          from {             protocol direct;             route-filter 10.0.5.0/24 exact;         }          then {             metric 101;              accept;         }     } } [edit] lab@r1# show protocols isis export direct; reference-bandwidth 500m; lsp-lifetime 3600; level 1 wide-metrics-only; interface all {     hello-authentication-key "$9$MexL7Vji.mT3"; # SECRET-DATA     hello-authentication-type md5; # SECRET-DATA     level 2 disable; }

Listing 4.5: r2 IS-IS Related Configuration

[edit] lab@r2# show interfaces fe-0/0/1 {     speed 100m;         link-mode half-duplex;      fastether-options {         no-flow-control;      }      unit 0 {          family inet {             address 10.0.4.10/30;         }          family iso;      } } fe-0/0/2 {      unit 0 {          family inet {             address 10.0.4.2/30;         }          family iso;      } } fe-0/0/3 {      fastether-options {         source-filtering;         source-address-filter {             00:a0:c9:6f:7b:84;         }     }      unit 0 {          family inet {              address 10.0.4.6/30;         }          family iso;     } } fxp0 {      unit 0 {          family inet {              address 10.0.1.2/24;         }     } } lo0 {      unit 0 {          family inet {              address 10.0.6.2/32;         }         family iso {             address 49.0002.0100.0000.6002.00;         }     } } [edit] lab@r2# show policy-options policy-statement direct {      term 1 {          from {             protocol direct;             route-filter 10.0.5.0/24 exact;         }          then {             metric 101;              accept;         }     } } [edit] lab@r2# show protocols isis export direct; reference-bandwidth 500m; lsp-lifetime 3600; level 1 wide-metrics-only; interface all {     hello-authentication-key "$9$TF6ArlMWxd"; # SECRET-DATA     hello-authentication-type md5; # SECRET-DATA      level 2 disable; }

Listing 4.6: r3 IS-IS Related Configuration

[edit] lab@r3# show routing-options static {      route 10.0.200.0/24 next-hop 10.0.1.102; } aggregate {     route 10.0.4.0/22; } [edit] lab@r3# show interfaces fe-0/0/0 {     vlan-tagging;      unit 0 {          vlan-id 200;          family inet {              mtu 1496;             address 10.0.4.13/30;         }          family iso;     } } fe-0/0/1 {      unit 0 {          family inet {             address 10.0.4.1/30;         }          family iso;      } } fe-0/0/2 {     unit 0 {          family inet {             address 172.16.0.13/30;         }          family iso;      } } at-0/1/0 {      atm-options {          vpi 0 maximum-vcs 17;          vpi 5 maximum-vcs 36;          ilmi;      }      unit 35 {          vci 5.35;          shaping {               cbr 50m;         }          oam-period 10;          oam-liveness {             up-count 2;             down-count 2;         }          family inet {             address 10.0.2.2/30;         }          family iso;      } } so-0/2/0 {     hold-time up 30 down 30;     encapsulation frame-relay;      lmi {          n392dte 2;          n393dte 3;          t391dte 15;          lmi-type itu;     }      unit 100 {         dlci 100;          family inet {              address 10.0.2.5/30;         }          family iso;     } } fxp0 {      unit 0 {          family inet {              address 10.0.1.3/24;         }               } } lo0 {      unit 0 {          family inet {              address 10.0.3.3/32;         }          family iso {             address 49.0002.0100.0000.3003.00;         }     } } [edit] lab@r3# show policy-options policy-statement summ {      term 1 {          from {             route-filter 10.0.5.0/24 exact;         }          to level 2;          then accept;     }      term 2 {          from {             protocol aggregate;             route-filter 10.0.4.0/22 exact;         }          to level 2;          then accept;      }     term 3 {         from {             route-filter 10.0.4.0/22 longer;         }          to level 2;          then reject;      } } [edit] lab@r3# show protocols isis export summ; reference-bandwidth 500m; lsp-lifetime 3600; level 2 {     authentication-key "$9$DCH.50OREyK"; # SECRET-DATA     authentication-type simple; # SECRET-DATA } level 1 wide-metrics-only; interface fe-0/0/0.0 {      level 2 disable;      level 1 {         hello-authentication-key "$9$qPT3REyrvL"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } } interface fe-0/0/1.0 {      level 2 disable;      level 1 {         hello-authentication-key "$9$FzZb6CuKvLX-w"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } } interface fe-0/0/2.0 {     passive;      level 1 disable; } interface all {      level 1 disable;     level 2 {         hello-authentication-key "$9$JeUi.AtOBEy"; # SECRET-DATA         hello-authentication-type md5; # SECRET-DATA      } }

Listing 4.7: r4 IS-IS Related Configuration

[edit] lab@r4# show routing-options static {      route 10.0.200.0/24 next-hop 10.0.1.102; } aggregate {     route 10.0.4.0/22; } [edit] lab@r4# show interfaces fe-0/0/1 {     speed 100m;     link-mode half-duplex;     fastether-options {         no-flow-control;      }     unit 0 {         family inet {             address 10.0.4.9/30;         }         family iso;      } } 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;     } } so-0/1/1 {      sonet-options {          path-trace r4-jnx;          aggregate as0;     } } so-0/1/2 {      sonet-options {          path-trace r4-jnx;          aggregate as0;     } } as0 {     aggregated-sonet-options {         minimum-links 2;         link-speed oc3;     }      unit 0 {          family inet {             address 10.0.2.10/30;         }          family iso;     } } fxp0 {      unit 0 {          family inet {              address 10.0.1.4/24;         }     } } lo0 {      unit 0 {         family inet {             address 10.0.3.4/32;         }                    family iso {             address 49.0002.0100.0000.3004.00;         }     } } [edit] lab@r4# show policy-options policy-statement summ {      term 1 {          from {              route-filter 10.0.5.0/24 exact;         }          to level 2;          then accept;     }      term 2 {          from {             protocol aggregate;              route-filter 10.0.4.0/22 exact;         }          to level 2;          then accept;     }      term 3 {          from {             route-filter 10.0.4.0/22 longer;         }          to level 2;          then reject;     } } [edit] lab@r4# show protocols isis export summ; reference-bandwidth 500m; lsp-lifetime 3600; level 2 {     authentication-key "$9$E7eSlM2gJZjq"; # SECRET-DATA     authentication-type simple; # SECRET-DATA } level 1 wide-metrics-only; interface fe-0/0/1.0 {      level 2 disable;      level 1 {         hello-authentication-key "$9$jdkmTOBEhrv"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } } interface all {      level 1 disable;      level 2 {         hello-authentication-key "$9$vsc8xdDjq.5F"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } }

Listing 4.8: r5 IS-IS Related Configuration

[edit] lab@r5# show routing-options static {      route 10.0.200.0/24 next-hop 10.0.1.102; } aggregate {     route 10.0.2.0/23;     route 10.0.8.0/21;     route 192.168.0.0/22;     route 172.16.40.0/29; } [edit] lab@r5# show interfaces fe-0/0/0 {      unit 0 {          family inet {              address 10.0.8.6/30;         }          family iso;      } } fe-0/0/1 {      unit 0 {          family inet {              address 10.0.8.9/30;         }          family iso;      } } so-0/1/0 {      sonet-options {          path-trace r5-jnx;          aggregate as1;      } } so-0/1/1 {      sonet-options {          path-trace r5-jnx;          aggregate as1;      } } at-0/2/1 {      atm-options {          vpi 0 maximum-vcs 17;          vpi 5 maximum-vcs 36;         ilmi;      }     unit 35 {                vci 5.35;          shaping {             cbr 50m;         }          oam-period 10;          oam-liveness {              up-count 2;             down-count 2;         }          family inet {              address 10.0.2.1/30;         }          family iso;     } } as1 {     aggregated-sonet-options {         minimum-links 2;          link-speed oc3;     }      unit 0 {          family inet {              address 10.0.2.9/30;         }          family iso;     } } fxp0 {      unit 0 {          family inet {              address 10.0.1.5/24;         }     } }                   lo0 {      unit 0 {          family inet {              address 10.0.3.5/32;         }         family iso {             address 49.0001.0100.0000.3005.00;         }     } } [edit] lab@r5#  show policy-options policy-statement summ {     term 1 {          from {              protocol aggregate;              route-filter 10.0.2.0/23 exact;         }          to level 1;          then accept;      }     term 2 {          from {             route-filter 10.0.8.0/21 longer;         }          to level 2;          then reject;      }     term 3 {          from {              protocol aggregate;              route-filter 10.0.8.0/21 exact;              route-filter 192.168.0.0/22 exact;              route-filter 172.16.40.0/29 exact;         }          to level 2;          then accept;      } } lab@r5#  show protocols isis export summ; reference-bandwidth 500m; lsp-lifetime 3600; level 2 {     authentication-key "$9$jEkmTOBEhrv"; # SECRET-DATA     authentication-type simple; # SECRET-DATA } level 1 preference 155; interface fe-0/0/0.0 {      level 2 disable;      level 1 {          hello-authentication-key "$9$H.fz1IcSeW"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA          priority 0;      } } interface fe-0/0/1.0 {      level 2 disable;      level 1 {         hello-authentication-key "$9$EORSlM2gJZjq"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA          priority 0;      } } interface all {      level 1 disable;      level 2 {          hello-authentication-key "$9$5znCyrvMX-"; # SECRET-DATA          hello-authentication-type md5; # SECRET-DATA      } }

Listing 4.9: r6 IS-IS Related Configuration

[edit] lab@r6# show interfaces fe-0/1/0 {      unit 0 {          family inet {              address 10.0.8.5/30;         }          family iso;      } } fe-0/1/1 {      mtu 4000;      unit 0 {          family inet {              address 10.0.8.1/30;         }          family iso;     } } fe-0/1/3 {      unit 0 {          family inet {             address 172.16.40.2/30;         }     } } fxp0 {      unit 0 {          family inet {              address 10.0.1.6/24;         }     } } lo0 {      unit 0 {          family inet {              address 10.0.9.6/32;         }                   family iso;             address 49.0001.0100.0000.9006.00;         }     } } [edit] lab@r6# show routing-options static {     route 10.0.200.0/24 next-hop 10.0.1.102; } router-id 10.0.9.6; [edit] lab@r6# show policy-options policy-statement isis-ospf {      term 1 {         from {             route-filter 0.0.0.0/0 exact;         }          then accept;      } } policy-statement ospf-isis {      term 1 {          from {              route-filter 192.168.0.0/22 longer;              route-filter 172.16.40.0/29 longer;         }          then accept;      }      term 2 {          from {             route-filter 0.0.0.0/0 exact;         }          then reject;      } } [edit] lab@r6#  show protocols isis {      export ospf-isis;     reference-bandwidth 500m;      lsp-lifetime 3600;      level 1 preference 155;     interface all {         hello-authentication-key "$9$NoVs4PfzF/t"; # SECRET-DATA         hello-authentication-type md5; # SECRET-DATA         level 2 disable;          level 1 priority 0;      } } ospf {     external-preference 159;      export isis-ospf;     area 0.0.0.2 {         nssa;         authentication-type simple; # SECRET-DATA         interface fe-0/1/3.0 {             authentication-key "$9$Byn1clKvLNVYWL"; # SECRET-DATA         }     } }

Listing 4.10: r7 IS-IS Related Configuration

[edit] lab@r7# show interfaces fe-0/3/0 {     mtu 4000;      mac 00.00.00.00.00.11;      unit 0 {          family inet {              address 10.0.8.2/30;         }          family iso;     } } fe-0/3/1 {      mac 00.00.00.00.00.22;      unit 0 {          family inet {             address 10.0.8.10/30;         }          family iso;     } } fe-0/3/3 {      unit 0 {          family inet {             address 172.16.40.6/30;         }     } } fxp0 {      unit 0 {          family inet {              address 10.0.1.7/24;         }     } } lo0 {      unit 0 {         family inet {             address 10.0.9.7/32;         }          family iso;             address 49.0001.0100.0000.9007.00;         }      } } [edit] lab@r7# show routing-options static {     route 10.0.200.0/24 next-hop 10.0.1.102; } router-id 10.0.9.7; [edit] lab@r7# show policy-options policy-statement isis-ospf {      term 1 {          from {             route-filter 0.0.0.0/0 exact accept;         }      } } policy-statement ospf-isis {      term 1 {          from {              route-filter 192.168.0.0/22 longer;              route-filter 172.16.40.0/29 longer;         }          then accept;      }      term 2 {          from {             route-filter 0.0.0.0/0 exact;         }          then reject;      } } [edit] lab@r7#  show protocols isis {      export ospf-isis;     reference-bandwidth 500m;      lsp-lifetime 3600;      level 1 preference 155;     interface all {         hello-authentication-key "$9$j5kmTOBEhrv"; # SECRET-DATA         hello-authentication-type md5; # SECRET-DATA         level 2 disable;          level 1 priority 0;      } } ospf {     external-preference 159;      export isis-ospf;     area 0.0.0.2 {         nssa;         authentication-type simple; # SECRET-DATA         interface fe-0/3/3.0 {             authentication-key "$9$6vcM/pBIRSeMXhS"; # SECRET-DATA         }      } }