Section 7.3. OSPF Areas


7.3. OSPF Areas

OSPF is almost always the preferred IGP for multi-area topologies. Multi-area OSPF networks are easier to design, configure, and administer than multi-area IS-IS networks. Although you can implement almost all the same intra- and inter-area behaviors in IS-IS as you can in OSPF, doing so often involves the use of routing policies that are not as easy to understand as the more straightforward OSPF mechanisms.

7.3.1. Backbone and Non-Backbone Areas

Normal OSPF design uses a loop-free inter-area topology, as discussed in the introduction to this chapter, by ensuring that all inter-area traffic originates in, terminates in, or passes through the backbone area. OSPF identifies the backbone area with an all-zero AID (0.0.0.0), commonly called area 0.

But saying that all inter-area OSPF traffic should touch area 0 is not the same thing as saying all inter-area OSPF traffic must touch area 0. Nothing in the OSPF protocol forces you to follow the recommended design procedure.[1] Take for example the topology in Figure 7.5, in which an ABR is configured between two nonzero areas: area 1 and area 2. Figure 7.6 shows that subnet 10.1.3.0/24 is installed in the routing table of router R3, demonstrating that ABR R2 has advertised the prefix from area 1 into area 2. Figure 7.7 shows the type 3 LSA advertised by the ABR (10.10.10.2), and you can see that there is no information in the LSA indicating what area the prefix is in or what inter-area path the route takes to reach the destination. In keeping with the distance vector nature of inter-area OSPF, knowledge of network details ends at the area boundary.

[1] Although nothing in the protocol forces you to follow recommended design procedure, some implementations do. The Cisco Systems OSPF implementation, for example, does not generate a type 3 LSA into a connected nonzero area for prefixes it learns from another connected nonzero area.

Figure 7.5. An example multi-area OSPF network with no area 0.


Figure 7.6. R3, in area 2, knows about the prefix 10.1.3.0/24 in area 1.

[View full width]

jeff@R3> show route 10.1.3.0 extensive inet.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden) 10.1.3.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 10.1.3.0/24 -> {so-0/2/1.0} *OSPF Preference: 10 Next hop: via so-0/2/1.0, selected State: <Active Int> Age: 8 Metric: 3 Area: 0.0.0.2 Task: OSPF Announcement bits (1): 0-KRT AS path: I


Figure 7.7. The Network Summary (type 3) LSA originated by the ABR (10.10.10.2) does not contain any information about the actual inter-area path to the destination.

[View full width]

jeff@R3> show ospf database netsummary lsa-id 10.1 .3.0 extensive OSPF link state database, area 0.0.0.2 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.1.3.0 10.10.10.2 0x80000001 43 0x2 0xc069 28 mask 255.255.255.0 TOS 0x0, metric 2 Aging timer 00:59:17 Installed 00:00:41 ago, expires in 00:59:17, sent 00:30:24 ago


In Figure 7.8, an area 0 has been added to the topology. In Figure 7.9 you can see that R3 now has two type 3 LSAs in its database advertising prefix 10.1.3.0/24: one originated by R2, and one originated by R4 (10.10.10.4), which is the ABR to area 0. Other than the RIDs of the originating ABRs, the LSAs appear identical.

Figure 7.8. A path through area 0 is added to the topology of Figure 7.5.


Figure 7.9. R3 has two type 3 LSAs in its database, one originated by ABR R2 and one originated by ABR R4.

[View full width]

jeff@R3> show ospf database netsummary lsa-id 10.1 .3.0 extensive OSPF link state database, area 0.0.0.2 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.1.3.0 10.10.10.2 0x80000001 660 0x2 0xc069 28 mask 255.255.255.0 TOS 0x0, metric 2 Aging timer 00:49:00 Installed 00:10:58 ago, expires in 00:49:00, sent 00:04:27 ago Summary 10.1.3.0 10.10.10.4 0x80000001 208 0x2 0xa282 28 mask 255.255.255.0 TOS 0x0, metric 2 Aging timer 00:56:32 Installed 00:03:25 ago, expires in 00:56:32, sent 00:03:25 ago


Figure 7.10 shows the resulting routing table entry in R3 for 10.1.3.0/24. As you might expect, the identical information in the two LSAs pertains to the prefix results in two route entries. A close look shows that R3 has selected the route through ABR R4reachable from SONET interface so-0/2/0over the path through ABR R2 reachable from interface so-0/2/2.

Figure 7.10. R3 has selected the path through area 0, via R4, as the route to 10.1.3.0/24.

[View full width]

jeff@R3> show route 10.1.3.0 extensive inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden) 10.1.3.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 10.1.3.0/24 -> {so-0/2/2.0} *OSPF Preference: 10 Next hop: via so-0/2/1.0 Next hop: via so-0/2/2.0, selected State: <Active Int> Age: 2:54 Metric: 3 Area: 0.0.0.2 Task: OSPF Announcement bits (1): 0-KRT AS path: I


But the information in the two LSAs indicates that the metric of both paths is 2. So has R2 somehow detected that one of the paths passes through the backbone area while the other does not, or is it a coincidence of randomly selecting between two equal-cost paths? The question is easily answered by changing the cost of one of the paths. In Figure 7.11, another router is added in area 0 so that the cost of that path from ABR R4 is now 3, while the cost from R2 remains 2, as reflected by the LSAs shown in Figure 7.12. This means that R3 now sees the cost of the path to the destination prefix through R4 as 4, while the cost of the path through R2 is 3. Because the costs of the two paths are no longer equal, only the shortest paththrough R2is entered into the routing table (Figure 7.13).

Figure 7.11. An extra router hop is added to the area 0 path.


