[Contents] [Prev] [Next] [Index] [Report an Error]


Examine Type 7 NSSA External LSA

Action

To examine a Type 7 NSSA external LSA, enter the following CLI operational mode command:

user@host> show ospf database nssa extensive

Sample Output

user@R1> show ospf database nssa extensive 

    OSPF link state database, area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
[...Output truncated...]
NSSA    *10.0.0.100       10.0.0.1         0x8000003b   843  0x8  0xa566  36
  mask 255.255.255.255
  Type 2, TOS 0x0, metric 0, fwd addr 10.0.0.1, tag 0.0.0.0
  Gen timer 00:35:56
  Aging timer 00:45:56
  Installed 00:14:03 ago, expires in 00:45:57, sent 00:14:01 ago
  Ours

What It Means

The sample output shows that the LSA belongs to a single NSSA, 0.0.0.1, and was generated by R1. This router has a metric value of 0, which is the default, and is listed as a Type 2 external metric. Any local router must use the default metric as the total cost for the route when performing an SPF calculation. The default metric of the route must be added to the cost to reach the advertising ASBR. This value then represents the total cost for the route.

In general, each ASBR within the NSSA generates a Type 7 LSA to advertise any routers external to the OSPF AS. This LSA is flooded to each router within the NSSA (R2). Because the LSA has only an area flooding scope, it is not sent into other adjacent areas. For each Type 7 LSA received, the ABR (R2) translates the information into a Type 5 LSA and sends the information into the backbone. The other backbone routers do not know that the original information came from an NSSA. The Type 5 LSA is then flooded to each non-stub router in the entire AS.


[Contents] [Prev] [Next] [Index] [Report an Error]