|
Home > Archive > WebSphere Edge Server > October 2004 > EdgeServer/LB 5.1.1 on Solaris 9 problems
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 |
EdgeServer/LB 5.1.1 on Solaris 9 problems
|
|
|
| Hi,
We have the following problems with EdgeServer/LB v5.1.1 on Solaris 9
Current setup:
Dispatcher 1 & 2 are on sites A & B respectively and are attached to two
extended VLANs (116 & 157).
Exact version: 05.01.01.00 - 20040625-181023 [wsbld207]
Dispatcher 1
========
dscontrol executor start
dscontrol executor set nfa X.X.157.50
dscontrol cluster add X.X.157.200 address X.X.157.200 primaryhost X.X.157.50
dscontrol port add X.X.157.200:389
dscontrol server add X.X.157.200:389:X.X.157.14
dscontrol server add X.X.157.200:389:X.X.157.133
dscontrol manager start manager.log 10004
dscontrol advisor start LDAP X.X.157.200:389 advisor-ldap389.log
dscontrol advisor interval LDAP X.X.157.200:389 15
dscontrol highavailability heartbeat add X.X.157.50 X.X.157.150
dscontrol highavailability heartbeat add X.X.116.50 X.X.116.150
dscontrol highavailability backup add primary auto 44500
Dispatcher 2
========
dscontrol executor start
dscontrol executor set nfa X.X.157.150
dscontrol cluster add X.X.157.200 address X.X.157.200 primaryhost X.X.157.50
dscontrol port add X.X.157.200:389
dscontrol server add X.X.157.200:389:X.X.157.139
dscontrol server add X.X.157.200:389:X.X.157.133
dscontrol manager start manager.log 10004
dscontrol advisor start LDAP X.X.157.200:389 advisor-ldap389.log
dscontrol advisor interval LDAP X.X.157.200:389 15
dscontrol highavailability heartbeat add X.X.157.150 X.X.157.50
dscontrol highavailability heartbeat add X.X.116.150 X.X.116.50
dscontrol highavailability backup add backup auto 44500
Problem 1) Booting ONLYone of two Dispatchers stalls with HA
status/sub-state => Listen
I have two dispatcher configured in HA mode (Primary/Standby not MHA).
The problem is that whenever I boot any one of the two machines its HA
status/sub-state
shows "Listen".. and will never start dispatching unless I do one of the
following;
1) Restart the dispatcher manually (no reboot)
2) Start the second machine
then everything start normally.
Is this a Normal behaviour ?
Is there any saved state between reboot ?
Problem 2) One of the two dispatchers MAC forwards with an invalid MAC
address
This is strange!
For an unknown reason (yet!) when dispatcher B starts it caches an
invalid MAC address for
server X.X.157.14.
Symptom: It DOES dispatch to it but the packets NEVER reach server
X.X.157.14.
I tried to use a different IP addr. .. same thing.
I decided to snif on the interface while dispatcher starts up using
snoop in order to find out wich node responds to the arp request
but strange enough ... server X.X.157.14 does respond with the correct
MAC.. when snooping.. and it works fine only .. when snooping.
When not snooping dispatcher always starts up with an invalid MAC addr..
I tried snooping/not snooping promiscuous mode or not about 20 times...
it's constant .. snooping makes the problem go away.
Our telecom team is currently investigating the network equipement .
Any idea on what could cause this besides the network equipement ??
Thanks
I don't have any hair left to pull
| |
|
| ERRATUM:
Dispatcher 2 setup below you should read
dscontrol server add X.X.157.200:389:X.X.157.14
instead of
dscontrol server add X.X.157.200:389:X.X.157.139
Eric
"Eric" <e.g@eg.com> a écrit dans le message de
news:clqs83$66pq$1@news.boulder.ibm.com...
> Hi,
>
> We have the following problems with EdgeServer/LB v5.1.1 on Solaris 9
>
> Current setup:
>
> Dispatcher 1 & 2 are on sites A & B respectively and are attached to
two
> extended VLANs (116 & 157).
> Exact version: 05.01.01.00 - 20040625-181023 [wsbld207]
>
> Dispatcher 1
> ========
> dscontrol executor start
> dscontrol executor set nfa X.X.157.50
> dscontrol cluster add X.X.157.200 address X.X.157.200 primaryhost
X.X.157.50
> dscontrol port add X.X.157.200:389
> dscontrol server add X.X.157.200:389:X.X.157.14
> dscontrol server add X.X.157.200:389:X.X.157.133
> dscontrol manager start manager.log 10004
> dscontrol advisor start LDAP X.X.157.200:389 advisor-ldap389.log
> dscontrol advisor interval LDAP X.X.157.200:389 15
> dscontrol highavailability heartbeat add X.X.157.50 X.X.157.150
> dscontrol highavailability heartbeat add X.X.116.50 X.X.116.150
> dscontrol highavailability backup add primary auto 44500
>
> Dispatcher 2
> ========
> dscontrol executor start
> dscontrol executor set nfa X.X.157.150
> dscontrol cluster add X.X.157.200 address X.X.157.200 primaryhost
X.X.157.50
> dscontrol port add X.X.157.200:389
> dscontrol server add X.X.157.200:389:X.X.157.139
> dscontrol server add X.X.157.200:389:X.X.157.133
> dscontrol manager start manager.log 10004
> dscontrol advisor start LDAP X.X.157.200:389 advisor-ldap389.log
> dscontrol advisor interval LDAP X.X.157.200:389 15
> dscontrol highavailability heartbeat add X.X.157.150 X.X.157.50
> dscontrol highavailability heartbeat add X.X.116.150 X.X.116.50
> dscontrol highavailability backup add backup auto 44500
>
> Problem 1) Booting ONLYone of two Dispatchers stalls with HA
> status/sub-state => Listen
>
> I have two dispatcher configured in HA mode (Primary/Standby not MHA).
> The problem is that whenever I boot any one of the two machines its HA
> status/sub-state
> shows "Listen".. and will never start dispatching unless I do one of
the
> following;
>
> 1) Restart the dispatcher manually (no reboot)
> 2) Start the second machine
>
> then everything start normally.
>
> Is this a Normal behaviour ?
> Is there any saved state between reboot ?
>
> Problem 2) One of the two dispatchers MAC forwards with an invalid MAC
> address
>
> This is strange!
>
> For an unknown reason (yet!) when dispatcher B starts it caches an
> invalid MAC address for
> server X.X.157.14.
>
> Symptom: It DOES dispatch to it but the packets NEVER reach server
> X.X.157.14.
>
> I tried to use a different IP addr. .. same thing.
>
> I decided to snif on the interface while dispatcher starts up using
> snoop in order to find out wich node responds to the arp request
> but strange enough ... server X.X.157.14 does respond with the correct
> MAC.. when snooping.. and it works fine only .. when snooping.
> When not snooping dispatcher always starts up with an invalid MAC
addr..
> I tried snooping/not snooping promiscuous mode or not about 20
times...
> it's constant .. snooping makes the problem go away.
>
> Our telecom team is currently investigating the network equipement .
>
> Any idea on what could cause this besides the network equipement ??
>
> Thanks
>
> I don't have any hair left to pull
>
>
| |
|
| Eric,
It's possible that the go* scripts have incorrect commands in them,
which cause errors on the startup. I'd recommend checking those to make
sure the ifconfig commands are correct (good ips, netmasks, etc).
I've seen the MAC get resolved incorrectly on older versions of the code
running on Windows, but never Sun. The act of snooping might be the
trigger to get the correct MAC resolved and picked up by Dispatcher.
Actually, the HA problem might also be a MAC resolution issue. When you
start up one and get this error state, check 'arp -a' to see what it
shows for the partner Dispatcher machine (both heartbeat targets) and
make sure that's correct.
If the go* scripts are right and the arp cache looks good, then I'd
recommend opening a PMR. No need to rip out all the hair! ;)
Jeff
|
|
|
|
|