Hot Topics - Messmer The Brain House

No dynamic routing protocol? No problem!
BY ALFRED CHRISTENSEN AND GUS KASSIMIS
Okay, so you have heard about all the great
benefits of Dynamic Virtual IP Addresses
(DVIPAs) and you’re sold. That is, you want
the availability, scalability and flexibility
that DVIPAs provide. You want to shield
your end users from failures in network
interfaces, applications, and systems or
changes in the network and computing
infrastructure.
There is one obstacle, however: does
deploying DVIPAs mean that you have to
deploy a dynamic routing protocol on your
z/OS systems? And, if the answer is yes,
does that become a deal breaker in your
environment?
If this sounds familiar, read on, there
might be some hope for you yet. While
running a dynamic routing protocol on
z/OS is the recommended approach to
deploying DVIPAs, it is possible to reap
many of the benefits of DVIPAs without
doing so.
Before we go into the details of what
that configuration looks like, let us quickly
review the reasons for the dynamic routing
protocol recommendation. That will help
us better understand the alternative
approach, including its benefits and any
drawbacks.
Why a dynamic routing protocol
is recommended
With a DVIPA, you can virtualize an IP
address and the resources represented
by the IP address. You can use a DVIPA
to provide a virtual view of a system, an
application or even an entire z/OS sysplex.
This means that a VIPA is not tied to
a specific network interface or even a
specific system. This capability provides
for a very flexible configuration, because
a DVIPA can move dynamically from one
system to another within a sysplex, during
planned configuration changes or during
unplanned outages.
Further, a DVIPA can tolerate failures
in network components. Dynamic routing
protocols, such as Open Shortest Path First
(OSPF), and a dynamic routing daemon,
such as the z/OS OMPROUTE daemon,
facilitate this dynamic nature of VIPAs.
OSPF and OMROUTE help to keep the
network infrastructure (such as routers)
aware of the best current network paths to
a DVIPA. As long as the system has some
36 February 2006 z/OS HOT TOPICS Newsletter, Issue 14
form of network connectivity, with at least
one network path to the DVIPA, users can
continue to use the DVIPA. This is true
even if multiple failures occur within the
network infrastructure.
Deploying DVIPAs without a
dynamic routing protocol
Without dynamic routing protocols to
keep routers and z/OS aware of the
whereabouts of DVIPAs and the status of
network adapters and LANs, we need to
rely on a lower level protocol, the address
resolution protocol (ARP), to help us
achieve the availability characteristics we
want. Using ARP for this purpose poses
some restrictions on how we design and
implement the IP network.
What is address resolution
protocol?
Every network adapter that is connected
to a local area network (LAN) has a
hardware address associated with it. This
address is known as the medium access
control (MAC) address. A network adapter
comes with a burnt-in MAC address—a
universally unique MAC address.
When computers attached to a LAN
need to send data to each other over the
LAN, they build LAN frames. The frame
header specifies the destination MAC
address to which the frame will go. The
frame body contains the data to be sent,
such as an IP packet.
So, how does an IP node on a LAN
discover the MAC addresses associated
with other nodes on the same LAN? That’s
where the ARP protocol comes into play.
It allows any IP node on a LAN to ask
for the MAC address associated with any
IP address on the same LAN by sending
broadcast frame containing an ARP
request for that IP address. The IP node
that owns that IP address then responds
with an Address Resolution Protocol (ARP)
reply that contains the MAC address for
one of its interfaces that is attached to this
LAN. The IP node that receives the reply
would then typically save the reply in an
ARP cache. Caching the reply allows this
information to be reused later if the IP
node needs to send another IP packet to
the same destination IP address.
OSA adapters and ARP processing
With OSA adapters operating in Queued
Direct IO (QDIO) mode, much of the ARP
processing is done by the OSA microcode.
Many TCP/IP stacks can share an OSA
adapter and, as a result, share a single
MAC address.
To help the OSA adapter determine
which TCP/IP stack an incoming IP
packet should be given, the OSA adapter
maintains a table that includes the home
IP addresses of all TCP/IP stacks that
share the adapter. This table is known
as the OSA address table (OAT) and its
content is strictly controlled by the TCP/IP
stacks, which register and deregister
HOME IP addresses as they become active
or inactive.
When an IP address is registered by
a TCP/IP stack in the OAT, the TCP/IP
stack indicates whether the OSA adapter
will do ARP processing for this address.
This allows the TCP/IP stacks to move
ARP responsibility from one OSA adapter
to another.
If an OSA adapter becomes unavailable,
but a TCP/IP stack has another OSA
adapter connected to the same subnet,
the TCP/IP stack requests the other OSA
adapter to take over ARP processing
responsibility for the IP address of the
failing OSA adapter in addition to its
own IP address — or, in a sense, move the
OSA IP address from one OSA adapter
to another. This process is also known as
ARP takeover.
VIPA and ARP processing
This ARP processing is the key to
achieving high availability with DVIPAs