Walter I always wondered why the manual bothered mentioning the famous "downloading" of IP addresses in the preamble to the section on "Querying and Purging the ARP Cache" - and now - I guess - I know! You need to keep in mind that OSA logic is playing "fast and loose" with ARP entries as IP addresses fly around in your Communications Server IP component.
The conclusion would appear to be to purge the ARP cache when you are reconfiguring the IP address "environment" of your LAN - which actually sounds eminently sensible whatever "tricks" may be happening "under the covers"! So that's "purge the ARP cache" rather than "shut down LPARS" - should be a bit easier and, well, a bit less disruptive! Chris Mason [1] Open Systems Adapter-Express Customers Guide and Reference, Chapter 9, "OSA Port Management": <quote> Querying and Purging the ARP Cache The Address Resolution Protocol (ARP) cache resides on the OSA-Express feature. When TCP/IP is started in QDIO mode, it downloads all the home IP addresses in the stack and stores them in the ARP cache. When running OSA- Express features in QDIO mode in a z/OS V1R4, z/VM Version 4 Release 4, or Linux environment, you can query and purge the contents of the ARP cache. Communications Server for z/OS V1R4 adds support for querying and purging the ARP cache using the following commands: To purge the ARP cache on z/OS VARY TCPIP,,PURGEcache,linkname for example, v tcpip,,purgec,link4 To query the ARP cache on z/OS DISPLAY TCPIP,,NETSTAT,ARP,ip_addr for example, d tcpip,,net,arp,10.11.91.200 or TSO NETSTAT command, for example, netstat arp all tcp tcpip To query the ARP cache on z/VM NETSTAT command, for example, netstat arp * See z/VM TCPIP Users Guide. The Linux qetharp utility is available to query or purge the contents of the ARP cache, for example: qetharp -q eth0 shows all ARP entries for OSA-Express interface eth0, while qetharp -p eth0 removes all entries from the ARP cache for OSA-Express port eth0. See Linux for zSeries: Device Drivers and Installation Commands, LNUX-1103, for a complete description of this command. </quote> On Wed, 19 May 2010 02:58:12 -0700, Walter Marguccio <[email protected]> wrote: >yes, we got: > >EZZ4329I LINK OSA > > Look for messages like: .... yes, we got: EZZ4329I LINK OSAEGFCLNK HAS TAKEN OVER ARP RESPONSIBILITY FOR INACTIVE LINK OSAEGF8LNK at the time we moved the cables. after all 6 cables were connected to the new, single switch (I know, this is a SPoF), the only OSAs we were able to ping/telnet were the OSC CHPID-type (OSA- Express2) for our MCS consoles and non-SNA TSO sessions. All other OSAs on OSD CHPID-type (OSA-Express3) were not reachable. I understand that the ARP cache might have had the old MAC address of the old switch stored, but I wonder if there is a command or another way to tell : "just forget all your connections so far, from now on you are connected to a new switch whose MAC address is xxxxxxxx" The only way which on Sunday did work was resetting the OSAs the hard- way, from the SE. Is is a WAD, or are we BAD ? ;-) Annswer to BTW2: we have 2 physical OSA-Express3 (4 OSD channel type) and two physical OSA-Express2 (2 OSC and two OSE channel type). Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany ---------------------------------------------------------------------- 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
