vlan inside bridge

M

Michael Lednev

Member
May 26, 2013
24
0
21
Yaroslavl, Russia
Hi. I have VM with pfsense inside it. Physical node has 2 eth interfaces which I use in following way: eth0 bridged into vmbr0 for lan, eth1 with 2 vlans bridged into vmbr1 for uplinks.

Code: 
# brctl show
bridge name     bridge id               STP enabled     interfaces
vmbr0           8000.002590a5b60a       no              eth0
                                                        tap101i0
vmbr1           8000.002590a5b60b       no              eth1
                                                        tap101i1

On pfsense these two taps are showing as em0 and em1

Code: 
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
em1_vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
em1_vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500





The problem is that when the node is running kernel 2.6.32-40-pve everything is working as it should be (and has been working for a few years). When the node is booted with 2.6.32-41-pve kernel the traffic continues to pass only on interface without vlans. I can see arp requests and replies on eth1 interface via tcpdump but they are not going away from the server as I can only see arp requests on uplink. eth0 interface works perfectly under the same circumstances. How can I fix this situation?
 
Yeah. Would like to keep with one thread on this so we can track it. Since I run my routers and firewalls virtually, this bug has me concerned. No updates for me until this is resolved
 
Hi Michael
Can you post the content of /etc/networkg/interfaces and the qm config of your pfsense VM ?
 
here you go

Code: 
auto lo vmbr0 vmbr1
iface lo inet loopback


iface vmbr0 inet static
        address 10.xx.xx.xx
        netmask 255.255.255.0
        gateway 10.xx.xx.xx
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0


iface vmbr1 inet manual
        bridge_ports eth1
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

and

Code: 
bootdisk: ide0
cores: 2
cpu: qemu64
ide0: lvm-local:vm-101-disk-1,size=32G
memory: 1024
name: pfsense
net0: e1000=6A:47:0B:18:6B:21,bridge=vmbr0
net1: e1000=4E:9B:C9:E4:92:09,bridge=vmbr1
onboot: 1
ostype: other
sockets: 1
 
Ok Thanks
Which NICs are you using your Proxmox host ? ( lspci | grep Ether)
 
Do you use OpenVZ? If not I recommend trying out a less antique kernel by upgrading to the newly released PVE4.0 ;-)
Otherwise I'd like to know more details about your network setup, because all I could reproduce was a problem that downgrading to 2.6.32-40 does not fix, so that would be a different issue.
 
no, i'm not using openvz. and no, i will not upgrade to 4.0 just yet, i'd rather stick with -40 kernel. what could possibly break vlans in -41?

and what else do you want to know about my network setup? looks like i've told you everything
 
Last edited:
And you're saying eth0 works and eth1 doesn't?

1) Are both cards using the e1000e driver or is one using the gbe driver? (my
google-fu failed me on that...). (Both of these aren't from the kernel source tree but from intel's repositories, you could try compiling them from the kernel .src.rpm in the pve-kernel-2.6.32 git repository to get the in-kernel version and see if that changes anything. In my tests described below it made no difference, though.)

2) Would this describe your setup?
Code: 
           +----------------------------------------------------------+
           | pve3.4                                                   |
           |                                      +-----------------+ |
           |                                      | pfSense         | |
           |                                      |                 | |
     ======x=======+    +=========+    +==========o==============+  | |
(A)--->NIC ¦ eth0 <------> vmbr0 <------>tap101i0 ¦    em0       |  | |
     ======x=======+    +=========+    +==========o==+ - - - - - +  | |
           |                                      |  | em0_vlan2 |  | |
           |                                      |  +===========+  | |
           |                                      |                 | |
     ======x=======+    +=========+    +==========o==============+  | |
(B)--->NIC ¦ eth1 <------> vmbr1 <------>tap101i1 ¦    em1       |  | |
     ======x=======+    +=========+    +==========o==+ - - - - - +  | |
           |                                      |  | em1_vlan3 |  | |
           |                                      |  +===========+  | |
           |                                      |                 | |
           |                                      +-----------------+ |
           |                                                          |
           +----------------------------------------------------------+

3) If you use tcpdump with `-e` on all those interfaces (em*, em*_vlan*, tap101i*, vmbr*, eth*), which of them show the vlan tag and which of them don't?
All but em*_vlan* should show the tags in the tcpdump output.

I've built the above setup with the `pve3.4` box being a VM + nesting. There the vlan tag disappears at (A) and (B) (but still show up at eth0 and eth1) unless they're virtio. But this happens with both -41 and -40.

Note that the newer (4.2) kernels in pve4 give you some more control over vlan (including vlan aware bridges...)

As for what could possibly break vlans in -41 => well, half the kernel source diff between the two versions is about vlans, so... a lot ;-)
 
pve3 also has a 3.10 kernel you could try if you don't want to upgrade to pve4 - what is it that keeps you on a 2.6 kernel series?
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back