IS-IS Policy

JUNOS software policy is used with IS-IS to configure route leaking, route summarization, and route redistribution. The configuration examples in this section demonstrate the use and verification of IS-IS routing policy.

Route Leaking and Summarization

Route leaking allows the injection of routing information from the IS-IS backbone into a level 1 area. The added routing information in the level 1 area reduces the area’s reliance on the default route generated by level 2–attached routers, and can eliminate the potential for inefficient routing that can result from using the metrically closest attached router for all inter-area destinations.

To complete this configuration example, you will need to configure area 49.0003 and then apply routing policy to effect route leaking and route summarization for the area according to the following criteria:

• Leak level 2 loopback addresses into area 49.0003 and ensure optimal routing to these prefixes.

• Summarize area 49.0003 addresses into the backbone.

• Maintain connectivity between all router loopback addresses.

Area 49.0003 Initial Configuration

Before route leaking and summarization can be demonstrated, you must first correctly configure area 49.0003 as a level 1 area according to Figure 4.2.

Figure 4.2: Route leaking and summarization

To complete the initial configuration of area 49.003, you will need to reassign the NET on both r3 and r4 (the current NET will prevent level 1 adjacency formation in area 49.0003), and configure the correct interfaces for level 1 operation. A working configuration from r4 is shown here with highlighted changes:

[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; } [edit] lab@r4# show interfaces lo0 unit 0 {      family inet {          address 10.0.3.4/32;      }     family iso {         address 49.0003.0100.0000.3004.00;      } }

The modified IS-IS stanza on r4 includes the declaration of interface fe-0/0/1 as a level 1– only interface:

[edit] lab@r4# show protocols isis no-authentication-check; level 2 {     authentication-key "$9$XX4NVYq.5QF/"; # SECRET-DATA     authentication-type md5; # SECRET-DATA } interface fe-0/0/1.0 {      level 2 disable; } interface so-0/1/0.100 {     hello-authentication-key "$9$OQpxIhrVb24aU"; # SECRET-DATA     hello-authentication-type md5; # SECRET-DATA      level 1 disable; } interface as0.0 {     hello-authentication-key "$9$SCLlvLoaUjHm"; # SECRET-DATA     hello-authentication-type md5; # SECRET-DATA      level 1 disable; } interface lo0.0 {      level 1 disable; } 

A functional configuration for a level 1 router in area 49.0003 is shown next for r1 with IS-IS additions highlighted:

[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; } [edit] lab@r1#  show interfaces 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; } [edit] lab@r1# show interfaces lo0 unit 0 {    family inet {       address 10.0.6.1/32;    }    family iso {       address 49.0003.0100.0000.6001.00;    }  }

r1’s IS-IS stanza correctly configures it as a level 1–only router:

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

Area 49.0003 Verification

After completing the initial configuration for area 49.0003, you can quickly assess your work by verifying that the appropriate adjacencies and SysIDs are present in area 49.0003:

lab@r3> show isis adjacency Interface             System         L State         Hold (secs) SNPA at-0/1/0.35           r5             2 Up                   21 fe-0/0/0.0            r1             1 Up                    7  0:a0:c9:6f:7b:3e fe-0/0/1.0            r2             1 Up                   26  0:a0:c9:6f:7a:ff so-0/2/0.100          r4             2 Up                   26 lab@r3> 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

Configure Route Leaking

For this example, your IS-IS route-leaking configuration is performed on the L1/L2-attached routers that serve area 49.0003. You must use a policy that makes use of route filters to achieve the goal of leaking only the backbone area’s loopback addresses. Before route leaking is configured, you first analyze the state of the routing table for level 1 routers in area 49.0003:

lab@r2> show route protocol isis inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0           *[IS-IS/15] 01:54:13, 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 10.0.4.12/30        *[IS-IS/15] 01:54:21, metric 20, tag 1                        to 10.0.4.1 via fe-0/0/2.0                      > to 10.0.4.5 via fe-0/0/3.0 10.0.6.1/32         *[IS-IS/15] 01:54:28, metric 10, tag 1                      > to 10.0.4.5 via fe-0/0/3.0

From this display, we can see that backbone area loopback addresses are not yet present in area 49.0003. The following commands create the policy needed to correctly leak lo0 prefixes into area 49.0003:

[edit policy-options policy-statement leak] lab@r4# set term 1 from protocol isis [edit policy-options policy-statement leak] lab@r4# set term 1 from level 2 [edit policy-options policy-statement leak] lab@r4# set term 1 from route-filter 10.0.3/24 longer [edit policy-options policy-statement leak] lab@r4# set term 1 to level 1 [edit policy-options policy-statement leak] lab@r4# set term 1 then accept 

The completed policy is now displayed:

[edit policy-options policy-statement leak] lab@r4# show term 1 {     from {         protocol isis;          level 2;         route-filter 10.0.3.0/24 longer;     }     to level 1;      then accept; } 

