Stub and Not-So-Stubby Areas

The performance and scalability of link-state routing protocols like OSPF are to a large degree determined by the volume and frequency of LSA flooding, because these factors impact the size of a router’s LSDB and number of times it must perform SPF calculations as a result of network changes. In many cases, the majority of information flooded throughout an OSPF routing domain, and thereby contained in the OSPF LSDB, will relate to AS external routes, which are routes that have been redistributed into OSPF from another protocol such as RIP, direct, or BGP. Stub and not-so-stubby areas (NSSA) were developed to eliminate the need to carry AS external routing information in non-transit areas.

Stub Areas

A stub area does not allow the flooding of AS external routing information into that area from the backbone, or out of that area into the backbone. The result is that LSA types 5 and 7 will not be present in a stub area. ASBR-summary LSAs (type 4s) are not generated to a stub area, as the lack of type 5 external LSAs makes the need to know the route to the originating ASBR a non-issue.

Routers within a stub area rely on default routes, originated by the area’s ABRs, to reach AS external destinations. Internal routers in a stub area simply choose the metrically closest ABR for the forwarding of packets destined for delivery to external addresses.

Note 

Juniper Networks routers do not automatically generate a default route when operating as an ABR attached to a stub or not-so-stubby area. With JUNOS software, you must configure a default metric before a default route will be advertised!

Network summary LSAs (type 3s) are generated by ABRs to summarize their SPF cost to destinations within their attached areas. Other routers compute their SPF cost to each ABR, and then add (as in distance vector routing!) the metric received in summary LSAs to compute the shortest path to inter-area destinations. Summary LSAs are advertised into a stub area by default, but can be restricted with the no-summaries option. The contents of the summary LSAs allow internal routers in a stub area to compute shortest paths to destinations in other areas (inter-area) so that packets are forwarded to the ABR that lies along the shortest path to that destination.

Totally Stubby Areas

A stub area that has been configured to block summary LSAs is often referred to as a Totally Stubby Area because internal routers will now have to rely on the default route received from the metrically closest ABR to reach both inter-area and AS external destinations. The behavior of a TSA is very similar to that of an IS-IS level 1 area, in that both require default routing to reach destinations outside of that router’s area. As mentioned earlier, you can create a TSA in JUNOS software by including the no-summaries option as part of the stub area’s definition. If desired, you can prevent routing to destinations outside of a stub area by omitting the default-metric statement, thus preventing the generation of the default route into that stub area.

Tip 

By their very nature, Totally Stubby Areas are black holes looking for a place to happen. You should always be on guard when configuring a TSA because achieving connectivity to inter-area destinations from within a TSA can be tricky, and the loss of inter-area connectivity could be overlooked in the heat of battle— resulting in major problems in your network’s operation down the road.

Stub Area Deployment

In the next section you will configure a stub area comprising routers r1, r2, r3, and r4, as shown in Figure 3.5.

Figure 3.5: OSPF stub areas

To better demonstrate the stub area concept, and to make things a bit more interesting, r7 will first be made into an ASBR so that AS external flooding behavior can be observed.

The criteria for this configuration task are as follows:

• Advertise the prefix 200.0.0/24 as an AS external from r7.

• r1 and r2 are internal area 10 routers.

• No type 5 LSAs are allowed in area 10.

• Loopback addresses of all routers must be reachable from area 10.

• No static routes permitted in area 10.

External LSA Generation

The first set of commands creates a static route on r7 and the policy needed to redistribute the route into another routing protocol:

[edit routing-options] lab@r7# set static route 200.0.0/24 reject [edit routing-options] lab@r7# top 

The static route redistribution policy is now created:

[edit] lab@r7# edit policy-options policy-statement stat [edit policy-options policy-statement stat] lab@r7# set term 1 from protocol static [edit policy-options policy-statement stat] lab@r7# set term 1 from route-filter 200.0.0/24 exact [edit policy-options policy-statement stat] lab@r7# set term 1 then accept [edit policy-options policy-statement stat] lab@r7# set term 2 then reject 

