× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 in fact.

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 same.

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 i nor the servers or clients it was talking to would have gotten a new ARP 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 ARP 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 might still have been directed there and that switch, no longer able to communicate with it, simply dropped the packets. So the correct solution 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 and others did not. Anything going through the old switch likely was getting 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 IBM i
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.