RE: Can someone explain this?

I think the point is the importance of the ARP table... and not on one
system, but on all of them local to that switch. As we have done in such
scenarios, every server within the local net will have its network ARP
cleared/reset/flushed when such a change is made. Else you might end up
with lots of head-scratchers that make no sense. Fact is: ARP wasn't
designed to make sense in that scenario.

If those two systems are across the switch (not in the same subnet) they
cannot communicate unless they don't know the new MAC of the switch. The
configuration of the network is an absolute unknown; I cannot comment
further on what might be true for them.

I thought the OP said that *all* switches were changed. I could be wrong,
but that was where I was coming from, and doesn't apply to the situation
below.

Recall that the OP question (only question) was something like "what might
cause this?" My response was ARP. I don't think anyone including you has
made a different suggestion... the only variable has been "whose ARP is it?"

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"If lawyers are disbarred and clergymen defrocked, doesn't it follow that
electricians can be delighted; musicians denoted; cowboys deranged; models
deposed; tree surgeons debarked and dry cleaners depressed?"
-- Virginia Ostman
... and programmers decoded.
-- Rory Hewitt

Your are correct, sort of. The MAC address of any IP address a system
is
communicating with will either be it's its ARP table OR the system will
send our an ARP packed seeking to obtain that MAC address. However,
even
if every single piece of network gear between system "A" and system "i"
was replaced the MAC address of System "A" and that of system "i" will
remain the same. Those addresses will either be the burned in address
of
their respective Ethernet cards or an overridden address in the *LIND
object. So despite a wholesale change in the network gear the tables on
each end do not change. But if the switches change, or worse, only one
switch changes, the path TO those MAC addresses might change. Since we
know the "i" was moved to a new switch, that old switch needs to
'learn'
that the 'i' (or more correctly it's MAC address) is now somewhere else.
Something has to happen for it to learn that. One way is for the tables
in the old switch to 'age out'. Another way is for the 'i' to send out
a
gratuitous ARP entry advertising it's new location, a third is for
traffic from the 'i' to enter that switch from a port it's not expected
to enter on (OH you're over THERE!) Until at least one of those
things
happen, that switch could be dumping traffic and communications is
broken.

- Larry "DrFranken" Bolhuis

On 4/14/2011 12:04 PM, Dennis wrote:

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.

"DrFranken"<midrange@xxxxxxxxxxxx> wrote:

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.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my

brevity.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.