You next apply the stat policy to the OSPF protocol as an export policy:

[edit protocols] lab@r7# set protocols ospf export stat 

The static route to 200.0.0/24 points to reject in this example, so that traceroutes to this address will complete with a “destination unreachable” message. The 200.0.0/24 route is used here strictly for purposes of external LSA generation, so using a discard next hop would result in time-outs when performing ping or traceroute testing to addresses that are encompassed by this prefix. The stat policy, as applied to the OSPF routing protocol, tells r7 to redistribute into OSPF all active routes that match the 200.0.0.0/24 exact route filter statement. The use of a discriminating route filter is used here to prevent the inadvertent redistribution of other static routes, such as the one associated with your fxp0 OoB network (in the event that you neglected to add the no-advertise tag when it was defined).

External LSA Verification

After committing the change on r7, we confirm all is well by verifying the presence of the resulting type 5 and type 4 LSAs in r5’s LSDB:

[edit] lab@r5# run show ospf database extern      OSPF external link state database  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len Extern   200.0.0.0        10.0.9.7         0x80000002     25  0x2  0xea04  36 [edit] lab@r5#  run show ospf database asbrsummary      OSPF link state database, area 0.0.0.0  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len ASBRSum *10.0.9.7         10.0.3.5         0x80000001     38  0x2  0xad81  28      OSPF link state database, area 0.0.0.1

Perfect. We see the external LSA advertising the route to 200.0.0.0/24 is being generated by r7, which is now an ASBR, and we also see the ASBR-summary LSA (LSA type 4) as generated by r5, the ABR, which is used to advertise reachability information for ASBRs in area 1.

Tip 

Because previously generated LSAs can remain in the LSDB for up to one hour (3600 seconds), it is often helpful to purge the OSPF LSDB to prevent confusion due to the presence of LSAs that should no longer be in the database. The purge switch to the clear ospf database command causes the router to reflood all the LSAs in its LSDB with an indication that their lifetime has reached 3600 seconds. This causes all routers in the OSPF domain to regenerate the LSAs that they consider valid, which in turn results in a clean and tidy LSDB that will greatly enhance your viewing pleasure.

Stub Area Configuration

The following commands correctly configure area 10 as a stub area, beginning with the configuration changes required on r3.

 [edit protocols ospf] lab@r3# set area 10 stub default-metric 10 [edit protocols ospf] lab@r3# set area 10 interface fe-0/0/0.200 [edit protocols ospf] lab@r3# set area 10 interface fe-0/0/1 

These commands correctly configure area 10 as a stub area on r3, and instruct r3 (the ABR) to generate a default route with a metric of 10 into the stub area. The presence of this default route will enable packet forwarding from the stub area to external destinations. The OSPF configuration for r3 is shown next with stub area–related entries highlighted:

[edit protocols ospf] lab@r3# show area 0.0.0.0 {     authentication-type md5; # SECRET-DATA     interface fe-0/0/2.0 {          passive;          authentication-key "$9$I3jhyKsYoJGi" key-id 10; # SECRET-DATA      }     interface lo0.0 {          passive;      }      interface at-0/1/0.35 {         authentication-key "$9$a1GjqCA0BIc" key-id 10; # SECRET-DATA      }     interface so-0/2/0.100 {          authentication-key "$9$hOuyeWg4ZUjq" key-id 10; # SECRET-DATA      } } area 0.0.0.10 {      stub default-metric 10;      interface fe-0/0/0.200;     interface fe-0/0/1.0; } 

r4’s stub area configuration is virtually identical to that performed on r3, because the only differences are those that relate to interface particulars. Though not shown, it is assumed that you have completed and committed the stub area configuration on r4 based on the example shown previously for r3.

The following commands are entered on r1 to correctly configure stub area 10:

[edit protocols ospf] lab@r1# set area 10 stub [edit protocols ospf] lab@r1# set area 10 interface fe-0/0/1.200 [edit protocols ospf] lab@r1# set area 10 interface fe-0/0/2 