Figure 7.12. The increased path cost of 3 is shown in the LSA originated by R4.

[View full width]

jeff@R3> show ospf database netsummary lsa-id 10.1 .3.0 extensive OSPF link state database, area 0.0.0.2 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.1.3.0 10.10.10.2 0x80000002 821 0x2 0xbe6a 28 mask 255.255.255.0 TOS 0x0, metric 2 Aging timer 00:46:18 Installed 00:13:38 ago, expires in 00:46:19, sent 00:04:08 ago Summary 10.1.3.0 10.10.10.4 0x80000001 252 0x2 0xbe68 28 mask 255.255.255.0 TOS 0x0, metric 3 Aging timer 00:55:47 Installed 00:04:08 ago, expires in 00:55:48, sent 00:04:08 ago


Figure 7.13. R3 enters only the lowest-cost path, through R2, into its routing table.

[View full width]

jeff@R3> show route 10.1.3.2 extensive inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden) 10.1.3.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 10.1.3.0/24 -> {so-0/2/1.0} *OSPF Preference: 10 Next hop: via so-0/2/1.0, selected State: <Active Int> Age: 6:20 Metric: 3 Area: 0.0.0.2 Task: OSPF Announcement bits (1): 0-KRT AS path: I


The point of this demonstration is that while all inter-area OSPF traffic should touch area 0, enforcing this rule through area topology design is up to you. Nothing in the protocol will enforce the rule for you.

And although a two-area topology is inherently loop-free, you should never assign nonzero AIDs to both areas as in Figure 7.5. Even if you are sure you will never need to add a third area, it makes no sense, and gains you nothing, to purposely exclude the possibility of ever doing so.

7.3.2. Factors for Scaling OSPF Areas

A useful guideline when designing a network is that network control traffic should never exceed 5 percent of the available bandwidth of any link in the network, and in normal circumstances should not exceed 1 percent. OSPF Hello packets are 44 bytes of fixed-length fields plus an additional 4 bytes for each neighbor on the subnet and are typically sent every 10 seconds by each neighbor. This means that on a point-to-point link, OSPF Hellos use 76.8 bits per second. Even on a low-speed 56kbps link, this amounts to only 0.14 percent of the total bandwidth.

More significant is the amount of bandwidth used by the LSAs as they are flooded across the links during database synchronization and periodic database refreshes. Although many LSA types are likely to be present in your network, you can normally get a reasonably accurate idea of the bandwidth requirements to support flooding, and the memory requirements to support the database, by accounting for just LSA types 1, 3, and 5.

First, consider type 1 LSAs. Each has 24 bytes of fixed fields (the 20-byte header plus another 4 bytes) and 12 bytes for each prefix advertised. Each router generates a type 1 LSA, so add 24 bytes for each router in the area and 12 bytes for each connected prefix in the area.

Next, consider type 3 LSAs. These LSAs are 32 bytes in length, and an ABR originates one for each prefix it advertises into an area. So simply multiply all prefixes outside the area but internal to the OSPF domain by 32.

Last, consider type 5 LSAs. These LSAs are 44 bytes in length, and an ASBR originates one for every external prefix it advertises into the OSPF domain. So multiply the number of AS-external prefixes by 44.

Of course, these LSAs are carried between routers in Update packets, which have a 28byte header. But like Hello packets, this is a small amount of the overall bandwidth requirement and can be reasonably disregarded.

As an example of calculating the impact LSAs will have on link bandwidth, take an area with 50 routers, each with 20 connected prefixes. The amount of space taken up in the link state database by type 1 LSAs is then:

24(50) + 12[(50)(20)] = 13,200 bytes

Recall that each router refreshes its LSAs every 1800 seconds (30 minutes). So in a 30minute period, 13,200 bytes are flooded in the area. This means that each link in the area must carry an average of 105,600 bits every 1800 seconds, or 58.7 bits per second.

Next, suppose a total of 2000 prefixes are outside of the area but inside the OSPF domain, and that the example area has two ABRs to area 0. Assuming that both of the ABRs advertise all 2000 prefixes into the area, type 3 LSAs take up the following amount of space in the link state database:

32(2000) = 64,000 bytes

These 64,000 bytes, or 512,000 bits, refreshed every 1800 seconds, require an average of 284.5 bits per second for flooding.

Last, suppose 5000 prefixes are advertised into the OSPF domain. Type 5 LSAs will account for:

44(5000) = 220,000 bytes

With the ASBRs refreshing these 5000 type 5 LSAs every 1800 seconds, flooding them requires an average of 977.8 bits per second.

Therefore, the total average flooding load on each link in the area is:

58.7 + 284.5 + 977.8 = 1321bps

Presumably, an area of such size would be unlikely to have links smaller than T1, and 1321bps accounts for only 0.08 percent of the bandwidth of a T1 link. Even a small 56kbps link in this area will use an average of only 2.4 percent of its bandwidth carrying OSPF flooding traffic; this is outside of the recommended 1 percent range, but still not too bad.

Of course, these averages assume that the expiration times of the refresh timers throughout the network are distributed evenly across a 30-minute period. In reality, refresh timers expire in a bursty pattern: many within some short periods of time, few within other short periods of time. But you can safely expect that over the 1800-second period the flooding load will be low enough at any one period to stay safely within 5 percent of the bandwidth of a T1 link.

From these calculations you can see that as long as sufficient bandwidth is available to support the size of the network, flooding should not be an issue. Usually, the larger issue is router memory for storing the database and router CPU for processing the LSAs. The LSA calculations demonstrated in this section are also useful for determining with reasonable accuracy the size of the database and so the amount of router memory the database will require. CPU requirements are much more difficult to determine.

