7.3. OSPF AreasOSPF 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 AreasNormal 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.
Figure 7.5. An example multi-area OSPF network with no area 0.
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.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.
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.
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 AreasA 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:
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:
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:
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:
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.
7.3.3. External Prefixes and OSPF ScalingA 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.
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.
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.
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:
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 AreasIf 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.
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:
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.
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]
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 AreasIf 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.
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 AreasImagine 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.
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).
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 SummarizationThe 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:
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:
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 LinksOSPF 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:
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:
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.
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.
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.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.
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:
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. |