There is no need for the default-metric option on r1, as this knob applies only to an ABR. The resulting configuration for r1 is shown next. It should be noted that we have correctly specified the logical interface for the r1-to-r3 Fast Ethernet link, which is using VLAN tagging and logical unit 200:

[edit protocols ospf] lab@r1# show area 0.0.0.10 {    stub;    interface fe-0/0/1.200;    interface fe-0/0/2.0;  }

The configuration of stub area 10 on r2 is shown next, and is very similar to that of r1:

[edit protocols ospf] lab@r2# show area 0.0.0.10 {    stub;    interface fe-0/0/1.0;    interface fe-0/0/2.0;    interface fe-0/0/3.0;  }

Stub Area Verification

Common OSPF operational mode commands will now be used to verify that the requirements of the stub area configuration example have been met. We start by confirming the adjacency status of r1:

 [edit protocols ospf] lab@r1# run show ospf neighbor   Address         Interface             State      ID              Pri  Dead 10.0.4.13        fe-0/0/1.200          Full      10.0.3.3         128    35 10.0.4.6         fe-0/0/2.0            Full      10.0.6.2         128    39

The adjacency between r1 and r3 confirm that they agree on the area number and the area type (stub areas set the "E" bit in the OSPF header’s options field), which is a good sign. Now to confirm that external LSAs are not being flooded into area 10, we issue the following command:

[edit protocols ospf] lab@r1# run show ospf database extern [edit protocols ospf] lab@r1#

As per the requirements of the OSPF stub area configuration example, r7’s type 5 LSA is not present in the LSDB of routers in area 10. The following actions will confirm the presence of the default route, and the resulting ability to reach external destinations:

lab@r1> show route protocol ospf | match 0.0.0.0 0.0.0.0/0          *[OSPF/10] 00:08:27, metric 11 

The default route is present, and shows the expected metric of 11, which represents the costs of the r1-r3 link (1) added to the advertised cost of the default route (10). The next command confirms that r1 does not have a route to any prefix that starts with 200/8, which is expected because of the lack of type 5 flooding into a stub area.

lab@r1> show route protocol ospf 200/8 

As expected, no matching routes are returned by r1. We now confirm that external destinations are reachable from within the stub area:

lab@r1> traceroute 200.0.0.1 traceroute to 200.0.0.1 (200.0.0.1), 30 hops max, 40 byte  packets  1 10.0.4.13 (10.0.4.13) 0.351 ms 0.243 ms 0.221 ms  2 10.0.2.1 (10.0.2.1) 0.675 ms 0.664 ms 0.875 ms  3 10.0.8.10 (10.0.8.10) 0.857 ms 0.700 ms 0.876 ms  4 10.0.8.10 (10.0.8.10) 0.858 ms !H 0.700 ms !H 0.862 ms !H 