The route-leaking policy is now applied as an export policy to the IS-IS instance and the changes are committed:

[edit] lab@r4# set protocols isis export leak [edit] lab@r4# commit commit complete

Verify Route Leaking

The effects of your route-leaking policy are tested with the following commands:

lab@r2> show route protocol isis inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0           *[IS-IS/15] 01:57:53, 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 10.0.3.3/32         *[IS-IS/18] 00:00:54, metric 20, tag 1                      > to 10.0.4.9 via fe-0/0/1.0 10.0.3.5/32         *[IS-IS/18] 00:00:54, metric 20, tag 1                      > to 10.0.4.9 via fe-0/0/1.0 10.0.4.12/30        *[IS-IS/15] 01:58:01, metric 20, tag 1                        to 10.0.4.1 via fe-0/0/2.0                      > to 10.0.4.5 via fe-0/0/3.0 10.0.6.1/32         *[IS-IS/15] 01:58:08, metric 10, tag 1                      > to 10.0.4.5 via fe-0/0/3.0

While these results are promising, r4’s loopback address is absent in area 49.0003. This situation is caused by the policy being written to match on IS-IS level 2 routes coupled with the fact that r4 has learned about its own lo0 address from the direct protocol. This problem is easily rectified with the highlighted policy modification on r4:

[edit policy-options policy-statement leak] lab@r4# show term 1 {     from {         protocol isis;         level 2;         route-filter 10.0.3.0/24 longer;      }      to level 1;      then accept; } term 2 {     from {         protocol direct;         route-filter 10.0.3.0/24 longer;      }      to level 1;      then accept; } 

Although the testing conducted with the 5.2 version of JUNOS software used in this test bed indicates that the to level 1 criteria is not needed for the route leaking behavior specified in this example, such syntax is needed when the goal is to leak a prefix into either level 1 or level 2, but not into both levels 1 and 2. The to level 1 syntax has been included here because it helps to reinforce the readers’ awareness of route-leaking directionality. Also of note is the fact that this policy does not make use of a "reject all" term, which means the default IS-IS policy of leaking level 1 prefixes into level 2 has not been altered. The net result is the expectation that r4 will continue to leak level 1 routes into level 2 while also leaking specific level 2 prefixes into area 49.0003.

To complete the route-leaking configuration, a similar policy must be applied to r3. This will ensure that the suboptimal routing from area 49.0003 to backbone router loopback addresses, which is demonstrated next, does not occur:

lab@r1> traceroute 10.0.3.3 traceroute to 10.0.3.3 (10.0.3.3), 30 hops max, 40 byte packets  1 10.0.4.6 (10.0.4.6) 0.219 ms 0.167 ms 0.115 ms  2 10.0.4.9 (10.0.4.9) 0.353 ms 0.307 ms 0.286 ms  3 10.0.3.3 (10.0.3.3) 0.504 ms 0.433 ms 0.421 ms

The extra hops in this capture are the result of having only one of the attached routers perform the route leaking. After applying the same route-leaking policy to r3, we see that optimal routing to level 2 lo0 addresses has been achieved:

lab@r1> traceroute 10.0.3.3 traceroute to 10.0.3.3 (10.0.3.3), 30 hops max, 40 byte packets  1 10.0.3.3 (10.0.3.3) 0.513 ms 0.376 ms 0.346 ms

Configure Route Summarization

Because the IS-IS protocol does not offer support of area-range statements, route summarization requires the definition of an aggregate route and the policy needed to advertise this aggregate while suppressing the more specific prefixes. Before configuring summarization, analyze the route table of a backbone router with regard to area 49.0003 routes in order to better judge the effect of your route summarization configuration:

lab@r5> show route protocol isis 10.0.4/22 inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/30         *[IS-IS/18] 02:46:47, metric 20, tag 2                      > to 10.0.2.2 via at-0/2/1.35 10.0.4.4/30         *[IS-IS/18] 00:02:27, metric 30, tag 2                      > to 10.0.2.2 via at-0/2/1.35                        to 10.0.2.10 via as1.0 10.0.4.8/30         *[IS-IS/18] 02:48:01, metric 20, tag 2                      > to 10.0.2.10 via as1.0 10.0.4.12/30        *[IS-IS/18] 02:46:47, metric 20, tag 2                      > to 10.0.2.2 via at-0/2/1.35 10.0.6.1/32         *[IS-IS/18] 00:02:34, metric 20, tag 2                      > to 10.0.2.2 via at-0/2/1.35 10.0.6.2/32         *[IS-IS/18] 00:02:27, metric 20, tag 2                      > to 10.0.2.2 via at-0/2/1.35                        to 10.0.2.10 via as1.0

These results confirm that summarization into the backbone does not occur by default. You can configure r3 to advertise a summary, and to suppress the more specific level 1 routes, with the following policy and aggregate route definition:

