Michael Unfortunately, the first type of OSA with which I have worked is the OSA-2. It appears from what Shane tells us that the Amdahl OSA is, in effect, an OSA-1.
Indeed it is possible to have multiple IP address entries specified for an OSA feature port in order that the destination IP address can be recognised in an arriving IP packet. Then the packet is passed to the IP instance in the LPAR identified to be associated with that destination IP address. Also, although not necessarily, those destination IP addresses can be VIPAs. Additionally there is a parameter which permits unrecognised, that is not specifically identified, IP addresses to be passed to a particular IP instance. The parameter is a little complicated in that it can take the values "primary", "secondary" or "none". I just checked section 6.4.3.2, "A Basic Passthru OAT Entry" in the "z900 Planning for the Open Systems Adapter-2 (OSA-2) Feature" manual, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IOA2GP00, and the parameter actually corresponds to the specification PRIROUTER, SECROUTER and NONROUTER in the MPCIPA (QDIO) DEVICE statement. It's surely normal, default, behaviour, that, if an adapter receives an IP packet it passes it to the IP instance which "opened" the adapter. If the destination IP address is one of those in the logical "home" list the packet will be passed to the logic, the application program, associated with the destination port (possibly via the TCP layer). If the destination IP address is *not* one of those in the logical "home" list, the "IP forwarding" option is checked. If the "IP forwarding" option has been enabled, the packet will be passed to the routing table logic. If the "IP forwarding" option has *not* been enabled, the packet will be passed to the "bit bucket" - just as it is when there is no appropriate port "open" or when the routing table logic can't handle the destination IP address. In other words, it's business as usual for an adapter *not* to concern itself with whether or not the IP packet has a recognisable destination IP address. It's only when adapters are shared between IP instances that defining IP addresses in adapter logic comes into play. If the Amdahl OSA feature allows this sort of sharing *surely* it doesn't throw away the possibility to pass unrecognised destination IP addresses to one of the sharing IP instances. In other words, using the MPCIPA parameter names, surely the default is PRIROUTER and not NONROUTER. Another "in other words": your sentence "This means both the real IP Address and the VIPA need to be defined to the OSA to get it to route correctly." is surely not true. I'm actually rather puzzled by your concept of a VIPA since the whole idea of a VIPA is to have one (or more, and, typically, if more, "floating", dynamic) IP address(es) which is (or are) *not* associated with any particular adapter. So, in terms of what you should do, I suggest the following: 1. Install your Amdahl OSA feature 2. Define the port/one of the ports of the OSA to Communications Server (CS) IP as an LCS adapter 3. Define your static VIPA in CS IP 4. In the router on the same LAN as the OSA port define a static route where the destination is the VIPA (which should not be using the same IP subnet) and the "next hop" is the IP address of the OSA port - and so on for other routers Of course, you could be using dynamic routing in which case you will not need step 4 but you will need to study how OMPROUTE handles VIPAs. Post again if you need help with this topic. Incidentally, I just checked my previous post and, although I was very unsure at the time, I see I was right that your problem was in the area of the "device router status" parameter. Finally, is the reason you need a VIPA because you want to implement Enterprise Extender? This might explain why you haven't seen the need to examine what a VIPA really is. Chris Mason ----- Original Message ----- From: "Michael Buckley" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, 21 September, 2006 12:35 AM Subject: Re: Amdahl OSA cards and VIPA > THe Amdahl OSA is not capable of QDIO, it is in fact defined as an LCS > device. This means both the real IP Address and the VIPA need to be difned > to the OSA to get it to route correctly. On an IBM OSA this is done by > updating the OSA configuration (OAT) with both addresses. For the Amdahl > card this does not appear to be possible. One possibility is to define 2 > devices to each LPAR with different IP Addresses on each. I do not beleive > this will work though, as the device for the VIPA seems to require a type > of VIRTUAL. OSA/SF will not work on Amdahl OSAs, so no help there, > unfortunately. I do have a manual provided by Amdahl for OSAs, but it does > not mention how this should be done at all. I would be happy with either a > response that 'do this and this and this', or 'it can't be done' ---------------------------------------------------------------------- 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
