I disagree (respectfully). ARP has hardware addresses (i.e. MAC addresses) of the systems on its local network. If the MAC address changes - regardless of IP address, since that is just what ARP translates - then it cannot get the message out since ultimately its messages are being sent to the wrong MAC.
First of you should certainly have the CMNRCYLMT on your ETHERNET lines--
set to (1 0) to allow infinite retries. ALL Y'ALL should be doing this
Well I don't think it was ARP on the i unless you use different IP
Addresses for the HTTP servers than for Telnet. There is a one to one
relationship between ARP entries and IP Addresses so you can't mess up
the HTTP ARP entry and not the TELNET ARP entry as they would be the
In addition to that if you think about it, the ARP entries ON the i
would be for itself but also for anything it's talking to. Neither the
nor the servers or clients it was talking to would have gotten a new
entry. Only the switches changed. So lets look at the switches.
Switches have ARP tables too, in fact theirs are VERY important. When
you pulled out the cable and moved it to the new switch it's not the
table on the i that had a problem, it's entries were still correct. The
switches in the network however may very well have though the i was
still where it was before - on the old switch. Hence traffic to it
still have been directed there and that switch, no longer able to
communicate with it, simply dropped the packets. So the correct
was to clear the ARP entries on the switches.
Depending on the switch brand you can clear those tables from command
lines. You can always reboot them (not a pretty option.) IPLing the i
accomplished the task in a rather brute force way because when it came
back up it advertised itself on the network as well as allowing for
sufficient time to pass for the switches ARP data to age out.
So why could you connect with some things and not others? Very possibly
because of the path to the system. Some switches had correct entries
others did not. Anything going through the old switch likely was
stuck while traffic that made it to the new switch was likely OK.
But then I'm guessing a lot too. :-)
- Larry "DrFranken" Bolhuis
On 4/14/2011 8:43 AM, Don Cavaiani wrote:
Last night we put in all new switches, and quickly replugged the IBMi
Ethernet cable, and the system went on running, telnet for sure.--
However, the http servers no longer connected. This morning I
re-started all the HTTP servers, but we were still unable to connect.
I then did an IPL which brought everything back up.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my brevity.