mountd does not respond via IPv6 over a bridge

M

martin_b

Scenario:
- Machine A on a network with RFC 1918 site-local IPv4 and old-style site-local IPv6 addresses (yes they are deprecated).
- The machine also serves as NFS server.
- For use with bhyve I modified rc.conf to always create a bridge0 and attach the physical network interface to it.

With this modification, a showmount -e machine_A on another machine hangs. Specifically, it hangs when using machine_A's hostname, and it turns out that in this case it tries the IPv6 address. Using the IPv4 address directly instead of the hostname works; using the IPv6 address hangs.

Before inserting the bridge, this worked fine.

A few relevant lines from rc.conf (before the modification, the ifconfig lines were done directly for em0):

Code: 
cloned_interfaces="bridge0"
create_args_bridge0="ether 42:00:01:00:13:01 addm em0 up"
ifconfig_bridge0="inet hostname_A netmask 255.255.255.0"
ifconfig_bridge0_ipv6="inet6 accept_rtadv hostname_A prefixlen 64"

/etc/hosts is properly populated for both IPv4 and IPv6, so the addresses get assigned correctly.

Running ifconfig gives:

Code: 
[0]# ifconfig bridge0                      
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=0
        ether 42:00:01:00:13:01
        inet 192.168.1.19 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fec0:0:0:4d42::13 prefixlen 64
        id f0:de:f1:98:86:a9 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id f0:de:f1:98:86:a9 priority 32768 ifcost 0 port 0
        member: em0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
                ifmaxaddr 0 port 1 priority 128 path cost 2000000 proto rstp
                role designated state discarding
        groups: bridge                       
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
[0]#

Note that ssh -6, ping6 etc. from another machine to A work fine.

Working neither is a direct mount command from another machine: mount fec0:0:0:4d42::13:/z/users/martin /mnt does not work, using the IPv4 address instead does.

Any ideas about how to get this going?

-- Martin

p.s. The motivation to finally get this going is this commit. Previously the addresses stayed with em0 even if I created a bridge0 for use with bhyve. Interestingly, that was (still) working, except that NDP always took an initial prodding to learn the destination MACs.
 
Very strangely, it is working now. Without any change.

What I did:
- Restored the old rc.conf, rebooted. Result: working normally.
- Restored the new rc.conf, rebooted. Result: working!

I am positive that I did not change anything in the new rc.conf.

I'll watch this for a while.

-- Martin
 
Ah, it is only sort of working. What happens is that there seems to be an arbitrary delay until the showmount finishes. Once it responded nearly instantaneously, then with delays of several to many seconds.

By the way, I am trying from multiple different other hosts.

Does anybody have any ideas what is going on here?
 
O.k., the answer time to do a time showmount -e machine_A from three different other machines is either 18.6 or 35.1 seconds, with very minor variations (+/- .3 s) around these two values. Quite incredible.
 
O.k. there is a parallel wlan0 interface on machine_A. But none of the routes went via this interface. Still, if I ifconfig it down, the showmount from the other machines to machine_A works instantaneously.

But the saga continues... did ifconfig wlan0 up again, again not working anymore. Only the link-local IPv6 routing entry exists for wlan0.

Again did ifconfig wlan0 down, now the IPv4 connectivity from machine_A to the other machines is lost!

This could be restored by down/upping bridge0.

I'll look at the routing tables of the other machines now I can reach them again.
 
More investigations... ifconfig wlan0 up removes the IPv4 routing entry to the internal network 192.168.1.0/24 (but none of the IPv6 ones). Then, down/upping bridge0 restores it.

Any ideas why ifconfig wlan0 up removes the IPv4 routing entry to the internal network?
 
Summarizing:
- Before I had em0 and wlan0 connecting to the same LAN segment with two different IP addresses. All routing was via em0.
- Then I created a bridge0 and made em0 a member of it, so the same LAN segment is now reachable via bridge0 and wlan0. This results in quite deterministic delays when querying the mountpoints of this machine from other machines.
- Even though netstat -rW shows that all routes go via bridge0 (previously em0), downing/upping wlan0 or bridge0 results in connectivity issues.
- In addition, on the other machines both arp and ndp show that the correct ether address is used for machine_A - it is always 42:00:01:00:13:01, i.e., the one of bridge0 of machine_A.
- Still, if on machine_A wlan0 is up in addition to bridge0, I have delays of 18.6 or 35.1 (+/- .3 s) seconds when doing time showmount -e machine_A on the other machines.

Any ideas on what is going on here are appreciated, especially considering that using em0 and wlan0 in parallel worked without problems so far.

-- Martin
 
I had setup an NFS server on FreeBSD recently. The client is a Debian server. To mount over IPv6, you enclose the IPv6 address in brackets..here's the command I used on the Debian server to mount it:

mount.nfs4 [200:eedc:5589:00aa:cc:bb:yy:xx]:/backups /home/user/backups

FreeBSD /etc/exports
Code: 
V4: / -network 204:6a74:aa:bb:cc:dd:ee:ff/128
/backups -alldirs -maproot=root -network 204:6a74:aa:bb:cc:dd:ee:ff/128
 
You must log in or register to reply here.
Back
Top