Yet another factor when considering the number of LSAs in a network is the time two neighbors will take to synchronize their databases. Section 7.3.3 presents an example of how an abnormally large number of LSAs can effect synchronization time.

Passive Interfaces Versus Redistributing Connected Interfaces

It is often desirable to have external linkslinks that connect the OSPF domain to other routing domainsknown to OSPF, usually for management purposes such as being able to ping the interfaces. But you do not want OSPF running on the links, risking the possibility of forming an unwanted adjacency with an OSPF router in the neighboring routing domain. The two most common approaches for making external links known within OSPF are running OSPF in passive mode on the links and redistributing connected links into OSPF.

A router includes the prefixes of any links running in passive mode in OSPF, but does not send Hellos on the link or respond to Hellos received on the link. Redistributing connected interfaces uses a policy to import the prefixes of all connected interfaces into OSPF. And although the functional objective of these two approaches is the same, their effects are quite different. Prefixes on passive interfaces are considered "internal" to OSPF, and so are included in the router's type 1 LSAs. Prefixes learned from redistributing connected interfaces are external prefixes, and so are advertised in type 5 LSAs.

So which is better? Passive interfaces are more economical, but redistributing connected interfaces can have less performance impact.

Consider a router with 25 external links that must be known by OSPF. If OSPF is run in passive mode on the interfaces, the size of the router's type 1 LSA is increased by 300 bytes. But if a policy is used to redistribute the prefixes of the 25 links into OSPF, the router becomes an ASBR and originates 25 type 5 LSAs with a total size of 1100 bytes.

On the other hand, if passive mode is used the router must flood a new type 1 LSA every time an external link is added or removed or the link state changes. In addition to the inefficiency of re-advertising all links just to notify area routers of the change in one link, the new type 1 LSA causes an SPF calculation in all routers in the area. Type 5 LSAs do not cause an SPF calculation when they are flooded, and the addition, removal, or change of an external prefix can be advertised with the origination of a single type 5 LSA.

In smaller networks, the approach you choose probably does not matter. As the network grows large, however, the tradeoff between database size and network stability becomes yet another factor to consider in your network design.


7.3.3. External Prefixes and OSPF Scaling

A limiting factor for both the scalability of an area and its robustness is the size of the area's link state database. Figure 7.14 shows the consequence of a very large OSPF database. These OSPF log entries, taken from an actual network,[2] show an OSPF adjacency being established. Notice that the database synchronization, from the time the neighbor state changes to Exchange to the time it changes to Full, is 95 seconds. This is an unacceptably long time for the databases to synchronize, and is the primary cause of the reliability and performance issues this network operator is experiencing.

[2] In this and any example taken from a real network, the IP addresses, router names, and any other detail by which the operator can be identified have been changed.

Figure 7.14. This router takes more than 1.5 minutes to synchronize its database with its neighbor.

[View full width]

jdoyle@RT1> show log ospf-log May 20 18:57:04 OSPF interface fe-0/3/11.0 (172.16 .119.145) state changed from Down to Waiting May 20 18:57:08 OSPF neighbor 172.16.119.146 (fe-0 /3/11.0) state changed from Down to Init May 20 18:57:08 OSPF neighbor 172.16.119.146 (fe-0 /3/11.0) state changed from Init to 2Way May 20 18:57:08 OSPF interface fe-0/3/11.0 (172.16 .119.145) state changed from Waiting to BDR May 20 18:57:08 OSPF neighbor 172.16.119.146 (fe-0 /3/11.0) state changed from 2Way to ExStart May 20 18:57:08 OSPF neighbor 172.16.119.146 (fe-0 /3/11.0) state changed from ExStart to Exchange May 20 18:58:41 OSPF neighbor 172.16.119.146 (fe-0 /3/11.0) state changed from Exchange to Loading May 20 18:58:43 OSPF neighbor 172.16.119.146 (fe-0 /3/11.0) state changed from Loading to Full May 20 18:58:43 RPD_OSPF_NBRUP: OSPF neighbor 172 .16.119.146 (fe-0/3/11.0) state changed from Loading to Full due to OSPF loading done


A look at a summary of the route entries in the router shows that there are 24,068 entries learned from OSPF (Figure 7.15). Obviously, this many route entries requires a very large database. But where are most of these entries coming from? The answer is easily seen in the database summary of Figure 7.16. There are 23,349 type 5 LSAs in the database, representing an extraordinarily large number of external prefixes redistributed into the OSPF domain.

Figure 7.15. OSPF has created 24,068 entries in the routing table.

[View full width]

jdoyle@RT1> show route summary Router ID: 172.16.121.41 inet.0: 24073 destinations, 24075 routes (24072 active, 0 holddown, 1 hidden) Direct: 4 routes, 3 active Local: 2 routes, 2 active OSPF: 24068 routes, 24066 active Static: 1 routes, 1 active


Figure 7.16. The major source of the 24,068 route entries in Figure 7.15 are the 23,349 external prefixes redistributed into the OSPF domain.

jdoyle@RT1> show ospf database summary Area 0.0.0.5:    12 Router LSAs    2 Network LSAs    2387 Summary LSAs    153 ASBRSum LSAs Externals:    23349 Extern LSAs 


Examining the OSPF statistics in Figure 7.17 gives some further insight into what happened during the synchronization process. First, notice that the router sent only 176 LSAs to its neighbor, indicating that the great majority of the LSAs are coming from the neighbor's database. But notice that 58,596 LSAs were requested from the neighbor, and 86,685 LSAs were acknowledgedfar more than the already large number of LSAs summarized in Figure 7.16. The conclusion from these statistics is that the router struggled to process all the LSAs and that multiple requests, timeouts, and retransmissions of the same LSAs occurred.

