FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 01-21-2012, 03:34 PM
Ben Hutchings
 
Default Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction

On Sat, 2012-01-21 at 15:43 +0100, Erich N. Pekarek wrote:
> Package: linux-2.6
> Version: 2.6.39-3~bpo60+1

This is long outdated; please test 3.2.1-1 from unstable.

> Severity: important
> Tags: d-i ipv6 upstream

What on earth has this to do with d-i or ipv6?!

> The network functionality is only guaranteed on the underlying network
> interface with vlanid 0. dmesg does not report any problems concerning
> vlan. The 8021q module is loaded. It can be loaded and unloaded
> without problems. Network interfaces and bridge interfaces which have
> been set up to use vlan can not be used.
[...]

It would have been nice if you'd actually provided some specific details
of your network configuration, but I'm going to use my psychic powers to
guess that you have something like:

eth0 - physical interface
br0 - bridge including eth0
eth0.N - VLAN interface attached to eth0
br1 - bridge including eth0.N

and you expect VLAN-tagged packets that arrive on eth0 to be forwarded
through br1, not br0?

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
 
Old 01-22-2012, 04:08 PM
"Erich N. Pekarek"
 
Default Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction

Hello!

Am 2012-01-21 17:34, schrieb Ben Hutchings:

On Sat, 2012-01-21 at 15:43 +0100, Erich N. Pekarek wrote:

Package: linux-2.6
Version: 2.6.39-3~bpo60+1

This is long outdated; please test 3.2.1-1 from unstable.
I did a "aptitude -t squeeze-backports" then updated and installed the
latest version available there. (State: yesterday). Since the machine
had no external network access after that, the information may differ.
It was the lastest available package from the squeeze-backports repository.


If you regard the sid kernel available to be stable enough please add it
to the squeeze-backports repository - i would appreciate some up to date
drivers on a stable kernel.



Severity: important
Tags: d-i ipv6 upstream

What on earth has this to do with d-i or ipv6?!
From a user perspective, ipv6 or debian installer functionality may be
affected by this bug in the underlying kernel. I prefer bug reports to
be tagged in an extensive way. My apologies, if that was inappropriate.



The network functionality is only guaranteed on the underlying network
interface with vlanid 0. dmesg does not report any problems concerning
vlan. The 8021q module is loaded. It can be loaded and unloaded
without problems. Network interfaces and bridge interfaces which have
been set up to use vlan can not be used.

[...]

It would have been nice if you'd actually provided some specific details
of your network configuration, but I'm going to use my psychic powers to
guess that you have something like:



eth0 - physical interface
br0 - bridge including eth0
eth0.N - VLAN interface attached to eth0
br1 - bridge including eth0.NYour psychic powers are quite amazing ;-)


physical: eth0
bridges: bri0, bri1, bri2, ..., bri6
#/etc/network/interfaces:
...
iface bri0 inet static
....
bridge_ports eth0.1234
bridge_stp on
bridge_maxwait 10
...

vlans: eth0.1234, eth0.1345 # (examples).
#/etc/network/interfaces:
...
iface eth0.1234 inet manual
vlan_raw_device eth0
...


and you expect VLAN-tagged packets that arrive on eth0 to be forwarded
through br1, not br0?

I expect VLAN-tagged packages to arrive untagged at their respective
bridge ports, which is a VLAN-interface, and to leave those VLAN-tagged
as they do while running linux-image-2.6.32-5-amd64. We are talking
about a tested and well proven setup.
Forward in terms of bridging applies, forward in terms of NAT is not
involved at this stage.


Currently only the bridge including the maintenance interface with the
plain eth0 interface receives all tagged and untagged packages, and
VLAN-inferfaces just receive tagged packets, while no untagged packet
get through, which would lead to the assumption that the vlan code is
inactive for some reason. Filtering (ebtables/iptables ...) was
previously disabled. The tagged interfaces receive packets originating
from the physical eth0's mac address, which iptraf regards to be "non-IP
packages".


I can not provide additional information at this time.


Ben.


Erich



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F1C4281.6010306@pekarek.at">http://lists.debian.org/4F1C4281.6010306@pekarek.at
 
Old 01-22-2012, 08:05 PM
Ben Hutchings
 
Default Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction

On Sun, 2012-01-22 at 18:08 +0100, Erich N. Pekarek wrote:
> Hello!
>
> Am 2012-01-21 17:34, schrieb Ben Hutchings:
> > On Sat, 2012-01-21 at 15:43 +0100, Erich N. Pekarek wrote:
> >> Package: linux-2.6
> >> Version: 2.6.39-3~bpo60+1
> > This is long outdated; please test 3.2.1-1 from unstable.
> I did a "aptitude -t squeeze-backports" then updated and installed the
> latest version available there. (State: yesterday). Since the machine
> had no external network access after that, the information may differ.
> It was the lastest available package from the squeeze-backports repository.
>
> If you regard the sid kernel available to be stable enough please add it
> to the squeeze-backports repository - i would appreciate some up to date
> drivers on a stable kernel.

The backport was being maintained by someone else. I am just about to
fix that, though.

Linux 2.6.39 has known bugs including security vulnerabilities which are
fixed in later versions.

> >> Severity: important
> >> Tags: d-i ipv6 upstream
> > What on earth has this to do with d-i or ipv6?!
> From a user perspective, ipv6 or debian installer functionality may be
> affected by this bug in the underlying kernel. I prefer bug reports to
> be tagged in an extensive way. My apologies, if that was inappropriate.