The traceroute succeeds, ironically by virtue of it terminating with an indication that the destination is unreachable (the “!H")! This is the expected result, and the reason why the static routes used in this example have their next hops set to reject instead of discard. Refer to the "External LSA Generation" section earlier in this chapter for more information on the use of reject vs. discard next hops. These results prove that routers in stub area 10 can use the default route to reach external destinations. Because summary LSAs are permitted in area 10, r1 and r2 should have complete inter-area routing for your OSPF network. This is confirmed with the following commands:

lab@r1> show ospf database netsummary     OSPF link state database, area 0.0.0.10  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len Summary  0.0.0.0          10.0.3.3         0x80000006    372  0x0  0x62dd  28 Summary  0.0.0.0          10.0.3.4         0x80000005    481  0x0  0x5ee1  28 Summary  10.0.2.0         10.0.3.3         0x80000008     58  0x0  0x59e4  28 Summary  10.0.2.0         10.0.3.4         0x80000005    346  0x0  0x63db  28 . . . . Summary  10.0.9.7         10.0.3.4         0x80000003    913  0x0  0xe54a  28 Summary  172.16.0.12      10.0.3.3         0x80000005    818  0x0  0xd1ae  28 Summary  172.16.0.12      10.0.3.4         0x80000003    913  0x0  0xd9a6  28

This (edited) output confirms that numerous network summary LSAs (type 3s) are present in r1’s LSDB. To quickly verify that inter- and intra-area routes are present, we confirm that OSPF routes exist for all loopback addresses:

lab@r1> show route protocol ospf | match /32 10.0.3.3/32 *[OSPF/10] 00:17:02, metric 1 10.0.3.4/32 *[OSPF/10] 00:17:02, metric 2 10.0.3.5/32 *[OSPF/10] 00:17:02, metric 2 10.0.6.2/32 *[OSPF/10] 00:17:02, metric 1 10.0.9.6/32 *[OSPF/10] 00:17:02, metric 3 10.0.9.7/32 *[OSPF/10] 00:17:02, metric 3 224.0.0.5/32 *[OSPF/10] 00:53:23, metric 1

With seven routers in the test bed, we expect to see OSPF routes to six remote router loop- back addresses. Because r1’s loopback address was not learned through OSPF, its absence in the previous display is also as expected. These results confirm that all aspects of the stub area configuration example have been met.

Totally Stubby Areas

Now that area 10’s stub behavior has been confirmed, your new goal is to convert area 10 into a totally stubby area that meets the following criteria:

• r1 and r2 are internal area 10 routers.

• No type 5 or type 3 LSAs in area 10.

• Loopback addresses of all routers reachable from area 10.

• No static routes in area 10.

Based on the specified criteria and our existing configurations, it should be apparent that to meet the new criteria, all we must do is eliminate the type 3 LSAs that differentiate a stub area from a totally stubby area. The following command, issued on area 1’s ABRs only, does the trick:

[edit protocols ospf area 0.0.0.10] lab@r4# set stub no-summaries 

Knowing all the OSPF LSA numbers and types, which routers generate them, and how they are used, is crucial for lab-based examinations. For example, you may be given a requirement with wording to the effect of “block LSA type 3’s.” Not knowing that a type 3 LSA is a network summary will make an otherwise simple configuration requirement seem much more difficult. The no-summaries option will likely not jump out at you when you are looking for something that references a type 3 LSA.

After committing this change on r3 and r4, the conversion of area 10 from a stub area to a totally stubby area should be complete.

Verify Totally Stubby Area Operation

To confirm that all requirements for this example have been met, we simply need to verify that summary LSAs are no longer contained in area 10’s LSDB, and that we still have inter-area connectivity through the default route generated by the ABRs:

lab@r1> show ospf database netsummary     OSPF link state database, area 0.0.0.10  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len Summary  0.0.0.0          10.0.3.3         0x80000007    265  0x0  0x60de  28 Summary  0.0.0.0          10.0.3.4         0x80000006    279  0x0  0x5ce2  28

As hoped for, the only summaries that are present in area 10 are those being used to describe the default routes that are being introduced by area 10’s ABRs (r3 and r4). The next command verifies that inter-area routes are no longer present in the totally stubby area:

lab@r1> show route protocol ospf | match /32 10.0.6.2/32 *[OSPF/10] 00:38:16, metric 1 224.0.0.5/32 *[OSPF/10] 01:14:37, metric 1

We see that the lack of summaries has caused the disappearance of all inter-area routes. We now trace a route to both external and inter-area destinations to confirm that the connectivity requirements have been met:

lab@r1> traceroute 200.0.0.1 traceroute to 200.0.0.1 (200.0.0.1), 30 hops max, 40 byte packets  1 10.0.4.13 (10.0.4.13) 0.359 ms 0.246 ms 0.219 ms  2 10.0.2.1 (10.0.2.1) 0.649 ms 0.654 ms 0.875 ms  3 10.0.8.10 (10.0.8.10) 0.856 ms 0.709 ms 0.872 ms  4 10.0.8.10 (10.0.8.10) 0.861 ms !H 0.701 ms !H 0.872 ms !H 

The trace to the external prefix works, so connectivity to inter-area destinations is now confirmed by tracing the route to the loopback address of r6:

lab@r1> traceroute 10.0.9.6 traceroute to 10.0.9.6 (10.0.9.6), 30 hops max, 40 byte packets  1 10.0.4.13 (10.0.4.13) 0.335 ms 0.248 ms 0.222 ms  2 10.0.2.1 (10.0.2.1) 0.942 ms 0.673 ms 0.872 ms  3 10.0.9.6 (10.0.9.6) 0.857 ms 0.696 ms 0.874 ms

These results confirm the proper operation of area 10 as a totally stubby area.

Not-So-Stubby Areas (NSSA)

A stub area does not receive external routing information from the backbone, which is great for the reduction of LSDB size, but this restriction on type 5 LSAs cuts both ways, because a stub area cannot introduce external routing into the backbone either. A not-so-stubby area (NSSA) addresses this issue by defining a new LSA type (type 7) that allows an NSSA to support the presence of ASBRs and their corresponding external routing information. By default, type 7 external LSAs are converted by the NSSA’s ABRs into conventional type 5 LSAs for flooding throughout the routing domain. The translation of type 7 LSAs to type 5 LSAs can be controlled at the ABR using area range statements with the restrict keyword.

As with stub areas, an NSSA is identified through a special setting in the OSPF options field (the N bit) with the intent being the assurance that all routers in a NSSA agree on the area’s type; adjacencies will not form if two routers disagree as to the area’s type. JUNOS software allows the filtering of network summary LSAs (LSA type 3s) into a NSSA, despite the wording of RFC 1587 that indicates network summary LSAs must be imported into a NSSA to ensure that OSPF internal routes will always be chosen over AS external routes. While no official name exists for such a beast, this author feels it is valid to refer to a NSSA that is configured to filter network summaries as a Totally Not-So-Stubby Area (TNSSA).

Not-So-Stubby Area Configuration

To demonstrate NSSA configuration and operation, area 10 will be converted into an NSSA that must comply with the following criteria:

• No type 5 or type 3 LSAs in area 10.

• Define and redistribute static route 3/8 into OSPF from r1 using a metric of 10. You must ensure that all routers adjust this metric to reflect their OSPF cost to reach r1.

• Inter-area and external prefixes must be reachable from area 10.

• No other static routes are permitted in area 10.

The following commands get things started on r1 by defining the static route and the policy needed to correctly redistribute it into OSPF with type 1 external metric:

[edit routing-options] lab@r1# set static route 3/8 reject [edit] lab@r1# edit policy-options policy-statement r1-stat [edit policy-options policy-statement r1-stat] lab@r1# set term 1 from protocol static [edit policy-options policy-statement r1-stat] lab@r1# set term 1 from route-filter 3/8 exact [edit policy-options policy-statement r1-stat] lab@r1# set term 1 then metric 10 [edit policy-options policy-statement r1-stat] lab@r1# set term 1 then external type 1 

By setting the external metric to a type 1, you ensure that each router will increase the metric based on its cost to the advertising ASBR. By default, routes redistributed into OSPF use a type 2 metric, which does not increase based on the OSPF cost to the originating ASBR. A working policy is shown next:

[edit] lab@r1# show policy-options policy-statement r1-stat {     term 1 {          from {             protocol static;             route-filter 3.0.0.0/8 exact;         }          then {              metric 10;              external {                 type 1;             }             accept;         }     } }

The policy is then applied to r1’s main OSPF instance as export:

[edit] lab@r1# set protocols ospf export r1-stat 

The following commands convert area 10 from a stub area to a NSSA. The commands shown next for r1 also need to be entered and committed on r2:

[edit protocols ospf area 0.0.0.10] lab@r1# set nssa 

Wow, that seemed too easy! The modified OSPF configuration for r1 is as follows with the NSSA-related changes highlighted:

[edit protocols ospf area 0.0.0.10] lab@r1# show nssa; interface fe-0/0/2.0; interface fe-0/0/1.200;

After committing the changes on r1, the loss of all adjacencies is expected due to the area type mismatch. This condition will persist until all routers in area 10 have been reconfigured to view the area as a NSSA.

[edit protocols ospf area 0.0.0.10] lab@r1# commit commit complete [edit protocols ospf area 0.0.0.10] lab@r1# run show ospf neighbor 

The following commands, entered on both r3 and r4, correctly configure the NSSA’s ABRs:

[edit protocols ospf area 0.0.0.10] lab@r4# set nssa no-summaries default-lsa type-7 metric-type 2 [edit protocols ospf area 0.0.0.10] lab@r4# set nssa default-lsa default-metric 10 

The modified NSSA ABR configuration is shown next with highlights:

edit protocols ospf area 0.0.0.10] lab@r4# show nssa {   default-lsa {     default-metric 10;     metric-type 2;     type-7;   }   no-summaries;  }  interface fe-0/0/1.0; 

