Update and final solution/workaround!
<For SRSS to work properly, all interfaces utilized by clients must be
plumbed and configured in the global zone, since that's where SRSS
software runs.>
<Then logical interface instances of those interfaces can be used in the
local zones for TX security, but these are invisible to SRSS.
The SRSS group membership traffic runs over the global zone interfaces,
not the labeled zone instances.>
Both e1000g0 and e1000g1 are in the global zone (tnrhdb) and are physical
interfaces. I'm not using logical interaces for SRSS. Won't work, as you say.
<The group manager information (echo gstatus | /opt/SUNWut/lib/utnetpipe
localhost 7010) is used in the same way by all of utgstatus, utswitch
-l, utselect, and the web interface. You must always restart SRSS after
making changes to auth.props.>
Same, always did "utrestart" after making changes.
<If you share a single subnet between your servers (configured in the
global zone), then using broadcast is going to greatly simplify your
troubleshooting. Be sure to restart SRSS after making such a change, and
you'll have a wait a few seconds for the group to assemble.>
Also same. I've got two physical networks shared between the global zones. One
is for external communications for multi-level printing, auditing, out-of-band
communications, etc. The other is exclusively for SRSS.
SOLUTION/Workaround:
I went ahead and used utgmtarget and set up my two servers, using the server1-srss and server2-srss host names. Did a "utrestart", and voila, utselect, utswitch, utgstatus, and the web SRSS GUI show both FOG servers.
Apparently, my TX setup has a problem with multicast/broadcast packets. Maybe
something in the configuration of the Multilevel ports.
I'm only expecting to have a few FOG members, so adding ones is not a problem.
Bob, thanks much for your support, and the rest of the SunRay-users as well.
Always learning something good here. More troubleshooting techniques are always
good.
Back to lurking!
AJ Levy
From: Bob Doolittle
Sent: Thu 4/23/2009 11:14 AM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] Sunray FOG on Trusted Extensionspartially working
A. J.. Levy wrote:
Strange. I enabled "multicastAddress = 224.101.101.101", did a "utrestart -c" on
both servers, and now "utgstatus" works on both systems. But I still don't get
both servers in the Sun Ray web GUI, utselect or utswitch.
I'm wondering, based on the web GUI, if Sun Ray has somehow set up two
interfaces, my global zone (176.1.0.x) as a LAN, without being commanded to, or
configured properly, and my intended interconnect (192.168.110.x) properly
configured.
For SRSS to work properly, all interfaces utilized by clients must be
plumbed and configured in the global zone, since that's where SRSS
software runs.
Then logical interface instances of those interfaces can be used in the
local zones for TX security, but these are invisible to SRSS.
The SRSS group membership traffic runs over the global zone interfaces,
not the labeled zone instances.
The group manager information (echo gstatus | /opt/SUNWut/lib/utnetpipe
localhost 7010) is used in the same way by all of utgstatus, utswitch
-l, utselect, and the web interface. You must always restart SRSS after
making changes to auth.props.
If you share a single subnet between your servers (configured in the
global zone), then using broadcast is going to greatly simplify your
troubleshooting. Be sure to restart SRSS after making such a change, and
you'll have a wait a few seconds for the group to assemble.
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
___________________
This email has been scanned for all viruses by Webroot Email
Security System.
___________________
___________________
This email has been scanned for all viruses by Webroot Email
Security System.
__________________________________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
