Hi Erik, Doing an IPv4 fallback is not trivial. That's a lot of work to do for something that should not happen in a properly setup site. That is, this is a rare event. The -I does disable IPv6 altogether and connections will need to use an IPv4 to connect. A redirector enabled for IPv6 also will accept IPv4 connections so there is no need to restart it. Andy On Thu, 16 Apr 2015, Erik Gough wrote: > Hi Andy, > > Thanks for the info. So in the case of a dual stack IPv4/IPv6 > redirector connecting to a IPv4 redirector (like the one at FNAL) I > assuming that the name resolution comes back with a IPv4 address and a > IPv4 socket is used. Is there not a way for cmsd to determine that a > IPv6 connection fails and to try the connection over IPv4? > > Does the -I v4 disable IPv6 altogether? If all my xrootd servers are > connected to the redirector over IPv6, will I also need to restart them > with the same option? > > Thanks > > On Wed, 2015-04-15 at 17:23 -0700, Andrew Hanushevsky wrote: >> Hi Erik, >> >> Yes, if you have configured a real IPv6 address then that interface is >> used by default (this is essentially an OS decision since it appears >> that we can create an IPv6 socket as no other information is available. >> In your case, the IPv6 address hasn't been fully configured to actually be >> usable but we don't know that from within the box. This seems to be >> another deployment mode that isn't an obvious approach. We have seen >> all sorts of ways sites are deploying an essentially broken IPv6 setup. >> >> Anyway, the way to revert to IPv4 mode is to add the following to the >> command line when starting the cmsd and xrootd (check your sysinit >> script): >> >> -I v4 >> >> this will force usage of only the IPv4 stack. I guess movement to IPv6 >> will be an interesting affair :-) >> >> Andy >> >> On Wed, 15 Apr 2015, Erik Gough wrote: >> >>> Hello, >>> >>> We have a dual stack IPv4/IPv6 xrootd redirector at Purdue. Currently, >>> IPv6 connectivity to the outside world is not working. cmsd on our >>> redirector keeps trying to connect to xrootd.unl.edu over IPv6 and times >>> out: >>> >>> 50415 14:33:45 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:34:48 42282 XrdOpen: Unable to connect socket to >>> xrootd.unl.edu; connection timed out >>> 150415 14:34:54 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:36:03 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:37:12 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:38:21 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:39:30 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:40:39 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:41:48 42282 Pander trying to connect to lvl 0 >>> xrootd.unl.edu:1213 >>> 150415 14:42:51 42282 XrdOpen: Unable to connect socket to >>> xrootd.unl.edu; connection timed out >>> >>> cmsd 42219 xrootd 54u IPv6 24938337 0t0 TCP >>> xrootd.rcac.purdue.edu:59977->xrootd.unl.edu:mpc-lifenet (SYN_SENT) >>> >>> This is all I get for the connection to UNL. >>> >>> Is it possible to make it fall back to IPv4 if the IPv6 connection isn't >>> available? Is this meant to happen or a possible bug? >>> >>> Thanks, >>> -Erik >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >>> > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1