Send SunRay-Users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.filibeto.org/mailman/listinfo/sunray-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SunRay-Users digest..."
Today's Topics:
1. Re: Shorting sunray network reconnect (Arthurpeck)
2. Re: Shorting sunray network reconnect (Bob Doolittle)
3. Re: Shorting sunray network reconnect (Craig Bender)
----------------------------------------------------------------------
Message: 1
Date: Sat, 18 Feb 2012 07:32:21 -0700
From: Arthurpeck<[email protected]>
To: [email protected]
Subject: Re: [SunRay-Users] Shorting sunray network reconnect
Message-ID:<[email protected]>
Content-Type: text/plain; charset=us-ascii
If it's any consequence, I have DTUs reset for no apparent reason and
I'm not using VPN connections. I've seen things like one whole side of
a classroom, 8 seats, reset all at the same time. Fortunately, the
user's desktop is reconnected and they can usually resume working
after login.
Some of these resets we understand are probably faulty network wiring,
but that would not explain clusters of resets. So far, all I've been
able to do is crank up the logXXX= settings in the *.parms file. From
that, I have seen what I think is a high number of KA_WARNING entries.
I'm told that if the DTU loses 3 consecutive KA packets, it will reset
so that could be some of it.
Just a little note, don't assume that all DTU network traffic is UDP.
There is some TCP traffic as well. Look in the Installation Guide for
the table that shows ports and protocols.
Art
Sent from my iPhone
------------------------------
Message: 2
Date: Sat, 18 Feb 2012 11:43:40 -0500
From: Bob Doolittle<[email protected]>
To: SunRay-Users mailing list<[email protected]>
Subject: Re: [SunRay-Users] Shorting sunray network reconnect
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 02/18/12 09:32, Arthurpeck wrote:
If it's any consequence, I have DTUs reset for no apparent reason and
I'm not using VPN connections. I've seen things like one whole side
of a classroom, 8 seats, reset all at the same time. Fortunately, the
user's desktop is reconnected and they can usually resume working
after login.
Some of these resets we understand are probably faulty network
wiring, but that would not explain clusters of resets.
Depending on your network topology, faulty network could easily
produce a cluster of resets.
For example, if you had an 8-port switch which had a faulty link
between it and the server.
You've probably looked into that already I imagine.
FWIW, in my experience it's far more likely to have a bad port on a
switch than a bad cable/wire. I've had a couple of experiences with
lightning that resulted in ports going bad.
-Bob
So far, all I've been able to do is crank up the logXXX= settings in
the *.parms file. From that, I have seen what I think is a high
number of KA_WARNING entries. I'm told that if the DTU loses 3
consecutive KA packets, it will reset so that could be some of it.
Just a little note, don't assume that all DTU network traffic is UDP.
There is some TCP traffic as well. Look in the Installation Guide for
the table that shows ports and protocols.
Art
Sent from my iPhone
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
Message: 3
Date: Sat, 18 Feb 2012 10:43:22 -0800
From: Craig Bender<[email protected]>
To: [email protected]
Subject: Re: [SunRay-Users] Shorting sunray network reconnect
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
A few comments:
KA_Warning messages:
These are warnings that the expected Keep Alive packet wasn't received.
The Sun Ray expects a keepalive message from the server every 20
seconds. Miss three of those in a row for the same DTU and it will
reboot. Note that the server also expects the same from the Sun Ray
every 240 seconds.
While the knee jerk reaction to this would be a network problem, in my
experience it's usually due to server side issues caused by poorly
written kiosk scripts. The rationale for not pointing fingers at the
network is that the DTU has successfully sent the KA_WARNING messages
*and* syslog has logged them. That means packets are flowing over the
network and the server isn't hung.
A poorly Sun Ray Kiosk script that does things like invoke authd to
gather information can lead to these messages if authd gets too busy.
Remember that "TurboCAM" settings still apply when it comes to Kiosk
Mode and the changes to auth.props with regards to worker threads for
authd. The default of 8 just isn't enough in many, especially today,
when you can have a 300-500 Sun Rays on one server and they all start
their sessions/insert their cards around the same time.
LogXXX= key/value pairs:
You should see a lot of of messages, many of them useful, if you set
LogNet=7, some of them quite useful. 7 is the highest verbosity for the
LogXXX key/value pairs. I'll make sure we get the levels back in the
doc as they seemed to be missing.
Also, don't forget to set LogHost=<IP Address> in the parms file as
well, otherwise the specification of just LogXXX= is useless.
Of course for a VPN connection, you won't see anything LogNet messages
after authentication (parms file read after auth + the loghost is
probably behind the VPN gateway). While it's not useful for
troubleshooting the VPN authentication process, you'll get a lot of very
useful information especially if your gateway is dropping due to
re-keying errors. Regardless, any messages that can be gathered if you
are experiencing sessions being dropped is better than just guessing.
Open a support call and provide them with the logs.
VPN connections and connection drops:
Let's say you've improperly set the Phase 1 (IKE Lifetime) or Phase Two
(IPSec Lifetime) values in the VPN config on the DTU. That's not going
to cause an error to be thrown on the gateway, the session will just
drop due to a normal expiration. I know this because I spent quite a
while trouble shooting remote Oracle Offices who kept dropping after 7
hours, even though they had 24 hours set of the various timer lifetimes.
Phase 2 needs to be much smaller than Phase 1, and in almost all cases,
Phase 2 should be set to lower than what the gateway has set as a Phase
2 limit. Note that this setting is in seconds. This ensures the DTU
will request a new encryption key before the gateway enforced setting
expires. Setting Phase 2 equal to the gateway settings is fine, but
higher is bad. That's a guaranteed dropped connection when the gateway
IPSec timer experies.
I know that some companies (Sun Microsystems...<cough>..<cough>) set the
timers on the Phase 1 and Phase 2 to be the same on the VPN gateway.
Though the troubleshooting previously mentioned, I've been educated on
what a poor security practice that is. IPSec is what does the actual
encryption and should be re-keyed more often than IKE.
Regardless of the IKE and IPSec timers, the Sun Ray will drop if
vpn-session-timeout is set. This is a VPN gateway side setting and is
expressed in minutes, so 1440 would mean you have a 1 day limit for a
connection.
Regards,
CB
On 2/18/12 8:43 AM, Bob Doolittle wrote:
On 02/18/12 09:32, Arthurpeck wrote:
If it's any consequence, I have DTUs reset for no apparent reason and
I'm not using VPN connections. I've seen things like one whole side of
a classroom, 8 seats, reset all at the same time. Fortunately, the
user's desktop is reconnected and they can usually resume working
after login.
Some of these resets we understand are probably faulty network wiring,
but that would not explain clusters of resets.
Depending on your network topology, faulty network could easily produce
a cluster of resets.
For example, if you had an 8-port switch which had a faulty link between
it and the server.
You've probably looked into that already I imagine.
FWIW, in my experience it's far more likely to have a bad port on a
switch than a bad cable/wire. I've had a couple of experiences with
lightning that resulted in ports going bad.
-Bob
So far, all I've been able to do is crank up the logXXX= settings in
the *.parms file. From that, I have seen what I think is a high number
of KA_WARNING entries. I'm told that if the DTU loses 3 consecutive KA
packets, it will reset so that could be some of it.
Just a little note, don't assume that all DTU network traffic is UDP.
There is some TCP traffic as well. Look in the Installation Guide for
the table that shows ports and protocols.
Art
Sent from my iPhone
_______________________________________________
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
End of SunRay-Users Digest, Vol 97, Issue 10
********************************************
