|
Home > Archive > WebSphere Edge Server > January 2004 > ND uses a malformed/invalid mac address
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ND uses a malformed/invalid mac address
|
|
|
| Sorry about the previous incomplete message .. I fell asleep on the
keyboard!.
Hi,
We're running ND 3.6.1 on Solaris 2.6 in HA mode.
We have one cluster address configured to dispatch three ports
with two servers each see the primary dispatcher config file below.
Recently our primary Dispatcher was found to be dispatching packets
to an invalid or malformed mac address, that is: e6:50:0:2:93:50. which
we discovered while snooping on the servers interfaces.
The switch was broadcasting the packets to all ports, I guess because this
mac was unknown to it and didn`t know where to send it.
This append following a scheduled shutdown of all the servers related to
this configuration.
The advisors, which are ip based, were reporting all services as up.
The end result was 50% of new connections timing out.
The problem was resolved by shutting down the primary ND and restarting it.
We are still trying to figure out what caused ND to learn this bad mac addr.
Has any of you experienced this behaviour ?
Thanks
Eric
=START=========== CONFIG FILE ==============
ndcontrol executor start
ndcontrol executor set nfa 131.195.11.201
ndcontrol cluster add 131.195.11.200 primaryhost 131.195.11.201
ndcontrol port add 131.195.11.200:389
ndcontrol server add 131.195.11.200:389:131.195.11.201
ndcontrol server set 131.195.11.200:389:131.195.11.201 collocated y
ndcontrol server add 131.195.11.200:389:131.195.11.202
ndcontrol port add 131.195.11.200:636
ndcontrol server add 131.195.11.200:636:131.195.11.201
ndcontrol server set 131.195.11.200:636:131.195.11.201 collocated y
ndcontrol server add 131.195.11.200:636:131.195.11.202
ndcontrol port add 131.195.11.200:6421
ndcontrol server add 131.195.11.200:6421:131.195.11.26
ndcontrol server add 131.195.11.200:6421:131.195.11.27
ndcontrol cluster configure 131.195.11.200 qfe0 255.255.255.0
ndcontrol manager start manager.log 10004
ndcontrol manager proportions 49 49 2 0
ndcontrol advisor start ldap 389 ldap_389.log
ndcontrol advisor interval ldap 389 30
ndcontrol advisor start ldaps 636 ldaps_636.log
ndcontrol advisor interval ldaps 636 30
ndcontrol advisor start connect 6421 entps_6421.log
ndcontrol advisor interval connect 6421 30
ndcontrol highavailability heartbeat add 131.195.11.201 131.195.11.202
ndcontrol highavailability backup add primary auto 10000
=END=========== CONFIG FILE ==============
| |
| Dan Poirier 2004-01-19, 3:02 pm |
| ND itself just sends packets to server IP addresses. It doesn't know
MAC addresses. It sounds as if the ARP table in that machine got an
incorrect MAC address in it somehow. Maybe a corrupted ARP reply
packet?
--
Dan Poirier <poirier@us.ibm.com>
| |
|
| Correct me if I'm wrong, but the way I understand it is that ND rewrites the
destination MAC addr in order to
forward the packets to the real server. So it has to know the servers MAC
addresses.
When the problem occured, the ARP table on the primary Dispatcher was just
fine which lead me to believe
that ND either uses is own "arp table" or caches the ARP information.
Also, when we discovered the wrong MAC, the connect:6421 advisor was
perfecly able to communicate with
the server therefore probably indirectly making use of the OS arp table.
I did some testing;
When restarting the primary Dispatcher it flushes the arp entries for the
servers and sends an arp request.
Then I manually corrupted the arp entry of one of the servers.. the
dispatcher was still able to dispatch to this
server.. it means it caches the MAC addr..
Eric
"Dan Poirier" <poirier@us.ibm.com> a écrit dans le message news:
yujn0pcuakv.fsf@percival.raleigh.ibm.com...quote:
> ND itself just sends packets to server IP addresses. It doesn't know
> MAC addresses. It sounds as if the ARP table in that machine got an
> incorrect MAC address in it somehow. Maybe a corrupted ARP reply
> packet?
>
> --
> Dan Poirier <poirier@us.ibm.com>
| |
|
| Eric,
ND does indeed resolve MAC addresses. There was a problem, which has
been fixed in 3.6.1.11 and higher, where ND on Solaris with multiple
interfaces would incorrectly discover MAC addresses (the first section
of the MAC address would inherit information from previous MAC addresses
instead of starting clean). Please download either 3.6.1.11 or 3.6.1.12
from the L2 support ftp server (contact IBM support if you need access
information). Test with that corrected MAC code and see what happens.
Note: Edge Server V1.0 (ND 3.6) is out of defect support, meaning IBM
will not fix newly discovered defects free of charge. As long as you
have a support contract, you will of course continue to receive
config/install help and fixes for known defects (such as the MAC one
above). Just FYI...
Jeff
|
|
|
|
|