[edit] lab@r3# show policy-options policy-statement summ term 1 {     from protocol aggregate;      to level 2;      then accept; } term 2 {     from {         protocol isis;          level 1;     }      to level 2;      then reject; } 

Term 2 in this policy negates the default IS-IS policy of leaking level 1 routes into level 2, which is intended to prevent the advertisement of the specific prefixes in area 49.0003. The aggregate route for area 49.0003 prefixes is displayed next:

[edit] lab@r3# show routing-options aggregate route 10.0.4.0/22;

The summ policy is then applied to r3’s IS-IS instance as an export policy:

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

Verify Route Summarization

You can easily verify the results of your route summarization by once again displaying the contents of a backbone router’s routing table, as it relates to area 49.0003 routes:

lab@r5> show route protocol isis 10.0.4/22 inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22        *[IS-IS/165] 00:00:22, metric 20, tag 2                      > to 10.0.2.2 via at-0/2/1.35 10.0.4.0/30         *[IS-IS/18] 03:04:49, metric 20, tag 2                      > to 10.0.2.2 via at-0/2/1.35 10.0.4.4/30         *[IS-IS/18] 00:00:22, metric 30, tag 2                      > to 10.0.2.10 via as1.0 10.0.4.8/30         *[IS-IS/18] 00:02:44, metric 20, tag 2                      > to 10.0.2.10 via as1.0 10.0.4.12/30        *[IS-IS/18] 03:04:49, metric 20, tag 2                      > to 10.0.2.2 via at-0/2/1.35 10.0.6.1/32         *[IS-IS/18] 00:00:22, metric 30, tag 2                      > to 10.0.2.10 via as1.0 10.0.6.2/32         *[IS-IS/18] 00:00:22, metric 20, tag 2                      > to 10.0.2.10 via as1.0

You can also assess the operation of the summarization policy by examining the contents of r3’s LSPs:

lab@r5> show isis database r3 detail IS-IS level 1 link-state database: IS-IS level 2 link-state database: r3.00-00 Sequence: 0x93, Checksum: 0x442, Lifetime: 413 secs    IS neighbor:                         r4.00  Metric:      10    IS neighbor:                         r5.00  Metric:      10    IP prefix:                     10.0.4.0/22 Metric:       10 External    IP prefix:                     10.0.2.4/30 Metric:       10 Internal    IP prefix:                     10.0.2.0/30 Metric:       10 Internal    IP prefix:                     10.0.4.0/30 Metric:       10 Internal    IP prefix:                    10.0.4.12/30 Metric:       10 Internal    IP prefix:                     10.0.3.3/32 Metric:        0 Internal    IP prefix:                  172.16.0.12/30 Metric:       10 Internal

These results confirm that r3 is correctly advertising the aggregate in its level 2 LSP, but also indicate that the 10.0.4.0/30 and 10.0.12.0/30 contributing routes are being incorrectly leaked (as indicated by the entries using at-0/2/1.35 as a next hop in r5’s routing table and by their presence in r3’s level 2 LSP). As you might expect, the problem here relates to the summarization policy, and the fact that it is not rejecting routes for directly connected interfaces that have IS-IS configured. Displaying one of these routes on r3 confirms this is indeed the case:

[edit] lab@r3# run show route 10.0.4.12/30 inet.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.12/30        *[Direct/0] 2d 03:50:53                     > via fe-0/0/0.0 10.0.4.13/32       *[Local/0] 2d 04:16:09                        Local via fe-0/0/0.0

To correct this problem, the summarization policy on r3 is modified as highlighted next. This is just one example of many possible policy modifications that could have resolved the route summarization problem:

 [edit policy-options policy-statement summ] lab@r3# show term 1 {     from protocol aggregate;     to level 2;     then accept; } term 2 {     from {         route-filter 10.0.4.0/22 longer;     }     to level 2;     then reject; }

In this example, omitting the to level 2 condition in term 2 would cause problems in area 49.0003 because routes matching the route-filter would then not be injected into any IS-IS level, and these routes should be present in the level 1 area. After applying the same summarization policy to r4, the results are once again verified on the backbone router r5:

lab@r5> show route 10.0.4/22 inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22        *[IS-IS/165] 00:00:00, metric 20, tag 2                       to 10.0.2.2 via at-0/2/1.35                     > to 10.0.2.10 via as1.0

Very good, the summary route for area 49.0003 now has two viable next hops, and the more specific prefixes are no longer being injected into the level 2 area in accordance with the configuration requirements.

Route Redistribution

Export policy can also be applied to IS-IS to facilitate route redistribution and the manipulation of metrics at L1/L2-attached routers. JUNOS software does not support the application of import policy for link-state routing protocols like IS-IS because such policies could lead to inconsistent LSDB entries, which in turn could result in routing inconstancies. The filtering of LSPs is only possible in a multi-level topology, which will suppress the injection of level 2 LSPs into level 1 areas by default.

