Hello, I will provide logs (syslog, passing "debug" to automount) and additional information first with this email and comment on my attempts to build a new autofs later. The file ipv4.txt.gz contains the log for a situation where server and client have GUA and ULA and autofs falls back to IPv4. The file 2001.txt.gz contains the log for a mount via 2001 GUA in a situation where server and client have only GUA entries in DNS. The mount in question is /local/core330. At the bottom is some more information probably necessary to understand the attached logs. If you need some other debug output please let me know how to get it. As far as I can see the main difference is that in 2001.txt.gz we have Apr 8 13:31:49 core324 automount[18359]: mount_mount: mount(nfs): calling mount -t nfs4 -s -o rw,intr,nosuid,soft,nodev core330:/locals /local/core330 and in ipv4.txt.gz Apr 8 13:27:05 core324 automount[18359]: mount_mount: mount(nfs): calling mount -t nfs4 -s -o rw,intr,nosuid,soft,nodev 192.168.220.118:/locals /local/core330 Also, I did some more tests using just mount. Just to demonstrate what the behaviour of mount is. Please observe the result in the last situation (number 5), there is some round robin (?) behaviour involved I did not expect. I remember that for multi-homed IPv4 the DNS would resolve randomly one or the other address. Might be the same for IPv6 ? To stress the point: I am always only changing DNS AAAA records, not the machines actual network configuration. 1. Server with 2001 and fd5f, client with 2001: mount -v -t nfs4 core330:/locals /mnt/disk1/ mount.nfs4: trying text-based options 'addr=fd5f:852:a27c:1261:2000::118,clientaddr=fd5f:852:a27c:1261:2000::104' 2. Server with 2001, client with 2001: mount.nfs4: trying text-based options 'addr=2001:638:708:1261:2000::118,clientaddr=2001:638:708:1261:2000::104' 3. Server with 2001, client with 2001 and fd5f: mount.nfs4: trying text-based options 'addr=2001:638:708:1261:2000::118,clientaddr=2001:638:708:1261:2000::104' 4. Server with fd5f, client with fd5f: mount.nfs4: trying text-based options 'addr=fd5f:852:a27c:1261:2000::118,clientaddr=fd5f:852:a27c:1261:2000::104' 5. Server with 2001 and fd5f, client with 2001 and fd5f: Mounting repeatedly I see both ! mount.nfs4: trying text-based options 'addr=fd5f:852:a27c:1261:2000::118,clientaddr=fd5f:852:a27c:1261:2000::104' mount.nfs4: trying text-based options 'addr=2001:638:708:1261:2000::118,clientaddr=2001:638:708:1261:2000::104' Best Regards Christof The logs contain output for the addtitonal mountpoints /sge, /home and eventually /usr/local, these are not relevant but in a production environment I cannot remove them. The server in question is core330.bccms.uni-bremen.de, the client is core324.bccms.uni-bremen.de. A dig of the server from the client gives either core330.bccms.uni-bremen.de. 604800 IN AAAA 2001:638:708:1261:2000::118 core330.bccms.uni-bremen.de. 604800 IN AAAA fd5f:852:a27c:1261:2000::118 core330.bccms.uni-bremen.de. 604800 IN A 192.168.220.118 or without the fd5f ULA. The client is either core324.bccms.uni-bremen.de. 604800 IN AAAA fd5f:852:a27c:1261:2000::104 core324.bccms.uni-bremen.de. 604800 IN AAAA 2001:638:708:1261:2000::104 core324.bccms.uni-bremen.de. 604800 IN A 192.168.220.104 or without the fd5f ULA. I should probably point out that we have a custom addresslabel in place on server and client to prevent usage of privacy adresses: root@core324:~# ip -6 addrlabel prefix ::1/128 label 0 prefix 2001:638:708:1261:2000::/96 label 99 prefix 2001:638:708:1261:1000::/96 label 99 prefix ::/96 label 3 prefix ::ffff:0.0.0.0/96 label 4 prefix 2001::/32 label 6 prefix 2001:10::/28 label 7 prefix 3ffe::/16 label 12 prefix 2002::/16 label 2 prefix fec0::/10 label 11 prefix fc00::/7 label 5 prefix ::/0 label 1 On Fri, Apr 08, 2016 at 12:46:00PM +0800, Ian Kent wrote: > On Thu, 2016-04-07 at 16:19 +0200, Christof Koehler wrote: > > Hello everybody, > > > > I am on ubuntu 14.04 with autofs 5.0.7 and I observe an (for me) > > unexpected behaviour as detailed below. Apparently using autofs NFS4 > > mounts fall back to using IPv4 addresses although valid IPv6 addresses > > are available under certain circumstances, while a plain mount works > > as > > expected. > > Can you provide a full debug log. > > It might be autofs interfering with the mount but mount.nfs(8) is a more > likely candidate. > > > > > Setup: > > ------ > > Both, NFS server and client, are configured with an IPv4 address and > > an > > IPv6 GUA and IPv6 ULA. For brevity I will shorten the IPv4 address to > > 192, the GUA to 2001 and the ULA to fd5f below. I will only change > > the > > DNS AAAA record in the following, the network configuration on > > server/client or the A records never change. Server and client have > > always working IPv4 and IPv6 GUA and ULA. > > > > Test with mount: > > ---------------- > > Using a plain "mount -t nfs4 server:/locals /mnt/disk1/" on the > > client > > gives depending on the DNS entries for the server the expected > > source/target selection: > > > > Server DNS entry| client address used to mount > > 2001 | 2001 > > fd5f | fd5f > > 2001+fd5f | fd5f > > > > So in all cases RFC 6724/3484 is observed selecting the addresses. > > Please note that the server has two AAAA records (multi-homed) in the > > last test. > > > > Test with autofs: > > ----------------- > > A map lookup will yield "-fstype=nfs4,rw,intr,nosuid,soft,nodev > > server:/locals" > > for the mount. Now I change again the servers AAAA records with the > > following result: > > > > Server DNS entry| client address used to mount > > 2001 | 2001 > > fd5f | fd5f > > 2001+fd5f | 192 > > > > For a multi-homed NFS4 server autofs apparently falls back to IPv4 > > although valid IPv6 options exist. As shown above just mounting > > without > > autofs would stick to RFC 6724/3484 instead. I believe that autofs > > should > > also select fd5f ULAs in the multi-homed case. > > > > Is this a known behaviour ? Do any workarounds exist ? I could not > > find > > anything. > > > > I tried to compile autofs 5.1.1 with --with-libtirpc because > > of https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1101779 but > > could not get the binary to work. I filed a bug report for the > > behaviour > > described above > > https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1564380 > > but suspect that this is better suited for this list. > > > > Best Regards > > > > Christof > > > -- > To unsubscribe from this list: send the line "unsubscribe autofs" in -- Dr. rer. nat. Christof Köhler email: c.koehler@xxxxxxxxxxxxxxxxxxx Universitaet Bremen/ BCCMS phone: +49-(0)421-218-62334 Am Fallturm 1/ TAB/ Raum 3.12 fax: +49-(0)421-218-62770 28359 Bremen PGP: http://www.bccms.uni-bremen.de/cms/people/c_koehler/
Attachment:
ipv4.txt.gz
Description: Binary data
Attachment:
2001.txt.gz
Description: Binary data