Figure 7.17. The OSPF statistics show that the number of LSAs requested from the neighbor and acknowledged to the neighbor are far greater than the number of LSAs in the database, implying that many retransmits took place, further lengthening the synchronization time.

[View full width]

jdoyle@RT1> show ospf statistics Packet type Total Last 5 seconds Sent Received Sent Received Hello 27 11 0 0 DbD 1259 1212 0 0 LSReq 523 12 0 0 LSUpdate 114 4533 0 2 LSAck 2121 16 0 0 DBDs retransmited : 60, last 5 seconds : 0 LSAs flooded : 5, last 5 seconds : 0 LSAs flooded high-prio : 3, last 5 seconds : 0 LSAs retransmited : 0, last 5 seconds : 0 LSAs transmited to nbr : 176, last 5 seconds : 0 LSAs requested : 58596, last 5 seconds : 0 LSAs acknowledged : 86685, last 5 seconds : 0 Flood queue depth : 0 Total rexmit entries : 0 db summaries : 0 lsreq entries : 0 Receive errors: None


The point of this example is that when the size of an OSPF (or IS-IS) database gets out of hand, external prefixes are usually the reason. In even the largest link state networks, if intelligently designed, type 1 and 2 LSAs should number in the low hundreds, and type 3 LSAs should number in the low thousands. A large OSPF network using a single-area topology might have type 1 and 2 LSAs numbering in the mid to high hundreds, but will have no type 3 LSAs. The number of type 4 LSAs, of course, depends on the number of routers in the OSPF domain redistributing external prefixes, but in the most extreme case will not exceed the number of routers in the domain.

The most common causes of excessive type 5 LSAs in an OSPF domain are:

  • A faulty routing policy that redistributes prefixes from BGP into the IGP

  • Redistribution of very large numbers of static routes into the IGP

  • Redistribution of very large numbers of directly connected link prefixes into the IGP

Results of redistribution from BGP vary from poor performance, if partial routes are redistributed, to catastrophic network failure, if full Internet routes are redistributed. The only realistic remedy for this situation is to locate the faulty routing policy and correct it.

Redistribution of static and directly connected prefixes is most likely to occur in service provider networks where there are external links to thousands or tens of thousands of customers and the customer prefixes are statically routed. Such is the case in the example network shown in this section.

The best approach to relieving the external prefix problem is to redistribute customer prefixes and external link prefixes into BGP, which is much better suited for handling large numbers of routes, instead of OSPF. In some situations, however, stub areas can help you cope with external prefixes in your OSPF domain. The next three sections introduce stub areas and two variants of it, and discuss the circumstances in which they can be useful.

7.3.4. Stub Areas

If an OSPF area does not have an ASBR in it, all packets to and from external destinations are going to pass through the area's ABR. For example, the network in Figure 7.18 has two ASBRs: one in area 0 and one in area 1. Any packets that the router in area 2 sends to or receives from the external destinations must pass through area 2's ABR. In this case, a default route[3] with the ABR as the next hop serves just as well as multiple route entries for any packets being sent from an area 2 router to an external destination. You have the option of making this area a stub area.

[3] A default route is a route to an all-zeroes prefix with a prefix length of 0 (variously written as 0.0.0.0/0, 0/0, or 0.0.0.0 0.0.0.0), which is matched if the route lookup finds no more-specific route to a destination.

Figure 7.18. Packets sent from the router in area 2 to any external destination must send the packet through the ABR. A single default route to the ABR will work just as well for the routers in this area as individual route entries to each external destination.


OSPF defines a stub area as one in which type 5 LSAs are illegal. The area's ABR does not flood any type 5 LSAs into the area, and instead uses a type 3 LSA to advertise a default route into the area with itself as the next hop. If routers within a stub area have no specific information about external prefixes other than a default route to the ABR, they have no need for information about the ASBRs that advertise the external prefixes. Therefore, in addition to type 5 LSAs, an ABR blocks type 4 LSAs from entering a stub area.

To make stub areas work as expected, a few rules are defined:

  • Because no type 5 LSAs are allowed in a stub area, it follows that no ASBRs can appear in the area.

  • The ABR must know that its attached area is a stub area so that it knows to block type 5 LSAs and advertise a default route.

  • All routers in the area must know that they are in a stub area so that they will reject any type 5 LSAs that might be injected in the area by mistake. Otherwise, if some routers accepted the type 5 LSAs, the area databases would not be identical across the area, violating a basic tenet of link state routing.

  • Area 0 cannot be a stub area, because at a minimum the backbone area and the connected ABRs must know the specific external routes. Any or all other areas in the OSPF domain can be stub areas.

  • Virtual links (described later in this chapter) cannot be configured across a stub area.

The second and third rules say that all routers in the area, including the ABR, must know that they are in a stub area. Figure 7.19 shows Juniper Networks JUNOS and Cisco Systems IOS configurations for setting up a stub area. As you can see, both configurations clearly and simply designate area 2 as a stub area: IOS with the statement area 2 stub and JUNOS with the statement stub under the area 2 configuration.

Figure 7.19. Cisco Systems and Juniper Networks stub area configurations.

IOS Configuration: router ospf 1  area 2 stub  network 10.2.1.2 0.0.0.0 area 2  network 10.2.2.1 0.0.0.0 area 2 ! JUNOS Configuration: [edit] jeff@Juniper4# show protocols ospf area 0.0.0.2 {     stub;     interface fe-0/1/1.0;     interface so-0/0/0.0; } 


