On Mar 11, 2014, at 3:48 PM, Matevz Tadel <[log in to unmask]> wrote:
> On 03/11/14 13:34, Brian Bockelman wrote:
>> Hi Andy,
>>
>> No, the xrootd on srm.unl.edu was not launched with any special flag (it's a bit on the older side FWIW).
>>
>> I think what's happening is the client is resolving both IPv6 and IPv4 addresses of the server and preferring the IPv6 one over IPv4 (this is not controllable through DNS) despite the fact there's no valid IPv6 route to the outside world.
>
> Yes, that was it. And our hosts/network does not know what to do with it so all connection attempts failed immediately.
>
You can tell this by looking at the 'ifconfig' output:
[1349] bbockelm@uaf-6 ~$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:1F:C6:EB:25:EB
inet addr:169.228.130.53 Bcast:169.228.131.255 Mask:255.255.254.0
inet6 addr: fe80::21f:c6ff:feeb:25eb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:77405859738 errors:0 dropped:238469 overruns:0 frame:0
TX packets:86329005746 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:93093258872047 (84.6 TiB) TX bytes:67247468125818 (61.1 TiB)
Interrupt:90 Memory:c8200000-c8220000
Note that 'inet6 addr' has scope set to link; that means that there's no routing for IPv6 outside the Layer 2 network. *However*, your DNS server will still return IPv6 addresses if queried over IPv4.
Most clients will not use IPv6 server addresses if there is no routing to the outside world through IPv6 (this is often done via the AI_ADDRCONFIG flag). There's an RFC somewhere outlining the best practices here (oddly enough, AI_ADDRCONFIG is considered harmful as determining whether or not IPv6 is working is not easy to determine, but implementing the RFC correctly is often more difficult).
Brian
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