The use of routing policy to evoke route redistribution has already been demonstrated several times in this book, as has the use of policy to set the metric values for a redistributed static route. The following configuration scenario will demonstrate these capabilities as part of an IS-IS and OSPF mutual route redistribution scenario.

You will now add to the complexity of your network by configuring mutual route redistribution between IS-IS and OSPF as shown in Figure 4.3. The configuration criteria for this example follow the figure.

Figure 4.3: IS-IS route redistribution

• Redistribute the 10.0.5/25 subnet from both r1 and r2 so that level 2 routers display a route metric of at least 500.

• r5 must be able to load balance to the 10.0.5/24 prefix.

• Redistribute the IS-IS default route from both r6 and r7 to the OSPF router.

• Redistribute OSPF routes 192.168.0/24 through 192.168.3/24 into area 49.0002 from both r6 and r7.

• Ensure that the OSPF router, r6, and r7 can reach destinations on the 10.0.5/24 subnet.

• Except for r5, no single point of failure can isolate the OSPF router from reaching the 10.0.5/24 subnet.

• Continue to advertise the area 49.0003 summary while suppressing more specific prefixes, except for the 10.0.5/24 route in accordance with the first requirement.

The OSPF Router’s Configuration

The pertinent portions of the OSPF router’s configuration are shown and described in the following. You may not modify the OSPF router’s configuration in this configuration example:

[edit] lab@ospf# show protocols ospf {     export ospf;     area 0.0.0.1 {         interface fe-0/0/0.0;     } }

The OSPF stanza defines OSPF area 1 operation with an export policy called ospf. The contents of this policy are as follows:

[edit] lab@ospf# show policy-options policy-statement ospf {    term 1 {       from protocol static;       then accept;    }  }

The ospf policy will redistribute routes learned through the static protocol into OSPF as AS externals. The OSPF router’s routing-options stanza contains the various 192.168.x static route definitions, with their next hops set to discard in this example:

[edit] lab@ospf# show routing-options static {    route 192.168.0.0/24 discard;    route 192.168.1.0/24 discard;    route 192.168.2.0/24 discard;    route 192.168.3.0/24 discard;    }

The OSPF router’s interface configuration correctly sets the addressing for the OSPF subnet, and assigns host addresses from each of the 192.168.x static routes to the lo0 interface so that pings and traceroutes to host-id 1 on each 192.168.x subnet can complete successfully:

 [edit] lab@ospf# show interfaces . . .  fe-0/0/0 {      unit 0 {          family inet {              address 172.16.40.1/24;         }     } } lo0 {      unit 0 {          family inet {              address 192.168.0.1/32;              address 192.168.1.1/32;              address 192.168.2.1/32;              address 192.168.3.1/32;         }     } }

IS-IS Redistribution on r1 and r2

Your configuration begins by creating and applying a policy that will redistribute the 10.0.5/24 direct route from r1 and r2 into IS-IS with a metric of at least 500. The following policy will work for the requirements of this example, but other techniques are certainly possible:

[edit policy-options policy-statement direct] lab@r1# show term 1 {      from {         route-filter 10.0.5.0/24 exact;      }      then {         metric 500;         accept;      } }

The policy is applied to r1’s IS-IS instance as an export policy, and the effects are confirmed on r5:

 [edit] lab@r5# run show route 10.0.5/24 [edit] lab@r5#

The route’s absence on r5 is not a good sign. Perhaps we should look closer to the route’s source by examining r3’s view of the situation?

[edit] 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/160] 00:02:51, metric 73, tag 1                        > to 10.0.4.14 via fe-0/0/0.0

Troubleshoot IS-IS Redistribution

The 10.0.5/24 route is present on r3, so r1’s export policy must be doing something. The metric value of 73 is odd (both literally and in the context of this example), considering that the policy used to redistribute the route was configured to set the metric to 500. When faced with multiple symptoms such as these, this author would suggest that you prioritize the symptoms so that you can concentrate on resolving the most significant problems first. In this case, it is suggested that you resolve the route’s absence on r5 before worrying about the incorrect metric, because in many cases connectivity problems will result in more point losses on your exam, which makes the missing route your highest priority. Besides, it is often the case that multiple symptoms will result from a common problem, so tackling the most significant issue first may result in less work overall.

The route’s presence in r3 combined with its absence in r3’s L2 LSP points to routing policy as the probable cause. There are really two issues at work here; one is general in nature while the other is somewhat specific to this example. The general problem relates to the fact that the default IS-IS export policy will not send level 1 external routes into the IS-IS backbone. The specific issue lies in the route-filter statement used in the existing sum policy that was designed to suppress the specific routes associated with area 49.0003, as the 10.0.5/24 route happens to fall within the aggregate 10.0.4/22, and is therefore being explicitly rejected. The problem area in the sum policy is highlighted next:

. . . term 2 {     from {         route-filter 10.0.4.0/22 longer;     }     to level 2;     then reject; } 