Once again, a default-metric setting is required to trigger the generation of the default route needed for routing to external (and in this example, inter-area) destinations. Normally, the default route injected into a NSSA will be a type 3 (network-summary), so configuration of a type 7–based default route and the inclusion of the no-summaries statement are needed to comply with the "no type 3 LSA" restriction of this configuration example. The external metric type for the default route is not specified in the configuration criteria, and so is left to the exam candidate’s discretion. In this example, a type 2 metric (the default) has been explicitly configured.

NSSA Verification

The same set of commands used to verify stub area operation will now be applied to the NSSA. We start by confirming there are no type 5 or type 3 LSAs in area 10:

lab@r1> show ospf database netsummary    OSPF link state database, area 0.0.0.10 lab@r1> show ospf database extern lab@r1>

Assuming that the external and summary LSAs are still present in the ABRs, these results confirm that we are dealing with some type of totally stubby area, as both type 5 and type 3 LSAs are being filtered at the ABRs. We now confirm the area’s type and the correct operation of r1’s OSPF export policy:

lab@r1> show ospf database nssa     OSPF link state database, area 0.0.0.10  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len NSSA     0.0.0.0          10.0.3.3          0x80000003  1276  0x0  0xc3f2  36 NSSA     0.0.0.0          10.0.3.4          0x80000003  1429  0x0  0xbdf7  36 NSSA    *3.0.0.0          10.0.6.1         0x80000001     42  0x8  0xe9b1  36 

