OSPF supports several types of areas, including standard areas, stub areas, totally stubby areas, and not-so-stubby (NSSA) areas. These special area types bring flexibility to OSPF network design, allowing OSPF to fit comfortably into the niches that otherwise could not be served, such as branch offices running legacy router hardware.
Remember that an area is a piece of the OSPF routing domain that implements the Dijkstra algorithm to pick paths. Path information is passed as a block between areas. Areas allow a large network to be broken into fractions that are small enough to reasonably run SPF.
The problem that can occur in OSPF is that an area can become too rich in LSA information and routers can become overloaded with information. Routers, particularly slower routers with less memory, can have their memory overwhelmed by the sheer volume of advertisements. Alternatively, even when memory is plentiful, the processor sometimes cannot process OSPF information fast enough to keep up with changes.
Figure 8-1 shows how a standard area handles the various LSA types. An ABR for a standard area passes all routes—external and inter-area—through to the standard area.
All the stub area types—stub, totally stubby, and not-so-stubby—deal in varying degrees with trying to limit the information that routers in an area must track. Certain characteristics unite all the stub area types:
Area 0 cannot be a stub.
All routers in the area must agree that it is a stub area.
No virtual links may traverse a stub area.
Stub areas are areas where the ABR filters all external advertisements and replaces them with a default route. Because a large portion of a routing table might come from external routes, this simple substitution can dramatically impact the size of the routing table that must be maintained internally. Recall that external routes are those which are redistributed from another routing process.
Figure 8-2 shows how the ABR for a stub area passes routes. A stub-area ABR passes all inter-area routes, but replaces external routes with a default route.
The reduction in routing table size comes with a cost, however. Routers in a stub area will always route external traffic through the closest ABR. Sometimes this will cause inefficient routing, as demonstrated in Figure 8-3. Router 8 wants to send traffic to the Internet through the ASBR. Because both stub-area ABRs are replacing specific Internet routes with a default route, Router 8 sends the traffic toward the closest ABR. Routing through Routers 7 and 3 would probably have been more efficient.
Although Figure 8-3 does not show IP addresses, assume that the routing table in Example 8-1 shows a routing table for Router 8 in a standard area 21.
10.0.0.0/32 is subnetted, 4 subnets O IA 10.0.22.5 [110/782] via 10.21.1.4, 00:01:35, FastEthernet0/0 O IA 10.0.22.6 [110/782] via 10.21.1.4, 00:01:35, FastEthernet0/0 O IA 10.0.22.9 [110/782] via 10.21.1.4, 00:01:35, FastEthernet0/0 O IA 10.0.0.1 [110/1] via 10.21.1.4, 00:01:35, FastEthernet0/0 O IA 10.0.0.2 [110/782] via 10.21.1.7, 00:02:52, Serial0/0/0 [110/782] via 10.21.1.4, 00:02:52, FastEthernet0/0 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks O 10.21.1.0/24 [110/10] via 10.21.1.4, 00:03:22, FastEthernet0/0 C 10.21.2.0/24 is directly connected, Loopback0 C 10.21.3.0/24 is directly connected, Serial0/0/0 O 10.0.1.0/24 [110/20] via 10.21.1.7, 00:04:01, Serial0/0/0 O 10.0.2.0/24 [110/30] via 10.21.1.4, 00:04:01, FastEthernet0/0 O 10.0.3.0/24 [110/30] via 10.21.1.4, 00:04:01, FastEthernet0/0 O 10.0.4.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O IA 10.22.1.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O IA 10.22.2.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O IA 10.22.3.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O E2 10.255.254.0/24 [110/50] via 10.21.1.4, 00:02:39, FastEthernet0/0 O E2 10.255.255.0/24 [110/50] via 10.21.1.4, 00:02:39, FastEthernet0/0 |
Example 8-2 shows the resulting routing table after making area 21 a stub area. Notice that the external routes (marked "E2") have been replaced by a default route.
10.0.0.0/32 is subnetted, 4 subnets O IA 10.0.22.5 [110/782] via 10.21.1.4, 00:02:39, FastEthernet0/0 O IA 10.0.22.6 [110/782] via 10.21.1.4, 00:02:39, FastEthernet0/0 O IA 10.0.22.9 [110/782] via 10.21.1.4, 00:02:39, FastEthernet0/0 O IA 10.0.0.1 [110/1] via 10.21.1.4, 00:02:39, FastEthernet0/0 O IA 10.0.0.2 [110/782] via 10.21.1.7, 00:02:52, Serial0/0/0 [110/782] via 10.21.1.4, 00:02:52, FastEthernet0/0 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks O 10.21.1.0/24 [110/10] via 10.21.1.4, 00:03:22, FastEthernet0/0 C 10.21.2.0/24 is directly connected, Loopback0 C 10.21.3.0/24 is directly connected, Serial0/0/0 O 10.0.1.0/24 [110/20] via 10.21.1.7, 00:04:01, Serial0/0/0 O 10.0.2.0/24 [110/30] via 10.21.1.4, 00:04:01, FastEthernet0/0 O 10.0.3.0/24 [110/30] via 10.21.1.4, 00:04:01, FastEthernet0/0 O 10.0.4.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O IA 10.22.1.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O IA 10.22.2.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O IA 10.22.3.0/24 [110/40] via 10.21.1.4, 00:04:01, FastEthernet0/0 O*IA 0.0.0.0/0 [110/2] via 10.1.1.1, 00:01:51, FastEthernet0/0 |
The command to implement a stub area on an ABR is
Router(config-router)# area area-id stub
All internal routers in a stub area must have this same command so that all hellos agree on the stub area flag.
An example configuration of an ABR is shown in Example 8-3.
Router ospf 1 Network 10.0.0.0 0.0.255.255 area 0 Network 10.21.0.0 0.0.255.255 area 21 Area 21 stub |
Totally stubby areas are areas where the ABR filters all inter-area and external advertisements and replaces them with a default route. Note that the totally stubby option is Cisco proprietary. Because a larger portion of a routing table comes from other areas or external sources, this restricts the routing table to internal routes plus a default.
Figure 8-4 shows how the ABR for a totally stubby area passes routes. A totally stubby ABR removes all inter-area and external routes and replaces them with a default route.
Continuing with the sample routing table from Example 8-2, Example 8-4 shows how the same routing table could be reduced in a totally stubby area.
10.0.0.0/32 is subnetted, 4 subnets 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks O 10.21.1.0/24 [110/10] via 10.21.1.4, 00:03:22, FastEthernet0/0 C 10.21.2.0/24 is directly connected, Loopback0 C 10.21.3.0/24 is directly connected, Serial0/0/0 O 10.0.1.0/24 [110/20] via 10.21.1.7, 00:05:59, Serial0/0/0 O 10.0.2.0/24 [110/30] via 10.21.1.4, 00:05:59, FastEthernet0/0 O 10.0.3.0/24 [110/30] via 10.21.1.4, 00:05:59, FastEthernet0/0 O 10.0.4.0/24 [110/40] via 10.21.1.4, 00:05:59, FastEthernet0/0 O*IA 0.0.0.0/0 [110/2] via 10.1.1.1, 00:03:51, FastEthernet0/0 |
The command to implement a totally stubby ABR is
Router(config-router)# area area-id stub no-summary
The area area-id stub no-summary command is only entered on the ABR of a totally stubby area. The other routers in the totally stubby area are only configured with the area area-id stub command.
All internal routers in a stub area must have the stub area flag set. This can be done with the following stub command:
Router(config-router)# area area-id stub
Example 8-5 shows a sample configuration of an ABR.
Router ospf 1 Network 10.0.0.0 0.0.255.255 area 0 Network 10.21.0.0 0.0.255.255 area 21 Area 21 stub no-summary |
Since stub areas cannot carry external routes, type 5 advertisements are not allowed in stub areas. Since type 5 LSAs are not allowed in stub areas, ASBRs cannot be located in stub areas. The problem is that sometimes the best solution to a design problem is to allow external routes. This problem is solved with not-so-stubby areas (NSSA).
An NSSA can be not-so-stubby or not-so-(totally)-stubby; either way an NSSA is a stub area that allows an ASBR. The ASBR understands that type 5 LSAs are not permitted and so disguises the LSAs as type 7. In all other respects, NSSA operates just like a stub area. NSSA is an Internet standard.
The type 7 advertisements cross the NSSA and are converted back to type 5 LSAs at the ABR. NSSA external routes show up as N1 or N2 instead of E1 or E2.
Note that the ABR of an NSSA does not automatically generate a default route; the no-summary or default-originate optional keywords must be appended to the area nssa area-id command for that to happen.
The command to implement a stub or totally stubby NSSA ABR is
Router(config-router)# area area-id nssa [no-summary]
All internal routers in an NSSA must recognize the NSSA area. This can be done with the area nssa command:
Router(config-router)# area area-id nssa
There are several useful show commands for looking at stub areas:
show ip ospf
show ip route
show ip ospf database
show ip ospf database nssa-external
When troubleshooting, show ip protocols provides an overview of active routing and is a good place to start. The show ip ospf command displays common OSPF parameters, while show ip route shows the current routing table so that the current routing may be analyzed.
The database commands are useful in particular areas once you identify the problem as pertaining to OSPF. These commands allow you to examine the routes in the topological database. Inter-area and external routes offer a clue about the effectiveness of stub area settings.
An attacker who could forge OSPF packets could force routes along paths that are easier to intercept, could deny service, or could make forged websites appear to exist at the real IP addresses. OSPF, by default, trusts all OSPF speakers and is susceptible to forged traffic.
As the network became more dangerous, authentication was developed for OSPF. Authentication allows neighbors to identify themselves as legitimate through a shared secret. There are three authentication modes:
null (no authentication)
plaintext password
Message Digest (MD5) hash
The following sections describe the plaintext password and MD5 hash authentication methods.
Password authentication provides little security. Any attacker with access to the medium can capture traffic and easily read the password. Nevertheless, it is presented here as an easy way to introduce the topic before considering the more appropriate method: MD5.
OSPF authentication is configured on an interface. At an interface configuration prompt, a key is set with the ip ospf authentication command:
Router(config-if)# ip ospf authentication-key password
Note
Prior to Cisco IOS Software version 12.0, authentication was set per-area. All routers in a given area had to share a password. This was less flexible than the newer interface-based shared secret.
Other routers connected through this interface should share this password. Next, enable authentication with the following command:
Router(config-if)# ip ospf authentication
MD5 hash authentication provides good security, ensuring that received messages can be trusted because they come from a source that knows the shared secret.
To configure OSPF MD5 authentication, first set a key. A key number is used in combination with the password to create a hash. The key is also useful when changing passwords, because more than one key may be active at a time. Other routers connected through this interface should share this password and key number. Use the following command syntax:
Router(config-if)# ip ospf message-digest-key key md5 password
Next, enable authentication using the message-digest keyword:
Router(config-if)# ip ospf authentication message-digest
Example 8-6 shows a configuration for a router that is set up for MD5 authentication.
Interface fastethernet0/0 ip address 10.0.0.1 255.255.255.0 ip ospf message-digest-key 1 md5 mi5kgbcia ip ospf authentication message-digest |
To verify that authentication is taking place, look at show ip ospf neighbor and verify that neighbors have become completely adjacent. The show ip ospf interface command also yields useful information about authentication.
The debug ip ospf adjacency command shows the status of authentication; it shows the progress from DOWN state to full state and—like show ip ospf neighbor—authentication success must be inferred. Unlike success, failure to authenticate is clearly shown using this command.
If two routers disagree over whether to use plaintext or MD5, the router will display an authentication type mismatch, as follows:
*Dec 03 17:52:17.527: OSPF: Rcv pkt from 10.0.0.1, Fastethernet0/0: Mismatch Authentication type. Input packet specified type 0, we use type 1
If the routers disagree over the password, the router shows a key mismatch:
*Dec 03 17:55:13.044: OSPF: Rcv pkt from 10.0.0.1, Fastethernet0/0: Mismatch Authentication Key - Clear Text