The highlighted policy modification punches a hole in term 2 to explicitly allow the 10.0.5/ 24 prefix:

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

The use of an accept terminating action in conjunction with the 10.0.5/24 route-filter statement causes packets that match the route-filter exactly to be accepted while all other area 49.0003 prefixes are rejected by the terminating action associated with term 2. After committing the modification to the summ policy on r3, the results are once again confirmed on r5:

[edit] lab@r5# run show route 10.0.5/24 inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24         *[IS-IS/165] 00:00:05, metric 73, tag 2                      > to 10.0.2.2 via at-0/2/1.35

Good! The route is now present on r5, but the metric is still stuck at 73. This is a tricky problem to solve, as its solution depends on an in-depth understanding of the IS-IS protocol and JUNOS software behavior. The issue here relates to narrow vs. wide metrics, and the fact that the former supports a maximum link cost of 63 and a total path cost of 1023. The use of narrow metrics explains why the route’s metric is stuck at 73. Neither r1 nor r3 can advertise a link metric higher than 63, and the cost for r5 to reach r3 is 10, which results in the displayed metric value of 73. By default, JUNOS software sends both wide and narrow metrics along with each route, and when given the choice, Juniper Networks routers will opt to use the narrow metric. To resolve this situation, you must modify the routers in areas 49.0003 and 49.0001 to use wide metrics only, with the following command:

 [edit] lab@r1# set protocols isis level 1 wide-metrics-only 

After the change has been committed, the contents of r1’s level 1 LSP is verified:

[edit] lab@r1# run show isis database r1 detail IS-IS level 1 link-state database: r1.00-00 Sequence: 0x70, Checksum: 0x75bc, Lifetime: 1195 secs    IS neighbor:                         r1.03  Metric:       10    IS neighbor:                         r1.02  Metric:       10    IP prefix:                     10.0.4.4/30 Metric:       10 Internal    IP prefix:                    10.0.4.12/30 Metric:       10 Internal    IP prefix:                     10.0.6.1/32 Metric:        0 Internal    IP prefix:                     10.0.5.0/24 Metric:      500 Internal . . .

The following command is now applied to r3 to enable its use of wide metrics only, in the level 2 area:

[edit] lab@r3# set protocols isis level 2 wide-metrics-only 

After the change is committed, the route is once again analyzed on r5:

[edit] lab@r5# run show route 10.0.5/24 inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24          *[IS-IS/18] 00:00:00, metric 520, tag 2                       > to 10.0.2.2 via at-0/2/1.35 

Good! Backbone routers now see a metric greater than 500, in accordance with the specified requirements. To complete this example, you must now apply the same IS-IS export policy to r2, and you must also set wide metrics only, on r2 and r4, as shown for r1 and r3. The added configuration is needed to comply with the redundancy requirements of this example. After making the changes, we expect to see two viable next hops for the 10.0.5/24 prefix on r5. Failing to disable narrow metrics on r4 will result in a single next hop on r5 (and point loss on your exam for not allowing load-balancing), because r5 will prefer the narrow metric sent from r4 to the wide metric that is advertised by r3. This situation is demonstrated in the following capture:

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

You now correctly disable level 2 narrow metrics on r4:

[edit] lab@r4# set protocols isis level 2 wide-metrics-only [edit] lab@r4# commit commit complete

After a few moments, we finally observe the required load-balancing behavior on r5:

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

To complete this configuration example, connectivity to the 10.0.5/24 prefix is tested from the perspective of a level 1 router in area 49.0002:

lab@r7> 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.9 (10.0.8.9) 0.338 ms 0.242 ms 0.216 ms  2 10.0.2.2 (10.0.2.2) 0.777 ms 0.656 ms 0.878 ms  3 10.0.4.2 (10.0.4.2) 0.565 ms 0.655 ms 0.379 ms  4 10.0.5.1 (10.0.5.1) 0.690 ms 0.688 ms 0.878 ms lab@r7> traceroute 10.0.5.2 traceroute to 10.0.5.2 (10.0.5.2), 30 hops max, 40 byte packets  1 10.0.8.9 (10.0.8.9) 0.342 ms 0.241 ms 0.216 ms  2 10.0.2.2 (10.0.2.2) 0.863 ms 1.162 ms 0.378 ms  3 10.0.5.2 (10.0.5.2) 0.276 ms 0.643 ms 0.

The (highlighted) extra hop through r2 to reach the 10.0.5.1 address could be the normal result of IS-IS load balancing from r3 to r1 and r2, if we assume that r2 has been chosen as the current next hop for the 10.0.5/24 subnet. The following capture confirms this suspicion and proves that all is well with the route redistribution and redundancy requirements of your configuration:

lab@r3> show route 10.0.5.1 inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24          *[IS-IS/15] 00:12:16, metric 510, tag 1                         to 10.0.4.14 via fe-0/0/0.0                       > to 10.0.4.2 via fe-0/0/1.0 

