The routing function in a sysplex

You might wonder how to keep on top of the routing requirements of these shifting IP addresses and shifting TCP/IP stacks.

What sort of routing solution can meet the changing needs of a DVIPA? We can begin by eliminating static routing. Static routing, under many circumstances, requires manual intervention if a DVIPA moves. Manual intervention would defeat the value of the sysplex's dynamic operations.

Looking at dynamic routing protocols, RIPv1 and RIPv2 should also be eliminated. The problem is that RIP protocols have a slow rate of convergence (up to 3 minutes). Convergence is the rate at which a network routing change is recognized and adapted to within a network. The value of a DVIPA is greatly diminished if it takes the routing layer several minutes to adapt to an IP address being moved.

The next choice of dynamic routing protocol is Open Shortest Path First, or OSPF, and it is the protocol recommended to support DVIPAs in a sysplex environment. With OSPF, when a DVIPA is moved to another host, convergence is both fast and automatic. Other hosts in the network can rapidly become aware of the new location of the DVIPA.

Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) has become an industry standard for dynamic routing within a given network. It is standardized most recently within RFC 2328, but OSPF standards seem to dapple the RFC landscape. Usually, the term OSPF is used to describe OSPF Version 2.

On z/OS, the OSPF protocol is implemented by the OMPROUTE server. The OMPROUTE server is actually a z/OS UNIX daemon. At the time of writing, OMPROUTE implements the OSPF Version 2 protocol as outlined in RFC 1583, as well as almost all of the features from RFC 2328. The important part is that OMPROUTE is completely compatible with adjacent routers that are capable of handling OSPF communications.

OSPF requirements in a cluster

The actual configuration of OSPF on z/OS, or any other host, is relatively straightforward. The difficult part is the network topology planning. From a network design viewpoint, OSPF is incredibly flexible, which translates to incredibly complex. Designing a well-planned network is a challenge.

The good news is that once an OSPF network has been designed, the actual configuration and execution of OMPROUTE is a straightforward task. However, there is one specific recommendation that we should discuss.

Even though OMPROUTE is a fully functional OSPF router, the z/OS operating system is not designed to be a backbone router operating system. So, a z/OS host (and in our case, a sysplex) should be implemented with the intention of having its dynamic routing requirements minimized. In the case of a sysplex, the ideal is to define the area encompassing the sysplex as a stub area. This is depicted in Figure 1.

Figure 1. OSPF stub area for sysplex

The area above the dotted line is area 0.0.0.2 (OSPF requires all router interfaces to be identified as being within an area; note that the number 0.0.0.2 is not significant--the area only needs to be unique).

What exactly is a stub area? The OSPF protocol defines a given routing area (as identified by the area number) as either being a transit area or a stub area. A transit area, as its name suggests, is an area that can have traffic passing through it. A stub area is nothing more than a network dead-end. Packets can flow into and out of a stub area, but traffic does not travel through it.

Why is this recommended for the sysplex? Here are some characteristics of a stub area:

A stub area router does not receive updates about the network beyond the stub area.
A stub area does not have any inter-area traffic (that is, you cannot reach any other OSPF network areas by travelling through the stub area).
Each stub area router communicates only default route and intra-area information.

The two routers shown in Figure 1, Router 1 and Router 2, are the routers that straddle two areas. These routers are referred to as area border routers, or ABRs. When updates from other areas arrive at an ABR, the information is not forwarded to the stub area.

Ultimately, an OSPF stub area allows the sysplex to be connected dynamically to the outside network and to dynamically reconfigure as appropriate within the sysplex. At the same time, the stub area minimizes the routing overhead required within the sysplex itself.

When TCP/IP rejoins an active sysplex

It was said before that communication within the sysplex is, as far as TCP/IP is concerned, effectively instantaneous. This means that when a TCP/IP stack joins the sysplex, its status is reflected immediately to all TCP/IPs participating in the sysplex. Yet, there is no guarantee that OMPROUTE is started immediately.

In fact, the TCP/IP started task can autostart a very large number of TCP/IP applications, of which OMPROUTE is only one. Obviously, OMPROUTE needs to build a routing table for TCP/IP in order for network communication can occur. TCP/IP can be configured to ensure that it does not join (or rejoin) the sysplex until OMPROUTE itself has been started. This reduces the possibility of a connection being routed to a host that doesn't yet have connectivity to the network.