Bret I'm glad John remembered to mention this function to you - I'd forgotten - and I had to describe it in a report so you'd think I'd remember.
The function is however very well described in the "OSA-Express Implementation Guide" redbook, Appendix G, "ARP Takeover". A good knowledge of the ARP protocol helps in understanding how this function works. John As "boys will be boys", "bigots will be bigots". Chris Mason ----- Original Message ----- From: "McKown, John" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, 31 August, 2006 9:47 PM Subject: Re: outbound TCP/IP question > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of Hoesly, Bret > > Sent: Thursday, August 31, 2006 9:49 AM > > To: [email protected] > > Subject: outbound TCP/IP question > > > > > > Hello, > > > > We have 3 OSA ports (IP's) defined in our TCP/IP stack on our > > z890. We > > recently converted our print center to TCP/IP printing. What we have > > noticed is only the first port (IP) defined in the stack is being > > utilized for outbound TCP/IP traffic. Is there a setting > > within TCP/IP > > that we are not aware of that is limiting the use to the one > > port (IP)? > > We really expected to see all 3 being utilized. > > Look at IPCONFIG MULTIPATH. The default is NOMULTIPATH > > > > > Our main concern is if the first port has a hardware problem > > will TCPIP > > use one of the other 2 ports (IP's) or will we have an outage to deal > > with? > > Yes, you will automatically use one of the other OSA cards. In fact, we > had this happen. We have two active OSA cards, only using one port on > each card. When one of the OSA cards failed, the other OSA card > automatically did an "ARP takeover" (or something like that). That is, > every session that was going to the failed card transparently went over > to the other OSA card. Neat! The surviving OSA card even responded to > the other OSA card's IP address for pings and session establishment. > > When the first OSA card was fixed, we just did a VARY command to get the > I/O addresses back ONLINE to z/OS, then a TCPIP START command to restart > the device. At this point, the second OSA stopped doing the "ARP > takeover" and traffic again, transparently without any outage, went back > to the first OSA card. > > This was truly wonderful and surprised the holy <elided> out of the > Windows networking people. They thought the entire z/OS system would > fail or at least TCPIP. When everything "just kept working", they were > stunned and disbelieving. Even so, they still thing Windows is superior > to z/OS in every way, manner, and form. <sigh> You can't even rub their > noses in it to any effect. > > > > > Any help with this would be greatly appreciated. > > > > Thank you, > > Bret Hoesly > > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology ---------------------------------------------------------------------- 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