Most excellent! The presence of type 7 LSAs confirms the area’s type as a NSSA, and the highlighted portion of this output also confirms that r1 is exporting its 3/8 static route. It can also be observed that both of the area’s ABRs are correctly sourcing a default route into the NSSA. By adding the detail switch, we can also confirm the correct metric setting and external metric type for the 3/8 route being advertised by r1, as highlighted in the following:

lab@r1> show ospf database nssa detail     OSPF link state database, area 0.0.0.10  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len NSSA     0.0.0.0          10.0.3.3          0x80000003  1504  0x0  0xc3f2  36   mask 0.0.0.0   Type 2, TOS 0x0, metric 10, fwd addr 0.0.0.0, tag 0.0.0.0 NSSA     0.0.0.0          10.0.3.4          0x80000003  1657  0x0  0xbdf7  36   mask 0.0.0.0   Type 2, TOS 0x0, metric 10, fwd addr 0.0.0.0, tag 0.0.0.0 NSSA    *3.0.0.0          10.0.6.1         0x80000001    270  0x8  0xe9b1  36   mask 255.0.0.0   Type 1, TOS 0x0, metric 10, fwd addr 10.0.6.1, tag 0.0.0.0

We now compare the metric seen in area 10 with that being calculated by routers in other areas to verify the type 1 external metric has been adjusted to reflect each router’s OSPF cost to reach r1:

lab@r6> show route 3/8 inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 3.0.0.0/8           *[OSPF/150] 00:06:33, metric 14, tag 0                       > to 10.0.8.6 via fe-0/1/0.0

The route entry for the 3/8 prefix in r6 reveals that the initial metric value of 10 has been increased by 4, which confirms that a type 1 metric has been attached to the routes as per the configuration requirements. However, you may have noticed that r6’s cost to reach route 3/8 seems a bit higher than expected, considering that the three links that separate r6 from r1 should each have an OSPF cost of 1. Because this discrepancy may indicate a configuration problem or hardware malfunction, further investigation is warranted. To determine if an interface is down, we display the route to r1’s lo0 interface as seen from r6:

