text:
The Art of Strategy: "Those who are victorious plan effectively and change decisively. They are like a great river that maintains its course but adjusts its flow . . . they have form but are formlxess. They are skilled in both planning and adapting and need not fear the result of a thousand battles; for they win in advance, defeating those that have already lost."--Sun Tzu, Chinese Warrior and Philosopher, 100 B.C.
This chapter covers a variety of subjects all relating to routing and designing OSPF networks. The foundation laid in the previous chapters is further expanded as the discussion of OSPF performance and design issues is expanded. Within each of the design sections, a series of "golden design rules" is presented. These rules will help the reader understand the constraints and recommendations of properly designing each section of an overall OSPF network. In many cases, examples that draw upon the material are presented to further reinforce key topics and ideas. The author would like to recognize the previous works presented on OSPF routing and design done by Dennis Black and Bassam Halabi. Both gentlemen penned internal Cisco documents and have done a commendable job of presenting the OSPF-related material in an easy-to-understand format. This chapter is built from that framework. In some cases, the material is presented directly from the original text, but the majority of the information has been expanded upon. For additional information on the two sources used in this chapter, please see the bibliography.
OSPF is a link-state protocol that uses a link-state database (LSDB) in order to build and calculate the shortest path to all known destinations. It is through the use of the SPF algorithm that the information contained within the LSDB is calculated into routes.
The shortest path algorithm by itself is quite complicated, and its inner workings are really beyond the scope of this book. But understanding its place and operation is essential to achieving a full understanding of OSPF. The text that follows reviews the operation of calculating the shortest path and then applies that to an example.
The following is a very high level, simplified way of looking at the various steps used by the algorithm:
The shortest path is calculated using the Dijkstra algorithm. The algorithm places each router at the root of a tree and calculates the shortest path to each destination based on the cumulative cost required to reach that destination. Each router will have its own view of the network's topology even though all the routers will build a shortest path tree using the same LSDB. This view consists of what paths and their associated costs are available to reach destinations throughout the network. In Figure 5-1, the Headquarters router is at the base of the tree (turn figure upside down). The following sections indicate what is involved in building a shortest path tree.
The cost or metric associated with an interface in OSPF is an indication of the overhead required to send packets across that interface. For example, in Figure 5-1, for Headquarters to reach network 22.214.171.124, a cost of 20 (10+5+5) is associated with the shortest path.
The cost of an interface is inversely proportional to the bandwidth of that interface. A higher bandwidth indicates a lower cost. There is more overhead (higher cost) and time delays involved in crossing a 56K serial line than crossing a 10M Ethernet line. The formula used by OSPF to calculate the cost is
Cost=100,000,000/bandwith in bps
For example, it will cost 10 EXP8/10 EXP7=10 to cross a 10M Ethernet line and will cost 10 EXP8/1544000=64 to cross a T1 line. By default, the cost of an interface is calculated based on the bandwidth, but you can place a cost on an interface through the use of the ip ospf cost [value] interface command.
In Cisco IOS release 10.2 and earlier, OSPF assigned default metrics to a router's interface, regardless of the bandwidth actually attached to the interface. For example, it would give a 64K and a T1 link the same metric. This required the user to override the default value in order to take advantage of the faster link. This overriding was accomplished through the use of the ip ospf cost [value] command, which would be placed on each interface as desired.
In Cisco IOS 10.3 and later, OSPF by default now calculates the cost (metric) for an interface according to the bandwidth of the interface. If needed, this feature can also be disabled through the use of the no ospf auto-cost-determination router command. You will then be able to customize the routing costs as needed.
Assum e you have the network diagram as shown in Figure 5-1 with the indicated interface costs. To build the shortest path tree for the Headquarters router, you would have to make it the root of the tree and calculate the smallest cost for each destination.
The directions of the arrows in this figure are used to calculate the route's cost. For example, the cost of the Manufacturing router's interface to network 184.108.40.206 is not relevant when calculating the cost to 126.96.36.199.
Headquarters can reach 192.213.11. 0 via the Manufacturing router with a cost of 20 (10+5+5). Headquarters can also reach 126.96.36.199 via the Sales router with a cost of 25 (10+15) or via the manufacturing router with a cost of 20 (10+5+5).
In case equal cost paths to the same destination exist, Cisco's implementation of OSPF will keep track of up to six next hops to the same destination.
To build the shortest path tree for Headquarters, you would have to make Headquarters the root of the tree and calculate the smallest cost for each destination. After the router builds the shortest path tree, it will start building the routing table accordingly. Directly connected networks will be reached via a metric (cost) of 0 and other networks will be reached according to the cost as calculated in the tree.
OSPF Convergence
One of the most attractive features about OSPF is its capability to quickly adapt to topology changes. The two essential components to routing convergence are
OSPF uses two mechanisms to detect topology changes. Interface status changes (such as carrier failure on a serial link) is the first mechanism. The second mechanism is the failure of OSPF to receive a hello packet from its neighbor within a timing window called a dead timer. After this timer expires, the router assumes the neighbor is down. The dead timer is configured using the ip ospf dead-interval interface configuration command. The default value of the dead timer is four times the value of the hello interval, which results in a dead timer default of 40 seconds for broadcast networks and 2 minutes for nonbroadcast networks.
To summarize, fault detection by OSPF can differ slightly depending upon the media type. In general, the failure of a hello packet can supersede the failure of keepalive packets. The media type will affect how OSPF detects a failure as shown in the following list:
After a failure has been detected, the router that detected the failure floods an LSA packet with the change information to all routers to which it is directly connected. The detecting router will continue to flood this information until each router to which it is directly connected acknowledges its receipt.
All of the routers will recalculate their routes using the Dijkstra (or SPF) algorithm. Remember that each router builds its routing table based upon the LSDB, and this change alters the contents of that database. Therefore, the router will rebuild its routing tables with it as the base of the route tree. The time required to run the algorithm depends on a combination of the size of the area and the number of routes in the database.
OSPF load balances along equal cost paths, this in turn allows for almost immediate convergence. OSPF can also l oad balance across four equal cost paths.
OSPF Design Guidelines
The OSPF protocol, as defined in RFC 1583 and RFC 2178, provides a high functionality open protocol that enables multiple vendor networks to communicate using the TCP/IP protocol family. Some of the benefits of OSPF are: fast convergence, VLSM, authentication, hierarchical segmentation, route summarization, and aggregation, all of which are needed to handle large and complicated networks.
Whether you are building an OSPF internetwork from the ground up or converting your internetwork to OSPF, the design guidelines highlighted in the following sections provide a foundation from which you can construct a reliable, scalable OSPF-based environment.
Different people have different approaches to designing OSPF networks. The important thing to remember is that any protocol can fail under pressure. The idea is not to challenge the protocol but rather to work with it in order to get the best performance possible from your network.
The OSPF RFCs 1583 and 2178 do not specify several very important considerations that are essential to a properly designed OSPF network. But RFC 2178 is a very good resource to consult when laying out the design of your OSPF network. It is also backward compatible with RFC 1583.
The two design activities that are critically important to a successful OSPF implementation are defining area boundaries and assigning addresses. Ensuring that these activities are properly planned and executed will make all the difference in your OSPF implementation.
OSPF works best in a hierarchical routing environment. The first and most important decision when designing an OSPF network is to determine which routers and links are to be included in the backbone (area 0) and which are to be included in each area. The following are three important characteristics to OSPF and its need for a hierarchical routing structure:
Several important items to consider when designing the topology for an OSPF network (discussed at length in the sections that follow) are as follows:
OSPF uses the CPU-intensive SPF algorithm. Experience has shown that 40 to 50 routers per area is the optimal upper limit for OSPF. The number of calculations that must be performed by the router given n link-state packets (LSPs) is proportional to n log n. As a result, the larger and more unstable the area, the greater the likelihood for performance problems associated with OSPF routing recalculation.
Generally, an area should have no more than 50 routers. That does not mean that networks with 60 or 70 routers in an area won't function, but why experiment with stability if you don't need to? Areas with unstable links should be smaller.
One of the main problems with areas is that network administrators let their backbone area grow too large. Try to outline the logical view of the network from the start, and remember that it doesn't hurt to start creating that other area before it is needed. A good rule of thumb is to plan for maximum growth coupled with long term planning. This has the added benefit of ensuring your network can handle rapid growth. In this case, planning for too much is never a bad thing to do.
However, those recommendations are made in accordance with "official" Cisco recommendations regarding OSPF networks. Studies and real world implementations have gone further. For example, the statistics in Table 5-1 came from the "IETF OSPF Standard Report."
It is good to know that OSPF has been thoroughly tested and can withstand scaling to a phenomenal size.
ABRs will keep a copy of the database for all areas they service. If a router is connected to five areas, for example, it will have to keep a list of five different databases. It is better not to overload an ABR; you should try to spread the areas over other routers. The ideal design is to have each ABR connected to two areas only, the backbone, and another area, with three areas being the upper limit. Figure 5-2 shows the difference between one ABR holding five different databases, including area 0 (part a) and two ABRs holding three databases each (part b).
These are just guidel ines; the more areas you attach per ABR, the lower the performance you get from that router. In some cases, the lower performance can be tolerated, but end users probably won't see it that way.
OSPF floods all link-state changes to all routers in an area. Routers with many neighbors have the most work to do when link-state changes occur. In general, any one router should have no more than 60 neighbors.
The number of routers connected to the same LAN is also important. Each LAN has a DR and BDR that build adjacencies with all other routers. The fewer neighbors that exist on the LAN, the smaller the number of adjacencies a DR or BDR have to build. You can see in Figure 5-3 that the more neighbors the DR or BDR has, the more work they must do.
This, of course, depends on how much processing power your router has. You could always change the OSPF priority to select your DR. Also, if possible, try to avoid having the same router be the DR on more than one segment. If DR selection is based on the highest RID, then one router could accidentally become a DR over all segments to which it is connected. This router would be doing extra effort while other routers are idle.
A router must run the link-state algorithm for each link-state change that occurs for every area in which the router resides. Every area border router is in at least two areas (the backbone and one area). In general, to maximize stability, one router should not be in more than three areas.
In general, th e DR and BDR on a LAN have the most OSPF work to do. It is a good idea to select routers that are not already heavily loaded with CPU-intensive activities to be the DR and BDR. This can be accomplished using the ip ospf priority [priority] command, which will allow you to organize the DRs as needed.
In addition, it is generally not a good idea to select the same router to be the DR on more than one LAN simultaneously. These guidelines will help ensure that no single broadcast link will have too many neighbors with too much hello traffic.
Nonbroadcast multiaccess (NBMA) clouds, such as Frame Relay or X.25, are always a challenge. The combination of low bandwidth and too many LSAs is a recipe for problems--even for OSPF. A partially-meshed topology has been proven to behave much better than a fully-meshed network topology. Figure 5-4 shows the benefits and differences between the two topologies.
A carefully laid out point-to-point or point-to-multipoint network can in some cases work much better than multipoint networks that have to deal with DR issues.
Although covered in previous chapters, these issues as related to the LSDB are very important and deal directly with its operation in relation to the topology of the network.
Your ability to scale an OSPF internetwork depends on your overall network structure and IP addressing scheme. As outlined in the discussions concerning network topology and route summarization, adopting a hierarchical addressing environment and a structured address assignment will be the most important factors in determining the scalability of your internetwork. Network scalability is affected by both operational and technical considerations.
Operationally, OSPF networks should be designed so that areas do not need to be split to accommodate growth. Address space should be reserved to permit the addition of new areas. Scalability should always be taken into consideration when designing your network. All routers keep a copy of the LSDB. As the network grows, they will eventually reach a point where the database becomes too large, resulting in inefficiency in your routing. Additionally, the LSAs will be flooded throughout the network, resulting in a congestion problem. The capability of your OSPF network to scale properly is determined by a multitude of factors, including the following:
In many cases, personnel who work directly with networks are not always in complete control of some of the factors discussed in this section. Of course, bigger is better; unfortunately, it is also more expensive.
An OSPF router stores all of the link states for all of the areas that it is in. In addition, it can store summary and external routes. Careful use of route summarization techniques and the creation of stub areas can reduce memory use substantially.
It is not easy to determine the exact amount of memory needed for a particular OSPF configuration. Memory issues usually come up when too many external routes are injected in the OSPF domain. A backbone area with 40 routers and a default route to the outside world would have less memory issues compared with a backbone area with 4 routers and 33,000 external routes being injected into OSPF. Router memory could also be conserved by using a good OSPF design. Summarization at the area border routers and use of stub areas could further minimize the number of routes exchanged.
The total memory used by OSPF is the sum of the memory used in the routing table ( show ip route summary ) and the memory used in the LSDB. The following numbers are a "rule of thumb" estimate. Each entry in the routing table will consume between approximately 200 and 280 bytes plus 44 bytes per extra path. Each LSA will consume a 100 byte overhead plus the size of the actual LSA, possibly another 60 to 100 bytes (For router links, this depends on the number of interfaces on the router). These amounts should be added to memory already used by other processes and by the IOS itself.
If you really want to know the exact number, you can do a show memory with and without OSPF being turned on. The difference in the processor memory used would be the answer.
Consider getting and keeping available a backup copy of the router configuration beforehand, of course.
Normally, a routing table using less than 500K bytes could be accommodated with 2 to 4MB of RAM; large networks that have routing tables greater than 500K might need 8 to 16MB. They might even need 32 to 64MB if full routes are injected from the Internet.
An OSPF router uses CPU cycles whenever a link-state change occurs. Thus, keeping the OSPF areas small and using route summarization dramatically reduces usage of the router's CPU and creates a more stable environment within which OSPF can operate.
OSPF send s partial LSA updates when a link-state change occurs. The updates are flooded to all routers in the area. In a quiet network, OSPF is a quiet protocol, go figure; aren't all protocols that way? Sorry, it had to be said. In a network with substantial topology changes, OSPF minimizes the amount of bandwidth used for customer traffic.
The two kinds of security applicable to routing protocols are as follows:
All routers within an area must agree on the value of the authentication field. Because OSPF is a standard protocol available on many platforms, including some hosts, using the authentication field prevents the inadvertent startup of OSPF in an uncontrolled platform on your network and reduces the potential for instability.
You might think it is possible to control the routing information within an OSPF area. Remember though, that for OSPF to operate properly, all routers within an area must have the same data. As a result, it is not possible to use route filters in an OSPF network to provide security because OSPF exchanges route information through the use of LSAs, not routes. OSPF then calculates the route to a destination based upon the LSA.
Area Design Considerations
When creating large-scale OSPF internetworks, the definition of areas and assignment of resources within areas must be done with a pragmatic view of your OSPF internetwork. This assignment of resources includes both physical and logical networking components so that optimal performance will result.
Areas are essentially little networks within the larger network, and as such, they route only necessary traffic within themselves, thereby reducing overall network traffic. There are many reasons that using OSPF's capability to create areas would result in benefits for your network. The use of areas is necessary so the OSPF's required hierarchical structure can be put into place. The topology of the network within an area is invisible to anything outside of that area, as demonstrated in Figure 5-5.
Non-stub areas carry a default route, static routes, intra-area routes, and external routes. An area must be a non-stub area when it contains a router that uses both OSPF and any other protocol, such as the Routing Information Protocol (RIP). Such a router is known as an autonomous system border router (ASBR). An area must also be a non-stub area when a virtual link is configured across the area. Non-stub areas are the most resource-intensive type of area.
The LSDB is everywhere within an OSPF network. When encountered in an area, the LSDB will be identical in each router within the area. The LSDB will also contain a variety of LSAs, as follows:
Area partitions will typically occur within an area. OSPF does not actively attempt to repair area partitions. When an area becomes partitioned the new sections simply become separate areas. As long as the backbone can reach both of them, it will continue to route information to them.
To maintain routing, an IP address range must not be spread across the split area. This assumes that some destinations will now require inter-area routing as a result. If this does occur, then some destinations will become unreachable and routing loops could occur. In an outage condition this information is not very helpful, but when designing areas, assign IP address ranges accordingly so that growth can be handled easier in the future should a new area be needed.
The backbone should never be partitioned, but if it does occur, then consider using a virtual link to temporarily repair the backbone. Virtual links are discussed later in this chapter. Even though partitioning your OSPF backbone is considered bad practice, there are times when it could be beneficial, so OSPF does allow it. For example, a company is trying to merge two separate OSPF networks into one network with a common area 0. In other instances, virtual links are added for redundancy in case some router failure causes the backbone to be split into two. Whatever the reason might be, a virtual link can be configured between separate ABRs that touch area 0 from each side and have a common area (see Figure 5-6).
In Figure 5-6, two area 0s are linked together via a virtual link. In case a common area does not exist, an additional area, such as area 3, could be created to become the transit area. In case any area that is different than the backbone becomes partitioned, the backbone will take care of the partitioning without using any virtual links. One part of the partitioned area will be known to the other part via inter-area routes rather than intra-area routes.
When you begin to design your OSPF network, it will be necessary for you to start with the area 0 the backbone area of every OSPF network. There are two very important rules that, if followed, will get you started properly:
The following are more general rules and OSPF capabilities that will help ensure that your OSPF network remains flexible and provides the kind of performance needed to deliver reliable service to all of its users:
If a particular location is densely connected, create an area specifically for nodes at that location. This will enable OSPF to better handle a large, dense cluster of nodes, and it will enable more efficient management and routing.
If your internetwork includes unstable links, consider implementing smaller areas to reduce the effects of route flapping. Whenever a route is lost or comes online, each affected area must converge on the new topology. The Dijkstra algorithm will run on all the affected routers. By segmenting your network into smaller or multiple areas, you can isolate unstable links and deliver more reliable overall service. This is always of benefit to everyone concerned.
A contiguous OSPF area is one in which a continuous path can be traced from any router in an area to any other router in the same area. This does not mean that all routers must share a common network media (like Ethernet). Refer to Figure 5-7 which demonstrates both concepts.
Ideally, areas should have multiple redundant internal and external links to prevent partitioning.
There is a group of tunable OSPF parameters that can help you design an area that will more readily meet your network's specific needs. All of these commands and their associated values generally default to good values. If you are considering changing them, it is good practice to change them in all routers.
Remember, Cisco routers will not show default values in their configuration files.
The tunable OSPF parameters are as follows:
The two most critical aspects of designing an area include determining how the area is addressed and determining how the area is connected to the backbone. Areas should have a contiguous set of network and/or subnet addresses whenever possible. You can have an area with any combination of networks and subnets, but it is strongly discouraged. Whenever possible, you should have an area consist of grouped networks and subnets so that route summarization can be easily accomplished. Without a contiguous address space, the implementation of route summarization is impossible.
The routers that connect an area to the backbone are called ARBs. Areas can have a single ABR or they can have multiple ABRs. In general, you should have more than one ABR per area to minimize the chance of the area becoming disconnected from the backbone.
The OSPF backbone (also known as area 0) is extremely important. If more than one area is configured in an OSPF network, one of these areas has to be area 0. When designing networks, it is good practice to start with area 0 and then expand into other areas later on. To summarize, the OSPF backbone is the part of the OSPF network that acts as the primary path for traffic that is destined to other areas or networks.
Accepted network design theory recommends a three-tiered approach (see Figure 5-8). This theory states that there should never be more than three tiers with a maximum of six router hops across the farthest points of the network. This type of design suits OSPF very well because of its area concepts and need for hierarchical routing. This design also reduces convergence time and facilitates route summarization.
You should stick to the following guidelines when designing an OSPF backbone (area 0):
The backbone has to be at the center of all other areas, that is, all areas have to be physically connected to the backbone. The reasoning behind this is that OSPF expects all areas to inject routing information into the backbone and, in turn, the backbone will disseminate that routing information into other areas. Figure 5-9 illustrates the flow of routing information in an OSPF network.
In Figure 5-9, all areas are directly connected to the backbone. Stability and redundancy are the most important criteria for the backbone. Keeping the size of the backbone reasonable results in stability. This is very desirable because every router in the backbone needs to recompute its routes after every link-state change. Keeping the backbone small reduces the likelihood of a change and reduces the amount of CPU cycles required to recompute routes.
Redundancy is important in the backbone to prevent partition when a link fails. Good backbones are designed so that no single link failure can cause a partition (that is, the backbone becomes isolated). OSPF backbones must be contiguous. All routers in the backbone should be directly connected to other backbone routers. Avoid placing hosts (such as workstations, file servers, or other shared resources) in the backbone area. Keeping hosts out of the backbone area simplifies internetwork expansion and creates a more stable environment because a host's normal operation (morning/evening, power up/down) will cause unnecessary LSA traffic.
OSPF includes the concept of virtual links. In the rare situations that a new area is introduced that cannot have a direct physical access to the backbone, a virtual link will have to be configured. A virtual link creates a path between two ABRs that are not directly connected. Accepted network design theory considers the use of virtual links the result of a poorly designed backbone.
A virtual link is able to connect an ABR to the backbone (area 0) even though it is not directly connected (see Figure 5-10). Through the use of a virtual link, which is similar to a tunnel, this can be accomplished.
Some of the characteristics and suggested uses for virtual links include the following:
Using the show ip ospf virtual-links command in enable (EXEC) mode, you can see the virtual links configured on a router.
A stub area in OSPF is an area that carries a default route, and inter-area routes but does not carry any external routes. Stub areas reduce network overhead by placing sections of the network into dead end areas, also known as stub areas. This reduces the routes being advertised across the network.
Because default routing is used, the LSDB is reduced in size, which in turn also reduces the load being placed on the router's CPU and memory. Routing updates are also reduced because specific link flaps will not be injected across the network; instead, they are confined to the area or they don't even enter the area, depending on where they occurred.
There are three different types of stub areas: normal stub, totally stubby area (TSA), and NSSAs. Each stub area and the corresponding characteristics will be discussed in the sections that follow.
Many stub area design rules are in place because a stub area is designed and configured not to carry external routers. If a situation occurred within a stub area that caused external links to be injected into the area, then its usefulness is ruined. The following are the rules:
The configuration command area # stub turns on stub area routing. External routes being advertised into OSPF must be done via the summary-address command; this is typically done at the ASBR.
Normal stub areas only block external routes; however, they do allow summary routes. For example, LSA Types 1-4 are allowed and 5-7 are blocked. This is the difference between normal stub areas and the other types of stub areas.
The command that configures an area as stub is as follows:
The command that configures a default-cost into an area is as follows:
If the cost is not set using the area area-id default-cost cost command, a cost of one will be advertised by the ABR. Figure 5-11 shows a very good example of stub areas. In the examples that follow, the router configuration files will be presented based upon the setup in Figure 5-11.
Assume that area 2 is to be configured as a stub area. The following examples show the routing table of RTE before and after configuring area 2 as a stub area.
Before Becoming a Stub Area
interface Ethernet 0
ip address 18.104.22.168 255.255.255.0
interface Serial1
ip address 18.104.22.168 255.255.255.252
router ospf 10
network 126.96.36.199 0.0.0.255 area 2
network 18.104.22.168 0.0.0.255 area 0
RTE#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
Gateway of last resort is not set
220.127.116.11 255.255.255.252 is subnetted, 1 subnets
C 220.127.116.11 is directly connected, Serial0
O IA 18.104.22.168 [110/74] via 220.127.116.11, 00:06:31, Serial0
188.8.131.52 is variably subnetted, 2 subnets, 2 masks
[110/10] via 188.8.131.52, 00:00:29, Serial0
[110/84] via 18.104.22.168, 00:03:57, Serial0
220.127.116.11 255.255.255.240 is subnetted, 1 subnets
O 188.8.131.52 [110/74] via 188.8.131.52, 00:00:10, Serial0
RTE has learned t he i nter-area rou tes (O IA) 184.108.40.206 and 220.127.116.11, and it has learned the intra-area route (O) 184.108.40.206 and the external route (O E2) 220.127.116.11. If you configure area 2 as stub, you need to do the following:
After Becoming a Stub Area
interface Ethernet 0
ip address 184.108.40.206 255.255.255.0
interface Serial1
ip address 220.127.116.11 255.255.255.252
router ospf 10
network 220.127.116.11 0.0.0.255 area 2
network 18.104.22.168 0.0.0.255 area 0
area 2 stub
interface Ethernet0
ip address 22.214.171.124 255.255.255.0
interface Ethernet1
ip address 188.8.131.52 255.255.255.240
interface Serial1
ip address 188.8.131.52 255.255.255.252
router ospf 10
network 22.214.171.124 0.0.0.255 area 2
network 184.108.40.206 0.0.0.255 area 0
network 126.96.36.199 0.0.255.255 area 2
area 2 stub
Note that the stub command is configured on RTE also; otherwise, RTE will never become a neighbor to RTC. The default cost was not set, so RTC will advertise 0.0.0.0 to RTE with a metric of 1.
RTE#sh ip route
Codes: C - conn ected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 220.127.116.11 to network 0.0.0.0
184.108.40.206 255.255.255.252 is subnetted, 1 subnets
C 188.8.131.52 is directly connected, Serial0
O IA 18.104.22.168 [110/74] via 188.8.131.52, 00:26:58, Serial0
22.214.171.124 255.255.255.252 is subnetted, 1 subnets
O IA 188.8.131.52 [110/84] via 188.8.131.52, 00:26:59, Serial0
188.8.131.52 255.255.255.240 is subnetted, 1 subnets
O 188.8.131.52 [110/74] via 18.104.22.168, 00:26:59, Serial0
O*IA 0.0.0.0 0.0.0.0 [110/65] via 184.108.40.206, 00:26:59, Serial0
Note that all the routes show up except the external routes that were replaced by a default route of 0.0.0.0. The cost of the route happened to be 65 (64 for a T1 line+1 advertised by RTC). You will now configure area 2 to be totally stubby and change the default cost of 0.0.0.0 to 10:
interface Ethernet 0
ip address 18.104.22.168 255.255.255.0
interface Serial1
ip address 188.8.131.52 255.255.255.252
router ospf 10
network 184.108.40.206 0.0.0.255 area 2
network 22.214.171.124 0.0.0.255 area 0
area 2 stub no-summary
RTE#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
126.96.36.199 255.255.255.252 is subnetted, 1 subnets
C 184.108.40.206 is directly connected, Serial0
188.8.131.52 255.255.255.240 is subnetted, 1 subnets
O 126.96.36.199 [110/74] via 18.104.22.168, 00:31:27, Serial0
O*IA 0.0.0.0 0.0.0.0 [110/74] via 18.104.22.168, 00:00:00, Serial0
Note that the only routes that show up are the intra-area routes (O) and the default-route 0.0.0.0. The external and inter-area routes have been blocked. The cost of the default route is now 74 (64 for a T1 line+10 advertised by RTC). No configuration is needed on RTE in this case. The area is already stub, and the no-summary command does not affect the hello packet at all as the stub command does.
Cisco indicates a TSA when configuring the routers by adding the no summary keyword to the configuration command. Thus, the configuration command needed is area # stub no summary.
A TSA blocks external routes and summary routes from entering the area. This leaves the default route and intra-area routes as the only types being advertised throughout the area. This is most complete summarization technique possible in OSPF and results in extremely small routing tables made up only of networks found with the area.
As mentioned in Chapter 4, "Introduction to OSPF," NSSAs have their own RFC and are a rather new concept to OSPF. The advent of this new type of hybrid stub area also introduced a new LSA, Type 7, which is responsible for carrying external route information.
NSSAs are not supported until Cisco IOS version 11.2 and later.
The two main benefits of the Type-7 LSA are that it can be filtered and flexibly summarized. Generally speaking, the use of a NSSA is advised when it lies between a ASBR and ABR, where the ASBR is connected to different routing protocol and the ABR is connected to OSPF's area 0.
In Chapter 4, under RFC 1587 you will find a detailed description of the reasons you would want to use an NSSA. You should also read the RFC itself for detailed information.
The operation of an NSSA is rather straightforward. You have an ASBR connected to a network running RIP. This router is also configured as part of an NSSA. The router will redistribute the routes learned from RIP into an OSPF Type-7 LSA for transmission into the NSSA. The NSSA ABR will see these advertisements and want to forward them onto area 0 for distribution throughout the netwo rk. The ABR will then redistribute the Type-7 LSAs into Type- 5 LSAs.
OSPF Route Selection
When designing an OSPF internetwork for efficient route selection, you need to consider three important topics:
The default value for OSPF metrics (cost) is based on bandwidth. The following characteristics show how OSPF metrics are generated:
In some cases, your network might implement a media type that is faster than the fastest default media configurable for OSPF (FDDI). An example of a faster media is ATM. By default, a faster media will be assigned a cost equal to the cost of an FDDI link--a link-state metric cost of 1. Given an environment with both FDDI and a faster media type, you must manually c onfigure link costs to configure the faster link with a lower metric. Configure any FDDI link with a cost greater than 1, and configure the faster link with a cost less than the assigned FDDI link cost. Use the ip ospf cost interface configuration command to modify link-state cost.
When route summarization is enabled, OSPF uses the metric of the best route in the summary.
Found within Cisco's IOS version 11.3 is a new OSPF command, ospf auto-cost reference bandwidth, which can assist you in route summarization.
Routes that originate from other routing protocols (or different OSPF processes) and that are injected into OSPF via redistribution are called external routes. There are two forms of external metrics: type 1 (E1) and type 2 (E2). These routes are represented by O E2 or O E1 in the IP routing table. They are examined after the router is done building its internal routing table. After they are examined, they are flooded throughout the Autonomous System (AS), unaltered. External information could come from a variety of sources, such as another routing protocol.
E1 metrics result in routes adding the internal OSPF metric to the external route metric; they are also expressed in the same terms as an OSPF link-state metric. The internal OSPF metric is the total cost of reaching the external destination, including whatever internal OSPF network costs are incurred to get there. These costs are calculated by the router wanting to reach the external route.
E2 metrics do not add the internal OSPF metric to the cost of external routes; they are also the default type used by OSPF. The E1 metric is generally preferred. The use of E2 metrics assumes that you are routing between AS; therefore, the cost is considered greater than any internal metrics. This eliminates the need to add the i nternal OSPF metrics. Figure 5-12 shows a nice comparison of the two metrics.
For example, suppose yo u have two routers (cost 10 and 80, respectively) advertising the same external route, which one do you take? OSPF will determine the link metric going to those external networks. In this case of 10 and 80, because 10 is lower, that is the route that will be chosen. But what if the cost was equal? Then OSPF will use the internal metric to determine the lowest cost, thus breaking the tie.
When an area has only a single ABR, all traffic that does not belong in the area will be sent to the ABR. In areas that have multiple ABRs, two choices are available for traffic that needs to leave the area:
Generally, the latter behavior is desirable because the backbone typically has higher bandwidth lines available. Also, the faster packets get there, the quicker they can be routed to their destination. However, if you want the traffic to use the ABR that is nearest the destination (so that traffic leaves the area as late as possible), the ABRs should inject route summaries into the area instead of just injecting the default route.
Most network designers prefer to avoid asymmetric routing (that is, using a different path for packets that are going from A to B than for those packets that are going from B to A.) It is important to understand how routing occurs between areas so you can avoid asymmetric routing if at all possible.
Routes that are generated from within an area (the destination belongs to the area) are called intra-area routes. These routes are represented by the letter O in the IP routing table. Routes that originate from other areas are called inter-area routes or summary routes. The notation for these routes is O IA in the IP routing table.
As part of your design, you will need to consider the traffic flow across the network and whether or not to use load balancing. The use of this OSPF feature can be very helpful to your network's overall health. This section discusses how to best utilize the OSPF load balancing feature with a network.
In routing, load balancing is the capability of a router to distribute traffic over all its network ports that are the same distance from the destination address. Good load-balancing algorithms use both line speed and reliability information. Load balancing increases the utilization of network segments, thus increasing effective network bandwidth.
Internetwork topologies are typically designed to provide redundant routes in order to prevent a partitioned network. Redundancy is also useful to provide additional bandwidth for high traffic areas. If equal-cost paths between nodes exist, Cisco routers automatically load balance in an OSPF environment.
Fast-switching is a Cisco feature whereby a route cache is used to expedite packet switching through a router. For line speeds of 56Kbps and faster, it is recommended that you enable fast-switching.
Cisco routers can use up to four equal-cost paths for a given destination. Packets might be distributed either on a per-destination (when fast-switching) or a per-packet basis. Per-destination load balancing is the default behavior. Per-packet load balancing can be enabled by turning off fast-switching using the no ip route-cache interface configuration command.
OSPF IP Addressing & Route Summarization
IP address assignment and route summarization are inextricably linked when designing OSPF networks. To create a scalable OSPF network, you should implement route summarization. To create an environment capable of supporting route summarization, you must implement an effective hierarchical addressing scheme. The addressing structure that you implement can have a profound impact on the performance and scalability of your OSPF network. The ultimate goal is to put as few routes as possible into the routing tables and reduce the number of updates.
Figure 5-13 illustrates the benefits of route summarization on a routing table. Without summarization, only three entries exist in the routing table, and with summarization, only one entry exists in the routing table.
When planning your OSPF network, consider the following golden rules of design for IP addressing and route summarization:
Route summarization is particularly important in an OSPF environment because it increases the stability and efficiency of the network. Summarizing is the consolidation of multiple routes into one single advertisement. This is normally done at the boundaries of ABRs or ASBRs. Although summarization could be configured between any two areas, it is better to summarize in the direction of the backbone. This way the backbone receives all the aggregate addresses and, in turn, will inject them, already summarized, into other areas. If route summarization is being used, routes within an area that change do not need to be changed in the backbone or in other areas. There are two types of summarization:
Inter-area route summarization is done on ABRs, and it applies to routes from within the AS. It does not apply to external routes injected into OSPF via redistribution. To take advantage of summarization, network numbers in areas should be assigned in a contiguous way so that you can lump these addresses into one range when summarizing them.
To specify an address range, perform the following task in router configuration mode:
The area-id is the area containing networks to be summarized. The address and mask will specify the range of addresses to be summarized in one range. Figure 5-14 illustrates an example of summarization.
In Figure 5-14, Router B is summarizing the range of subnets found within area 1 from 220.127.116.11 to 126.96.36.199 into one range: 22.214.171.124 with a mask of 255.255.224.0 into the backbone. This is achieved by masking the first three left-most bits of 64, using a mask of 255.255.224.0.
In the same way, Router C is generating the summary address 126.96.36.199 255.255.224.0 into the backbone. Note that this summarization was successful because you have two distinct ranges of subnets, 64-95 and 96-127 in areas 1 and 2 respectively.
It would be hard to summarize if the subnets between area 1 and area 2 were overlapping. The backbone area would receive summary ranges that overlap and routers in the middle would not know where to send the traffic based on the summary address. The following is the relative configuration of Router B, and you can extrapolate Router C's configuration as well:
Router B#
router ospf 100
area 1 range 184.108.40.206 255.255.224.0
External route summarization is specific to external routes that are injected into OSPF via redistribution done by ASBRs. Also, make sure that external ranges being summarized are contiguous. Summarization that overlaps ranges from two different routers could cause packets to be sent to the wrong destination. Summarization is done via the following router ospf subcommand:
This command is effective only on ASBRs doing redistribution into OSPF.
In Figure 5-15, Router A and Router D (both ASBRs) are injecting external routes into OSPF by redistribution. Router A is injecting subnets in the range 128.213.64-95 and Router D is injecting subnets in the range 128.213.96-127.
To properly summarize the subnets into one range on each router, you can configure the routers as follows:
Router A#
router ospf 100
summary-address 220.127.116.11 255.255.224.0
redistribute bgp 50 metric 1000 subnets
Router D#
router ospf 100
summary-address 126.96.36.199 255.255.224.0
redistribute bgp 20 metric 1000 subnets
This will cause Router A to generate one external route 188.8.131.52 with a mask of 255.255.224.0 and will cause Router D to generate one external route 18.104.22.168 with a mask of 255.255.224.0. Note that the summary-address command has no effect if used on Router B because Router B is not doing the redistribution into OSPF, nor is it an ASBR.
Route summarization addresses two important questions of route information distribution:
If you know the answers to these questions, you will be able to effectively design how you need to summarize routes within your OSPF network.
There are several key considerations when setting up your OSPF areas for proper summarization. OSPF route summarization occurs in the ABRs. OSPF supports variable length subnet masks (VLSM), so it is possible to summarize on any bit boundary in a network or subnet address. OSPF requires manual summarization. As you design the areas, you need to determine summarization at each ABR.
Four potential types o f routing information exist in an area and are listed in Table 5-2, which shows the different types of areas according to the routing information that they use.
The types of routes de fined in Table 5-2 for OSPF areas are as follows:
The following sections discuss OSPF route summarization and the three most commonly encountered IP addressing scenarios:
In this scenario each OSPF area has its own unique NIC-assigned IP address range. This can be as grand as a Class A address for the entire network with multiple Class Bs assigned to each area, or more realistically, you can be using a group of Class C addresses. This example is demonstrated in Figure 5-15. The benefits of this method are as follows:
The following two steps are the basic steps for creating such a network:
As an example, the route summarization configuration at the ABRs is greatly simplified. Routes from area 4 injected into the backbone would be summarized as "all routes starting with 150.98 are found in area 4." This can be accomplished on a Cisco router with the following command:
The main drawback of this approach is that it can be very wasteful with important IP address space. Of course, this space could also be very difficult to obtain, at least until IPv6.
There might be a situation where you only have one NIC address (a single Class B for example) to allocate for all areas of your multi-area OSPF network. You might also wish to save some address space by using VLSM such that the point-to-point serial links in each area have a subnet mask that allows two hosts per subnet.
This example uses part of the address space for the NIC address 22.214.171.124. It is meant to illustrate both the concept of "area masks" and also the breakdown of large subnets into smaller ones (VLSMs).
The points that follow list the assumptions made and describe the process used to allocate addresses:
The portion of the address space that has the 2-bit host field (subnet mask of 255.255.255.252) was chosen arbitrarily from one of the larger subnet fields. This method of assigning addresses for the VLSM portion of the address space is done to guarantee no address overlap. Alternatively, if the requirement had been different, you could have chosen any number of the larger subnets (with mask 255.255.255.240) and broken them up into smaller ranges with fewer hosts, or combined several of them to create subnets with more hosts.
It is imp ortant to note that the sample of addresses and mask boundary choices in scenario 2 were chosen simply so that the entire address space of a single area could be shown on a single page. It is not realistic to have an OSPF network designed with 500 areas.
A realistic design might include the following:
Now that you know about segmenting the IP address space for 500 areas, you can take a more realistic approach. Assume that you have the following design criteria and IP addresses to work with:
Here, each Class C network will be used entirely in its own area (similar to scenario 1) and the Class B address will be subdivided using an area mask and distributed among the remaining 16 areas.
The Class B network, 126.96.36.199, could be subdivided as follows:
156.77. x x x x y y y y . y z
area mask boundary
The letters x, y and z represent bits of the last two octets of the Class B.
The four x bits are used to identify 16 areas.
The five y bits represent up to 32 subnets per area.
The seven z bits allow for 126 (128-2) hosts per subnet.
All of the principles used for summarization and VLSM shown in scenarios 1 and 2 also apply for this more realistic example.
Route summarization is extremely desirable for a reliable and scalable OSPF internetwork. The effectiveness of route summarization, and your OSPF implementation in general, hinges on the addressing scheme that you adopt. Summarization in an OSPF internetwork occurs between each area and the backbone area. Summarization must be configured manually in OSPF.
Because of the careful assignment of addresses, each area can be summarized with a single range command. This is a requirement to be able to scale an OSPF network. The first set of addresses starting with 126.96.36.199xxxxxxx (the last octet is represented in binary) can be summarized into the backbone with the following command:
area 8 range 220.127.116.11 255.255.255.128
This means that all addresses starting with 188.8.131.52xxxxxxx can be found in area 8.
Similarly, with the second area shown, the range of addresses starting with
can be summarized as follows:
area 17 range 18.104.22.168 255.255.255.128
This design methodology is extensible such that the area mask boundary and the subnet masks may be drawn at any point in the address space. This might be required if you had originally planned for 32 areas in your network but then later decided that you needed more. Here, you may decide to have a variable-length area mask boundary. This becomes much more complex to manage and is beyond the scope of this book. Strategy 2 is meant to show one approach that tries to simplify something that is inherently complicated for people to deal with. Keep in mind that if you had displayed the entire address space for 220.127.116.11, there would be an additional 510 pages to the document.
Bit-wise subnetting and variable-length subnet masks (VLSMs) can be used in combination to save address space. Consider a hypothetical network where a Class B address is subdivided using an area mask and distributed among 16 areas. The Class B network, 220.127.116.11, might be subdivided as illustrated in Figure 5-17.
In Figure 5-17, the letters x, y, and z represent bits of the last two octets of the Class B network as follows:
Private addressing is another option often cited as simpler than developing an area scheme using bit-wise subnetting. Although private address schemes provide an excellent level of flexibility and do not limit the growth of your OSPF internetwork, they have certain disadvantages.
For instance, developing a large-scale internetwork of privately addressed IP nodes limits total access to the Internet and mandates the implementation of what is referred to as a demilitarized zone (DMZ). If you need to connect to the Internet, Figure 5-18 illustrates the way in which a DMZ provides a buffer of valid NIC nodes between a privately addressed network and the Internet.
All nodes (end systems and routers) on the network in the DMZ must have NIC-assigned IP addresses. The NIC might, for example, assign a single Class C network number to you. The DMZ shown in Figure 5-18 has two routers and a single application gateway host (ApGate).
Router A provides the interface between the DMZ and the Internet, and Router B provides the firewall between the DMZ and the private address environment. All applications that need to run over the Internet must access the Internet through the application gateway.
Firewalls can take many forms. They can be a router specially configured through the use of the Cisco firewall feature set or a dedicated machine designed from the ground up to perform firewall duties, such as a PIX Firewall, Raptor Eagle, or Firewall-1.
IP networks are divided into Class A, B, and C addresses. You can define a mask that specifies which bits in the address define the subnet and which define the host. OSPF supports a concept called variable-length subnet masks (VLSM) which enables an administrator to use different masks for the same network number on different interfaces.
You might want to use VLSM if you are concerned about running out of IP address space. VLSM enables you to get more use out of your available space. VLSM offers the flexibility to handle subnets with different numbers of hosts. For example, a customer who has not implemented VLSM has some interfaces with only a few hosts and other interfaces with many hosts may choose to use a long mask on the first interface and a short mask on the second interface. This address space must be assigned VERY carefully. It is very likely that existing networks will need to re-number their networks in order to be able to take advantage of this feature.
With VLS M, you don't have to waste network numbers on serial interfaces because you can support unnumbered IP interfaces. Also, VLSM supports discontinuous subnets. An example of a discontinuous subnet application is where a customer has two Class B addresses. One is used in the backbone, and one is used by sites. The site network number is discontinuous if there is more than one site with the same network number. The existing solution is to use secondary IP addresses on the same interface. In this way, you can provide a set of network numbers across the backbone and, thus, connect the discontinuous subnets.
Some of the disadvantages of VLSM include the following:
When using VLSM, be very careful about assigning addresses. For example, Cisco's internal Class B network number is 126.96.36.199.
First a little math to help show some common masks:
Suppose that you had two labs to which you want to assign subnet numbers. The first lab is very small and will never have more than six hosts. The second lab is large and might need to support up to 126 hosts. The obvious thing to do is to assign the masks appropriately. However, it is easy to make mistakes when doing this.
This is an illegal configuration because one of the network/mask pairs is a bit-wise subset of the other. Watch wh at can happen.
The owners of those labs are allowed to assign their IP addresses within the labs themselves. Let's say that the owner of Lab A assigns a host the IP address of 126.96.36.199--this is host `2' in network 22.214.171.124. Meanwhile, the owner of Lab B assigns a host the IP address 18.104.22.168--this is host `122' in network 126.96.36.199. Both of these are legal addresses.
However, it is impossible for a router to tell which host should get packets that are sent to that IP address. Worse yet, neither of the lab owners realizes that they have created a problem. To make this even harder to keep straight, the following configuration in Table 5-5 shows other legal possibilities:
A final pitfall to watch out for is the use of subnet zero, which isn't legal. If you use subnet masks that don't fall on 8-bit boundaries, you can end up creating a non-obvious subnet zero.
For example, network 188.8.131.52 mask 255.255.255.0 has eight hosts on it (192.111.108.[1-8]). You can try to expand the number of networks by stretching the mask: network 220.127.116.11 mask 255.255.255.240 (15 nets with 14 hosts each)
However, this leaves all of the existing hosts in subnet zero, which doesn't work. The hosts need to be renumbered (17-24, for example). This problem exists even when VLSMs are NOT used. However, VLSM makes it more likely to occur.
According to RFC 795, the only illegal number is subnet zero. The all ones subnet is fair game. In fact, the ip subnet zero IOS command gets around the first restriction.
The best way to use VLSM is to keep the existing numbering plan in place and gradually migrate some networks in order to recover address space. In Cisco's network, the Class B address is 18.104.22.168. You use a mask of 255.255.255.0. You could take one address and decide to use it for all serial lines, for example:
Existing addressing: network number: 126.96.36.199, mask: 255.255.255.0
Reserve one existing subnet for all serial lines: network number: 184.108.40.206, mask: 255.255.255.252
The use of VLSM allows 6-bits or 64 subnets for serial lines. These subnets would be
18.104.22.168 and 22.214.171.124
22.214.171.124 and 188.8.131.52
22.214.171.124 and 18.104.22.168
. . .
Note that host numbers with all zeros or all ones are not supported. This achieves a 64:1 improvement in address space allocation on serial lines. It also assumes that you are including subnet zero and the broadcast.
Routers in a si ngle area must agree on the network mask. IGRP does not support VLSM. So when information is redistributed from OSPF to IGRP, only a single mask will be used. The best way to make this work is to hide all VLSMs from IGRP. OSPF should summarize the networks to achieve one mask per network number.
The idea behind VLSMs is to offer more flexibility in dealing with dividing a major network into multiple subnets and still being able to maintain an adequate number of hosts in each subnet. Without VLSM, one subnet mask can only be applied to a major network. This would restrict the number of hosts given the number of subnets required. If you pick the mask such that you have enough subnets, you wouldn't be able to allocate enough hosts in each subnet. The same is true for the hosts: a mask that allows enough hosts might not provide enough subnet space.
For example, suppose you were assigned a Class C network 18.104.22.168, and you need to divide that network into three subnets with 100 hosts in one subnet and 50 hosts for each of the remaining subnets. Ignoring the two end limits 0 and 255, you theoretically have available to you 256 addresses (18.104.22.168-184.108.40.206). This cannot be done without VLSM. Figure 5-19 shows an example of how you can use VLSM to segment a Class C address.
There are a handful of subnet masks that can be used; remember that a mask should have a contiguous number of ones starting from the left and the rest of the bits being all zeros. As an example, some common VLSM configurations include the following:
Without VLS M, you have the choice of using mask 255.255.255.128 and dividing the addresses into two subnets with 128 hosts each or using 255.255.255.192 and dividing the space into four subnets with 64 hosts each.
This would not meet the requirement. By using multiple masks you can use mask 128 and further subnet the second chunk of addresses with mask 192. Figure 5-20 shows the proper division of address space.
Now, be careful in allocating the IP addresses to each mask. After you assign an IP address to the router or to a host, you have used up the whole subnet for that segment. For example, if you assign 184.108.40.206 255.255.255.128 to E2, the whole range of addresses between 126.96.36.199 and 220.127.116.11 is consumed by E2. In the same way if you assign 188.8.131.52 255.255.255.128 to E2, the whole range of addresses between 184.108.40.206 and 220.127.116.11 is consumed by the E2 segment.
The following is an illustration of how the router will interpret these addresses. Please remember that any time you are using a mask different than the natural mask, the router will complain if the combination IP address and mask result in a subnet zero. To resolve this issue, use the ip subnet-zero commandon the router:
ip subnet-zero
interface Ethernet2
ip address 184.108.40.206 255.255.255.128
interface Ethernet3
ip address 18.104.22.168 255.255.255.192
interface Ethernet4
ip address 126.96.36.199 255.255.255.192
RTA# show ip route connected
18.104.22.168 is variably subnetted, 3 subnets, 2 masks
C 220.127.116.11 255.255.255.128 is directly connected, Ethernet2
C 22.214.171.124 255.255.255.192 is directly connected, Ethernet3
C 18.104.22.168 255.255.255.192 is directly connected, Ethernet4
Chapter Summary
This chapter completes the discussion on the mathematics surrounding the SPF algorithm and its operation within OSPF. The various "golden rules of design" were provided for all of the essential portions of an OSPF network. Included within those discussions was the ability of OSPF to summarize routes and the benefits of using such a strong feature of the protocol. The discussion concluded with a demonstration of VLSM's usefulness within the OSPF environment.
In conclusion, many of the OSPF-specific configuration commands will be presented in detail in the next chapter. All of the configuration commands are grouped together for your ease of reference In addition, a complete list and definition of the commands will be provided in Chapter 7, "Designing & Implementing an OSPF Network."
OSPF Case Study: Point-to-Multipoint
Link Networks
The objective of this case study is to demonstrate how to design, configure, and troubleshoot an OSPF point-to-multipoint link network.
This feature's importance is linked with the increased use of Frame Relay due to reduced cost for the service. As customers used point-to-multipoint on nonbroadcast media (Frame Relay), they found that their routers could not dynamically discover their neighbors. The OSPF point-to-multipoint link feature allows the neighbor command to be used on point-to-multipoint interfaces. The use of point-to-multipoint can be used to minimize the number of IP addresses that are used and basically enable the user to configure a nonbroadcast media similarly to a LAN.
Before the OSPF point-to-multipoint link feature, some OSPF point-to-multipoint protocol traffic was treated as multicast traffic. This meant that the neighbor command was not needed for point-to-multipoint interfaces because multicast took care of the traffic. In particular, multicast hellos discovered all neighbors dynamically.
Also, on any point-to-multipoint interface (broadcast or not), the Cisco IOS software assumed that the cost to each neighbor was equal. In reality, the bandwidth to each neighbor can be different; therefore, the cost should be different because the OSPF point-to-multipoint link enables you to configure a separate cost for each neighbor.
One method of increasing your understanding of this feature is to become familiar with the following document: http://www.cisco.com/univercd/cc/td/doc/product/ software/ios113ed/113aa/ospfpmp.htm.
Another advantage is that you do not need to use subinterfaces with this feature. Subinterfaces count toward the practical upper limit of 300 IDBs (Interface Descriptor Blocks). There is an IDB assigned for each physical and software interface that is configured on the router. This includes any subinterfaces. There is no command that will tell you how many IDBs have been used. In other words, Cisco IOS currently supports less then 300 interfaces on the router (real or virtual) unless you have an 11.1CA or CC image which has 1,024 IDBs, but this only runs on the high end routers.
How many DLCIs can one configure per physical interface? How many DLCIs can one configure in a specific router? These two questions are frequently asked. Disappointingly, the answer is, "It depends."
DLCI address space: Approximately 1,000 DLCIs can be configured on a single physical link, given a 10-bit address. Because certain DLCIs are reserved (vendor implementation dependent), the maximum is about 1,000.
Local Management Interface (LMI) status update: The LMI protocol (ANSI Annex D, and ITU-T standards also) requires that all PVC status reports fit into a single packet and generally limits the number of DLCIs to less than 800, depending on the maximum transmission unit (MTU) size. This limit does not apply to Cisco LMI (also known as the "Gang of Four" LMI), which allows fragmentation of the PVC status report.
Configuring NBMA networks as either broadcast or nonbroadcast assumes that there are VCs from every router to every other router. This is often not true due to real world cost constraints. In these cases, you can configure the OSPF network type as point-to-multipoint. This will enable routing between two routers that are not directly connected to go through the router that has the VCs to each.
Figure 5-21 illustrates the network topology considered in this case study.
As illustrated in Figure 5 -21, Hub Router R1 has virtual circuits to Spoke Routers R2, R3, and R4. But the other three routers do not have direct circuits. This will be configured as a single subnet rather than multiple point-to-point links.
To configure an interface as point-to-multipoint broadcast and assign a cost to each neighbor, you will need to perform the following tasks on each interface while in configuration mode:
The following are examples of the configurations contained within the routers shown in Figure 5-21:
interface Serial 0
ip address 10.0.1.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
frame-relay local-dlci 100
router ospf 1
network 10.0.1.0 0.0.0.255 area 0
neighbor 10.0.1.2 10
neighbor 10.0.1.3 10
neighbor 10.0.1.4 10
interface Serial 0
ip address 10.0.1.2 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
frame-relay local dlci 101
router ospf 1
network 10.0.1.0 0.0.0.255 area 0
network 10.2.0.0 0.0.255.255 area 2
neighbor 10.0.1.1 10
interface Serial 0
ip address 10.0.1.3 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
frame-relay local-dlci 103
router ospf 1
network 10.0.1.0 0.0.0.255 area 0
network 10.3.0.0 0.0.255.255 area 3
neighbor 10.0.1.1 10
interface Serial 0
ip address 10.0.1.4 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast
frame-relay local-dlci 104
router ospf 1
network 10.0.1.0 0.0.0.255 area 0
network 10.4.0.0 0.0.255.255 area 4
neighbor 10.0.1.1 10
Note that no static frame relay map statements were configured. This is because
Inverse ARP will take care of the DLCI to IP resolution and mapping.
You will not be able to ping your own IP address on a multipoint Frame Relay interface. This is because FR multipoint (sub)interfaces are nonbroadcast (unlike Ethernet and point-to-point interfaces (HDLC) and Frame Relay point-to-point sub-interfaces). Furthermore, you will not be able to ping from one spoke router to another spoke router in a hub and spoke configuration. This is because there is no mapping for your own IP address (and none was learned via inverse-arp). However, if you configure a static map (frame-relay map) for your own IP address (or one for the remote spoke) to use the local DLCI, you can ping yourself to your heart's content.
The following c apture from a router occurred before the circuit went active. Check the State. The following example highlights the important fields that you would use in troubleshooting an OSPF link-state problem:
Hub_router1#show ip ospf interface serial 0
Serial0 is up, line protocol is up
Internet Address 10.0.1.1/24, Area 0
Process ID 10, Router ID 10.0.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64
DoNotAge LSA allowed.
Transmit Delay is 1 sec, State DOWN,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
After the OSPF state goes active, the capture from the router is as follows:
Hub_router1#show ip ospf interface serial 0
Serial0 is up, line protocol is up
Internet Address 10.0.1.1/24, Area 0
Process ID 10, Router ID 10.0.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64
DoNotAge LSA allowed.
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.0.1.2
Suppress hello for 0 neighbor(s)
Taking a look at the show ip ospf neighbor command for each of the routers will show the following:
Hub_Router1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.1.2 1 FULL/ - 00:01:30 10.0.1.1 Serial0
10.0.1.3 1 FULL/ - 00:01:30 10.0.1.1 Serial0
10.0.1.4 1 FULL/ - 00:01:30 10.0.1.1 Serial0
The preceding command shows that the state is a full adjacency. Notice that there is no DR or ADR, which is normal and expected behavior for a NBMA media. If the state is anything but FULL, then the adjacencies have not been comp letely built and there might be a problem with the multicast LSA packets being passed through the interface. Perform the following command to check the state:
Spoke_Router2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.1.1 1 FULL/ - 00:01:52 10.0.1.2 Serial0
Spoke_Router3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.1.1 1 FULL/ - 00:01:52 10.0.1.3 Serial0
Spoke_Router4#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.1.1 1 FULL/ - 00:01:52 10.0.1.4 Serial0
The following sections provide a definition of the different OSPF states.
The following is a brief description of the possible OSPF neighbor state changes:
Typically you will see OSPF go from 2-Way to full; however, when a full state is reached, this reflects that the LSDBs (that is, all database exchanges) have been completely exchanged between the two routers in question. This process differs from the Hello protocol and is the subtle difference between the two.
The following is a brief description of the possible OSPF neighbor state changes:
It is important to note that there is no DR/BDR election on a point-to-multipoint interface and that you can confirm that with the appropriate show command.
If you do not see full adjacencies, then the packet negotiation sequence that occurs can be seen through the use of a debug ip ospf events command. This can be essential in identifying problems with the OSPF process by looking at the packets with the debug command as follows:
HUB_ROUTER1#term monitor
HUB_ROUTER1#debug ip ospf events
%FR-5-DLCICHANGE: Interface Serial0 - DLCI 100 state changed to ACTIVE
OSPF: rcv. v:2 t:1 l:44 rid:10.0.1.2
Field definitions:
aid:0.0.0.0 chk:EE35 aut:0 auk: from Serial0
rcv - received packet
v:2 - OSPF v2
rid: - Router ID
aid: - Area ID
chk: -
aut: - Authentication
auk: - physical interface packet was received through
OSPF: rcv. v:2 t:2 l:32 rid:10.0.1.2
aid:0.0.0.0 c hk:D363 aut:0 auk: from Serial0
OSPF: Receive dbd from 10.0.1.2 seq 0x1A6E --- begin of database exchange
OSPF: 2 Way Communication to neighbor 10.0.1.2 - building of adjacency
OSPF: send DBD packet to 10.0.1.2 seq 0x995
OSPF: rcv. v:2 t:2 l:72 rid:10.0.1.2
aid:0.0.0.0 chk:36C4 aut:0 auk: from Serial0
OSPF: Receive dbd from 10.0.1.2 seq 0x995
OSPF: NBR Negotiation Done We are the MASTER - neighbor negotiation
OSPF: send DBD packet to 10.0.1.2 seq 0x996
OSPF: Database request to 10.0.1.2
OSPF: sent LS REQ packet to 10.0.1.2, length 12 - we are sending a request to 10.0.1.2 for link state data.
OSPF: rcv. v:2 t:2 l:32 rid:10.0.1.2
aid:0.0.0.0 chk:E442 aut:0 auk: from Serial0
OSPF: Receive dbd from 10.0.1.2 seq 0x996
OSPF: send DBD packet to 10.0.1.2 seq 0x997
OSPF: rcv. v:2 t:3 l:48 rid:10.0.1.2
aid:0.0.0.0 chk:5E71 aut:0 auk: from Serial0
OSPF: rcv. v:2 t:4 l:64 rid:10.0.1.2
aid:0.0.0.0 chk:98D8 aut:0 auk: from Serial0
OSPF: rcv. v:2 t:2 l:32 rid:10.0.1.2
aid:0.0.0.0 chk:E441 aut:0 auk: from Serial0
OSPF: Receive dbd from 10.0.1.2 seq 0x997
OSPF: Exchange Done with neighbor 10.0.1.2
OSPF: Synchronized with neighbor 10.0.1.2, state:FULL - completion of the adjacency process
Explanation of the fields is included with the first packet, and they are also shown in Table 5-6:
This sequence shows the distribution of the LSA packets and the building of the database. It also shows the building of the OSPF adjacency. The debug ip ospf events command is very useful in discovering the problems that might be causing an OSPF adjacency problem on the network.
The output from a debug ip ospf events command shows both the received and transmitted packets, the building of the OSPF adjacency, and the exchange of database information. If you are having a problem with building the OSPF adjacency or there are OSPF database problems, then this debug command can help you identify whether the packets are being received or sent.
The following example illustrates a nonbroadcast point-to-multipoint network using the frame relay map statement for clarification of the PVCs. This enables you to identify both ends of the PVC and if you need to define multiple DLCIs for a split DLCI --one PVC for receiving and one PVC for transmitting. This enables you to work with your provider in setting the committed information rate (CIR) for each of the PVCs. As customers need to shape their user and application traffic across their frame relay circuits, the use of this kind of mapping is necessary.
interface Serial0
ip address 10.0.1.1 255.255.255.0
ip ospf network point-to-multipoint non-broadcast
encapsulation frame-relay
frame-relay local-dlci 100
frame-relay map ip 10.0.1.2 102
frame-relay map ip 10.0.1.3 103
frame-relay map ip 10.0.1.4 104
no shut
router ospf 1
network 10.0.1.0 0.0.0.255 area 0
neighbor 10.0.1.3
neighbor 10.0.1.4
neighbor 10.0.1.5
The preceding code also illustra tes the use of the neighbor command to force the configured OSPF routers interconnecting to nonbroadcast networks. The neighbor statements are used to form OSPF adjacency. This also enables the user to dictate upon which connections the router will attempt to form an OSPF adjacency.
Without the neighbor command, the OSPF adjacency might have problems being attained. With the command, you know which routers you should make an OSPF adjacency with and, therefore, know what to look for if there are problems.
Because OSPF performs an election process for a DR and BDR, which acts as a "central distribution" point for routing information, the setting up of neighbors can be important. Also, OSPF routers will only form a full adjacency to the DR and BDR. Therefore, OSPF can efficiently support a full mesh of neighboring routers per interface. This will enable the point-to-multipoint feature to provide the connectivity that is needed for a non-fully-meshed network.
Another command used to troubleshoot the connection is show frame-relay map . It can be used to confirm the Layer 1 and 2 connectivity between the routers. This enables you to eliminate this as a problem before you begin concentrating on the Layer 3 issues. This command is available for use and is shown in the following example:
HUB_ROUTER1#show frame map
Serial0 (up): point-to-point dlci, dlci 101(0x12,0x420), broadcast
Serial0 (up): point-to-point dlci, dlci 102(0x10,0x400), broadcast
Serial0 (up): point-to-point dlci, dlci 103(0x12,0x420), broadcast
This shows the connection from serial 0 to three different DLCIs; it shows that they are enabled for broadcast; and it will also show if the mapping is dynamic or static.
If there is no mapping to the other end, then the PVC has not been fully made. Therefore, there is a problem with the Frame Relay circuit and any associated problems with routing or with the OSPF process are not important until the physical layer problem has been taken care of.
Also, show ip ospf interface serial 0 will show the following:
Spoke_R2#show ip ospf interface serial 0
Serial0 is up, line protocol is up
Internet Address 10.0.1.2/24, Area 0
Process ID 1, Router ID 10.0.1.2, Network Type POINT_TO_MULTIPOINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.0.2.1
The preceding co mmand shows the network type and state. It also lets you confirm that different timers that are set in OSPF. These should be identical between your routers. If these are not, or there is a problem with the subnet masks between the two routers, then a debug ip ospf events will show the following:
OSPF: Mismatched hello parameters from 126.96.36.199
Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.248 C 255.255.255.0
OSPF: Mismatched hello parameters from 126.96.36.199
Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.248 C 255.255.255.0
What is happening in the preceding output?
The mask is not matching.
R indicates what you are receiving.
C indicates what is configured.
If one end of a Frame Relay link is configured to be a multipoint link type and the other end point-to-point, the multipoint interface would advertise the link as a Nonbroadcast and the point-to-point would interface the link as a point-to-point, which creates a conflict in the LSDB. It might cause the router to learn none of the routes through that link.
One possible fix for this is to change the point-to-point interface to a multipoint interface or change the interface type to broadcast by using the command ip ospf network broadcast.
OSPF and multipoint can be dangerous. OSPF needs a DR and if you start missing PVCs, then some routers might loose connectivity and want to become the DR. This can become a serious problem even though other routers still see the old DR. So your OSPF process will go a little crazy. Overhead associated with OSPF is not as obvious and predictable as that with traditional distance vector-routing protocols. The unpredictability comes from whether or not the OSPF network links are stable. If all adjacencies to a Frame Relay router are stable, only neighbor hello packets (keepalives) will flow, which is comparatively much less overhead than that incurred with a distance vector protocol (RIP, IGRP). If, however, routes (adjacencies) are unstable, link-state flooding will occur, and bandwidth can quickly be consumed. OSPF also is very processor-intensive when running the Dijkstra algorithm, which is used for computing routes.
The objective of this case study was to demonstrate how to use, configure, and troubleshoot an OSPF point-to-multipoint link. You have an example and explanation for the configuration, which should help you in both design considerations and implementation. The different show commands and debug commands reviewed will assist you in troubleshooting the point-to-multipoint configuration and, by understanding the data, should be helpful in troubleshooting more general OSPF problems as well.
A summary of appropriate show and debug commands for OSPF point-to-multipoint use, configuration, and troubleshooting is as follows:
Frequently Asked Questions
Protocol 89
No, sometimes the link layer protocol might also require special multicast MAC addresses so as to route the info properly.


text:
Search ShopTalk
About the bloggers
Elyse Toribio is the newest addition to the Better Living staff, contributing to Travel and other sections. She graduated from Ramapo College in 2012 and spends most of her downtime listening to news podcasts, scouring fashion blogs for the latest trends, and hoping for a run-in with Beyonce in the near future.
View all of her posts
North Jersey's complete guide to local shopping and style
Tag Archives: black friday 2012
Neiman Marcus Paramus Black Friday 2012 deals
For those venturing to Garden State Plaza in Paramus on Friday for some Black Friday deals, here are Neiman Marcus' sales: ALL DAY: Spend $100 or more anywhere in the store on Nov. 23 and receive a $50 gift card … Continue reading
Posted in Bergen County Shopping, Sales and Deals Tagged black friday 2012, garden state plaza, neiman marcus
Bergen County Black Friday 2012 mall and store hours
Black Friday is almost upon us, but soon it might be called Black Thursday, or Black Thanksgiving. More and more stores are choosing to open Thursday night, tempting people to abandon that second piece of pumpkin pie to get a … Continue reading
Posted in Bergen County Shopping, Sales and Deals Tagged bergen county, black friday 2012, black friday sales, passaic county
Are you a dedicated Bergen County Black Friday shopper?
After the turkey is finished and the pumpkin pie is put away, do you start putting together a strategy for your Black Friday shopping? Do you have certain stores you have to go to, no matter how early you have … Continue reading
Posted in Bergen County Shopping Tagged black friday 2012, black friday sales

subset: commoncrawl