bridge.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [Bridge] Tagged/untagged and gretap bridging question.
@ 2011-01-14  0:15 Jonathan Thibault
  2011-01-14  8:21 ` Nicolas de Pesloüan
  0 siblings, 1 reply; 2+ messages in thread
From: Jonathan Thibault @ 2011-01-14  0:15 UTC (permalink / raw)
  To: bridge

Greetings list,

Assuming the following network setup of three locations linked by two
ethernet over gre (gretap) tunnels.

I am assuming that a broadcast on the local network, if it comes
untagged to eth0 will reach both network1 and network2 untagged.

My main question is about a broadcast happening in the tagged portion of
(local network).  Is there a chance for an ethernet broadcast in vlan 1
on the local network to reach remote network 2?  I'm thinking not, but
if I tcpdump an interface that has vlans enabled, I will see the tagged
packets on eth0.  As such I wonder if they will travel through br0 to
the remote locations as well, something I would rather avoid.

(local network)
|                                              (remote network 1)
| eth0.1 <--br1--> gre1.1                                       |
+-eth0   <--br0--> gre1-- (l3_to_host1) -- gre0 <--br0--> eth0-+
            |
            +----> gre2 -- (l3-to_host2) -- gre0 <--br0--> eth0-+
  eth0.2 <--br2--> gre2.2                                       |
                                               (remote network 2)

Of interest too is knowing if the tags will survive all the way to
remote networks or if I need to enable vlans on the remote gretap and
ethernet interfaces as well for them to work.

Alternatively, the setup would look like this:

(local network)
|                                              (remote network 1)
| eth0.1 <--br1--> gre1.1                                       |
| eth0.3 <--br0--> gre1-- (l3_to_host1) -- gre0 <--br0--> eth0-+
+-eth0
  eth0.4 <--br3-->gre2 -- (l3-to_host2) -- gre0 <--br0--> eth0-+
  eth0.2 <--br2--> gre2.2                                       |
                                               (remote network 2)

The goal being not to see any untagged frames coming out on the local
network from remote locations and instead having them appear in specific
local vlans.

So at the core of my questions really is this:  Will bridging the
untagged portion of an interface that has vlans enabled (eth0 when
eth0.x exists) let tagged frames go through to other members of the bridge?

Thanks for your collective wisdom,

Jonathan

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Bridge] Tagged/untagged and gretap bridging question.
  2011-01-14  0:15 [Bridge] Tagged/untagged and gretap bridging question Jonathan Thibault
@ 2011-01-14  8:21 ` Nicolas de Pesloüan
  0 siblings, 0 replies; 2+ messages in thread
From: Nicolas de Pesloüan @ 2011-01-14  8:21 UTC (permalink / raw)
  To: Jonathan Thibault; +Cc: bridge

Le 14/01/2011 01:15, Jonathan Thibault a écrit :
> The goal being not to see any untagged frames coming out on the local
> network from remote locations and instead having them appear in specific
> local vlans.
>
> So at the core of my questions really is this:  Will bridging the
> untagged portion of an interface that has vlans enabled (eth0 when
> eth0.x exists) let tagged frames go through to other members of the bridge?

In order to strictly control what goes into the bridge and what stay local, you should have a look 
at the ebtables command.

The following thread might also be useful:

http://www.mail-archive.com/bridge@lists.linux-foundation.org/msg01269.html

	Nicolas.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-01-14  8:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-14  0:15 [Bridge] Tagged/untagged and gretap bridging question Jonathan Thibault
2011-01-14  8:21 ` Nicolas de Pesloüan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).