kernel-packages team mailing list archive

[liquidhorse <1098302@xxxxxxxxxxxxxxxxxx>]

Yes, that would probably do just fine.  Raring is using the 3.8 kernel,
yes?  I have been building 3.8 kernels for some of my 12.04 deploys, and
with few exceptions it has worked well, as it has the necessary fix.  So,
if Raring is on 3.8, the enablement stack would work for me.  Thanks!

-- Matthew


On Fri, Jan 3, 2014 at 1:13 PM, Christopher M. Penalver <
christopher.m.penalver@xxxxxxxxx> wrote:

> liquidhorse, would utilizing the Raring enablement stack in Precise via
> https://wiki.ubuntu.com/Kernel/LTSEnablementStack work for you?
>
> ** Changed in: linux (Ubuntu)
>        Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1098302
>
> Title:
>   Bonding mode Balance-ALB stomps VM MACs
>
> Status in “linux” package in Ubuntu:
>   Incomplete
>
> Bug description:
>   This issue was fixed in the 3.8 kernel series; I have backported the
>   appropriate patch (as directed by the netdev kernel list) to the 3.0
>   kernel and it worked successfully on several machines.  I have built
>   but NOT tested this patch against 3.2 and 3.4 kernels.  The patch
>   appears to require minor modification for inclusion in the 3.7 kernel
>   series.  The issue resolved is as follows:
>
>   This issue affects (at the least) virtual machines running under KVM
>   and using bridging to connect to a network, when that bridge
>   communicates over a bond using mode-6 (balance-alb).  To replicate,
>   configure a bond of 1 or more adapters with mode-6 and bridge over
>   that bond.  Configure a virtual machine (in my instance, I used KVM)
>   to place its vnet adapter under the same bridge.  With the VM running,
>   ping the virtual machine from a remote host and check the ARP cache on
>   the remote host.  You will find that the MAC reported for the virtual
>   machine will not be its configured MAC, but the MAC of one of the
>   bond's slaves.  This causes intermittent and significant connectivity
>   losses (both to and from the virtual machine).
>
>   The patch modifies the balance-alb bonding driver to leave non-local
>   MACs unmodified.  After application, a repeat of the above test should
>   result in the virtual machine's correct MAC being reported in the ARP
>   cache of the remote host.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1098302/+subscriptions
>

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1098302

Title:
  Bonding mode Balance-ALB stomps VM MACs

Status in “linux” package in Ubuntu:
  Incomplete

Bug description:
  This issue was fixed in the 3.8 kernel series; I have backported the
  appropriate patch (as directed by the netdev kernel list) to the 3.0
  kernel and it worked successfully on several machines.  I have built
  but NOT tested this patch against 3.2 and 3.4 kernels.  The patch
  appears to require minor modification for inclusion in the 3.7 kernel
  series.  The issue resolved is as follows:

  This issue affects (at the least) virtual machines running under KVM
  and using bridging to connect to a network, when that bridge
  communicates over a bond using mode-6 (balance-alb).  To replicate,
  configure a bond of 1 or more adapters with mode-6 and bridge over
  that bond.  Configure a virtual machine (in my instance, I used KVM)
  to place its vnet adapter under the same bridge.  With the VM running,
  ping the virtual machine from a remote host and check the ARP cache on
  the remote host.  You will find that the MAC reported for the virtual
  machine will not be its configured MAC, but the MAC of one of the
  bond's slaves.  This causes intermittent and significant connectivity
  losses (both to and from the virtual machine).

  The patch modifies the balance-alb bonding driver to leave non-local
  MACs unmodified.  After application, a repeat of the above test should
  result in the virtual machine's correct MAC being reported in the ARP
  cache of the remote host.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1098302/+subscriptions