|
|
OSPF's basic unit of topological information is called a link. It may be a bit confusing, but OSPF (and other link-state protocols) consider routers as a special kind of link. Do not assume that "link" is restricted to just media, which is the usage of "link" in the data-link layer of the OSI reference model.
As mentioned above, each piece of topological information is originated by one -- and only one -- router, the advertising router. Inside a single-area OSPF domain, you will principally be concerned with two kinds of link: router links and what OSPF calls network links.
Other link types are used to track topology involving multiple areas, as well as topology outside the OSPF domain. Link information is carried in a data structure called a link state advertisement (LSA), which is not a packet type itself but is carried inside various OSPF protocol packets discussed later in this paper.
Each router in the domain must have a unique router identifier, which is a 32-bit string normally written in the same four-octet form as an IP address. Every piece of routing information in an OSPF domain is "owned" by the advertising router. Other routers preserve the router ID in announcements that they propagate to other routers. Routing announcements originate in one -- and only one -- area, but, under some circumstances, can propagate to other areas.
Non-backbone areas have no internal auto-repair mechanisms. To ensure reliability, you need to ensure adequate redundancy.
Figure 2. Non-Backbone Area Failures
Controlling how announcements propagate between areas is the essence of how OSPF imposes hierarchy.
Do not put application servers into area 0.0.0.0, even if they are the central corporate servers. Even when there are only small sets of central servers, my usual practice is to put them in their own area, even if that area is no more than one LAN.
Think about a set of servers. There certainly will be backup, and there may be inter-server synchronization and distributed processing. This kind of traffic should stay local, in its own area.
The purpose of area 0.0.0.0 is inter-area transit, and your routing domain will be far easier to troubleshoot if you restrict it to that. A limited exception can be made for low-traffic infrastructure servers such as SNMP managers, TFTP servers, and primary DNS, which need to be extremely well-connected. DHCP servers often can have too large a peak load to be safe in area 0.0.0.0. Indeed, if you have significant DNS activity, put secondary or caching-only DNS servers in nonzero areas.
Keep the area 0.0.0.0 topology simple. You want enough redundancy to avoid single points of failure, but not so much redundancy that keeping track of alternative paths introduces significant hello and update traffic.
Figure 3 shows an OSPF area 0.0.0.0 topology I have used in many operational networks. It has no single point of failure. Each site has a pair of routers connected to each other with a high-speed LAN, and each of those routers is connected to a router at another site. Essentially, this is a ring topology, with redundant routers at each point of the ring.
Figure 3. Area 0.0.0.0 Example, Ring Topology
Another useful area 0.0.0.0 design works well for centralized networks.
Figure 4. Area 0.0.0.0 Example, Collapsed Backbone
You can make the switches and routers redundant, as shown by dotted box in Figure 4.
Figure 5 shows a general example of the areas in an OSPF domain. You will see that there can be various configurations of the area border routers (ABR) that interconnect nonzero areas with the backbone.
Figure 5. General Inter-Area
To understand the reasons for the guidelines about how many routers can go into an area, you need to know some theory of the computational workload of computing routing tables.
In a completely flat network, the work of computing a routing table is proportional to the number of prefixes in the network. Computer scientists phrase this workload as "on the order of" the number of prefixes, and write it as O(Prefixes).
When you go to a hierarchical structure, the workload of computing each area's routing table is on the order of the number of intra-area prefixes, plus the number of other prefixes injected into the area. For area k, we can express the workload as O(Prefixesk + Otherk).
But this formula isn't adequate for link-state protocols such as OSPF and ISIS, where the intra-area computation includes both prefix links and router links. The Dijkstra algorithm is used only for the intra-area calculation, and its workload goes up exponentially. Non-intra-area routes add linearly to the workload.
To do the preliminary assignment of areas, the boundaries of an area containing users, whenever possible, should follow a community of interest: a set of clients and servers with common applications, so traffic tends to stay inside the area. If the community of interest initially contains more than 50 to 100 OSPF-speaking routers, you probably want to split it on geographic boundaries.
Cisco recommends no more than 50 to 100 routers per area. This is a conservative recommendation that will work under most conditions with routers that have relatively slow CPUs, such as the 2500 series. In practice, with routers with RISC processors, it is usually practical to have a good deal more routers per area. The key thing to watch is CPU utilization. If the routers are consistently showing 50% 5-minute utilization, you should be cautious about adding more routers, and definitely not add more if utilization touches 70%.
Cisco's recommendation of a maximum of three areas per router also is conservative. The underlying reason for this rule is that the more areas that are connected to a router, the more likely it is that there will be a simultaneous change in more than one area, and a need to run the CPU-intensive Dijkstra algorithm in multiple areas.
Area Border Routers (ABR) connect one or more nonzero areas to the backbone (Figure 6). They have several functions.
Figure 6. Area Border Router
From a nonzero area to the backbone, the ABR blocks router LSAs, and converts appropriate LSAs to Type 3 inter-area LSAs. If there are Type 5 or Type 7 externals in the area, the ABR also exports them to the backbone unless filtering is specified. If the externals are Type 7 (NSSA), they are converted to Type 5 before they enter area 0.0.0.0. (More details on Externals and their types are covered later.)
ABR configurations include:
One physical ABR per area
One physical ABR servicing more than one area
Multiple physical ABRs servicing one area
Multiple physical ABRs servicing multiple areas.
[IE-OSPF2-WP1-F04]
[2001-07-31-02]
|