64bit xenial, same issue here;
it's sad, not able to use jumbo frames with in lxd guests.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1399064
Title:
bridges cannot have a mtu > 1500 by themselves
LXC displays similar behavious in Xenial. The "solution" was to set the
MTUs for all the slave interfaces, and all the interfaces within the
guests, then finally set the bridge MTU, otherwise it will simply
refuse. Worked fine.
Haven't yet looked into the configs to see if I can do this permanentl
** Tags added: xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1399064
Title:
bridges cannot have a mtu > 1500 by themselves
To manage notifications about this bug go to:
https://bugs.launchpa
If any one runs into this issue in the future, be sure you are using
virtio for your network interfaces for the vm's.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1399064
Title:
bridges cannot have
We ran into this while training for NOC. Deploying on our laptop labs
so not sure of greater implications but it's tied us up for a good bit
so I figured I'd bump this thread.
so:
BUMP
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed t
** Tags added: canonical-bootstack
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1399064
Title:
bridges cannot have a mtu > 1500 by themselves
To manage notifications about this bug go to:
https://
I am wondering if there has been any progress on this, and if a bug report has
been opened to the kernel devs.
This is impacting kvm deployments, and while there are workarounds, they are
all rather ugly (read: scripts that adjust tun MTUs after VMs boot).
--
You received this bug notification
Also affects Linux 3.19 on Ubuntu Trusty (linux-generic-lts-vivid).
It seems that the only way to create a bridge with MTU=9000 is by
creating it on top of a dummy interface, with mtu 9000 already
configured... Very annoying...
--
You received this bug notification because you are a member of Ub
** Tags added: latest-bios-1.45
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1399064
Title:
bridges cannot have a mtu > 1500 by themselves
To manage notifications about this bug go to:
https://bug
On 12/05/2014 01:20 AM, Andy Whitcroft wrote:
> Which is calculated rather simplistically where there are no attached
> devices:
>
> int br_min_mtu(const struct net_bridge *br)
> {
> [...]
> if (list_empty(&br->port_list))
> mtu = ETH_DATA_LEN;
> [...]
>
> It is no
Looking at the current mainline code, when you set the MTU is it clamped
by the bridge wide "lowest" mtu:
static int br_change_mtu(struct net_device *dev, int new_mtu)
{
struct net_bridge *br = netdev_priv(dev);
if (new_mtu < 68 || new_mtu > br_min_mtu(br))
retu
This issue appears to be an upstream bug, since you tested the latest
upstream kernel. Would it be possible for you to open an upstream bug
report[0]? That will allow the upstream Developers to examine the issue,
and may provide a quicker resolution to the bug.
Please follow the instructions on th
On 12/04/2014 01:44 PM, Joseph Salisbury wrote:
> Did this issue occur in a previous version of Ubuntu, or is this a new
> issue?
This is reproducible on 12.04 too.
> Would it be possible for you to test the latest upstream kernel? Refer
> to https://wiki.ubuntu.com/KernelMainlineBuilds . Please
Did this issue occur in a previous version of Ubuntu, or is this a new
issue?
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.18 kernel[0].
If this bug is fixed in the mainline kernel, please add th
14 matches
Mail list logo