Hi Ben, Thanks for the reply. You're absolutely right about the ordering of the iface statements. I modified my interfaces file such that the bonding parameters followed "iface bond0 inet static" and now it loads the bonding module and adds a default gateway for IPV4. The configuration below works properly. I'm pretty sure I know what happened. I've been using bonding with IPV4-only for quite a while; I used the Debian howto to set it up. I recently added a Hurricane Electric 6in4 tunnel to my pfsense router and therefore added the "iface bond0 inet6 static" section. Restarting the bond using "ifdown bond0 && ifup bond0" worked, perhaps because the bonding module was already loaded. I wasn't able to find much documentation about how to setup a bond with both IPV4 and IPV6. The bonding guide is IPV4 only, and the IPV6 guide doesn't discuss bonding.
However, I still think there's something wrong with my configuration. If I attempt to use "iface bond0 inet6 dhcp", I get an IP from the DHCPv6 server, but no default gateway is created, so attempting to access the internet results in no route to host. I know Router Advertisements and DHCPv6 are working as other Windows and Linux clients are working (tested with both SLAAC and DHCPv6 w/RA). Do you know why I'm not getting a default route when using DHCPv6? auto lo iface lo inet loopback iface eth0 inet manual iface eth1 inet manual auto bond0 iface bond0 inet dhcp slaves eth0 eth1 bond_mode 802.3ad bond_miimon 100 bond_downdelay 200 bond_updelay 200 mtu 9000 iface bond0 inet6 static address 2001:470:8:1141::2 netmask 64 gateway 2001:470:8:1141::1 auto eth2 iface eth2 inet static address 10.0.0.1 netmask 255.255.255.0 mtu 9000 Thanks, Jason On Fri, May 26, 2017 at 7:30 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > Control: tag -1 moreinfo > > I don't see any changes in the kernel bonding driver, or any relevant > changes to kernel networking. > > On Fri, 2017-05-26 at 00:31 -0400, Jason Cohen wrote: > > ** Network interface configuration: > [...] > > auto bond0 > > iface bond0 inet static > > address 192.168.1.200 > > netmask 255.255.255.0 > > network 192.168.1.0 > > gateway 192.168.1.1 > > iface bond0 inet6 static > > address 2001:470:8:1141::2 > > netmask 64 > > gateway 2001:470:8:1141::1 > > slaves eth0 eth1 > > bond_mode 802.3ad > > bond_miimon 100 > > bond_downdelay 200 > > bond_updelay 200 > > mtu 9000 > [...] > > I'm pretty sure this configuration never worked, and that you just > found that out by rebooting after the upgrade. > > The problem is that ifupdown treats each 'iface' statement as > introducing a separate interface configuration, so the above is parsed > as: > > iface bond0 inet static > address 192.168.1.200 > netmask 255.255.255.0 > network 192.168.1.0 > gateway 192.168.1.1 > > iface bond0 inet6 static > address 2001:470:8:1141::2 > netma > sk 64 > gateway 2001:470:8:1141::1 > slaves eth0 eth1 > > bond_mode 802.3ad > bond_miimon 100 > bond_downdelay 200 > > bond_updelay 200 > mtu 9000 > > I think it will first try to apply the first interface configuration. > There are no bonding parameters so the code to create a bonding > interface (and load the bonding module) doesn't run. As there is no > such interface, the IPv4 configuration can't be applied either. > > I don't know whether ifupdown tries to process the second interface > configuration after this failure, but I would guess not. > > If you move all the bonding and mtu parameters into the first interface > configuration, does the bonding interface start working again? > > Ben. > > -- > Ben Hutchings > The generation of random numbers is too important to be left to chance. > - Robert Coveyou >
