[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#863389: Fwd: Bug#863389: linux-image-4.9.0-0.bpo.3-amd64: After update to linux-image-4.9.0.0-0.bpo.3, no route to host via IPV4



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 <ben@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



Reply to: