[I hope this nests with the original message.] We had a similar experience. Here's the network engineer's conclusions:
It looks like the issue with the thin clients resetting is related to a bug (described in the thread below) with the SunRay 3 devices. We were told by some of the users that the (2) older Sun Ray clients in the same area do not reset. Apparently, there is some specific multicast, broadcast, or unknown unicast packet that when delivered to the TC, causes it to reset and lose connection to the network. Blocking these packets at the switch port seems to have stopped the TC from losing their links. From the thread below, it sounds like Oracle may have already acknowledged the issue and assigned a bug #. If this proves to be the culprit, and no solution from the vendor is provided, we may need to move these TC devices to their own VLAN to isolate them from whatever traffic is causing the problem. Other standard devices (PCs, printers, etc.) don't appear to be affected. -------------------- There are 2 types of blocks available, one that blocks unknown broadcasts (including multicast) and the other blocks unknown unicasts. The switch port keeps a MAC table for each port, which contains the learned MAC addresses from the device that's connected to the port (the TC in this case). If the switch forwards a frame to the TC port, with a destination MAC that is not in TC switch port's table, it is considered unknown but would only be blocked if the blocking command is present. By turning on one command vs. the other on a few switch ports, I determined that an unknown unicast is what's causing the resets, not unknown broadcast traffic. ---------------------- At this point, it looks like the resets were caused by a flood of unknown unicast frames (frames with a destination MAC address other than the TC MAC address) hitting the TC NIC card at a rate of approx. 3K frames in less than 1 second. While this type of flooding should be rare, it does occur at times when there are spanning tree topology changes on the vlan. These flooded packets reach all of the devices connected to the vlan, but don't seem to have the same affect (resetting the device) on other PCs, SunRay2, printers, etc. ------------------------------ SRSS 4.2/SRWC 2.2 FW = SunRayP10-GUI4.2_140993-03_2010.06.21.19.00 This might have already been fixed in a subsequent FW release but I'm trying to get my entitlement straightened out [sound familiar?]. Re: [SunRay-Users] VDI 3.2.2/ SRS 5.1.2 DIsconnected DTU sessions lars.tunkrans Thu, 30 Jun 2011 07:39:40 -0700 Hi, I have raised an SR today. SR 3-3946944381 I have seen the AUTHD Disconnect for P10 and P9 DTU's I am running on the SRS4.2 Patch 7 DTU firmware from 2010-12-30. I am waiting now for some responce. //Lars On Thu, 30 Jun 2011 15:15:48 +0200, Jens Langner <j.lang...@hzdr.de> wrote: > Hi Lars, > > if your customer has a support contract I can only urge you to open a > service request and refer mine as that is currently the only thing > that can be done. > > The problem with the SunRay3 (not +) clients seems to be that some > specific network traffic seems to trigger that DTU reset. Here I have > already catched a network snoop for the support request and sent it to > Oracle support. Lets hope they can investigate which network packages > are triggering these resets and that they can come up with some > updated firmwares. The other option is that this is actually a > hardware bug of the network hardware. However, it is definitely not a > bug/problem within the SRS software but a specific problem with the > SunRay3 hardware/firmware somehow. But the case that the 3+ clients > are not affected is a bit strange to me and somehow points to a more > severe problem of the SunRay3 DTU hardware. > > best regards, > jens > > lars.tunkr...@bredband.net schrieb: >> Hi , It seems to be affecting Sunray3 and not sunray2 nore sunray3+ >> Will have to do some more validation tomorrow. >> >> I have established that the users uttsc process does not crash >> but survives >> the DTU disconnect ( reboot ? ) >> >> The process that reports the disconnect is the Authd java process. >> probably saying that the DTU has dissapeared. ( broken pipe ) >> meaning that Authd cant talk to the DTU anymore. >> >> >> How do we establish if this is a hardware or software problem in the >> Sunray3 DTU ? >> does the DTU reboot becaus of a DTU Software crash or a faulty >> capacitor that glitches the power or something. >> >> Can the memmory of the DTU be dumped to somewhere ? >> >> And yes this customer has a full support contract. >> >> >> //Lars >> >> >> >> >> >> On Wed, 29 Jun 2011 16:55:41 +0200, Jens Langner<j.lang...@hzdr.de> >> wrote: >>> Hi Lars, >>> >> >>> Does this only affect your SunRay3 (not plus) clients? And are these >>> clients resetted and the user is presented with the Oracle logo and the >>> spinning wheel and the after some seconds the user is reconnected again? >>> >>> If so, then this might be the exact same problem we are facing here with >>> sudden resets/disconnects of our SunRay3 clients. In fact we still have >>> an open service request for that (SR #3-2756461385). So if you have a >>> support contract please upen a service request as well and reference >>> mine. In fact, Oracle has already stated that this seems to be a bug >>> within the SunRay3 clients (BUG #3-2756461385 - "SUNBT7024683 SUN RAY >>> 3'S ON SAME SUBNET SPONTANEOUSLY AND SIMULTANEOUS REBOOT DU") and it >>> seems SunRay3+ clients are not affected by that. However, we are still >>> waiting for the bug to get fixed because otherwise we are going to >>> return all of our SR3 clients. >>> >>> Best regards, >>> jens _______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
