OSPF routing domain and areas

OSPF routing depends on the relationship that is defined between areas within a routing domain. CL commands are used to define area types and i5/OS routing neighbors.

For the OSPF protocol, an autonomous system (AS) is a collection of IP networks that are under a common administration, sharing a common routing strategy, and running only one routing protocol. The routers and links that make up the AS are in logical groups called areas. Areas are identified by uniquely assigned numbers and an AS must define at least one area.

When an AS is divided into multiple areas, the areas are interconnected by a router that is designated as an area border router (ABR). By definition, an ABR has different OSPF interfaces that are attached to different OSPF areas so that it can operate in more than one area. The ABR keeps a copy of the link-state database for each associated area.

All routers in an area have identical copies of the autonomous system topology database. Each router computes its own routing table using a spanning tree algorithm, called the Dijkstra algorithm, that computes the Shortest Path First.

OSPF supports multipath, which means it supports multiple routes to the same destination or system. When a new link-state update packet is received, the entire tree is recomputed. Other multipath calculation considerations include the following:

The routing tree retains all multiple equal-cost routes.
The routing tree selects only the shortest path for retention when multiple routes exists to the same destination.
Both costs are added to the stack when two routes, that have the same costs, are to the same destination.
OSPF always adds the route with the lowest cost to the TCP/IP stack.
Multipath routes to the same destination are added to the TCP/IP routing table when those paths have the same cost.

Each router in an OSPF area originates a link-state advertisement (LSA), which is a basic means of OSPF communication, to transport the topology of one router to all other routers in the same OSPF area. Each link-state originated advertisement, in each router, is stored in its link-state database. The database is synchronized between routers so that each router of the OSPF area, has an identical copy of the link-state database.

An ABR uses a separate, summary-LSA to advertise to all other destinations that are known to the ABR but that are outside of the area.

An area designated as the backbone area is a requirement in an OSPF AS. All areas must connect to the backbone because it is responsible for providing routing information between all areas in the OSPF AS. This backbone or tree-like design supports routing from any ABR to any other ABR by traversing only backbone network segments.

Areas are identified by an ID that is four octets in length. The backbone area is always assigned to the reserved ID of 0.0.0.0. All other areas in an AS must have a unique identifier. By definition an OSPF area is a collection of networks, not a collection of routers. A backbone network segment is an IP subnet that belongs to the area identified by 0.0.0.0. Areas that are not physically connected to the backbone are logically connected by a backbone ABR using an OSPF virtual link. The Add OSPF Area (ADDOSPFARA) command adds i5/OS backbone and nonbackbone areas to an OSPF configuration.

Depending on the size of the routing trees, OSPF is compute-intensive so it is common to populate only nonbackbone areas with application servers. The topology of one area is hidden from the rest of the areas of an AS to reduce routing overhead, because fewer routing updates are sent and smaller routing trees are computed and maintained. This also leads to a reduction in storage and CPU consumption.

Figure 1. Split an OSPF routing domain into areas.

In the example, the backbone area is located at IP address 9.7.85.0. Three nonbackbone areas, area 1.1.1.1, area 2.2.2.2, and area 3.3.3.3, are connected, with area 3.3.3.3 connected to the backbone area through a virtual link.

OSPF backbone, nonbackbone, and stub areas

The backbone area requirement is that the distribution of routing information is done from subnet areas to the backbone area and then the backbone sends this information to the rest of the nonbackbone areas. To distribute routing information through different areas, the ABR does calculations from entries of routing tables, which are summary-LSAs, that are received from the backbone area. The ABR then sends this routing information, also in LSA-summaries, to its attached nonbackbone areas.

Virtual links are configured between ABRs and are considered point-to-point interfaces to connect nonbackbone areas to the OSPF backbone area 0.0.0.0, when there is not a physical connection between them. When the virtual link reaches full adjacency with a neighbor through a nonbackbone area, this nonbackbone area is advertised as a transit area. Transit areas carry traffic that is not originated in or destined for the area itself.

An area that is configured as a stub area does not support the flooding of external routing information by external LSAs. Stub areas are configured to omit external routing to reduce CPU cycles and to reduce the size of its link-state database. The only way an i5/OS stub area can reach external routing is by a default route. To configure a stub area, set the stub area option to *YES on the ADDOSPFARA or Change OSPF Area (CHGOSPFARA) command:

ADDOSPFARA AREA('1.1.1.1') STUB(*YES)

Another type of area is called a totally stubby area, which receives less routing information than a stub area. It receives only default routes. Totally stubby areas minimize the compute-intensive operations necessary to build routing trees and also minimize the storage requirements for the topology database. To configure an area as a totally stubby area, set the IMPORT parameter to *YES, on the ADDOSPFARA or CHGOSPFARA command:

ADDOSPFARA AREA('1.1.1.1') STUB(*YES) IMPORT(*YES)

The OSPF not so stubby area (NSSA) type is not supported on i5/OS.