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