When a router is configured with a stub area, the OSPF Hellos it sends out all interfaces in that area have the E bit cleared (E = 0) in the Options field (Figure 7.20) to indicate that it does not support an external routing capabilitythat is, it does not accept or originate type 5 LSAs. If the router receives a Hello from a neighbor with the E bit set (E = 1), indicating that the neighbor does support external routing capability, the router drops the Hello. As a result new adjacencies do not form between neighbors whose E bits do not agree, and an existing adjacency is broken if the value of the E bit is changed in one neighbor but not the other.[4]

[4] Note that the E bit is always set in the Options field of type 5 LSAs, and it is set or cleared as appropriate in the options field of Database Description packets. But the value of the flag in the DD packet is informational only.

Figure 7.20. The E bit in the Options field of the OSPF Hello messages is set to indicate support of external routing capability (a nonstub area) and is cleared to indicate nonsupport of external routing capability (a stub area).


Stub areas prove useful when you want to minimize the size of an area's link state database, either to control performance problems (such as when you need to protect a few underpowered routers) or to simplify management and troubleshooting. But there can be a tradeoff when the stub area has multiple ABRs. A router in the area does not have specific metric information on the external destinations, but only default routes from each of the ABRs. As a result the router will choose the ABR whose default route is the lowest cost, and send all packets to external destinations it. Although that ABR is metrically closest to the router, the path from the ABR to the ASBR at which the packet exits the OSPF domain might not be the optimal path. Whether this reduction in routing accuracy within the domain is significant is something you must consider when deciding whether to make an area stubby.

7.3.5. Totally Stubby Areas

If a default route to the ABR is being used in a stub area to reach all destinations external to the OSPF domain to reduce the size of the area database, why not use the same default route to reach all destinations external to the area? This is the logic behind making an area totally stubby, so that the ABR blocks not only type 5 and type 4 LSAs, but also all type 3 LSAs with the exception of the type 3 LSA carrying the default route.

Figure 7.21 shows the IOS and JUNOS stub configurations similar to the previous example, but with an optional keyword that tells the ABR to block all Summary LSAs. Note that unlike the simple stub configuration, only the ABR has to be configured with the no-summaries option to create a totally stubby area, because only the ABR creates type 3 LSAs.

Figure 7.21. The addition of the no-summary (IOS) or no-summaries (JUNOS) keyword at the ABR makes an area totally stubby.

IOS Configuration: router ospf 1  area 2 stub no-summary  network 10.0.0.5 0.0.0.0 area 0  network 10.0.0.15 0.0.0.0 area 0  network 10.2.1.2 0.0.0.0 area 2  network 10.2.2.1 0.0.0.0 area 2 ! JUNOS Configuration: [edit] jeff@Juniper4# show protocols ospf area 0.0.0.0 {     interface so-0/0/1.0;     interface so-0/1/0.0; } area 0.0.0.2 {     stub no-summaries;     interface fe-0/1/1.0;     interface so-0/0/0.0; } 


Looking back to the very large database in Figure 7.16, you can see that in addition to the 23,349 external LSAs and 153 type 4 LSAs there are 2387 type 3 LSAs. By making this area totally stubby, you can reduce the area database from 25,903 LSAs to a mere 15 LSAs.

If you choose to make an area with a single ABR stub, there is little reason to not make it totally stubby. But if there are multiple ABRs, you must again consider the price of reduced routing accuracywith totally stubby areas routing accuracy is reduced not only to destinations external to the domain, but also to destinations internal to the OSPF domain.

7.3.6. Not-So-Stubby Areas

Imagine a case in which an ASBR is originating a large number of type 5 LSAs into your OSPF domain, and you want to keep these LSAs out of a certain area by making it stubby. But you also need to place an ASBR in that same area to reach other external destinations. Stub areas are an all-or-nothing solution: If you want to keep some type 5 LSAs out of the area, you must keep all type 5 LSAs out of the area. Not-so-stubby areas (NSSAs)[5] allow you to be more selective, preventing an ABR from flooding type 5 LSAs into an area while at the same time permitting an ASBR to reside in the area. Continuing to make type 5 LSAs illegal in the area, as with regular stub areas, and carrying any external prefixes advertised by an ASBR within the area in a different LSA type accomplishes that objective.

[5] Rob Coltun and Vince Fuller, "The OSPF NSSA Option," RFC 1587, March 1994.

The LSA that makes NSSAs possible is a type 7 LSA, unsurprisingly called an NSSA LSA. Figure 7.22 shows the LSA's format. You can readily see that the format is exactly the same as the format of the type 5 LSA (Figure 5.23), except that the value of the type field in the header is 7.

Figure 7.22. The NSSA LSA format.


The rules for using the forwarding address field in the type 7 LSA differ somewhat from the rules for using the forwarding address field in the type 5 LSA. Type 5 LSAs can have the forwarding address set to 0.0.0.0, indicating that packets to the advertised prefix should be sent to the originating ASBR, or to the address of its external neighbor's interface if the connecting link is advertised into OSPF as an internal route,[6] or some other internal address for a "route server" function. The forwarding address of type 7 LSAs must be either the address of the external peer's interface address or, if the connecting link is not advertised as an OSPF internal route, one of the ASBR's interface addresses (normally the ASBR's RID).

[6] Where this might happen is when the external prefix is learned from an External BGP (EBGP) session, which sets the next hop of the route to the interface address of the router in the adjacent AS that is advertising the prefix.

NSSAs use the fifth bit in the Options field to indicate functional support. Notice in Figure 7.20 that this bit is labeled as the N/P bit. This is because the same bit serves different purposes in an NSSA depending upon whether the Options field is in a Hello message or in a type 7 LSA.