Congratulations! You have met the requirements specified for the 10.0.5/24 prefix, with regard to its redistribution, metric setting, and backbone load-balancing capabilities.

While not required for this example, it is suggested that you now disable narrow metrics (at level 2) on r5, and at level 1 on r3 and r4. Mixing narrow and wide metrics within a single area can cause confusion down the road.

IS-IS and OSPF Redistribution on r6

You will now configure r6 to redistribute the default route from IS-IS into OSPF, and in the reverse direction, to redistribute the 192.168.x/24 OSPF routes into IS-IS. We begin with the following command that configures r6 to run OSPF on its fe-0/1/3 interface in area 1:

[edit protocols] lab@r6# set ospf area 1 interface fe-0/1/3 

After committing the changes, we verify that routes are now being received from the OSPF router:

 [edit protocols] lab@r6# run show route protocol ospf inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24       *[OSPF/150] 00:00:16, metric 0, tag 0                        > to 172.16.40.1 via fe-0/1/3.0 192.168.1.0/24       *[OSPF/150] 00:00:16, metric 0, tag 0                        > to 172.16.40.1 via fe-0/1/3.0 192.168.2.0/24       *[OSPF/150] 00:00:16, metric 0, tag 0                        > to 172.16.40.1 via fe-0/1/3.0 192.168.3.0/24       *[OSPF/150] 00:00:16, metric 0, tag 0                        > to 172.16.40.1 via fe-0/1/3.0 224.0.0.5/32         *[OSPF/10] 00:01:23, metric 1 iso.0: 1 destinations, 1 routes (1 active, 0 holddown,  0 hidden)

Great, r6 has formed an adjacency to the OSPF router. The next step is to write an export policy to redistribute the OSPF routes into IS-IS:

[edit] lab@r6# edit policy-options policy-statement ospf-isis [edit policy-options policy-statement ospf-isis] lab@r6# set term 1 from protocol ospf [edit policy-options policy-statement ospf-isis] lab@r6# set term 1 from route-filter 192.168.0/22 longer [edit policy-options policy-statement ospf-isis] lab@r6# set term 1 then accept 

The resulting OSPF to IS-IS redistribution policy is shown next:

[edit policy-options policy-statement ospf-isis] lab@r6# show term 1 {     from {         protocol isis;          level 1;         route-filter 192.168.0.0/22 longer;     }     to level 2;      then accept; }

The ospf-isis policy is now applied to the IS-IS instance as an export policy:

[edit] lab@r6# set protocols isis export ospf-isis 

With the export policy in place on r6 and the changes committed, we confirm the presence of the 192.168.x/24 routes on r5 to determine its effect:

[edit] lab@r5# run show route 192.168.0/22 inet.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24       *[IS-IS/160] 00:00:01, metric 10, tag 1                        > to 10.0.8.5 via fe-0/0/0.0 192.168.1.0/24 *[IS-IS/160] 00:00:01, metric 10, tag 1                        > to 10.0.8.5 via fe-0/0/0.0 192.168.2.0/24 *[IS-IS/160] 00:00:01, metric 10, tag 1                        > to 10.0.8.5 via fe-0/0/0.0 192.168.3.0/24 *[IS-IS/160] 00:00:01, metric 10, tag 1                        > to 10.0.8.5 via fe-0/0/0.0

So far, so good—all the OSPF routes are present on r5 as IS-IS level 1 external routes. To get the routes into the IS-IS backbone, you must now write an export policy on r5 instructing it to redistribute level 1 externals into level 2. The l1-ext policy shown here works well for our purposes:

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

After applying the l1-ext as export to r5’s IS-IS instance, the presence of the 192.168.x routes are confirmed on r3:

lab@r3> show route 192/8 inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24       *[IS-IS/18] 00:00:01, metric 20, tag 2                       > to 10.0.2.1 via at-0/1/0.35 192.168.0.1/32       *[IS-IS/18] 00:00:01, metric 21, tag 2                       > to 10.0.2.1 via at-0/1/0.35 192.168.1.0/24       *[IS-IS/18] 00:00:01, metric 20, tag 2                       > to 10.0.2.1 via at-0/1/0.35 192.168.2.0/24       *[IS-IS/18] 00:00:01, metric 20, tag 2                       > to 10.0.2.1 via at-0/1/0.35 192.168.3.0/24       *[IS-IS/18] 00:00:01, metric 20, tag 2                       > to 10.0.2.1 via at-0/1/0.35

In this example, r3 displays a preference of 18 for the 192.168.0/22 routes because the use of level 2 wide metrics on r5 prevents r3 from seeing the routes as level 2 externals, which have a default preference of 165. Refer back to the previous section, "Troubleshoot IS-IS Redistribution," for details on why wide metrics have been enabled in the level 2 backbone. With OSPF–to–IS-IS redistribution working properly at r6 and r5, you now create and apply the policy needed to redistribute the IS-IS default route from r6 into OSPF. The policy shown next will accommodate the requirements of this example, but other policy approaches are also workable.

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