Those tags mean that the bug specifically relates to the installer or
IPv6, not that it might affect it.

> >> The network functionality is only guaranteed on the underlying network
> >> interface with vlanid 0. dmesg does not report any problems concerning
> >> vlan. The 8021q module is loaded. It can be loaded and unloaded
> >> without problems. Network interfaces and bridge interfaces which have
> >> been set up to use vlan can not be used.
> > [...]
> >
> > It would have been nice if you'd actually provided some specific details
> > of your network configuration, but I'm going to use my psychic powers to
> > guess that you have something like:
>
> > eth0 - physical interface
> > br0 - bridge including eth0
> > eth0.N - VLAN interface attached to eth0
> > br1 - bridge including eth0.NYour psychic powers are quite amazing ;-)
>
> physical: eth0
> bridges: bri0, bri1, bri2, ..., bri6
> #/etc/network/interfaces:
> ...
> iface bri0 inet static
> ....
> bridge_ports eth0.1234
> bridge_stp on
> bridge_maxwait 10
> ...
>
> vlans: eth0.1234, eth0.1345 # (examples).
> #/etc/network/interfaces:
> ...
> iface eth0.1234 inet manual
> vlan_raw_device eth0
> ...
>
> > and you expect VLAN-tagged packets that arrive on eth0 to be forwarded
> > through br1, not br0?
> >
> I expect VLAN-tagged packages to arrive untagged at their respective
> bridge ports, which is a VLAN-interface, and to leave those VLAN-tagged
> as they do while running linux-image-2.6.32-5-amd64. We are talking
> about a tested and well proven setup.
> Forward in terms of bridging applies, forward in terms of NAT is not
> involved at this stage.
>
> Currently only the bridge including the maintenance interface with the
> plain eth0 interface receives all tagged and untagged packages, and
> VLAN-inferfaces just receive tagged packets
[...]

Right, that's what I thought.

You're really supposed to only attach either a bridge device or VLAN
devices to an underlying physical device. However, I'm aware that the
Linux bridge driver is not so useful as a VLAN bridge and that there was
never any restriction in the kernel that prevented you from doing this.

Due to the way VLAN tag offload was implemented, the above configuration
worked for a long time if the underlying physical device implemented
VLAN tag offload - but not if it didn't. In Linux 2.6.37 the handling
of VLAN tags was significantly changed to remove the special case for
receiving packets from devices with VLAN tag offload, causing this
configuration to break. Since many people used similar configurations,
this was fixed in Linux 3.2 (I think).

Ben.

--
Ben Hutchings
Knowledge is power. France is bacon.
 
Old 07-29-2012, 08:39 PM
Phil Regnauld
 
Default Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction

Ben Hutchings (ben) writes:
> >
> > Currently only the bridge including the maintenance interface with the
> > plain eth0 interface receives all tagged and untagged packages, and
> > VLAN-inferfaces just receive tagged packets
> [...]
>
> Right, that's what I thought.
>
> You're really supposed to only attach either a bridge device or VLAN
> devices to an underlying physical device. However, I'm aware that the
> Linux bridge driver is not so useful as a VLAN bridge and that there was
> never any restriction in the kernel that prevented you from doing this.
>
> Due to the way VLAN tag offload was implemented, the above configuration
> worked for a long time if the underlying physical device implemented
> VLAN tag offload - but not if it didn't. In Linux 2.6.37 the handling
> of VLAN tags was significantly changed to remove the special case for
> receiving packets from devices with VLAN tag offload, causing this
> configuration to break. Since many people used similar configurations,
> this was fixed in Linux 3.2 (I think).

That is, unfortunately, not the case.

Ganeti, and other virtualization solutions built on top of Xen and KVM,
makes use of bridges to attach VMs to the underlying interface. The
underlying interface could be anything: vlan, raw ethernet, bond'ed link,
etc...

This works fine on 2.6.32, as was pointed out, but fails afterwards.

I've tried with 3.2 and 3.5, and the bug persists. My setup is as described
earlier by Erich:

br0: eth0 (for management)
br1: eth0.3
br2: eth0.4
brX: eth0.X

... with the IP for management on br0.

This, by the way, works with bonded interfaces as well on 2.6.32:

br0: bond0: eth0 + eth1
br1: bond0.3
br2: bond0.4
...

On 3.2, this stopped working. At first I thought it was the bond
interface, so I attempted to run directly on eth0.* - but that
didn't help. Then I suspected an issue with mixing tagged and
untagged + bridging. And since mixing tagged and untagged on the same
link is usually not a good idea, I reconfigured everything to run in
trunked/.1q, not using eth0 for any IP traffic directly:

br0: eth0.100 (now using a tagged vlan for the management IP)
br1: eth0.3
etc...

... but this doesn't work in 3.2+

It might not be Debian specific, but nevertheless it's a showstopper...

If this configuration is not supported, what is the suggested alternative ?

KVM and other hypervisors need a bridge to attach VMs to: how is one
supposed to host different VMs on different subnets on a single machine ?
(Something easily done on 2.6.32, or even on FreeBSD or VMWware) ? I could
try OpenvSwitch...

Thanks,
Phil
 
Old 07-29-2012, 09:12 PM
Ben Hutchings
 
Default Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction

Please open a new bug report; you seem to be describing a different
problem.

Ben.

--
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily Tomlin
 

Thread Tools




All times are GMT. The time now is 07:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org