In a Hello, the fifth bit of the Options field is the N bit and indicates support (N = 1) or nonsupport (N = 0) of type 7 LSAs. As with the E bit, if the N bit in the Hellos exchanged between two neighbors does not match the Hellos are dropped and an OSPF adjacency is not formed. This ensures that all routers in an area agree on whether they are in an NSSA.

In a type 7 LSA, the fifth bit of the Options field is the P (Propagate) bit. This bit enables flexibility in the NSSA by telling the ABR how it should handle the type 7 LSA. Type 7 LSAs have an area flooding scopethat is, they are not permitted outside of the area in which they are originatedbecause there is no assurance that they will be understood in other areas. So, if you want an external prefix advertised by an NSSA ASBR to be known throughout the OSPF domain, the P bit of the type 7 LSA carrying the prefix is set to 1. When the ABR receives this LSA, it translates the LSA into a type 5 LSA and floods it to all its connected nonstub areas. The type 5 LSA, having AS flooding scope, makes the prefix known throughout the OSPF domain.

But you might want a prefix advertised by the NSSA ASBR to be known only within the NSSA. In this case, the P bit of the prefix's type 7 LSA is cleared, telling the ABR to not translate the LSA into a type 5 LSA. Because the type 7 LSA is not permitted outside its area, the prefix is not known outside the area.

An interesting application of an NSSA is one in which you want all routers in one area to send all packets with external destinations to an ASBR in the area. At the same time, you want routers elsewhere in the OSPF domain to be more selective in how they forward packets to external destinations by selecting the best route from prefixes advertised by multiple ASBRs. In this case the NSSA ASBR can originate a single type 7 LSA advertising a default route. Packets with destination addresses not matching any of the internal prefixes advertised in type 3 LSAs by the ABR are then routed out of the domain at the NSSA ASBR. As with other type 7 LSAs, you have the option of setting the P bit in a type 7 LSA carrying a default route, causing the ABR to translate it into a type 5 LSA and advertising the default route into the rest of the domain. There are a few special rules for ABRs attached to an NSSA. First, unlike with totally stubby areas the ABR should always advertise all prefixes internal to the OSPF domain into the NSSA in type 3 LSAs. Otherwise, you run the risk of incorrectly matching an external route to the NSSA ASBR and sending a packet out of the domain when it should be routed through the ABR to an internal destination.

Conversely, if the ABR advertises a default route into the NSSA it should be sent in a type 7 LSA rather than a type 3. This is because prefixes advertised in type 3 LSAs are always considered internal, and prefixes advertised in type 7 LSAs are always considered external. Internal prefixes are always preferred over external prefixes, so a default prefix advertised in a type 3 LSA would always be chosen over any more-specific external route or default route advertised in a type 7 LSA, again resulting in incorrect routing.

Then there is the case in which an ABR attached to an NSSA is also an ASBR. In this situation, the ABR/ASBR will advertise its external prefixes into the NSSA using type 7 LSAs, and the same prefixes into the backbone and any attached non-NSSAs using type 5 LSAs. However, an ABR never sets the P bit of any type 7 LSA it originates. Otherwise, the risk is run that another ABR attached to the same NSSA will translate the LSA into a type 5 and flood it, possibly causing inaccurate routing.

7.3.7. Address Summarization

The advantage of stub areas is that some set of prefixes, whether all prefixes external to the OSPF domain or all prefixes external to the area, are represented in the area with a default route, thereby reducing the LS database size. The default route is nothing more than a prefix that summarizes all possible IP addresses.

A summary address[7] represents an aggregation of all prefixes that are longer than the summary address but whose beginning bits match the summary address. For example, consider the following prefixes:

[7] Summary addresses are also called address aggregates.

  • 192.168.1.0/25

  • 192.168.1.128/25

These two prefixes can be represented with the single summary address 192.168.1.0/24.

The 24-bit summary matches the first 24 bits of all the longer prefixes it represents. When performing an IP route lookup, a router always chooses the prefix with the longest number of bits matching the destination address of the IP packet. For example, if a router does a route lookup for a destination address 192.168.1.135 and 192.168.1.0/24 is the longest matching prefix in the routing table, that route is selected for forwarding the packet. But if both 192.168.1.0/24 and 192.168.1.128/25 exist in the routing table the latter, longer route prefix is selected.

From this example, you can see that a summary route always has a shorter prefix length than the prefixes it summarizes. That is why a default route is a summary of all possible IP prefixes: Any IP prefix has a longer prefix length than the 0 length of the default.

Summary routes can be used to help with OSPF area scalability in two ways:

  • An ABR can summarize a set of prefixes in a nonbackbone area into the backbone area.

  • An ASBR can summarize external prefixes into the OSPF domain.

Note that because all routers in an area must have identical LS databases, address summaries can be generated only at an area border or at the domain boundary. A router internal to an area cannot summarize a set of prefixes in the same area, or inconsistent databases within the area would result.

The backbone area cannot be a stub area because by definition it is the transit area for all inter-area traffic. But by summarizing all nonbackbone area prefixes into the backbone, you can significantly reduce the size of the backbone database. How significant that reduction is depends on how many prefixes you can represent with a single summary route. The ideal case is one in which all prefixes in an area can be represented with a single summary route. For example, if you are assigning all prefixes in your OSPF domain from the aggregate address block 172.16.0.0/16, you might assign all backbone prefixes from 172.16.0.0/24, and then all other area prefixes subsequently from blocks 172.16.1.0/24, 172.16.2.0/24, 172.16.3.0/24, and so on. By having each ABR advertise only its area summary address into the backbone, and blocking all more-specific area prefixes, the backbone database will contain only as many type 3 LSAs as there are ABRs in the network.

