That sounds like an excellent train of thought, not stupid at all [although sometimes I am, but that's a different matter].
I considered the IPv6 angle [I know nothing about IPv6] but thought it was suspect because from that SRS, uttsc works with other WTSs; it's only this one particular WTS that's giving the SRS uttsc problems. The other reason was that I'm pretty sure IPv6 has been enabled on this interface for some time now since I built it maybe a year ago [not sure why I enabled IPv6]. But you've given me something to think about. Since there doesn't appear to be any way that I can change how uttsc does name resolution, maybe I can disable IPv6 instead. I can just unplumb/delete the IPv6 on that interface without affecting the existing IPv4 config, right? Thanks! Scott -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bjoern Rost Sent: Thursday, December 20, 2012 1:57 PM To: SunRay-Users mailing list Subject: EXT :Re: [SunRay-Users] riddle me this: interesting uttsc failure problem Hi Scott, This may be really stupid and you may have ruled this out already. But you said that one of your servers has ipv6 enabled and the other does not. So if the DNS name resolves to both an ipv4 and an ipv6 address and your server has ipv6 enabled, it will try only v6. And if for some reason ipv6 does not work between your hosts, it would explain why you cannot reach the server with the name(s) but only the ipv4 address. it would also explain what you see with snoop (because you are filtering on the v4 address). And it also explains the ping success (try ping6). try "host WTS" and it should return the v6 address if one is defined bjoern PS: I have sent this message from a different account earlier today but it did not make the list. If it is just delayed and not dropped, I apologize for posting twice On 20.12.2012, at 18:16, Nishimura, Scott L (ESS) wrote: > Possibly important correction about snoop: forget what I wrote below. > > If I snoop the destination WTS IP and do "uttsc WTS1" or "uttsc WTS1 FQDN", I > get zilcho. Even in verbose mode. > > If I do "uttsc IP", I get back what you'd expect: a conversation between the > SRS and the WTS. > > It doesn't appear to be a firewall or the WTS blocking a connection from my > SRS because I can get to the WTS via the IP. > > It doesn't appear to be my SRS because I can get to other WTSs. > > It doesn't appear to be a name resolution problem because even using the FQDN > doesn't work. Also, non-fully qualified names of other WTSs work. > > It doesn't appear to be patching as another T2000 was patched with the same > patchset and the problem doesn't occur there. > > The fact that snoop doesn't pick up *any* traffic between the SRS and WTS is > telling...but I don't know what it's telling me. > > -----Original Message----- > From: Nishimura, Scott L (ESS) > Sent: Thursday, December 20, 2012 7:51 AM > To: [email protected] > Subject: riddle me this: interesting uttsc failure problem > > I have an interesting uttsc problem [I used a slightly different word than > "interesting" yesterday]: > > 2 SRSs in a FOG > > serverA [T1000] and serverB [T2000] have been patched with the latest cluster. > > When I run /opt/SUNWuttsc/bin/uttsc to connect to a particular WTS [call it > WTS1], I get inconsistent results > > SRS WTS result > B WTS1 Failed to connect > B WTS1 [FQDN] Failed > B WTS1 IP success > A WTS1 success > A WTS1 [FQDN] success > A WTS1 IP success > > So my fails occur when using SRS B and using a name [FQDN or not]. > > I tried connecting, from B, to other machines in the domain: no problem. > > The WTS is in another state. So I tried connecting to a WTS in another state > [not the same state as the problematic one as I don't have another one > there]: no problem. > > I ran a snoop trace: if I try to connect to the name, the trace contains > only the IP. > > If I try to connect to the IP, the trace only contains the name. > > But in neither case do I see anything that stands out as a cause. > > I used the soft client with the extended menus to get an xterm and ran my > tests from there since that most closely mimics what the TC is doing [similar > environment variables]. > > Any ideas? This is a weird one. So close after patching I want to say > that's the culprit but that doesn't explain why 03 doesn't have the problem > nor why connections to other WTSs are fine. > > I did notice that A is a T1000 and B is a T2000. Also, 08 has IPv6 enabled > on the same interface as IPv4; 03 has no IPv6. But it's been this way for a > long time, not just recently. > > At first glance it seems to be a name lookup problem but if so 1) the FQDN > should work and 2) that doesn't explain why no other WTS in the same domain > has that problem. > > Ping and nslookup work on the unqualified name. > > Traceroute fails to complete but it fails on both A & B. > > It's almost as if that one particular server's name is on a "deny" list of > some sort. > > I compared the size and date of uttsc-bin between A & B: same. > I compared the ldd output of uttsc-bin between A & B: same. > > TIA > > > Scott > _______________________________________________ > 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