Now apply the default policy as an export to OSPF using the following command:

[edit] lab@r6# set protocols ospf export default 

After committing the change, confirm that the default route is present on the OSPF router:

lab@ospf> show route protocol ospf inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0            *[OSPF/150] 00:02:47, metric 10, tag 1                        > to 172.16.40.2 via fe-0/0/0.0 10.0.9.6/32          *[OSPF/10] 00:22:38, metric 1                        > to 172.16.40.2 via fe-0/0/0.0 224.0.0.5/32 *[OSPF/10] 00:23:23, metric 1 

The default route is present as required, but unfortunately so is the route to r6’s loopback address. In accordance with the requirements of this example, you are to advertise only the default route to the OSPF router. Solving this problem can also be tricky. The issue relates to the JUNOS software behavior of automatically advertising a stub route to the interface from which the OSPF RID was obtained, as described in Chapter 3, "OSPF Configuration and Testing." To eliminate this route, you must manually assign r6’s RID as shown:

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

Once again, confirm the results from the perspective of the OSPF router:

lab@ospf> show route protocol ospf inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0            *[OSPF/150] 00:08:11, metric 10, tag 1                        > to 172.16.40.2 via fe-0/0/0.0 224.0.0.5/32 *[OSPF/10] 00:28:47, metric 1

As required, r6 is now advertising only the default route to the OSPF router. With this 5.2 code base, a routing daemon restart was not required for the change in RID source to take effect. With some JUNOS software versions, you may have to restart routing (or for dramatic effect, reboot the router) in order to have the routing daemon begin using the new source of its RID. With the default route confirmed in the OSPF router, you decide to test connectivity to the 10.0.5/24 prefix before bringing r7 into the route redistribution fray:

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.2 (172.16.40.2) 0.190 ms 0.123 ms 0.096 ms  2 * * * ^C 

This problem should seem familiar, as the very same issue arose in the OSPF-to-RIP redistribution example provided in Chapter 3. The issue is the lack of a route in the IS-IS routing domain for the 172.16.40/24 OSPF subnet used by the OSPF router when sourcing its packets. This is confirmed by using the source switch to the traceroute command as shown next:

lab@ospf> traceroute 10.0.5.1 source 192.168.0.1 traceroute to 10.0.5.1 (10.0.5.1) from 192.168.0.1, 30 hops max, 40 byte packets  1 172.16.40.2 (172.16.40.2) 0.190 ms 0.122 ms 0.094 ms  2 10.0.8.6 (10.0.8.6) 0.321 ms 0.289 ms 0.277 ms  3 10.0.2.2 (10.0.2.2) 0.756 ms 0.705 ms 0.874 ms  4 10.0.4.2 (10.0.4.2) 0.621 ms 0.673 ms 0.374 ms  5 10.0.5.1 (10.0.5.1) 0.628 ms 0.704 ms 0.875 ms

Because no restrictions have been placed on how you should handle this problem (other than your not being able to modify the OSPF router’s configuration), you could opt for one of several solutions that include running IS-IS passive on the OSPF subnet, or the redistribution of the direct interface route from r6. Because the latter approach will also require a policy modification on r5 to tell it that it should also redistribute the 172.16.40/24 level 1 external into the backbone, this author has opted to go with the simpler passive IGP approach, as shown next:

[edit protocols] lab@r6# set isis interface fe-0/1/3 level 2 disable [edit protocols] lab@r6# set isis interface fe-0/1/3 passive [edit interfaces] lab@r6# set fe-0/1/3 unit 0 family iso 

After committing changes on r6, we again test reachability to 10.0.5/24 from the OSPF router:

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.2 (172.16.40.2) 0.195 ms 0.123 ms 0.094 ms  2 10.0.8.6 (10.0.8.6) 0.341 ms 0.304 ms 0.278 ms  3 10.0.2.2 (10.0.2.2) 0.777 ms 1.204 ms 0.876 ms  4 10.0.4.2 (10.0.4.2) 0.400 ms 0.682 ms 0.375 ms  5 10.0.5.1 (10.0.5.1) 0.845 ms 1.204 ms 0.872 ms

IS-IS and OSPF Redistribution on r7

With IS-IS to OSPF route redistribution working on r6, you must now configure r7 so that it too redistributes routes between IS-IS and OSPF. As always, the bidirectional redistribution of routes from multiple locations is a task fraught with the peril of a routing loop. Before attacking this problem, it might behoove you to consider that the default preference for the IS-IS default route is 15, while the OSPF external route that results from its redistribution into OSPF will have a preference of 150. This means that r6 and r7 will automatically "ignore" the redistributed default route should it later be received over the OSPF subnet. Further, if this default should be inadvertently re-advertised back into the IS-IS level 1 area, the level 1 external preference will be 160, which will result in the continued use of the default route being injected by r5, which is a level 1 internal with a preference of 15. The same preference settings should also cause r6 and r7 to make the "right" choice when presented with the 192.168.x routes as both OSPF routes and IS-IS level 1 external routes, which is to say that the routers will prefer the OSPF source as desired.