When this approach is used, it is common to see the aggregate assigned to an area also used as the AID. If the prefixes in an area are assigned from the aggregate 172.16.5.0/24, for example, the AID of that area is 172.16.5.0. This can prove handy for operational understanding of the network. An ASBR can also summarize external prefixes into an areaeither using one or more address aggregates to represent some subsets of external IP addresses, or using a default address to represent all external prefixes. With good summarization from ABRs and defaults from the ASBRs, you can make the backbone database almost as small as that of a stub area.

The price you pay for summarization is the same as you pay for stub areas with multiple ABRs: a possible loss of routing accuracy. If multiple ABRs into an area are summarizing the area prefixes, there is no way to choose the best ABR to a particular destination in the area. Instead, a router in the backbone just selects the closest ABR. Similarly, if multiple ASBRs advertise a summary or default, a router just selects the closest ASBR, which might not necessarily be the best ASBR for a given destination.

7.3.8. Virtual Links

OSPF offers a tool called a virtual link that enables you to logically connect an ABR to a backbone area when a physical connection is not available. Virtual links have two applications:

  • To connect to the backbone an area that has no direct physical link to the backbone

  • To prevent or repair partitions of the backbone area

Figure 7.23 illustrates the first application. Area 2 has been added to the OSPF domain, but a physical link from that area's ABR to the backbone is not available. An example of where such a situation might arise is when two OSPF domains are being merged into one. Area 2 is connected to the backbone by creating a virtual link through area 1 between ABR A and ABR B. Although the packets crossing the virtual link actually pass through routers RTC and RTD in area 1, OSPF interprets the virtual link as a direct link to a backbone router.

Figure 7.23. A virtual link can be used to connect an ABR to the backbone when there is no direct physical link to the backbone area.


Figure 7.24 illustrates the second application. Here, the backbone area is vulnerable to partitioning if either the link between ABR A and RTE or the link between ABR B and RTE fails, or if RTE itself fails. If any of those failures occur, areas 1 and 2 would still have connectivity to area 3 but they would not have connectivity to each other because ABRs A and B cannot "see" each other through area 3. A virtual link between ABRs C and D in area 3 is treated as a link in the backbone area, making a more robust backbone. Although the virtual link actually passes through RTF, OSPF again sees it as a direct connection between the two ABRs.

Figure 7.24. A virtual link can be used to reduce the partitioning vulnerability in a poorly designed backbone.


When a virtual link is configured between ABRs, the ABRs attempt to form a virtual adjacency. When that adjacency is established, OSPF treats the link as an unnumbered point-to-point backbone link. OSPF packets flow over the link, and the link is included in backbone type 1 LSAs.

Keep in mind a few rules when using virtual links:

  • The virtual link must be configured through a single areathat is, ABRs at each end of the link must have an attachment to a common area.

  • Although the virtual link is considered by OSPF as a backbone link, it must be configured through a nonbackbone area.

  • The cost of a virtual link is not configurable. Instead, it is always the cost of the intra-area path between the two ABR endpoints.

  • Virtual links cannot be configured in stub areas.

  • An ABR describes the neighboring ABR at the other end of a virtual link in its neighbor table by the neighbor's RID.

  • An ABR that has at least one fully adjacent virtual link sets the V bit in its type 1 LSAs.

  • An ABR gives the virtual link a Link Type of 4 in its type 1 LSAs.

  • The Link ID field in a type 1 LSA describing a virtual link is set to the RID of the neighboring ABR.

  • The Data Link field in a type 1 LSA describing a virtual link is set to the IP address of the originating router's interface associated with the virtual link.

  • OSPF packets sent over the virtual link are routed within the link's transit area as intra-area packets. This is the only time OSPF packets are not limited to directly connected neighbors.

  • The AID of packets sent over the virtual link is 0. This is the only situation in which a router's interface can be attached to a nonzero area and receive an OSPF packet with an AID other than that area's AID.

  • Hellos on virtual links are unicast to neighboring ABRs, as would be expected of point-to-point links.

  • No network address mask is associated with a virtual link, so the Address Mask field in the Hellos sent on the link is set to 0.0.0.0.

  • The Interface MTU field in Database Description packets sent over virtual links is set to 0.

  • Type 5 LSAs are never flooded over virtual links because they appear in all areas anyway (except for stub areas, where virtual links are not permitted).

Figure 7.25 shows an application of a virtual link. Area 1 is connected to two different areas with AIDs of 0. Such a situation might have arisen from two OSPF domains being merged in such a way that the only connection point between them is through area 1.

Figure 7.25. Two areas with AID 0 are linked to area 1.


No problem is apparent in the neighbor tables in Juniper2 and Cisco2 in Figure 7.26: Both ABRs show full adjacencies to both of their neighbors. But examining the OSPF entries in the routing tables of Juniper1 and Cisco1, you can see that both routers have learned the prefixes in area 1 but neither of them have learned the prefixes in the opposing area 0: Juniper1 does not have entries for 10.2.1.0/24 or 10.2.2.0/24, and Cisco1 does not have entries for 192.168.2.0/24 or 192.168.6.0/24.

Figure 7.26. The neighbor tables of both Juniper2 and Cisco2 in Figure 7.25 show the expected adjacencies.

[View full width]

jeff@Juniper2> show ospf neighbor Address Interface State ID Pri Dead 192.168.2.1 fxp2.0 Full 1.1.1.1 128 32 192.168.3.1 fxp3.0 Full 1.1.1.3 128 39 --------------------------------------------------------------------- Cisco2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.3 128 FULL/DR 00:00:38 10.1 .1.2 Ethernet0 2.2.2.1 1 FULL/DR 00:00:38 10.2 .1.2 Ethernet1


