Gadi > BTW, since we defined the partition, we've added some VIPA's, and they work fine, even without defining them in the OAT.
You need to define VIPAs in the OAT - with OSE - if you are sharing an OSA and you want to have arriving IP packets passed to the correct Communications Server (CS) IP instance. When you use OSD, the set of IP addresses associated with real and logical interfaces of the CS IP instance, corresponding to the internal dynamic version of the HOME statement list, is kept in step with the OAT entry for that CS IP instance dynamically.If you are using dynamic VIPAs and they "belong" to the address range which corresponds to the address range you have associated with the LAN, the so-called "subnet", you will also get proactive ARP support - commonly called "gratuitous" - so that "moving" a dynamic VIPA can be tracked by adjacent routers supporting IP traffic on the LAN. In the case of OSE you are obliged to set up this correspondence manually. Generally this will mean that dynamic VIPAs are impractical. In addition, this will mean that you cannot use dynamic ARP support. OSE is very limited! It is no surprise that a *static* VIPA which is *not* defined in the OAT will work. Also a *dynamic* VIPA would work if supported by a dynamic routing protocol. The key point is whether the router adjacent to the OSE OSA interface "knows" to route an IP packet with the destination address of the VIPA to (one of) the address(es) defined in the relevant OAT entry which "belongs" to the same address range as the relevant interface of the adjacent router and thereby participates in the ARP on the LAN. If the routing table in the adjacent router defines the VIPA - or a range of IP addresses which incorporates the VIPA - as an IP address - or range - which can be reached indirectly by being sent to an address within the same range as the range which applies to a LAN to which the router has an interface, that obviously works - at least in that "inbound" direction. Similar basic IP routing logic will apply for the "outbound" direction and, when both are correctly defined, statically or dynamically, any old PING will work! - > The main problem is that the second partition to come up does not have TCP/IP connectivity. No ping, either from with the partition or from outside the partition. I was hoping for a bit more precision here. Does the START operation for the DEVICE statement in the second CS IP instance succeed? If it does, you should try to PING the associated IP address from the adjacent router. If the routing you have defined in the second CS IP instance is correct, the PING should succeed. In addition you will have provoked ARP into creating an entry in the adjacent router for the IP address used in the PING command. There will also be an ARP entry in the second CS IP instance for the IP address of the adjacent router interface. It was this precise dissection of what did not function as expected I was hoping to see. Simple "sharing" of an OSA feature should work. I see from the response to Jack Kelly's post that you have the "hardware" definitions in place. Saying "the second partition to come up" tends to imply that it all works when either "PROD" or "TEST" is active but not both. Does the second CS IP instance work when the first CS IP instance has not activated the OSA feature? - > If I have more than 8 IP addresses, how would my OAT look? I'm not sure I follow your point here but it may not be important if you are not getting any particular benefit from placing VIPAs in the OAT. Chris Mason On Thu, 10 Dec 2009 16:19:17 +0200, גדי &#1489;ן אבי <[email protected]> wrote: >The main problem is that the second partition to come up does not have TCP/IP connectivity. No ping, either from with the partition or from outside the partition. > >If I have more than 8 IP addresses, how would my OAT look? > >BTW, since we defined the partition, we've added some VIPA's, and they work fine, even without defining them in the OAT. > >Gadi > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chris Mason >Sent: Thursday, December 10, 2009 4:11 PM >To: [email protected] >Subject: Re: OSA OAT problem > >Gadi > >>The OSA is defined as OSE. >> >> ... >> >>1. Do I have to define the VIPAs in the OAT? > >Yes > >From the Open Systems Adapter-Express Customers Guide and Reference: > ><quote> > >ARP Takeover > >... > >When TCP/IP is started in QDIO mode, it downloads all the home IP addresses >in the stack and stores them in each OSA-Express feature. This service of >QDIO architecture occurs automatically for OSD channels. > >For OSA-Express features set up as OSE channels (non-QDIO), you must >define multiple IP addresses in the OAT using OSA/SF as all the ARP functions >reside in the Host TCP/IP Stack. The OSA-Express then responds to ARP >requests for its own IP address, as well as for virtual IP addresses (VIPAs). >The OSA that is planned to takeover the ARP responsibility should have its >own IP address, VIPA address and the IP addresses that it is planned to >takeover in its OSA Address Table. > >... > ></quote> > >>2. How do I define the OAT so that both partitions have TCP/IP access? > >What symptoms do you see? > >>3. Do I have to use leading zeroes in the IP addresses? > >I don't believe so. > >Chris Mason > >On Thu, 10 Dec 2009 15:41:40 +0200, גדי &#1489;ן אבי <[email protected]> wrote: > >>Hi, >> >>We have an OSAExpress2 1000Base-T on our z890. >>There are two partitions defined, and they share the OSA. >>The OSA is defined as OSE. >> >>Each partition has one Physical address and many virtual addresses. >> >>The problem: Only the first partition that is IPLs has TCP/IP access. The >other partition cannot access the OSA. >> >> >>1. Do I have to define the VIPAs in the OAT? >> >>2. How do I define the OAT so that both partitions have TCP/IP access? >> >>3. Do I have to use leading zeroes in the IP addresses? >> >>TIA >> >>Gadi >> >>This is what my OAT currently looks like >> >> Image 0.0 (N/A) >>00(N/A)* passthru 00 no S OSA >> Image 0.1 (PROD ) >>00(1200)* passthru 00 Pri 010.206.005.016 SIU ALL >> 010.205.001.001 SIU ALL >>* 010.203.030.051 SIU ALL >>* 010.203.030.052 SIU ALL >>* 010.203.030.053 SIU ALL >> 010.203.030.054 SIU ALL >> 010.203.002.070 SIU ALL >> 010.203.010.071 SIU ALL >> 010.203.010.091 SIU ALL >> 010.206.005.022 SIU ALL >>02(1202) SNA 00 SIU ALL >> Image 0.2 (TEST ) >>00(1200)* passthru 00 Sec 010.206.005.010 SIU ALL >> 010.205.001.017 SIU ALL >> 010.206.005.020 SIU ALL >>02(1202) SNA 00 SIU ALL ---------------------------------------------------------------------- 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