Based on the default route preference settings, it would seem that a loop will not occur if the somewhat sloppy export policy in use by r6 is simply copied over to r7, even though such a procedure did result in a routing loop when OSPF was used to redistribute routes to and from the RIP protocol in Chapter 3. To put the theory to the test, r6’s export policies are copied and committed on r7. You should also configure r7’s OSPF area 1, and passive IS-IS interface as shown for r6 in the previous section. Lastly, do not forget to add the manually assigned RID to r7 to prevent it from advertising a stub route to its loopback address.

Verify OSPF and IS-IS Redistribution

When the configuration of r7 is complete, the results are confirmed with the following commands, starting with the verification that the OSPF router sees two equal-cost next hops for the default route:

lab@ospf> show route protocol ospf inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0            *[OSPF/150] 00:01:32, metric 10, tag 1                        > to 172.16.40.2 via fe-0/0/0.0                          to 172.16.40.3 via fe-0/0/0.0 224.0.0.5/32         *[OSPF/10] 01:49:48, metric 1

We now confirm that r6 and r7 prefer the OSPF 192.168.x/24 externals, as received from the OSPF router, to the redistributed IS-IS level 1 externals:

[edit] lab@r7# run show route 192/8 inet.0: 20 destinations, 21 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24     *[OSPF/150]  00:01:26, metric 0, tag 0                      > to 172.16.40.1 via fe-0/3/3.0 192.168.0.1/32     *[OSPF/10] 00:01:26, metric 1                      > to 172.16.40.1 via fe-0/3/3.0 192.168.1.0/24     *[OSPF/150]  00:01:26, metric 0, tag 0                      > to 172.16.40.1 via fe-0/3/3.0 192.168.2.0/24     *[OSPF/150]  00:01:26, metric 0, tag 0                      > to 172.16.40.1 via fe-0/3/3.0 192.168.3.0/24     *[OSPF/150] 00:01:26, metric 0, tag 0                     > to 172.16.40.1 via fe-0/3/3.0 

You should also verify that the IS-IS level 1 default route is preferred to the OSPF external default on r6 and r7:

[edit] lab@r6# run show route 3.3.3.3 inet.0: 20 destinations, 21 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0           *[IS-IS/15] 02:14:46, metric 10, tag 1                     > to 10.0.8.6 via fe-0/1/0.0                      [OSPF/150] 00:15:57, metric 10, tag 1                     > to 172.16.40.3 via fe-0/1/3.0

These results indicate that, as predicted, the default route preference settings for IS-IS and OSPF internal/external routes result in the routers just “doing the right thing” in that no loops have been created by the mutual route redistribution actions of r6 and r7. The last step is to confirm that r5 sees two equal-cost next hops for the redistributed 192.168.x/24 OSPF routes, which verifies that both r6 and r7 are correctly exporting the OSPF routes into IS-IS:

[edit] lab@r5# run show route 192.168.0/24 inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24      *[IS-IS/160] 00:06:11, metric 10, 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:07:21, metric 11, tag 1                       > to 10.0.8.5 via fe-0/0/0.0                         to 10.0.8.10 via fe-0/0/1.0

All indications point to a properly functioning, loop-free network, which will provide both optimal routing and the required redundancy. A few quick traceroutes provide the final confirmation that you have met the requirements of the route redistribution example:

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.2 (172.16.40.2) 0.189 ms 0.123 ms 0.094 ms  2 10.0.8.6 (10.0.8.6) 0.329 ms 0.288 ms 0.279 ms  3 10.0.2.2 (10.0.2.2) 1.029 ms 1.204 ms 0.876 ms  4 10.0.4.2 (10.0.4.2) 0.323 ms 0.677 ms 0.372 ms  5 10.0.5.1 (10.0.5.1) 0.924 ms 1.186 ms 0.874 ms 

The OSPF router has the required connectivity through r6, so we quickly test that r7 can also correctly forward should it be chosen by the OSPF router as the forwarding next hop the next time a load-balancing hash is performed:

lab@r7> 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.9 (10.0.8.9) 0.326 ms 0.242 ms 0.216 ms  2 10.0.2.2 (10.0.2.2) 0.839 ms 0.657 ms 0.880 ms  3 10.0.4.2 (10.0.4.2) 0.499 ms 0.653 ms 0.379 ms  4 10.0.5.1 (10.0.5.1) 0.759 ms 0.697 ms 0.866 ms

The traceroutes produce the expected results, which brings this configuration example to a close. You will not need to source traffic from the 10.0.5/24 subnet when testing connectivity to the OSPF router from either r1 or r2 because this example provides a default route to the OSPF router, which affords it connectivity to the whole IS-IS routing domain.

Congratulations!