Figure 7.27. Juniper1 and Cisco1 in Figure 7.25 have both learned the prefixes in area 1, but neither has learned the prefixes in the opposing area 0.

[View full width]

jeff@Juniper1> show route protocol ospf inet.0: 16 destinations, 17 routes (15 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.1.1.0/24 *[OSPF/10] 00:15:28, metric 12 > to 192.168.2.2 via fxp1.0 192.168.3.0/24 *[OSPF/10] 02:44:11, metric 2 > to 192.168.2.2 via fxp1.0 ----------------------------------------------------------------------- Cisco1#show ip route ospf 10.0.0.0/24 is subnetted, 3 subnets O IA 10.1.1.0 [110/20] via 10.2.1.1, 00:18:38, Ethernet0 O IA 192.168.3.0/24 [110/21] via 10.2.1.1, 00:18 :38, Ethernet0


Adding a virtual link between the two ABRs, Juniper2 and Cisco2, as depicted in Figure 7.28, solves the problem. Figure 7.29 shows the configurations of these ABRs. Although the syntax differs, the information supplied to the router is the same: The RID of the neighbor at the other end of the link and the transit area are specified.

Figure 7.28. A virtual link connecting the two ABRs through area 1 allows the full exchange of prefixes.


Figure 7.29. A virtual link is configured between Juniper2 and Cisco2.

[View full width]

Juniper2: [edit] jeff@Juniper2# show protocols ospf area 0.0.0.0 { virtual-link neighbor-id 2.2.2.2 transit-area 0.0.0.1; interface fxp2.0; } area 0.0.0.1 { interface fxp3.0; } ---------------------------------------------------------------------- Cisco2: router ospf 1 router-id 2.2.2.2 area 1 virtual-link 1.1.1.2 network 10.1.1.1 0.0.0.0 area 1 network 10.2.1.1 0.0.0.0 area 0 !


The OSPF entries in the routing tables of Juniper1 and Cisco1 are again displayed in Figure 7.30. You can see that the two routers have now learned the prefixes in the other area 0.

Figure 7.30. Juniper1 and Cisco1 in Figure 7.28 have learned the prefixes in the opposing area 0.

[View full width]

jeff@Juniper1> show route protocol ospf inet.0: 18 destinations, 19 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.1.1.0/24 *[OSPF/10] 00:38:28, metric 12 > to 192.168.2.2 via fxp1.0 10.2.1.0/24 *[OSPF/10] 00:26:15, metric 22 > to 192.168.2.2 via fxp1.0 10.2.2.0/24 *[OSPF/10] 00:26:15, metric 32 > to 192.168.2.2 via fxp1.0 192.168.3.0/24 *[OSPF/10] 00:38:42, metric 2 > to 192.168.2.2 via fxp1.0 ---------------------------------------------------------------------- Cisco1#show ip route ospf 10.0.0.0/24 is subnetted, 3 subnets O IA 10.1.1.0 [110/20] via 10.2.1.1, 00:29:16, Ethernet0 O IA 192.168.6.0/24 [110/23] via 10.2.1.1, 00:29 :16, Ethernet0 O IA 192.168.2.0/24 [110/22] via 10.2.1.1, 00:29 :16, Ethernet0 O IA 192.168.3.0/24 [110/21] via 10.2.1.1, 00:29 :16, Ethernet0


Figure 7.31 shows the entries in the interface databases of Juniper2 and Cisco2 for the virtual link between them. You can observe in these entries that the default Hello interval, router dead interval, retransmit interval, and transmit (transit) delay for a point-to-point link are used. All of these parameters are configurable, as is authentication between the neighbors.

Figure 7.31. The virtual link appears as an entry in the interface database of Juniper2 and Cisco2.

[View full width]

jeff@Juniper2> show ospf interface vl-2.2.2.2 extensive Interface State Area DR ID BDR ID Nbrs vl-2.2.2.2 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 Type Virtual, address 192.168.3.2, mask 0.0.0.0, MTU 0, cost 11 adj count 1 Hello 10, Dead 40, ReXmit 5, Not Stub -------------------------------------------------------------------- Cisco2# show ip ospf virtual-links Virtual Link OSPF_VL2 to router 1.1.1.2 is up Run as demand circuit DoNotAge LSA not allowed (Number of DCbitless LSA is 24). Transit area 1, via interface Ethernet0, Cost of using 11 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:05 Adjacency State FULL Index 2/1, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec


Although virtual links are easy to configure, they nonetheless add complexity, making the network harder to understand and troubleshoot. You should therefore consider them a tool of last resort. In the hypothetical domain merge depicted in Figure 7.25, for example, you should consider the following alternatives:

  • Can a physical link from Cisco2 to the existing backbone area be established?

  • Can area 1 be reconfigured as area 0 to make a contiguous backbone topology?

  • Can the merging domain be reconfigured as area 1?

  • Rather than merge the OSPF domains, can BGP or static routes be used to connect them?

As for backbone topologies, a robust backbone with enough physical links to withstand at least two simultaneous link failures is the foundation of a good OSPF design. Virtual links are a poor substitute for doing the design right in the first place. When virtual links must be usedeither for merging domains or for reducing backbone vulnerabilitiesthey should be considered a temporary feature of your network, put in place only until a better alternative is implemented.




OSPF and IS-IS(c) Choosing an IGP for Large-Scale Networks
OSPF and IS-IS: Choosing an IGP for Large-Scale Networks: Choosing an IGP for Large-Scale Networks
ISBN: 0321168798
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Jeff Doyle

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net