Dennis
Have you seen the thread in the IBMTCP-L list entitled "VIPARANGE
definitions"? This thread, focusing on just one of the original questions
asked, has discussed the essence of what you want to do, namely having VIPAs
defined in the IP address range which is also defined for the LAN to which
OSA feature ports are attached. Unfortunately nobody contributing to the
thread knew specifically whether this would work even though there are many
hints that it would work in the two key documents:
- System z9 and eServer zSeries Open Systems Adapter-Express Customer's
Guide and Reference - SA22-7935-05
- OSA-Express Implementation Guide - SG24-5948-04
I'm glad that Matthew Stitt confirmed that he was, indeed, putting a VIPA in
the LAN address range and, presumably, it works for him. One point he didn't
mention - and neither did you - is the issue[1] of using a dynamic routing
protocol. In principle, he shouldn't need to because ARP and the QDIO
mechanisms should be taking care of the dynamic discovery of the location of
the VIPA.
Particularly to do what you want, you should read and digest Appendix G in
the redbook "OSA-Express Implementation Guide". This describes the scenario
you want with the very unfortunate omission of the VIPA. However, if indeed,
your configuration is limited to one LPAR and two OSA feature ports on
separate adapters, you do not actually need a VIPA. This is nothing to do
with the redbook having not used a VIPA - although actually they may not
have used a VIPA because it wouldn't add anything to the basic point they
were making - but it is because you could have used either of the IP
addresses defined for the OSA ports. In the failure/backup scenario
described in Appendix G, when there is a failure, *both* OSA port IP
addresses can be found using ARP on the surviving OSA port *and*, very
importantly, any adjacent router ARP caches will be forced to make the
change because, at the time of the failure, a "gratuitous" ARP is sent out
describing the new association between the IP address, previously associated
with the MAC of the failing OSA port, and the MAC address of the surviving
OSA port.
The manuals mention, most explicitly in section 1.2.9, "Enhanced IP network
availability" of the OSA-Express Implementation Guide redbook, that, if
there is a VIPA, it too is included in the ARP mechanism just like the IP
address associated with the OSA port - and the IP address of any OSA port
which is being backed up.
<quote>
The OSA-Express feature port then responds to ARP requests for its own IP
address and for VIPAs.
</quote>
I can understand why you don't want to run multiple instances of the
Communications Server IP main address space since that is totally
unnecessary - but - I don't follow why you should have an aversion to
"binding" an application to an IP address. In principle, this is what VIPAs
are all about. You should, at least, plan to associate each of your
applications to an IP address so that, when (rather than "if") in the
future, also for the purposes of high availability during planned
maintenance and following "unforced errors" (it's tennis time again - the
Australian Open <g>), you have another production LPAR which can act as a
backup for your current production LPAR, you can convert your static VIPAs
to become dynamic VIPAs - although you may as well define them as VIPARANGE
dynamic VIPAs together with "binding" each application to an IP address from
the very beginning.
However, in the interim, you could associate one static VIPA to each of your
server applications using the BIND parameter of the PORT statement or the
parameters of the server application itself. It now occurs to me that the
former is probably to be encouraged as it provides more appropriate
documentation regarding the association than having to go trawling though
started task procedures to find where the VIPA is used.
I think your brain outstripped your fingers in the following sentence: "The
setup just needs to provide connectivity to my LPAR in the event of a
failure to port on switch connected to the first OSA." Probably you meant:
"The setup just needs to provide connectivity to my LPAR in the event of a
failure of the port on the switch connected to the first OSA." In fact, the
OSA backup mechanism will allow for the failure of either OSA port so that
either of the OSA ports which survives can, as it were, pretend to be the
failed OSA port until the failed port is repaired. Take a good look at that
Appendix G.
In terms of configuration, there is really nothing at all special that you
need to do for the basic backup scenario as described in that Appendix G.
It's all provided free, "under-the-covers" by the OSA features when run in
QDIO mode.[3] The only extension to the standard statements to be found in
the PROFILE data set in order for the VIPA to participate is what is shown
in Matthew Stitt's post is placing the VIPA in the same address range as is
used for the LAN to which the OSA ports connect, obviously the same address
range used by the IP addresses associated with the OSA ports. Matthew shows
only one set of definitions for an OSA port whereas you will have two sets,
of course.
Incidentally, it is not evident from the definitions which Matthew has
supplied, what the address range is for the LAN to which the OSA ports
connect. I am assuming that the mask used is something like 255.255.255.0,
"/24", - although actually 255.255.255.248, "/29", is the most extensive
mask that could apply - so that addresses 10.2.15.125 and 10.2.15.122 are
part of the same address range. We would need to see the relevant parts of
his routing table to be sure of that - assuming he is using static routes,
[1] People in this list - and in the supposedly English-speaking world
generally[2] - sometimes/often misuse the word "issue" when they are really
describing a "problem". The reason I'm highlighting this "issue" here is
that some people regard having to run a dynamic routing protocol, say, OSPF,
as a problem they'd prefer not to have to solve rather than an issue they'd
prefer not to have to deal with. Thus I could actually have said "problem"
rather than "issue" here.
A word of practical advice to all those reading who suspect I may have taken
leave of my senses: if you feel tempted to write/say "issue", try
substituting "problem" and see if it reads/sounds better. If it does, you
know what to do. If you never do, it's too late!
[2] I even suspect that the folk writing the text for BBC TV newsreaders are
becoming infected and some supposedly popular contemporary series on BBC TV
are in intensive care over the issue (sic). There was a
"fingernails-on-blackboard" example yesterday evening ("Waterloo Road").
[3] Even in non-QDIO mode you can get a similar benefit but you need to
perform OSA/SF customization rather than CS IP PROFILE customization.
Chris Mason
----- Original Message -----
From: "Dennis Leong" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Thursday, 25 January, 2007 11:01 PM
Subject: VIPA tcpip profile definitions
> I want to be able to setup high availability to my production lpar using
> static vipa with arp takeover. We have 2 osa ports on separate adapters
> running in qdio mode and we run z/os 1.4. I don't want to run multiple
> tcpip stacks and also do not want to bind any specific application to an
> address. The setup just needs to provide connectivity to my lpar in the
> event of a failure to port on switch connected to the first osa. What
are
> the key tcpip profile statements or better yet does anyone have working
> sample? Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
