The Continuing Evolution of OSPF
Barriers to Understanding OSPF Deployment This section of the Draft covers several of the more common misconceptions regarding the deployment of OSPF. It briefly discusses them, provides several good examples, and then provides suggestions on how to reduce the impact of these barriers. Some of the more interesting topics in this section concern virtual links. If you are seriously considering using virtual links, this entire draft should be consulted, as there are several places where they are discussed. Area Sizing and Numbering Strategies This section of the Draft covers some techniques and suggestions on how to deploy your use of IP addresses. It also briefly discusses some of the more common misconceptions surrounding OSPF and how it functions within an area that does not have a contiguous address range. Increasing Backbone Reliability & Backbone of Backbones These two sections cover the essential requirements and considerations that should be given to every OSPF area 0 and its future physical media. As previously discussed, the heart of every OSPF network is its backbone, in this OSPF area 0. By default, the OSPF network must be redundant to avoid being split in the event of a catastrophic failure. This draft covers three useful and unique techniques you can use to achieve increased reliability.
Transition and Network Consolidation This section concentrates on how to bring OSPF networks together so that there is single OSPF area 0. There are three solutions presented and very briefly discussed in this draft (if additional information on these subjects is required, this text covers transition and network consolidation in a bit more detail):
Transition of Legacy Routing Protocol Domains to OSPF This section of the Draft is very relevant to many network designers. If you have not encountered this particular problem, you will as more and more networks begin to conform to the IETF recommendations of OSPF as the IGP of choice. In this section, all of the examples deal with the acquired network and the belief that they are running RIP and need to be converted to OSPF. Many of the techniques in this section not only apply to RIP but to the overall process as presented in this section, including
Traffic Management The last section in this draft deals with managing the various unique traffic needs that can be found in any network. Specifically, it deals with how to OSPF to meet these needs. OSPF Multiple Area LinksDate Published: March 1998 Author: P. Murphy Expiration Date: September 1998 File name: draft-ietf-ospf-mlinks-01.txt AbstractThis memo describes an option to the OSPFv2 specification, which enables multiple areas to share the same link or one hop path. This option adds no additional link-state flooding over the link/path other than the normal LSDB exchange and update originating from the link/path’s configured primary area. The option applies to standard areas, stub areas, and NSSAs. When it is properly done, it is easy to implement and configure. It eliminates the excess area 0 link-state baggage that accompanies the use of virtual links as currently practiced when configuring similar transits for standard OSPF areas. Routers with this option configured are backward compatible with routers running the standard OSPFv2 compliant implementation as defined in RFC 2178 and can be restricted to a subset of the OSPF routing domain. The application is applied only on OSPF border routers. The implementation of OSPF multiple-area links requires a modification to the OSPF interface data structure, which enables an interface of an area border router to be connected to multiple areas. One area is always configured as the interface’s primary area. Any additional areas that are configured for an interface are called the interface’s secondary areas. Two adjacent border routers with mutually shared secondary areas might transit a secondary area’s intra-area traffic over the adjacency. A typical application is a stub area or NSSA that is dual homed to the area 0 backbone and loosely joined internally by a slow speed connection. If a high speed area 0 adjacency exists between the area’s two border routers, this option enables the preferred path between the two parts to be the adjacent link. The current specification forces traffic to prefer the slow speed connection. Another not so common application makes area 0 the secondary area over a local high speed LAN link with the primary area a local stub or NSSA. Here, area 0 is not primary due to topological limitations, which restrict its applicability. For example, the local LAN link could be a campus backbone with dozens of routers on it, all part of the same NSSA, and splitting the NSSA would impact aggregation. Draft SummaryThis draft was developed to remove a flaw in the design of OSPF. The author does a good job of explaining why this is needed, so I will just summarize. You have two border routers connected via a DS3 link (area 0) and they are connected to two other routers making up NSSA 1. All paths are T1 speed except the area 0 link, and each has the same cost, as illustrated in Figure 11-1.
In the current OSPF specification, intra-area routes are always preferred over inter-area routes. When looking at Figure 11.1, you consider the path from R1 to N2 to be:
However, a more optimal path through the DS3 in area 0 exists. We can provide several more examples on how the DS3 link is never even seen as an option even though it is magnitudes larger than a T1. In the current specification, R4 does not even see the optimal path through the DS3 because it is an internal router to the NSSA. R1 will see it, but because there is an intra-area route to N1, it cannot take advantage of it. Therefore, a need is apparent that enables the link between R1 and R2 to be seen in area 0 and NSSA 1. You could create NSSA 1 into a regular area and add a virtual link that would add extra load to your routers.
|
EAN: 2147483647
Pages: 200