All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: bridge@lists.linux-foundation.org
Subject: [Bridge] VLAN tagged traffic and different behavior on two CentOS 6.6 boxes
Date: Tue, 10 Feb 2015 19:30:55 +0100	[thread overview]
Message-ID: <54DA4E5F.3090800@assyoma.it> (raw)

Hi list,
I have a bridged KVM setup where I would trunk both tagged and untagged 
traffic. In other words, some VMs will reside on the untagged portion, 
while other on the tagged one.

I have two CentOS 6.6 boxes that behave quite differently each other and 
I can not understand why. On both boxes I have:
- an eth0 interface bridged to lanbr0
- an eth0.10 interface bridged to lanbr10

 From what I read here [1] and here [2], to have a working setup I need 
to create an ebtables rules similar to "ebtables -t broute -A BROUTING 
-p 802_1Q -i eth0 -j DROP". On the first system, until I create that 
rules I can not ping the lanbr10 interface (from another system).

But on the second system, after some 20-25 seconds (less if I disable 
STP on the bridge) I can ping the lanbr10 interface even _without_ the 
ebtables rules above.

How that is possibile? Why the second box seems to auto-configure it 
while the first one need the ebtables rule? I hope this is the right list...

Thanks.

[1] http://ebtables.netfilter.org/misc/brnf-faq.html
[2] http://www.rackspace.com/blog/vms-vlans-and-bridges-oh-my-part-2/

Additional informations:

FIRST BOX:
[root@singularity ~]# ifconfig eth0.10 0.0.0.0
[root@singularity ~]# brctl addbr lanbr10
[root@singularity ~]# brctl addif lanbr10 eth0.10
[root@singularity ~]# ifconfig lanbr10 10.0.0.100 netmask 255.255.255.0
[root@singularity ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
dmzbr0		8000.00a0d213ef5d	yes		eth1
							vnet0
							vnet4
							vnet7
lanbr0		8000.002522027e10	yes		eth0
							vnet1
							vnet2
							vnet3
							vnet5
lanbr10		8000.002522027e10	no		eth0.10
virbr0		8000.5254005a0aac	yes		virbr0-nic


SECOND BOX:
[root@kvm-black ~]# brctl addbr lanbr10
[root@kvm-black ~]# brctl addif lanbr10 eth0.10
[root@kvm-black ~]# ifconfig lanbr10 10.0.0.85 netmask 255.255.255.0
[root@kvm-black ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
lanbr		8000.0022196645d4	yes		eth0
lanbr10		8000.0022196645d4	no		eth0.10


-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

                 reply	other threads:[~2015-02-10 18:30 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54DA4E5F.3090800@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=bridge@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.