From: gigi.ccie@gmail.com
Date: Sun May 21 2006 - 13:30:02 ART
Now here is a good reference for this one.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2003.htm#wp3841
OSPF NSSA (Not-So-Stubby Area) Overview
Prior to NSSA, to disable an area from receiving external (Type 5) link-state advertisements (LSAs), the area needed to be defined as a stub area. Area Border Routers (ABRs) that connect stub areas do not flood any external routes they receive into the stub areas. To return packets to destinations outside of the stub area, a default route through the ABR is used.
RFC 1587 defines a hybrid area called the Not-So-Stubby Area (NSSA). An OSPF NSSA is similar to an OSPF stub area but allows for the following capabilities:
Importing (redistribution) of external routes as Type 7 LSAs into NSSAs by NSSA Autonomous System Boundary Routers (ASBRs).
Translation of specific Type 7 LSAs routes into Type 5 LSAs by NSSA ABRs.
Using OSPF NSSA
Use OSPF NSSA in the following scenarios:
When you want to summarize or filter Type 5 LSAs before they are forwarded into an OSPF area. The OSPF Specification (RFC 1583) prohibits the summarizing or filtering of Type 5 LSAs. It is an OSPF requirement that Type 5 LSAs always be flooding throughout a routing domain. When you define an NSSA, you can import specific external routes as Type 7 LSAs into the NSSA. In addition, when translating Type 7 LSAs to be imported into nonstub areas, you can summarize or filter the LSAs before importing them as Type 5 LSAs.
If you are an Internet service provider (ISP) or a network administrator that has to connect a central site using OSPF to a remote site that is using a different protocol, such as RIP or EIGRP, you can use NSSA to simplify the administration of this kind of topology. Prior to NSSA, the connection between the corporate site ABR and the remote router used RIP or EIGRP. This meant maintaining two routing protocols. Now, with NSSA, you can extend OSPF to cover the remote connection by defining the area between the corporate router and the remote router as an NSSA, as shown in . You cannot expand the normal OSPF area to the remote site because the Type 5 external will overwhelm both the slow link and the remote router.
In , the central site and branch office are interconnected through a slow WAN link. The branch office is not using OSPF, but the central site is. Rather than define an RIP domain to connect the sites, you can define an NSSA.
In this scenario, Router A is defined as an ASBR (autonomous system border router). It is configured to redistribute any routes within the RIP/EIGRP domain to the NSSA. The following lists what happens when the area between the connecting routers is defined as an NSSA:
1 Router A receives RIP or EGRP routes for networks 10.10.0.0/16, 10.11.0.0/16, and 20.0.0.0/8.
2 Because Router A is also connected to an NSSA, it redistributes the RIP or EIGRP routers as Type 7 LSAs into the NSSA.
3 Router B, an ABR between the NSSA and the backbone Area 0, receives the Type 7 LSAs.
4 After the SPF calculation on the forwarding database, Router B translates the Type 7 LSAs into Type 5 LSAs and then floods them throughout Backbone Area 0. It is at this point that router B could have summarized routes 10.10.0.0/16 and 10.11.0.0/16 as 10.0.0.0/8, or could have filtered one or more of the routes.
Type 7 LSA Characteristics
Type 7 LSAs have the following characteristics:
They are originated only by ASBRs that are connected between the NSSA and autonomous system domain.
They include a forwarding address field. This field is retained when a Type 7 LSA is translated as a Type 5 LSA.
They are advertised only within an NSSA.
They are not flooded beyond an NSSA. The ABR that connects to another nonstub area reconverts the Type 7 LSA into a Type 5 LSA before flooding it.
NSSA ABRs can be configured to summarize or filter Type 7 LSAs into Type 5 LSAs.
NSSA ABRs can advertise a Type 7 default route into the NSSA.
Type 7 LSAs have a lower priority than Type 5 LSAs, so when a route is learned with a Type 5 LSA and Type 7 LSA, the route defined in the Type 5 LSA will be selected first.
Configuring OSPF NSSA
The steps used to configure OSPF NSSA are as follows:
--------------------------------------------------------------------------------
Step 1 Configure standard OSPF operation on one or more interfaces that will be attached to NSSAs.
Step 2 Configure an area as NSSA using the following commands:
router(config)#area area-id nssa
Step 3 (Optional) Control the summarization or filtering during the translation. shows how Router will summarize routes using the following command:
router(config)#summary-address prefix mask [not-advertise] [tag tag]
NSSA Implementation Considerations
Be sure to evaluate these considerations before implementing NSSA. As shown in , you can set a Type 7 default route that can be used to reach external destinations. The command to issue a Type 7 default route is as follows:
router(config)#area area-id nssa [default-information-originate]
When configured, the router generates a Type 7 default into the NSSA by the NSSA ABR. Every router within the same area must agree that the area is NSSA; otherwise, the routers will not be able to communicate with one another.
If possible, avoid doing explicit redistribution on NSSA ABR because you could get confused about which packets are being translated by which router.
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:22 ART