Matthew I'm also glad that Dennis Leong has asked the question since it has prompted you to provide the benefit of your experience.
Have you seen the thread in the IBMTCP-L list entitled "VIPARANGE definitions"? Presumably not or you would have provided a similar response there when the matter of having OSA ports and VIPAs sharing the same address range arose. Alan Watthey is planning to try this so your experience is some encouragement. I've made a few comments on your post already in my reply to Dennis. In addition I would like to make a couple more. In terms of what is relevant to Dennis's project, there is nothing you show in the IPCONFIG statement which is actually needed - with one possible exception. The possible exception is the MULTIPATH parameter. In the part of the redbook which describes features of the OSA "ARP Takeover" in section 1.2.8, "ARP cache management", it is suggested that MULTIPATH is necessary in order to cause the OSA backup mechanism to happen. It's just about impossible to see why there should be a connection between the OSA backup mechanism and the IPCONFIG MULTIPATH parameter. Rather I think that the idea that the IPCONFIG MULTIPATH parameter should be specified is that, when you have two OSA ports connected to the same LAN, you will have the benefit of using them, that is, both of them when they are both working, only when you specify IPCONFIG MULTIPATH. This is actually the way the need for the MULTIPATH parameter reads in Appendix G - just about. A scan for the word "MULTIPATH" in System z9 and eServer zSeries Open Systems Adapter-Express Customer's Guide and Reference shows it used only with reference to "multipath channel" (MPC) and there is no mention of MULTIPATH in the section where relevant IPCONFIG parameters are discussed, section 1.7.2.2.1, "Recommendations" under 1.7.2.2, "Updating the TCP/IP Profile for QDIO". The following paragraph from a post of mine from last year applies if you have specified the MULTIPATH parameter of the IPCONFIG statement: <quote> If you switch to MULTIPATH, you are going to have to choose between PERCONNECTION and PERPACKET. Some folk insist on PERCONNECTION since this can avoid problems associated with fragmentation. If you have so designed your network that you can see that there will not be problems with fragmentation (or full packets arriving out of sequence), you may well prefer PERPACKET. For example, if your printer is being driven within one TCP connection, you won't see any change from what you have right now obviously with PERCONNECTION. </quote> I see you have MULTIPATH PERCONNECTION but it's not evident from the sample statements you supply that you potentially have multiple routes to some or all destinations. Specifically, you show only one set of definitions for an OSA port. Similar considerations apply to the IPCONFIG DATAGRAMFWD FWDMULTIPATH PERPACKET parameter with the additional point that you do not appear to be using your CS IP instance as a router. Maybe you have so pruned your definitions that what you show can't be taken as a consistent set of definitions. If this is so what you shouldn't have pruned is the set of definitions for your second OSA port. You do refer at the end of your post to OSA features in the plural. By "Preferably the VIPA IP address should be used in all instances." do you mean that the VIPA, a static VIPA in your example, should always be used as the destination address representing your applications? I would tend to qualify this by suggesting the following: a) that a single VIPA should be used as the destination for each application b) that it may as well be a VIPARANGE dynamic VIPA activated by use of the PORT statement entry BIND parameter today even if setting up backup LPARs and Automatic Restart Management (ARM) is for the future c) that each application service is identified in the name server using a name which describes that particular service and is associated with the (VIPARANGE dynamic) VIPA d) that there remains just one static VIPA which is associated with the node, may be so identified in the name server and is used for services necessarily tied to the node such as the SNMP agent Chris Mason ----- Original Message ----- From: "Matthew Stitt" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, 25 January, 2007 11:41 PM Subject: Re: VIPA tcpip profile definitions > Glad you asked this question. I just did something similar to your request. > Here are some key definitions I used: > > IPCONFIG > ARPTO 1200 > DATAGRamfwd FWDMULTipath PERPacket > SOURCEVIPA > NOSYSPLEXRouting > IGNORERedirect > MULTIPATH PERConnection > PATHMTUDISCovery > NODYNAMICXCF > NOIQDIORouting > TTL 60 > > ; DEVICE and LINK for VIPA Devices: > DEVICE VIPA1 VIRTUAL 0 > LINK VIPA1 VIRTUAL 0 VIPA1 > ; > ; DEVICE and LINK for MPCIPA QDIO Devices: > ; > ; QDIO (gen - OSD), see NET.VTAMLST(TRL??) > DEVICE OSA4VME MPCIPA NONRouter AUTORESTART > LINK Z990CH41LNK1 IPAQENET OSA4VME > > HOME > 10.2.15.125 VIPA1 > 10.2.15.122 Z990CH41LNK1 > > The connections can be made using any of the IP addresses assigned to the > OSA adapters, or the VIPA IP address. Preferably the VIPA IP address should > be used in all instances. > > On Thu, 25 Jan 2007 14:01:59 -0800, Dennis Leong <[EMAIL PROTECTED]> wrote: > > >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