lab@r6> show route 10.0.6.1 inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.6.1/32          *[OSPF/10] 00:27:34, metric 3                        > to 10.0.8.6 via fe-0/1/0.0 

Based on these results, we can conclude that all links are functional between r6 and r1, as the route metric of 3 correctly reflects the summation of the OSPF cost, which by default is 1for any link that is equal to or faster than 100Mbps for each of the three links that make up the optimal path between r6 and r1. The following sidebar explains why there is a metric discrepancy between the OSPF route to r1’s loopback address and the OSPF metric associated with the external prefix being advertised by r1. For our purposes, we can conclude that all is working as per design and move on with the task of NSSA verification.

Metric Mania

Because r6 crosses three links to reach r1, a path metric of 3 is the expected (and confirmed) value. Knowing that 10 + 3 is 13 can cause confusion when it is noted that the external route to 3/8 shows a path metric of 14. This confusion might cause some exam candidates to try chasing down what is perceived to be a problem, when in fact the network is behaving normally.

The answer to this riddle lies in the way that the ABRs in a NSSA translate type 7 LSAs into type 5 LSAs for flooding throughout the OSPF domain. Because multiple ABRs can exist in a NSSA, having each ABR translate the type 7 LSAs could produce extra flooding traffic that would result in more or less redundant LSDB entries. The NSSA specification addresses this problem by indicating that the type 7–to–type 5 translation should be performed by the ABR with the highest RID on behalf of the entire NSSA. While this approach improves protocol scalability, it comes at the potential cost of less-than-ideal routing in some topologies (such as in this case, where packets from r6 that are destined for r1 are being forced to endure an extra hop through r4) and can result in the whole NSSA being black-holed if the ABR that is performing type 7 translation should lose its connectivity to the backbone while maintaining connectivity to the NSSA. Some vendors can enable LSA translations on all NSSA ABRs (in violation of the RFC), but at this time JUNOS software does not support this behavior. The traceroute output shown here confirms that the metric at r6 is higher than expected due to the behavior described previously:

[edit] lab@r6# run traceroute 3.0.0.1 traceroute to 3.0.0.1 (3.0.0.1), 30 hops max, 40 byte  packets  1 10.0.8.6 (10.0.8.6) 0.330 ms 0.245 ms 0.215 ms  2 10.0.2.10 (10.0.2.10) 0.269 ms 0.246 ms 0.232 ms  3 10.0.4.10 (10.0.4.10) 0.180 ms 0.167 ms 0.155 ms  4 10.0.4.5 (10.0.4.5) 0.496 ms 0.694 ms 0.378 ms  5 10.0.4.5 (10.0.4.5) 0.363 ms !H 0.690 ms !H 0.376 ms !H

To test that the default route is providing connectivity to routes outside of area 10, we perform a few traceroutes to key targets such as r6’s loopback and the external route 200.0.0.0/ 24 coming from r7:

[edit] lab@r1# 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.4.13 (10.0.4.13) 0.351 ms 0.249 ms 0.222 ms  2 10.0.2.1 (10.0.2.1) 0.724 ms 1.166 ms 0.872 ms  3 10.0.9.6 (10.0.9.6) 0.859 ms 1.191 ms 0.876 ms lab@r2# run traceroute 200.0.0.1 traceroute to 200.0.0.1 (200.0.0.1), 30 hops max, 40 byte packets  1 10.0.4.1 (10.0.4.1) 0.393 ms 0.315 ms 0.234 ms  2 10.0.2.1 (10.0.2.1) 1.281 ms 0.494 ms 0.359 ms  3 10.0.8.10 (10.0.8.10) 0.356 ms 0.655 ms 0.374 ms  4 10.0.8.10 (10.0.8.10) 0.360 ms !H 0.665 ms !H 0.368 ms !H

The success of these traceroutes confirms that all NSSA requirements have been achieved.