Identifies area 1 as the area containing the range of networks to be summarized. The networks will be summarized into area 0. The ABR R1 summarizes the range of subnets from 172.16.32.0 to 172.16.63.0 into one range: 172.16.32.0 255.255.224.0.
Configuring External OSPF Route Summarization on an ASBR
By default, each external route, redistributed into OSPF from other protocols, is advertised individually with an external LSA. Summarization of external routes can be done on an ASBR for type 5 LSAs (redistributed routes) before injecting them into the OSPF domain. A summary route to null 0 is automatically created for each summary range.
To configure manual route summarization on an ASBR to summarize external routes, use the following procedure:
Table 3-19: summary-address Command Parameters
Open table as spreadsheet | Parameter | Description |
| ip-address | The summary address designated for a range of addresses |
| mask | The IP subnet mask used for the summary route |
| not-advertise | (Optional) Used to suppress routes that match the address/mask pair |
| tag tag | (Optional) A tag value that can be used as a “match” value to control redistribution via route maps |
| Note | In an NSSA area, the ABR can summarize external routes when it creates a type 5 summary LSA from a type 7 LSA representing the external route. NSSA areas are described in the upcoming “Configuring NSSAs” section. |
OSPF Virtual Links
OSPF’s two-tiered area hierarchy requires that if more than one area is configured, one of the areas must be area 0, the backbone area. All other areas must be directly connected to area 0, and area 0 must be contiguous. OSPF expects all nonbackbone areas to inject routes into the backbone, so that the routes can be distributed to other areas.
A virtual link is a link that allows discontiguous area 0s to be connected, or a disconnected area to be connected to area 0, via a transit area. The OSPF virtual link feature should be used only in very specific cases, for temporary connections or for backup after a failure. Virtual links should not be used as a primary backbone design feature.
Virtual links are part of the OSPF open standard and have been a part of Cisco IOS Software since software release 10.0.
The virtual link relies on the stability of the underlying intra-area routing. Virtual links cannot go through more than one area, nor through stub areas. Virtual links can only run through standard nonbackbone areas. If a virtual link needs to be attached to the backbone across two nonbackbone areas, then two virtual links are required, one per area.
In Figure 3-41, two companies running OSPF have merged and a direct link does not yet exist between their backbone areas. The resulting area 0 is discontiguous. A logical link (virtual link) is built between the two ABRs, routers A and B, across area 1, a nonbackbone area. The routers at each end of the virtual link become part of the backbone and act as ABRs. This virtual link is similar to a standard OSPF adjacency, except that in a virtual link, neighboring routers do not have to be directly attached.
Figure 3-42 illustrates another example where a nonbackbone area is added to an OSPF network, and a direct physical connection to the existing OSPF area 0 does not yet exist. In this case, area 20 is added, and a virtual link across area 10 is created to provide a logical path between area 20 and the backbone area 0. The OSPF database treats the virtual link between ABR1 and ABR2 as a direct link. For greater stability, loopback interfaces are used as router IDs, and virtual links are created using these loopback addresses.
The Hello protocol works over virtual links as it does over standard links, in 10-second intervals. However, LSA updates work differently on virtual links. An LSA usually refreshes every 30 minutes. However, LSAs learned through a virtual link have the DoNotAge (DNA) option set, so that the LSA does not age out. This DNA technique is required to prevent excessive flooding over the virtual link.
Configuring OSPF Virtual Links
Use the area area-id virtual-link router-id [authentication [message-digest | null]] [hello-interval seconds] [retransmit-interval seconds] [transmit-delay seconds] [dead-interval seconds] [[authentication-key key] | [message-digest-key key-id md5 key]] router configuration command to define an OSPF virtual link. To remove a virtual link, use the no form of this command.
Table 3-20 describes the options available with the area area-id virtual-link command. Make sure you understand the effect of these options before changing them. For instance, the smaller the hello interval, the faster the detection of topological changes, but the more routing traffic. You should be conservative with the setting of the retransmit interval, or the result is needless retransmissions. The value should be larger for serial lines and virtual links. The transmit delay value should take into account the interface’s transmission and propagation delays.
Table 3-20: area area-id virtual-link Command Parameters
Open table as spreadsheet | Parameter | Description |
| area-id | Specifies the area ID of the transit area for the virtual link. This ID can be either a decimal value or in dotted-decimal format, like a valid IP address. There is no default. The transit area cannot be a stub area. |
| router-id | Specifies the router ID of the virtual link neighbor. The router ID appears in the show ip ospf display. This value is in an IP address format. There is no default. |
| authentication | (Optional) Specifies an authentication type. |
| message-digest | (Optional) Specifies the use of MD5 authentication. |
| null | (Optional) Overrides simple password or MD5 authentication if configured for the area. No authentication is used. |
| hello-interval seconds | (Optional) Specifies the time (in seconds) between the hello packets that the Cisco IOS Software sends on an interface. The unsigned integer value is advertised in the hello packets. The value must be the same for all routers and access servers attached to a common network. The default is 10 seconds. |
| retransmit-interval seconds | (Optional) Specifies the time (in seconds) between LSA retransmissions for adjacencies belonging to the interface. The value must be greater than the expected round-trip delay between any two routers on the attached network. The default is 5 seconds. |
| transmit-delay seconds | (Optional) Specifies the estimated time (in seconds) to send an LSU packet on the interface. This integer value must be greater than 0. LSAs in the update packet have their age incremented by this amount before transmission. The default value is 1 second. |
| dead-interval seconds | (Optional) Specifies the time (in seconds) that must pass without hello packets being seen before a neighboring router declares the router down. This is an unsigned integer value. The default is four times the default hello interval, or 40 seconds. As with the hello interval, this value must be the same for all routers and access servers attached to a common network. |
| authentication-key key | (Optional) Specifies the password used by neighboring routers for simple password authentication. It is any continuous string of up to 8 characters. There is no default value. |
| message-digest-key key-id md5 key | (Optional) Identifies the key ID and key (password) used between this router and neighboring routers for MD5 authentication. There is no default value. |
| Note | OSPF authentication, including details of the key and key-id parameters, is described further in the “Configuring OSPF Authentication” section, later in this chapter. |
The virtual link configuration must be done on the routers at each end of the virtual link. The area area-id virtual-link command requires the router ID of the far-end router. To find the router ID of the far-end router, use the show ip ospf command, show ip ospf interface command, or show ip protocols command on that remote router. Example 3-26 illustrates the output of the show ip ospf command, displaying the OSPF router ID.
Example 3-26: Finding the OSPF Router ID for Use on a Virtual Link
remoterouter#show ip ospf
Routing Process "ospf 1000" with ID 10.2.2.2
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an area border router
In the example in Figure 3-43, area 0 is discontiguous. A virtual link is used as a backup strategy to temporarily connect area 0. Area 1 is used as the transit area. Router A builds a virtual link to Router B, and Router B builds a virtual link to the Router A. Each router points at the other router’s router ID.
Verifying OSPF Virtual Link Operation
The show ip ospf virtual-links command is used to verify OSPF virtual link operation. Example 3-27 provides the output of the show ip ospf virtual-links command on Router A in the example in Figure 3-43, verifying that the configured link works properly. In this example, the virtual link to Router B (with ID 10.2.2.2) is up. The virtual link uses transit area 1.
Example 3-27: show ip ospf virtual-links Command Output from Router A in Figure 3-43
RouterA#show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 10.2.2.2 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 1, via interface Serial0/0/1, Cost of using 781
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Adjacency State FULL (Hello suppressed)
Index 1/2, retransmission queue length 0, number of retransmission 1
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
RouterA#
Table 3-21 describes some of the field of the output of the show ip ospf virtual-links command in detail.
Table 3-21: show ip ospf virtual-links Command Fields
Open table as spreadsheet | Field | Description |
| Virtual Link OSPF_VL0 to router 10.2.2.2 is up | Specifies the OSPF neighbor and whether the link to that neighbor is up or down |
| Transit area 1 | Specifies the transit area through which the virtual link is formed |
| Via interface Serial0/0/1 | Specifies the interface through which the virtual link is formed |
| Cost of using 781 | Specifies the cost of reaching the OSPF neighbor through the virtual link |
| Transmit Delay is 1 sec | Specifies the transmit delay on the virtual link |
| State POINT_TO_POINT | Specifies the state of the OSPF neighbor |
| Timer intervals configured | Specifies the various timer intervals configured for the link |
| Hello due in 0:00:07 | Specifies when the next hello is expected from the neighbor |
| Adjacency State FULL | Specifies the adjacency state between the neighbors |
Routers across a virtual link become adjacent and exchange LSAs via the virtual link, similar to the process over a physical link.
Other commands that are useful when troubleshooting virtual links are show ip ospf neighbor, show ip ospf database, and debug ip ospf adj.
Example output from the show ip ospf neighbor command is provided in Example 3-28. Router A is in FULL state with Router B (with ID 10.2.2.2) on the virtual link.
Example 3-28: show ip ospf neighbor Command Output from Router A in Figure 3-43
RouterA#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.200.200.13 1 FULL/DR 00:00:33 10.1.1.3 FastEthernet0/0
10.2.2.2 0 FULL/ - - 172.16.1.2 OSPF_VL0
10.2.2.2 0 FULL/ - 00:00:32 172.16.1.2 Serial0/0/1
RouterA#
Example output from the show ip ospf database command for router 10.2.2.2 is shown in Example 3-29. The LSAs learned through the virtual link have the DoNotAge option set.
Example 3-29: show ip ospf database Command Output from Router A in Figure 3-43
RouterA#show ip ospf database router 10.2.2.2
OSPF Router with ID (10.1.1.1) (Process ID 1000)
Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 1 (DoNotAge)
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.2.2.2
Advertising Router: 10.2.2.2
LS Seq Number: 80000003
Checksum: 0x8380
Length: 48
Area Border Router
Number of Links: 2
Link connected to: a Virtual Link
(Link ID) Neighboring Router ID: 10.1.1.1
(Link Data) Router Interface address: 172.16.1.2
Number of TOS metrics: 0
TOS 0 Metrics: 781
continues
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.2.2
(Link Data) Router Interface address: 10.1.2.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Router Link States (Area 1)
Routing Bit Set on this LSA
LS age: 1688
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.2.2.2
Advertising Router: 10.2.2.2
LS Seq Number: 80000008
Checksum: 0xCC81
Length: 48
Area Border Router
Virtual Link Endpoint
Number of Links: 2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.1.1.1
(Link Data) Router Interface address: 172.16.1.2
Number of TOS metrics: 0
TOS 0 Metrics: 781
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.1.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 781
RouterA#
OSPF LSDB for Virtual Links
Figure 3-44 presents another example network. The configurations for Routers R1 and R3 are provided in Example 3-30.
Example 3-30: Configurations for Routers R1 and R3 in Figure 3-44
R1#
interface Loopback0
ip address 1.1.1.1 255.0.0.0
interface Ethernet2/0/0
ip address 172.16.0.1 255.255.0.0
interface Serial2/1/0
ip address 172.17.0.1 255.255.0.0
router ospf 2
network 172.16.0.0 0.0.255.255 area 0
network 172.17.0.0 0.0.255.255 area 1
area 1 virtual-link 3.3.3.3
R3#
interface Loopback0
ip address 3.3.3.3 255.0.0.0
interface Ethernet0/0
ip address 172.19.0.3 255.255.0.0
interface s2/0.20 point-to-point
ip address 172.18.0.3 255.255.0.0
router ospf 2
network 172.19.0.0 0.0.255.255 area 2
network 172.18.0.0 0.0.255.255 area 1
area 1 virtual-link 1.1.1.1
Example 3-31 illustrates output from the show ip ospf database command on Router R1. The router link states are type 1 LSAs and the summary net link states are type 3 LSAs, advertising routes from one are to another. Notice that LSAs learned through the virtual link have the DoNotAge (DNA) option. The virtual link is treated like a demand circuit.
Changing the Cost Metric
Recall that by default on Cisco routers, the OSPF metric for an interface is calculated according to the inverse of the interface’s bandwidth. The default OSPF cost in Cisco routers is calculated using the formula (100)/(bandwidth in Mbps). This formula can also be written as (108) / (bandwidth in bps). The cost is a 16-bit value. The lower the cost the better the route is considered. For example, a 64-kbps link gets a metric of 1562, and a T1 link gets a metric of 64. However, this formula is based on a maximum bandwidth of 100 Mbps, which results in a cost of 1. If you have faster interfaces, you may want to recalibrate the cost of 1 to a higher bandwidth.
The ip ospf cost, bandwidth, and auto-cost reference-bandwidth commands can be used to manipulate the cost metric.
If interfaces that are faster than 100 Mbps are being used, use the auto-cost reference-bandwidth ref-bw router configuration command on all routers in the network to ensure accurate route calculations. The rf-bw parameter is the reference bandwidth in megabits per second. The range is from 1 to 4,294,967. The default is 100.
For example, in a network that has Fast Ethernet and Gigabit Ethernet interfaces, both would have a default OSPF cost of 1. In this case, the reference bandwidth could be changed to 10,000 Mbps using the auto-cost reference-bandwidth 10000 command. The OSPF cost of a Fast Ethernet interface would then be 10,000/100 = 100 and the OSPF cost of a Gigabit Ethernet interface would be 10,000/1000 = 10. Thus, the interface costs would be differentiated.
When using the interface’s bandwidth to determine OSPF cost, always remember to use the bandwidth value interface configuration command to accurately define the bandwidth per interface, in kilobits per second.
To override the default cost, manually define the cost using the ip ospf cost interface-cost configuration command on a per-interface basis. The interface-cost is an integer from 1 to 65,535. The lower the number, the better (and more preferred) the link.
Configuring OSPF Special Area Types
As discussed, OSPF is based on a two-level hierarchical area structure with backbone and nonbackbone areas. Each area has its own topology database, which is invisible from outside the area. A router belonging to several areas (an ABR) has several topology databases, one per area to which it is attached. All areas have to be connected to a backbone area or linked to it with a virtual link. The backbone area has to be contiguous. A nonbackbone area can be discontiguous. This section describes special area types that can be configured for OSPF.
The characteristics assigned to an area control the type of route information it receives. The purpose behind any type of stub area is to inject default routes into an area so that external and/or summary LSAs are not flooded into the area. This reduces the LSDB size and the routing table size in the routers within the area. The possible area types, some of which are shown in Figure 3-45, are as follows:
-
Standard area— This default area type accepts link updates, route summaries, and external routes.
-
Backbone area— The backbone area is labeled area 0, and all other areas connect to this area to exchange and route information. The OSPF backbone has all the properties of a standard OSPF area.
-
Stub area— This area type does not accept information about routes external to the autonomous system, such as routes from non-OSPF sources. If routers need to route to networks outside the autonomous system, they use a default route, indicated as 0.0.0.0. Stub areas cannot contain ASBRs (except that the ABRs may also be ASBRs).
-
Totally stubby area— This Cisco proprietary area type does not accept external autonomous system routes or summary routes from other areas internal to the autonomous system. If a router needs to send a packet to a network external to the area, it sends the packet using a default route. Totally stubby areas cannot contain ASBRs (except that the ABRs may also be ASBRs).
-
NSSA— NSSA is an addendum to the OSPF RFC. This area type defines a special LSA type 7. NSSA offers benefits that are similar to those of a stub area. They do not accept information about routes external to the autonomous system, but instead use a default route for external networks. However, NSSAs allow ASBRs, which is against the rules in a stub area.
-
Totally stubby NSSA— Cisco routers also allow an area to be configured as a totally stubby NSSA, which allows ASBRs, but does not accept external routes or summary routes from other areas. A default route is used to get to networks outside of the area.
Table 3-22 summarizes the OSPF area types. Three of the column headers in this table also indicate how the various types of routes are indicated in the routing table.
Table 3-22: OSPF Area Types
Open table as spreadsheet | Area Type | Accepts Routes Within Area (O) | Accepts Routes from Other Areas (O IA) | Accepts External Routes (O E1 and O E2) | Allows ASBR | Cisco Proprietary |
| Standard | Yes | Yes | Yes | Yes | No |
| Backbone | Yes | Yes | Yes | Yes | No |
| Stub | Yes | Yes | No (uses interarea default route) | No | No |
| Totally stubby | Yes | No (uses interarea default route) | No (uses interarea default route) | No | Yes |
| NSSA | Yes | Yes | No (uses interarea default route) | Yes | No |
| Totally stubby NSSA | Yes | No (uses interarea default route) | No (uses interarea default route) | Yes | Yes |
Routers within stub and totally stub areas do not have any external routes (type 5 LSAs).
| Note | Because type 5 LSAs, describing external routes from ASBRs, are not sent into stub areas, type 4 LSAs, which describe the path to the ASBR, are also not sent into stub areas. This fact is not explicitly stated in some Cisco documentation, but it is in the OSPF RFC and we confirmed it by testing. |
An area qualifies as stub or totally stubby area if it has the following characteristics:
-
There is a single exit point from that area; or if there are multiple exits, one or more ABRs inject a default route into the stub area and suboptimal routing paths are acceptable. In other words, it is acceptable if routing to other areas or autonomous systems can take a suboptimal path to reach the destination by exiting the area via a point that is farther from the destination than other exit points.
-
All OSPF routers inside the stub area, including ABRs, are configured as stub routers. All of these routers must be configured as stub routers before they can become neighbors and exchange routing information.
-
The area is not used as a transit area for virtual links.
-
There is no ASBR is inside the area.
-
The area is not the backbone area (area 0).
Configuring Stub Areas
Configuring a stub area reduces the size of the LSDB inside an area, resulting in reduced memory requirements for routers in that area. Routers within the stub area also do not have to run the SPF algorithm as often because they will receive fewer routing updates. External network LSAs (type 5), such as those redistributed from other routing protocols into OSPF, are not permitted to flood into a stub area, as shown in Figure 3-46. (Type 4 LSAs are also not flooded, as described earlier.) Routing from these areas to a route external to the OSPF autonomous system is based on a default route (0.0.0.0). If a packet is addressed to a network that is not in the routing table of an internal router, the router automatically forwards the packet to the ABR that originates a 0.0.0.0 LSA. Forwarding the packet to the ABR allows routers within the stub area to reduce the size of their routing tables, because a single default route replaces many external routes.
A stub area is typically created using a hub-and-spoke topology, with a spoke being a stub area, such as a branch office. In this case, the branch office does not need to know about every network at the headquarters site, because it can use a default route to reach the networks.
To configure an area as a stub, use the following procedure:
| Note | The hello packet exchanged between OSPF routers contains a stub area flag that must match on neighboring routers. The area area-id stub command must be enabled on all routers in the stub area so that they all have the stub flag set. The routers can then become neighbors and exchange routing information. |
By default, the ABR of a stubby or totally stubby area advertises a default route with a cost of 1. To change the cost of the default route, use the area area-id default-cost cost router configuration command. This command is configured only on the ABR. The parameters of this command are shown in Table 3-23
Table 3-23: area default-cost Command Parameters
Open table as spreadsheet | Parameter | Description |
| area-id | The identifier for the stub area, totally stubby area, or NSSA. The identifier can be either a decimal value or a value in dotted-decimal format, like an IP address. |
| cost | Cost for the default summary route. The acceptable values are 0 through 16777215. The default is 1. |
Figure 3-47 illustrates an example. Area 2 is defined as the stub area. No routes from the external autonomous system are forwarded into the stub area. Example 3-33 shows the OSPF configuration on Routers R3 and R4, including enabling an OSPF stub area.
Example 3-33: OSPF Stub Area Configuration for Routers R3 and R4 in Figure 3-47
Router R3:
R3(config)#interface FastEthernet0/0
R3(config-if)#ip address 192.168.14.1 255.255.255.0
R3(config)#interface Serial 0/0/0
R3(config-if)#ip address 192.168.15.1 255.255.255.252
R3(config)#router ospf 100
R3(config-router)#network 192.168.14.0.0 0.0.0.255 area 0
R3(config-router)#network 192.168.15.0.0 0.0.0.255 area 2
R3(config-router)#area 2 stub
Router R4:
R4(config)#interface Serial 0/0/0
R4(config-if)#ip address 192.168.15.2 255.255.255.252
R4(config)#router ospf 100
R4(config-router)#network 192.168.15.0.0 0.0.0.255 area 2
R4(config-router)#area 2 stub
The last line in each router configuration (area 2 stub) defines the stub area. The R3 router (the ABR) automatically advertises 0.0.0.0 (the default route) with a default cost metric of 1 into the stub area.
Each router in the stub area must be configured with the area stub command.
The routes that appear in the routing table of router R4 (the internal router) are as follows:
-
Intra-area routes, which are designated with an O in the routing table.
-
The default route and interarea routes, which are both designated with an IA in the routing table. The default route is also denoted with an asterisk (O*IA).
Configuring Totally Stubby Areas
A totally stubby area is a Cisco-specific feature that further reduces the number of routes in the routing table. A totally stubby area blocks external type 5 LSAs and summary type 3 and type 4 LSAs (interarea routes) from entering the area, as shown in Figure 3-48. By blocking these routes, the totally stubby area recognizes only intra-area routes and the default route 0.0.0.0. ABRs inject the default summary link 0.0.0.0 into the totally stubby area. Each router within the area picks the closest ABR as a gateway to everything outside the area.
Totally stubby areas minimize routing information further than stub areas and increase stability and scalability of OSPF internetworks. Using totally stubby areas is typically a better solution than using stub areas, assuming the ABR is a Cisco router.
To configure an area as totally stubby, do the following:
Table 3-24 explains the area area-id stub no-summary command.
Table 3-24: area area-id stub no-summary Command Parameters
Open table as spreadsheet | Parameter | Description |
| area-id | The identifier for the stub or totally stubby area. It can be either a decimal value or a value in dotted-decimal format, like an IP address. |
| no-summary | Stops summary LSAs, in addition to external LSAs, from flooding into the totally stubby area. |
Figure 3-49 shows an example of a totally stubby area topology. The configurations on routers R2, R3, and R4 are shown in Example 3-34. All routes advertised into area 1 (from area 0 and the external autonomous system) default to 0.0.0.0. The default route cost is set to 5 on R2 and to 10 on R4. Both default routes are advertised into area 1. However, the default route from R2 is advertised with a lower cost to make it more preferable if the internal cost from R3 to R4 is the same as the internal cost from R3 to R2.
Example 3-34: Totally Stubby Configuration for Routers in Figure 3-49
Router R2:
R2(config)#router ospf 10
R2(config-router)#network 172.17.0.0 0.0.255.255 area 0
R2(config-router)#network 172.16.0.0 0.0.255.255 area 1
R2(config-router)#area 1 stub no-summary
R2(config-router)#area 1 default-cost 5
Router R3:
R3(config)#router ospf 10
R3(config-router)#network 172.16.0.0 0.0.255.255 area 1
R3(config-router)#area 1 stub
Router R4:
R4(config)#router ospf 10
R4(config-router)#network 172.17.0.0 0.0.255.255 area 0
R4(config-router)#network 172.16.0.0 0.0.255.255 area 1
R4(config-router)#area 1 stub no-summary
R4(config-router)#area 1 default-cost 10
Remember that all routers in a stub or totally stubby area must be configured as stubs. An OSPF adjacency will not form between stub and nonstub routers. Notice that R3 requires the area 1 stub command, yet the no-summary keyword is not required. Only ABRs (R2 and R4) use the no-summary keyword to keep summary LSAs from being propagated into another area.
Interpreting Routing Tables in Different Types of OSPF Areas
This section illustrates routing tables when different area types are configured.
Example 3-35 shows how the routing table of an OSPF router in a standard area (without any kind of stub configuration) might look. Intra-area (O), interarea (O IA), and external routes (O E1 and O E2) are all maintained in a standard area.
Example 3-35: Routing Table in a Standard Area
RouterA#show ip route
Example 3-36 shows how the same routing table looks if the area is configured as a stub area. Intra-area (O) and interarea (O IA) routes are all maintained. However, external routes (O E1 and O E2) are not visible in the routing table. These routes are accessible via the interarea default route (O*IA), as shown in the last line of the routing table.
Example 3-36: Routing Table in a Stub Area
RouterA#show ip route
Example 3-37 shows how the same routing table looks if summarization is performed on the ABR. The area is still configured as a stub area, and intra-area (O) and summarized interarea (O IA) routes are all maintained. In this example the two routes 172.31.11.1 and 172.31.11.2 were summarized to 172.31.11.0/24. External routes are not visible in the routing table but are accessible via the interarea default route (O*IA).
Example 3-37: Routing Table in a Stub Area with Summarization
RouterA#show ip route
Example 3-38 shows how the same routing table looks if the area is configured as a totally stubby area. Notice that routers in the totally stubby area have the smallest routing tables. Intra-area routes (O) are maintained. Individual interarea (O IA) and external (O E1 and O E2) routes are not visible in the routing table but are accessible via the interarea (O*IA) default route.
Example 3-38: Routing Table in a Totally Stubby Area
RouterA#show ip route
Configuring NSSAs
The OSPF NSSA feature is described by RFC 3101 and was introduced in Cisco IOS Software Release 11.2. It is a nonproprietary extension of the existing stub area feature that allows the injection of external routes in a limited fashion into the stub area.
Redistribution into an NSSA area creates a special type of LSA known as type 7, which can exist only in an NSSA area. An NSSA ASBR generates this LSA, and an NSSA ABR translates it into a type 5 LSA, which gets propagated into the OSPF domain. Type 7 LSAs have a propagate (P) bit in the LSA header to prevent propagation loops between the NSSA and the backbone area. Type 7 LSAs are the same format as type 5 LSAs.
The NSSA feature allows an area to retain the other stub area features—the ABR sends a default route into the NSSA instead of external routes from other ASBRs—while also allowing an ASBR to be inside of the area. Recall that one of the rules of stub areas is that there must not be an ASBR inside of a stub area. An NSSA—a not-so-stubby area—bends this rule. Figure 3-50 illustrates an NSSA.
Routers operating in NSSA areas set the N-bit to signify that they can support the type 7 LSA. These option bits are checked during neighbor establishment and must match for an adjacency to form.
The link-state ID in the type 7 LSA is the external network number. As is the case for type 5 LSAs, because of the flooding scope and depending on the number of external networks, the default lack of route summarization can be a major issue with these LSAs. Therefore, the network administrator should always attempt to summarize blocks of external network numbers at the ASBR to reduce flooding problems.
The type 7 LSA is described in the routing table as an O N2 or O N1 (N means NSSA). N1 means that the metric is calculated like external type 1 (internal costs are added to the external metric); N2 means that the metric is calculated like external type 2 (internal costs are not added to the external metric). The default is O N2.
To configure an area as an NSSA, do the following:
Remember that all routers in the NSSA must have this command configured. Two routers will not form an adjacency unless both are configured as NSSA.
Table 3-25 defines the parameters of the area nssa command.
Table 3-25: area area-id nssa Command Parameters
Open table as spreadsheet | Parameter | Description |
| area-id | The identifier for the NSSA. It can be either a decimal value or a value in dotted-decimal format, like an IP address. |
| no-redistribution | (Optional) Used when the router is an NSSA ABR and you want the redistribute command to import routes only into the standard areas, but not into the NSSA area. |
| default-information-originate | (Optional) Used to generate a type 7 default LSA into the NSSA area. This keyword takes effect only on an NSSA ABR or an NSSA ASBR. |
| metric metric-value | (Optional) Metric that is used for generating the default route. Acceptable values are 0 through 16777214. |
| metric-type type-value | (Optional) OSPF metric type for default routes. It can be one of the following values: 1: type 1 external route 2: type 2 external route |
| no-summary | (Optional) Allows an area to be a totally stubby NSSA, which is like an NSSA but does not have summary routes injected into it. |
In Figure 3-51 and Example 3-39, R1 is the ASBR that redistributes RIP routes into area 1, the NSSA. R2 is the NSSA ABR. The NSSA ABR converts type 7 LSAs into type 5 LSAs for advertisement into backbone area 0. R2 is also configured to summarize the type 5
LSAs that originate from the RIP network—the 172.16.0.0 subnets—to 172.16.0.0/16 and advertise this summary route into area 0. To cause R2 (the NSSA ABR) to generate an O*N2 default route (O*N2 0.0.0.0/0) into the NSSA, the default-information-originate parameter is used on the area area-id nssa command on R2.
Example 3-39: OSPF NSSA Configuration for Routers in Figure 3-51
Router R1:
R1(config)#router ospf 10
R1(config-router)#redistribute rip subnets
R1(config-router)#default metric 150
R1(config-router)#network 172.17.0.0 0.0.255.255 area 1
R1(config-router)#area 1 nssa
Router R2:
R2(config)#router ospf 10
R2(config-router)#summary-address 172.16.0.0 255.255.0.0
R2(config-router)#network 172.17.20.0 0.0.0.255 area 1
R2(config-router)#network 172.17.0.0 0.0.255.255 area 0
R2(config-router)#area 1 nssa default-information-originate
OSPF NSSA LSDB
Figure 3-52 illustrates another example network, used to illustrate an NSSA LSDB. The configuration of Routers R1, R2, and R3 are provided in Example 3-40.
Example 3-40: OSPF NSSA Configuration for Routers in Figure 3-52
R1#:
interface Loopback0
ip address 1.1.1.1 255.0.0.0
interface Serial2/1/0
ip address 172.17.0.1 255.255.0.0
interface Ethernet2/0/0
ip address 172.16.0.1 255.255.0.0
router ospf 4
redistribute static metric 5 metric-type 1
network 172.17.0.0 0.0.255.255 area 1
network 172.16.0.0 0.0.255.255 area 1
area 1 nssa
ip route 172.19.0.0 255.255.0.0 172.16.0.2
R2#:
interface Loopback0
ip address 2.2.2.2 255.0.0.0
interface Serial0/1/0
ip address 172.17.0.2 255.255.0.0
interface s1/0.20 point-to-point
ip address 172.18.0.2 255.255.0.0
router ospf 2
network 172.17.0.0 0.0.255.255 area 1
network 172.18.0.0 0.0.255.255 area 0
area 1 nssa
R3#
interface Loopback0
ip address 3.3.3.3 255.0.0.0
interface s2/0.20 point-to-point
ip address 172.18.0.3 255.255.0.0
router ospf 2
network 172.18.0.0 0.0.255.255 area 0
Area 1 is configured as an NSSA. Router R1 is an ASBR and is redistributing a static route into the OSPF area. Router R2 is the ABR, and is connected to the NSSA area 1 and to the backbone area 0.
Example 3-41 is the output of the show ip ospf database command on the R2 router, the ABR. The router link states are type 1 LSAs. The summary net link states are type 3 LSAs, advertising routes from one area into another. To advertise external routes into an NSSA, the ASBR Router R1 creates a type 7 LSA. The ABR converts the type 7 LSA into a type 5 LSA and propagates the type 5 LSA into other areas.
Example 3-41: show ip ospf database Output on Router R2 in Figure 3-52
R2#show ip ospf database
OSPF Router with ID (2.2.2.2) (Process ID 2)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
2.2.2.2 2.2.2.2 1235 0x8000001D 0xD9FF 2
3.3.3.3 3.3.3.3 1100 0x8000000B 0x9455 2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.0.0 2.2.2.2 1979 0x80000002 0xFDE7
172.17.0.0 2.2.2.2 1483 0x80000004 0x8864
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 319 0x8000000C 0xAFA8 3
2.2.2.2 2.2.2.2 220 0x8000002F 0xD478 2
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
172.18.0.0 2.2.2.2 1483 0x8000001C 0x7894
Type-7 AS External Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Tag
172.19.0.0 1.1.1.1 334 0x80000005 0xD738 0
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
172.19.0.0 2.2.2.2 1725 0x80000004 0x50C6 0
Notice that ASBR summary LSAs (type 4) are not used in this case because the ABR, not the ASBR, originates the external type 5 LSA, and the ABR is reachable within area 0. In contrast if the area was a standard area, the ASBR would originate the type 5 LSA and the ABR would create a type 4 LSA describing how other routers can reach the ASBR.
Configuring Totally Stubby NSSAs
The OSPF totally stubby NSSA feature is a Cisco proprietary extension to NSSA that blocks type 3, 4, and 5 LSAs. A single default route replaces both inbound external (type 5) LSAs and summary (type 3 and 4) LSAs into the totally NSSA area.
The ABR of a totally stubby NSSA must be configured with the no-summary keyword to prevent the flooding of summary routes for other areas into the NSSA area.
To configure an area as a totally stubby NSSA, do the following:
In the example in Figure 3-53 and Example 3-42, notice that the ABR, R2, is using the area 1 nssa no-summary command. This command works exactly the same as the totally stubby technique. A single default route replaces both inbound external (type 5) LSAs and summary (type 3 and 4) LSAs into the area. The NSSA ABR, Router R2, automatically generates the O*N2 default route into the NSSA area when the no-summary option is configured at the ABR, so the default-information-originate parameter is not required.
Example 3-42: NSSA Totally Stubby Configuration for Routers in Figure 3-53
Router R1:
R1(config)#router ospf 10
R1(config-router)#redistribute rip subnets
R1(config-router)#default metric 150
R1(config-router)#network 172.17.0.0 0.0.255.255 area 1
R1(config-router)#area 1 nssa
Router R2:
R2(config)#router ospf 10
R2(config-router)#summary-address 172.16.0.0 255.255.0.0
R2(config-router)#network 172.17.20.0 0.0.0.255 area 1
R2(config-router)#network 172.17.0.0 0.0.255.255 area 0
R2(config-router)#area 1 nssa no-summary
All other routers in the NSSA area require the area 1 nssa command only. The NSSA totally stubby configuration is a Cisco-specific feature, just as the totally stubby area feature is.
Example OSPF Area Types in a Network
Figure 3-54 illustrates a network with a variety of area types as follows:
-
Standard area 11 accepts link updates, summaries, and external routes.
-
Stub area 14 does not accept type 4 summary or type 5 external LSAs, but does accept type 3 summary LSAs.
-
Totally stubby area 12 does not accept summary or external LSAs.
-
NSSA area 10 does not accept type 4 summary or type 5 external LSAs, but does accept type 3 summary LSAs and allows an ASBR.
-
Totally stubby NSSA area 13 does not accept summary or external LSAs, but allows an ASBR.
Verifying All Area Types
The show commands in Table 3-26 are used to display the area type that has been configured and other information about the area.
Table 3-26: show Commands for All Area Types
Open table as spreadsheet | Command | Description |
| show ip ospf | Displays OSPF information,, including which areas are standard, stub, or NSSA |
| show ip ospf database | Displays details of LSAs |
| show ip ospf database nssa-external | Displays specific details of each LSA type 7 update in the database |
| show ip route | Displays all routes |
0 comments
Post a Comment