It's the "lastpkt -1" interfaces that are the problematic ones, right?
sunfire5 e1000g1
sunfire4 e1000g1
sunfire6 e1000g1
-1 means you're not seeing any packets on those interfaces.
You *do* have multicast enabled, if you haven't specified otherwise.
The way to interpret the auth.props file is that the commented values
are the defaults.
You need to explicitly add a line that says enableMulticast=false and
then restart SRSS to disable multicast (i.e. enable broadcast). That
may help.
-Bob
CJ Keist wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bob,
Thank you so much for your reply. Here is the output on the sunfire2
server:
# echo gstatus | /opt/SUNWut/lib/utnetpipe localhost 7010
numhosts 6
host sunfire2 lastseen 12 timeoff 0 addr 8152e00b numifs 2 period 20
starttime 1
interface ce0 ip 8152e00b mask fffff800 bcast 8152e7ff lastpkt 12 LAN
interface ce1 ip c0a86401 mask fffffc00 bcast c0a867ff lastpkt 12
sessions 76 idles 41 load 6.1
host sunfire5 lastseen 17 timeoff -1 addr 8152e003 numifs 2 period 20
starttime
interface e1000g0 ip 8152e003 mask fffff800 bcast 8152e7ff lastpkt 17 LAN
interface e1000g1 ip c0a8640c mask fffffc00 bcast c0a867ff lastpkt -1
sessions 69 idles 13 load 8.3
host sunfire3 lastseen 7 timeoff -1 addr 8152e007 numifs 2 period 20
starttime 1
interface ipge0 ip 8152e007 mask fffff800 bcast 8152e7ff lastpkt 7 LAN
interface ipge1 ip c0a86409 mask fffffc00 bcast c0a867ff lastpkt 7
sessions 297 idles 154 load 26.2
host sunfire4 lastseen 3 timeoff -1 addr 8152e00c numifs 2 period 20
starttime 1
interface e1000g0 ip 8152e00c mask fffff800 bcast 8152e7ff lastpkt 3 LAN
interface e1000g1 ip c0a8640b mask fffffc00 bcast c0a867ff lastpkt -1
sessions 53 idles 40 load 4.4
host sunfire lastseen 14 timeoff 0 addr 8152e00a numifs 2 period 20
starttime 12
interface ce0 ip 8152e00a mask fffff800 bcast 8152e7ff lastpkt 14 LAN
interface ce1 ip c0a8640a mask fffffc00 bcast c0a867ff lastpkt 14
sessions 92 idles 32 load 14.1
host sunfire6 lastseen 3 timeoff -2 addr 8152e01f numifs 2 period 20
starttime 1
interface e1000g0 ip 8152e01f mask fffff800 bcast 8152e7ff lastpkt 3 LAN
interface e1000g1 ip c0a8640d mask fffffc00 bcast c0a867ff lastpkt -1
sessions 44 idles 31 load 0.9
endhosts
Also the enableMulticast is not enable on all my servers, config looks
like following:
# Enable Multicast
# Flag to enable/disable use of multicast in group manager.
# If disabled, group manager will use broadcast.
#enableMulticast = true
One thing is all the sunfire4, sunfire5 and sunfire6 servers are in a
off site building from the first three servers. But the subnet
129.82.224.0 is trunked over to that building as well as our sunray vlan
192.168.100.0. I'll check about broadcast packets being dropped. But I
never have seen case where it happens just one way as it would appear is
happening for me.
- ------------------------------
Message: 3
Date: Wed, 29 Oct 2008 14:16:27 -0400
From: Bob Doolittle <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] Load balancing not working
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
When you don't see a "U" indication in the flags for an interface, it
means that the local server hasn't received a Group Manager
multicast/broadcast packet from that host, on that interface, within the
last 60 seconds. Such packets are sent every 20 seconds. If an
interface isn't marked as "U", the local server doesn't consider it a
viable Sun Ray server currently, and won't forward DTUs to it.
My guess is you're dropping packets somewhere.
Here's something you can do, on your master, to get more information:
echo gstatus | /opt/SUNWut/lib/utnetpipe localhost 7010
This produces the raw info that utgstatus uses.
Take a look at "lastseen". That's how many seconds have elapsed since a
broadcast/multicast was seen from the listed host. "period" is the
interval between sending the packets. Group Manager will tolerate
missing packets for up to 3 periods, then it blacklists the host until
it hears from it again.
Have you set the /etc/opt/SUNWut/auth.props enableMulticast property to
'false'? Do all your hosts share a common subnet? If so, you can
disable multicast in that way, and use broadcast instead. We've seen
some switches that won't handle IP multicast reliably. You could try it
just on sunfire5 first, as an experiment. Note you have to restart SRSS
on the local server after the change to pick it up.
- -Bob
CJ Keist wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I'm currently running Sunray Server 4.0 on Solaris 10. I have a FOG
of six servers. I'm running into a problem where three of my six
servers seem to think the network interface to three other servers is
down. So my thin clients are only connecting to the first three servers
and they are getting over loaded. Here is utgstatus from my master FOG
server:
# ./utgstatus
host flags interface flags interface flags
129.82.224.0/21 192.168.100.0/22
- ----------- ------------------- -------------------
sunfire2 TN 129.82.224.11 UA- 192.168.100.1 UAM
sunfire5 TN 129.82.224.3 UA- 192.168.100.12 -AM
sunfire3 TN 129.82.224.7 UA- 192.168.100.9 UAM
sunfire4 TN 129.82.224.12 UA- 192.168.100.11 -AM
sunfire TN 129.82.224.10 UA- 192.168.100.10 UAM
sunfire6 TN 129.82.224.31 UA- 192.168.100.13 -AM
As you can see it thinks sunfire4, sunfire5 and sunfire6 192.168.100.*
interfaces are down. This is same if I run it from sunfire and
sunfire3. But if I run utgstatus from Sunfire4, 5 or six I get:
# ./utgstatus
host flags interface flags interface flags
129.82.224.0/21 192.168.100.0/22
- ----------- ------------------- -------------------
sunfire4 TN 129.82.224.12 UA- 192.168.100.11 UAM
sunfire5 TN 129.82.224.3 UA- 192.168.100.12 UAM
sunfire3 TN 129.82.224.7 UA- 192.168.100.9 UAM
sunfire TN 129.82.224.10 UA- 192.168.100.10 UAM
sunfire2 TN 129.82.224.11 UA- 192.168.100.1 UAM
sunfire6 TN 129.82.224.31 UA- 192.168.100.13 UAM
Saying everything is happy. I can ping the 192.168.100.12,11 and 13
from the first three sunfire servers. And vise-versa I can ping all the
first three sunfire servers from the last three servers. utreplica shows
everything is fine on all servers.
Only sunfire, sunfire2, 3 and 4 are configured to deal out DHCP
addresses on the 192.168.100 subnet.
Any ideas how to get my first three servers to acknowledge that the last
three servers interconnects or up and running?
- --
C. J. Keist Email: [EMAIL PROTECTED]
UNIX/Network Manager Phone: 970-491-0630
Engineering Network Services Fax: 970-491-5569
College of Engineering, CSU
Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJB4OIA29OFr7C6jcRAgUqAJ4rwK8mPY2oQdDMvltlTuUGDkjNbgCfdHyG
GtGtI55jcIbPoCVBRK3S4Ys=
=vLxB
-----END PGP SIGNATURE-----
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
- --
C. J. Keist Email: [EMAIL PROTECTED]
UNIX/Network Manager Phone: 970-491-0630
Engineering Network Services Fax: 970-491-5569
College of Engineering, CSU
Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJCxoGA29OFr7C6jcRAljPAJ9+IAOqRwKPsdCQSEF+Bayr2iruhgCg4YWH
lHrOiyOgb8ULysmg6pxXB2E=
=lAWh
-----END PGP SIGNATURE-----
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
