Re: [Qemu-discuss] qemu guests using 802.1q vlans bridged on host

[Tony Su]

Is this a valid test?
What you describe might work because only one vlan is being passed
through the bridge device so although it might suggest the vlan tag
attribute is recognized on each end, it could be default behavior
because it's the only vlan and doesn't really test whether vlan tags
are truly read and utilized.
What if you passed two different active vlans through that bridge device?

Tony

On Wed, Sep 11, 2013 at 9:50 AM, Vlad Yasevich <address@hidden> wrote:
>> Rally? I mean isn't using tagged 802.1q vlans something pretty normal? I
>> cannot believe that linux is incapable of doing what every 10 bucks
>> desktop
>> switch and its bridge can...
>
>
>
> Yes, it is normal.  I just tried the same on 3.10.10 kernel and it works
> fine.  My config was:
>
> #brctl show br0
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.5254001f7aef       no              eth0
>                                                         vnet0
>
>
> vnet0 is just a tap interface on top of which VM is running.
>
> Inside VM, vlan100 is configured with an address.  Another host
> configured vlan100 as well and I can send traffic between the two
> just fine.
>
> -vlad
>
>
>>
>> --
>> Regards
>> Stephan
>>
>>
>> On Thu, 22 Aug 2013 10:58:08 -0700
>> Tony Su <address@hidden> wrote:
>>
>>> I haven't investigated what you describe so can't offer much help...
>>>
>>> But my reaction is that if it's not possible to configure some kind of
>>> "master vlan tag" I'd consider "packaging" all the VLANs through a VPN
>>> just long enough to pass through any major obstacles (technical or
>>> onerous work). Of course such an approach would likely come with
>>> significant overhead but it's a matter of trade-offs.
>>>
>>> Or, I suppose that you could attempt to script the creation of your
>>> bridges and just deal with them all.
>>>
>>> Tony
>>>
>>> On Thu, Aug 22, 2013 at 10:49 AM, Stephan von Krawczynski
>>> <address@hidden> wrote:
>>> > Sorry, you misunderstood my writing. I am talking of several hundred
>>> > vlans
>>> > with - of course - different ids and quite some guests (around 50).
>>> > There is no way to simplify this setup besides the trivial way of a
>>> > bridge
>>> > that carries all vlan-tagged interfaces. The trivial thing about it is
>>> > all
>>> > these different vlans come in through one trunk. So if vlan-tagged
>>> > bridging
>>> > worked I would have only one bridge interface with 50 guests connected
>>> > ...
>>> >
>>> > --
>>> > Regards,
>>> > Stephan
>>> >
>>> >
>>> >
>>> > On Thu, 22 Aug 2013 10:29:59 -0700
>>> > Tony Su <address@hidden> wrote:
>>> >
>>> >> If you're configuring the all your "hundreds" of guests to connect to
>>> >> the same VLAN, then you should able to simply configure all guests to
>>> >> connect to the same working bridge device without further
>>> >> configuration.
>>> >>
>>> >> You're surely not trying to configure hundreds of individual vlans,
>>> >> separate ones for each guest?
>>> >>
>>> >> Tony
>>> >>
>>> >> On Thu, Aug 22, 2013 at 10:04 AM, Stephan von Krawczynski
>>> >> <address@hidden> wrote:
>>> >> > Hello Tony,
>>> >> >
>>> >> > thank you for answering, my comments are inline. Just as an
>>> >> > additional hint to
>>> >> > what I've tested so far. Since I found vlan bridging not working I
>>> >> > configured
>>> >> > the vlan on the host and put that interface to a bridge and over to
>>> >> > a virtio
>>> >> > device (non-vlan-tagged) in the guest. As you might expect this
>>> >> > works
>>> >> > perfectly. Unfortunately it is not useable for me, because if you
>>> >> > want several
>>> >> > hundred vlans to several guests you will end up configuring hundreds
>>> >> > of
>>> >> > bridges and interfaces.
>>> >> >
>>> >> >
>>> >> > On Thu, 22 Aug 2013 09:32:42 -0700
>>> >> > Tony Su <address@hidden> wrote:
>>> >> >
>>> >> >> Have you
>>> >> >> - Tested without VLAN tags?
>>> >> >
>>> >> > Yes, works perfectly.
>>> >> >
>>> >> >> - Verified IP Forwarding is enabled, I usually see this implemented
>>> >> >> in
>>> >> >> /etc/sysctl.conf and not written directly to the /proc files
>>> >> >
>>> >> > Yes, forwarding is active.
>>> >> >
>>> >> >> - Disabled all the transparent bridge filters, typicallly at
>>> >> >> /proc/sys/net/bridge/* again, although you can write directly to
>>> >> >> these
>>> >> >> files I'd recommend you simply add the commands to your sysctl.conf
>>> >> >
>>> >> > Yes, I played with these a bit but found out that there is no effect
>>> >> > on my
>>> >> > problem.
>>> >> >
>>> >> >> - Verified any personal FW is configured properly.
>>> >> >
>>> >> > There is none.
>>> >> >
>>> >> >> Tony
>>> >> >>
>>> >> >> On Thu, Aug 22, 2013 at 7:39 AM, Stephan von Krawczynski
>>> >> >> <address@hidden> wrote:
>>> >> >> > Hello all,
>>> >> >> >
>>> >> >> > I'd like to do something very simple - at least that's what I
>>> >> >> > thought
>>> >> >> > I want a guest to have access to a network just as if he was
>>> >> >> > connected to the
>>> >> >> > real card, but set up as bridge on the host and virtio network
>>> >> >> > driver. The
>>> >> >> > guest should be able to configure and use some or maybe even many
>>> >> >> > 802.1q vlans
>>> >> >> > on this network and the traffic should go out tagged.
>>> >> >> >
>>> >> >> > So I setup the hosts bridge and connected an intel network card
>>> >> >> > and a qemu
>>> >> >> > virtio card. Now the problem: No vlan-tagged traffic from the
>>> >> >> > physical
>>> >> >> > interface reaches the guest at all, and no vlan-tagged traffic
>>> >> >> > from the guest
>>> >> >> > reaches the physical net over the bridge. One major reason for
>>> >> >> > this is the
>>> >> >> > vlan offloading by the host interface card (intel). Another seems
>>> >> >> > to be that
>>> >> >> > arp requests are somehow not going through the bridge for the
>>> >> >> > vlans.
>>> >> >> >
>>> >> >> > I hope that someone here has used 802.1q vlans inside guests
>>> >> >> > before and can
>>> >> >> > share some tips how to make this work. Because out-of-the-box it
>>> >> >> > does not. All
>>> >> >> > system are linux of course and with latest kernels (3.10.9
>>> >> >> > currently).
>>> >> >> > qemu is 1.5.2.
>>> >> >> > Thanks for any hints.
>>> >> >> >
>>> >> >> > --
>>> >> >> > Regards,
>>> >> >> > Stephan
>>
>>
>>
>