Bemis, Suzanna K wrote:
I think so too. But I don't see a problem with using -A,
what problem do you see? Craig is right that she'll have to
use the 192.* addresses instead of the public IP addresses,
however. Is this what you were referring to? That's the one
advantage to using the Interconnect - it will translate the
public IP to the appropriate private one internally.
I strongly suspect that Suzanna never restarted SRSS after
utadm -L on, otherwise we'd see "U" for all interfaces on all
networks.
I ran 'utadm -L on' followed by 'utrestart' on all computers. Last one
was on ndssr01 and in fact users this morning were asking who's pablo?
So when the utrestart on ndssr01 happened the sunray users lost the
connection to 'ndssr01', and 'pablo' appeared on their sunray's. I had
to disconnect the 192.168.132.0 network cable from pablo and skb-linux
so ndssr01 would be the default. It's good to know that we could run
the linux sunray servers, but the point is I need some users to know
about the linux servers and use them, but I don't want ALL users to.
We're still testing the linux environment in general.
This is going to be a problem, once you get things
working smoothly. Unless you take special
measures it'll be a roll of the dice as to what
server you'll connect to.
I recommend you follow OttoM's suggestion to
revert to an Interconnect config (although I
disagree with several of his statements,
cockroaches notwithstanding, regarding the
severity of using '-A' - it'll work fine for
redirecting *between* FOGs, which is what I
believe you care about and I verified this both by
re-reading the code and trying it myself).
An Interconnect config will work if you want
to be able to redirect within a FOG also, and it
allows you to use the primary hostname/IP
when redirecting, so it's preferable. Get this
working first.
To avoid the die-roll sending you to the Linux
boxes, you have a few options.
- Just disable/shutdown DHCP on the Linux boxes
after getting utadm set up the way you want it.
Since the solaris box will offer DHCP the DTUs
will be told to connect to it initially. This
is your simplest option.
- Use AMGH. This would allow you to configure
your systems to send specific users where you
want them. If you have some folks you want to
be using Linux, and some not, this will make
things seamless for you. You can specify the
behavior per-Sun Ray, per-smartcard, per-user,
or whatever works best for you.
- Configure DHCP individually for each MAC, on
both servers, to specify where you want each Sun
Ray to go. Sounds painful, not your first
option but I mention it for completeness.
Your first step is to just get things working to a
point where utswitch redirects work, without
introducing any new variables. Then you can
experiment with the options above to get more
control over where the DTUs are connecting.
-Bob
Craig asked earilier to try 'utswitch -h 192.168.132.3' on ndssr01 -
same result as 'utswitch -h skb-linux' - it went to a 25D and showed
134.222.187.182.
And, in answer to OttoM about the private network - 192.168.132.0 is
only used for the sunray's. Administration, Internet, etc is done on the
134.222.187.0 network.
So what might the 'utadm -A' option do that the 'utadm -a' didn't? All
we have on the 192.168.132.0 network are sunray's and these three sunray
servers.
If you have questions about how the network is set up and routed from a
physical perspective I can't answer any of those questions myself but if
you tell me what to ask the Networking group I can do that much. All I
can say is that I don't want to get an entire new LAN for the linux
sunray servers because the infrastructure costs would be more than it's
worth.
Thanks again and still -
Suzie
-Bob
Craig -- why do you think it isn't an isolated interconnect?
Suzanna -- is this 192.168.132.0 supposed to be reachable from the
rest of your network, or is it supposed to be a private isolated
subnet?
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
_______________________________________________
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
_______________________________________________
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
