Bridging / VLANs / ebtables

Bridging / VLANs / ebtables

[Tim Nelson]

Greetings-

I have an interesting situation that requires bridging some VLAN enabled interfaces together on a Debian 7.x x86 system. On the host, there is a single physical interface passing traffic natively (eth0), and two tagged VLANs also passing traffic (eth0.2 and eth0.3).

The use case is that I need to bridge eth0 with eth0.2, allowing layer two traffic to pass seamlessly between interfaces, and still leave eth0.3 in a usable state. The switch this system is connected to is outside of my control, which is the reason for the odd network setup.

What I'm finding by simply creating a new bridge br0 with members eth0 and eth0.2 is no connectivity on eth0.2, and slow/quirky connectivity on eth0 (native connectivity to Debian 7.x host). In doing research, I've found suggestions of adding the VLAN interfaces to the bridge direct, resulting in a br0, br0.2, and br0.3, but the results were the same.

It has been suggested to use ebtables to filter the VLANs from the eth0 interface on the bridge, yet allow operation to the system interface eth0.2/eth0.3. I found a very specific reference on the ebtables site for this scenario [1], usage suggested (modified to fit my environment):

ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP
ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j DROP

If my understanding of the ebtables usage as a brouter, and the kernel's interaction between all components involved, this should work. However, as noted, no change in operation is observed.

I'm hoping someone can shed light on what needs to be done for a successful bridge of eth0/eth0.2, with an intact eth0.3 (point to point link between Debian 7.x host and another device). I posted this to the debian-users list but given the wide audience, was not successful in getting relevant content.

All tips/tricks/suggestions welcome.

Thank you,

--Tim

[1] http://ebtables.netfilter.org/misc/brnf-faq.html#quiz2

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> Greetings-
> 
> I have an interesting situation that requires bridging some VLAN
> enabled interfaces together on a Debian 7.x x86 system. On the host,
> there is a single physical interface passing traffic natively
> (eth0), and two tagged VLANs also passing traffic (eth0.2 and
> eth0.3).
> 
> The use case is that I need to bridge eth0 with eth0.2, allowing
> layer two traffic to pass seamlessly between interfaces, and still
> leave eth0.3 in a usable state. The switch this system is connected
> to is outside of my control, which is the reason for the odd network
> setup.
> 
> What I'm finding by simply creating a new bridge br0 with members
> eth0 and eth0.2 is no connectivity on eth0.2, and slow/quirky
> connectivity on eth0 (native connectivity to Debian 7.x host). In
> doing research, I've found suggestions of adding the VLAN interfaces
> to the bridge direct, resulting in a br0, br0.2, and br0.3, but the
> results were the same.
> 
> It has been suggested to use ebtables to filter the VLANs from the
> eth0 interface on the bridge, yet allow operation to the system
> interface eth0.2/eth0.3. I found a very specific reference on the
> ebtables site for this scenario [1], usage suggested (modified to
> fit my environment):
> 
> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP
> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j DROP
> 
> If my understanding of the ebtables usage as a brouter, and the
> kernel's interaction between all components involved, this should
> work. However, as noted, no change in operation is observed.
> 
> I'm hoping someone can shed light on what needs to be done for a
> successful bridge of eth0/eth0.2, with an intact eth0.3 (point to
> point link between Debian 7.x host and another device). I posted
> this to the debian-users list but given the wide audience, was not
> successful in getting relevant content.
> 
> All tips/tricks/suggestions welcome.
> 
> Thank you,
> 
> --Tim
> 
> [1] http://ebtables.netfilter.org/misc/brnf-faq.html#quiz2

**bump** Any thoughts? Thanks!

--Tim

Re: Bridging / VLANs / ebtables

[Akshat Kakkar]

I might not be correct. In my understanding an Interface can be a part
of multiple vlans but it should not be possible to have all those vlan
interfaces (on the same physical interface) in the same bridge.

Can you share some more details of why do you require such set up?
What all are the connected devices and what is vlan config of each (I
understand you cannot change this configuration)?

On Tue, Dec 16, 2014 at 6:50 AM, Tim Nelson <tnelson@rockbochs.com> wrote:
> ----- Original Message -----
>> Greetings-
>>
>> I have an interesting situation that requires bridging some VLAN
>> enabled interfaces together on a Debian 7.x x86 system. On the host,
>> there is a single physical interface passing traffic natively
>> (eth0), and two tagged VLANs also passing traffic (eth0.2 and
>> eth0.3).
>>
>> The use case is that I need to bridge eth0 with eth0.2, allowing
>> layer two traffic to pass seamlessly between interfaces, and still
>> leave eth0.3 in a usable state. The switch this system is connected
>> to is outside of my control, which is the reason for the odd network
>> setup.
>>
>> What I'm finding by simply creating a new bridge br0 with members
>> eth0 and eth0.2 is no connectivity on eth0.2, and slow/quirky
>> connectivity on eth0 (native connectivity to Debian 7.x host). In
>> doing research, I've found suggestions of adding the VLAN interfaces
>> to the bridge direct, resulting in a br0, br0.2, and br0.3, but the
>> results were the same.
>>
>> It has been suggested to use ebtables to filter the VLANs from the
>> eth0 interface on the bridge, yet allow operation to the system
>> interface eth0.2/eth0.3. I found a very specific reference on the
>> ebtables site for this scenario [1], usage suggested (modified to
>> fit my environment):
>>
>> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP
>> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j DROP
>>
>> If my understanding of the ebtables usage as a brouter, and the
>> kernel's interaction between all components involved, this should
>> work. However, as noted, no change in operation is observed.
>>
>> I'm hoping someone can shed light on what needs to be done for a
>> successful bridge of eth0/eth0.2, with an intact eth0.3 (point to
>> point link between Debian 7.x host and another device). I posted
>> this to the debian-users list but given the wide audience, was not
>> successful in getting relevant content.
>>
>> All tips/tricks/suggestions welcome.
>>
>> Thank you,
>>
>> --Tim
>>
>> [1] http://ebtables.netfilter.org/misc/brnf-faq.html#quiz2
>
> **bump** Any thoughts? Thanks!
>
> --Tim
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bridging / VLANs / ebtables

[Paul Robert Marino]

You can bridge physical interfaces or bonds but not vlan sub interfaces.

This is a very odd request to bridge two vlans on the same physical interface.

Please give us details on what you are trying to accomplish with this
and we may be able to help.



On Tue, Dec 16, 2014 at 4:01 AM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
> I might not be correct. In my understanding an Interface can be a part
> of multiple vlans but it should not be possible to have all those vlan
> interfaces (on the same physical interface) in the same bridge.
>
> Can you share some more details of why do you require such set up?
> What all are the connected devices and what is vlan config of each (I
> understand you cannot change this configuration)?
>
> On Tue, Dec 16, 2014 at 6:50 AM, Tim Nelson <tnelson@rockbochs.com> wrote:
>> ----- Original Message -----
>>> Greetings-
>>>
>>> I have an interesting situation that requires bridging some VLAN
>>> enabled interfaces together on a Debian 7.x x86 system. On the host,
>>> there is a single physical interface passing traffic natively
>>> (eth0), and two tagged VLANs also passing traffic (eth0.2 and
>>> eth0.3).
>>>
>>> The use case is that I need to bridge eth0 with eth0.2, allowing
>>> layer two traffic to pass seamlessly between interfaces, and still
>>> leave eth0.3 in a usable state. The switch this system is connected
>>> to is outside of my control, which is the reason for the odd network
>>> setup.
>>>
>>> What I'm finding by simply creating a new bridge br0 with members
>>> eth0 and eth0.2 is no connectivity on eth0.2, and slow/quirky
>>> connectivity on eth0 (native connectivity to Debian 7.x host). In
>>> doing research, I've found suggestions of adding the VLAN interfaces
>>> to the bridge direct, resulting in a br0, br0.2, and br0.3, but the
>>> results were the same.
>>>
>>> It has been suggested to use ebtables to filter the VLANs from the
>>> eth0 interface on the bridge, yet allow operation to the system
>>> interface eth0.2/eth0.3. I found a very specific reference on the
>>> ebtables site for this scenario [1], usage suggested (modified to
>>> fit my environment):
>>>
>>> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP
>>> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j DROP
>>>
>>> If my understanding of the ebtables usage as a brouter, and the
>>> kernel's interaction between all components involved, this should
>>> work. However, as noted, no change in operation is observed.
>>>
>>> I'm hoping someone can shed light on what needs to be done for a
>>> successful bridge of eth0/eth0.2, with an intact eth0.3 (point to
>>> point link between Debian 7.x host and another device). I posted
>>> this to the debian-users list but given the wide audience, was not
>>> successful in getting relevant content.
>>>
>>> All tips/tricks/suggestions welcome.
>>>
>>> Thank you,
>>>
>>> --Tim
>>>
>>> [1] http://ebtables.netfilter.org/misc/brnf-faq.html#quiz2
>>
>> **bump** Any thoughts? Thanks!
>>
>> --Tim
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> You can bridge physical interfaces or bonds but not vlan sub
> interfaces.
> 
> This is a very odd request to bridge two vlans on the same physical
> interface.
> 
> Please give us details on what you are trying to accomplish with this
> and we may be able to help.

Greetings Paul-

Please see my other post (moments ago) for the use case. I understand this is an odd situation. Is it possible with the use of manipulation/filtering (ebtables and company) or simply not a possibility?

Thank you,

--Tim

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> I might not be correct. In my understanding an Interface can be a
> part
> of multiple vlans but it should not be possible to have all those
> vlan
> interfaces (on the same physical interface) in the same bridge.
> 
> Can you share some more details of why do you require such set up?
> What all are the connected devices and what is vlan config of each (I
> understand you cannot change this configuration)?
> 

Greetings-

The use case is a server connected to a switch (provided, not able to manage/configure), where it has access to three subnets, delivered via ethernet on the link untagged, and tagged in VLANs 2/3. I have a need to bridge the untagged parent interface (eth0) and VLAN 3 (eth0.3), while leaving the VLAN 2 interface (eth0.2) untouched.

Believe me, I understand this is an odd situation, but I'm very curious if it is possible using ebtables or some other filtering/manipulation application to make it work.

Thank you,

--Tim

Re: Bridging / VLANs / ebtables

[Jason Cooper]

On Tue, Dec 16, 2014 at 03:15:33PM -0600, Tim Nelson wrote:
> The use case is a server connected to a switch (provided, not able to
> manage/configure), where it has access to three subnets, delivered via
> ethernet on the link untagged, and tagged in VLANs 2/3. I have a need
> to bridge the untagged parent interface (eth0) and VLAN 3 (eth0.3),
> while leaving the VLAN 2 interface (eth0.2) untouched.

iiuc, you have the following types of packets on eth0:

	x.x.x.x/24
	y.y.y.y/24
	z.z.z.z/24
	vlan2:a.a.a.a/24
	vlan3:b.b.b.b/24

So, you need x.x.x.x/24, y.y.y.y/24, and z.z.z.z/24 to get routed into
vlan3.  Does traffic need to go the other way?  Is there broadcast or
multicast traffic to worry about?

thx,

Jason.

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> iiuc, you have the following types of packets on eth0:
> 
> 	x.x.x.x/24
> 	y.y.y.y/24
> 	z.z.z.z/24
> 	vlan2:a.a.a.a/24
> 	vlan3:b.b.b.b/24
> 
> So, you need x.x.x.x/24, y.y.y.y/24, and z.z.z.z/24 to get routed
> into
> vlan3.  Does traffic need to go the other way?  Is there broadcast or
> multicast traffic to worry about?
> 

Greetings Jason-

Specifically, I have:

eth0: x.x.x.x/24
eth0.2: y.y.y.y/29
eth0.3: z.z.z.z/24

After bridging eth0 and eth0.3, devices on eth0.3 will utilize the same address space as that present on eth0 native (x.x.x.x/24). Of course, traffic to/from eth0.2 would continue to be functional. Traffic *does* need to operate in both directions, and yes there will be broadcast traffic originating from eth0.3, as a DHCP request, which would be answered by a DHCP server on the eth0 native connected network.

Thanks!

--Tim

Re: Bridging / VLANs / ebtables

[Jason Cooper]

On Tue, Dec 16, 2014 at 03:46:59PM -0600, Tim Nelson wrote:
> ----- Original Message -----
> > iiuc, you have the following types of packets on eth0:
> > 
> > 	x.x.x.x/24
> > 	y.y.y.y/24
> > 	z.z.z.z/24
> > 	vlan2:a.a.a.a/24
> > 	vlan3:b.b.b.b/24
> > 
> > So, you need x.x.x.x/24, y.y.y.y/24, and z.z.z.z/24 to get routed
> > into vlan3.  Does traffic need to go the other way?  Is there
> > broadcast or multicast traffic to worry about?
> > 
> 
> Greetings Jason-
> 
> Specifically, I have:
> 
> eth0: x.x.x.x/24
> eth0.2: y.y.y.y/29
> eth0.3: z.z.z.z/24
> 
> After bridging eth0 and eth0.3, devices on eth0.3 will utilize the
> same address space as that present on eth0 native (x.x.x.x/24). Of
> course, traffic to/from eth0.2 would continue to be functional.
> Traffic *does* need to operate in both directions, and yes there will
> be broadcast traffic originating from eth0.3, as a DHCP request, which
> would be answered by a DHCP server on the eth0 native connected
> network.

I'm sure I'm missing something, but a quick test in a VM worked:

[root@triton] # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00163e1c9a87       no              eth126
                                                        eth126.3

eth126.3 did not have an ip address.  eth126 did, but you have to set
both interfaces promiscuous and 0.0.0.0.  Then, assign an IP in the
range z.z.z.z/24 to br0.

hth,

Jason.

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> On Tue, Dec 16, 2014 at 03:46:59PM -0600, Tim Nelson wrote:
> > ----- Original Message -----
> > > iiuc, you have the following types of packets on eth0:
> > > 
> > > 	x.x.x.x/24
> > > 	y.y.y.y/24
> > > 	z.z.z.z/24
> > > 	vlan2:a.a.a.a/24
> > > 	vlan3:b.b.b.b/24
> > > 
> > > So, you need x.x.x.x/24, y.y.y.y/24, and z.z.z.z/24 to get routed
> > > into vlan3.  Does traffic need to go the other way?  Is there
> > > broadcast or multicast traffic to worry about?
> > > 
> > 
> > Greetings Jason-
> > 
> > Specifically, I have:
> > 
> > eth0: x.x.x.x/24
> > eth0.2: y.y.y.y/29
> > eth0.3: z.z.z.z/24
> > 
> > After bridging eth0 and eth0.3, devices on eth0.3 will utilize the
> > same address space as that present on eth0 native (x.x.x.x/24). Of
> > course, traffic to/from eth0.2 would continue to be functional.
> > Traffic *does* need to operate in both directions, and yes there
> > will
> > be broadcast traffic originating from eth0.3, as a DHCP request,
> > which
> > would be answered by a DHCP server on the eth0 native connected
> > network.
> 
> I'm sure I'm missing something, but a quick test in a VM worked:
> 
> [root@triton] # brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.00163e1c9a87       no              eth126
>                                                         eth126.3
> 
> eth126.3 did not have an ip address.  eth126 did, but you have to set
> both interfaces promiscuous and 0.0.0.0.  Then, assign an IP in the
> range z.z.z.z/24 to br0.
> 

I've done the same:

root@h4222:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.b827ebbd9e51       no              eth0
                                                        eth0.3

I've set both eth0 and eth0.3 to promiscuous mode (ifconfig ethX[.y] promisc), and neither eth0 or eth0.3 have an IP, but br0 does. I'm not able to communicate with the IP assigned to the bridge from either interface.

Thank you very much for the helpful suggestions, it is greatly appreciated.

--Tim

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> ----- Original Message -----
> > On Tue, Dec 16, 2014 at 03:46:59PM -0600, Tim Nelson wrote:
> > > ----- Original Message -----
> > > > iiuc, you have the following types of packets on eth0:
> > > > 
> > > > 	x.x.x.x/24
> > > > 	y.y.y.y/24
> > > > 	z.z.z.z/24
> > > > 	vlan2:a.a.a.a/24
> > > > 	vlan3:b.b.b.b/24
> > > > 
> > > > So, you need x.x.x.x/24, y.y.y.y/24, and z.z.z.z/24 to get
> > > > routed
> > > > into vlan3.  Does traffic need to go the other way?  Is there
> > > > broadcast or multicast traffic to worry about?
> > > > 
> > > 
> > > Greetings Jason-
> > > 
> > > Specifically, I have:
> > > 
> > > eth0: x.x.x.x/24
> > > eth0.2: y.y.y.y/29
> > > eth0.3: z.z.z.z/24
> > > 
> > > After bridging eth0 and eth0.3, devices on eth0.3 will utilize
> > > the
> > > same address space as that present on eth0 native (x.x.x.x/24).
> > > Of
> > > course, traffic to/from eth0.2 would continue to be functional.
> > > Traffic *does* need to operate in both directions, and yes there
> > > will
> > > be broadcast traffic originating from eth0.3, as a DHCP request,
> > > which
> > > would be answered by a DHCP server on the eth0 native connected
> > > network.
> > 
> > I'm sure I'm missing something, but a quick test in a VM worked:
> > 
> > [root@triton] # brctl show
> > bridge name     bridge id               STP enabled     interfaces
> > br0             8000.00163e1c9a87       no              eth126
> >                                                         eth126.3
> > 
> > eth126.3 did not have an ip address.  eth126 did, but you have to
> > set
> > both interfaces promiscuous and 0.0.0.0.  Then, assign an IP in the
> > range z.z.z.z/24 to br0.
> > 
> 
> I've done the same:
> 
> root@h4222:~# brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.b827ebbd9e51       no              eth0
>                                                         eth0.3
> 
> I've set both eth0 and eth0.3 to promiscuous mode (ifconfig ethX[.y]
> promisc), and neither eth0 or eth0.3 have an IP, but br0 does. I'm
> not able to communicate with the IP assigned to the bridge from
> either interface.
> 
> Thank you very much for the helpful suggestions, it is greatly
> appreciated.
> 

*BUMP*

Any thoughts on this? I know it's "odd", but all suggestions welcome and appreciated. Thanks!

--Tim

Re: Bridging / VLANs / ebtables

[Jason Cooper]

Tim,

Ah crap.  I should've read the OP first.  Definitely some scenario lost
in quote-trimming...

On Fri, Dec 12, 2014 at 02:03:12PM -0600, Tim Nelson wrote:
> Greetings-
> 
> I have an interesting situation that requires bridging some VLAN
> enabled interfaces together on a Debian 7.x x86 system. On the host,
> there is a single physical interface passing traffic natively (eth0),
> and two tagged VLANs also passing traffic (eth0.2 and eth0.3).
> 
> The use case is that I need to bridge eth0 with eth0.2, allowing layer
> two traffic to pass seamlessly between interfaces, and still leave
> eth0.3 in a usable state. The switch this system is connected to is
> outside of my control, which is the reason for the odd network setup.
> 
> What I'm finding by simply creating a new bridge br0 with members eth0
> and eth0.2 is no connectivity on eth0.2, and slow/quirky connectivity
> on eth0 (native connectivity to Debian 7.x host). 

This sounds a bit like an IP address / routing rule conflict.  Did you
set eth0 and eth0.2 0.0.0.0 and promiscuous?  Did you assign one IP
address to the bridge?  Would you mind sending the output of:

# ip addr show

and

# route -n

?

> It has been suggested to use ebtables to filter the VLANs from the
> eth0 interface on the bridge, yet allow operation to the system
> interface eth0.2/eth0.3. I found a very specific reference on the
> ebtables site for this scenario [1], usage suggested (modified to fit
> my environment):
> 
> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP
> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j DROP
> 
> If my understanding of the ebtables usage as a brouter, and the
> kernel's interaction between all components involved, this should
> work. However, as noted, no change in operation is observed.

Yes, based on your description of the network you are going to need the
above rules.

thx,

Jason.

Re: Bridging / VLANs / ebtables

[Akshat Kakkar]

Its not about finding a workaround or something.

If we bridge two vlans on the same interface, then what should be the
VLAN-tag on the packets moving out of the box? As it might not be
possible to decide this, thats why we cannot bridge two vlans on the
same interface.

On Wed, Dec 17, 2014 at 8:25 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> Tim,
>
> Ah crap.  I should've read the OP first.  Definitely some scenario lost
> in quote-trimming...
>
> On Fri, Dec 12, 2014 at 02:03:12PM -0600, Tim Nelson wrote:
>> Greetings-
>>
>> I have an interesting situation that requires bridging some VLAN
>> enabled interfaces together on a Debian 7.x x86 system. On the host,
>> there is a single physical interface passing traffic natively (eth0),
>> and two tagged VLANs also passing traffic (eth0.2 and eth0.3).
>>
>> The use case is that I need to bridge eth0 with eth0.2, allowing layer
>> two traffic to pass seamlessly between interfaces, and still leave
>> eth0.3 in a usable state. The switch this system is connected to is
>> outside of my control, which is the reason for the odd network setup.
>>
>> What I'm finding by simply creating a new bridge br0 with members eth0
>> and eth0.2 is no connectivity on eth0.2, and slow/quirky connectivity
>> on eth0 (native connectivity to Debian 7.x host).
>
> This sounds a bit like an IP address / routing rule conflict.  Did you
> set eth0 and eth0.2 0.0.0.0 and promiscuous?  Did you assign one IP
> address to the bridge?  Would you mind sending the output of:
>
> # ip addr show
>
> and
>
> # route -n
>
> ?
>
>> It has been suggested to use ebtables to filter the VLANs from the
>> eth0 interface on the bridge, yet allow operation to the system
>> interface eth0.2/eth0.3. I found a very specific reference on the
>> ebtables site for this scenario [1], usage suggested (modified to fit
>> my environment):
>>
>> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP
>> ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j DROP
>>
>> If my understanding of the ebtables usage as a brouter, and the
>> kernel's interaction between all components involved, this should
>> work. However, as noted, no change in operation is observed.
>
> Yes, based on your description of the network you are going to need the
> above rules.
>
> thx,
>
> Jason.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> Its not about finding a workaround or something.
> 
> If we bridge two vlans on the same interface, then what should be the
> VLAN-tag on the packets moving out of the box? As it might not be
> possible to decide this, thats why we cannot bridge two vlans on the
> same interface.
> 

My assumption (wrongful?) would be some sort of state tracking wherein the kernel notes the interface the traffic is sourced from, and return traffic goes back via the same path (including layer 2 characteristics including VLAN ID).

--Tim

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> Tim,
> 
> Ah crap.  I should've read the OP first.  Definitely some scenario
> lost
> in quote-trimming...
> 
> On Fri, Dec 12, 2014 at 02:03:12PM -0600, Tim Nelson wrote:
> > Greetings-
> > 
> > I have an interesting situation that requires bridging some VLAN
> > enabled interfaces together on a Debian 7.x x86 system. On the
> > host,
> > there is a single physical interface passing traffic natively
> > (eth0),
> > and two tagged VLANs also passing traffic (eth0.2 and eth0.3).
> > 
> > The use case is that I need to bridge eth0 with eth0.2, allowing
> > layer
> > two traffic to pass seamlessly between interfaces, and still leave
> > eth0.3 in a usable state. The switch this system is connected to is
> > outside of my control, which is the reason for the odd network
> > setup.
> > 
> > What I'm finding by simply creating a new bridge br0 with members
> > eth0
> > and eth0.2 is no connectivity on eth0.2, and slow/quirky
> > connectivity
> > on eth0 (native connectivity to Debian 7.x host).
> 
> This sounds a bit like an IP address / routing rule conflict.  Did
> you
> set eth0 and eth0.2 0.0.0.0 and promiscuous?  Did you assign one IP
> address to the bridge?  Would you mind sending the output of:
> 

I had not thought of putting the interfaces in promiscuous mode, but have since tested (as per your last email). Still no change.

> # ip addr show
> 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
    link/ether b8:27:eb:bd:9e:51 brd ff:ff:ff:ff:ff:ff
3: eth0.3@eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP
    link/ether b8:27:eb:bd:9e:51 brd ff:ff:ff:ff:ff:ff
4: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether b8:27:eb:bd:9e:51 brd ff:ff:ff:ff:ff:ff
    inet 172.31.255.249/29 brd 172.31.255.255 scope global eth0.2
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:febd:9e51/64 scope link
       valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether b8:27:eb:bd:9e:51 brd ff:ff:ff:ff:ff:ff
    inet 172.16.23.152/24 brd 172.16.23.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:febd:9e51/64 scope link
       valid_lft forever preferred_lft forever


> and
> 
> # route -n
> 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.23.1     0.0.0.0         UG    0      0        0 br0
172.16.23.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
172.31.255.248  0.0.0.0         255.255.255.248 U     0      0        0 eth0.2


> ?
> 
> > It has been suggested to use ebtables to filter the VLANs from the
> > eth0 interface on the bridge, yet allow operation to the system
> > interface eth0.2/eth0.3. I found a very specific reference on the
> > ebtables site for this scenario [1], usage suggested (modified to
> > fit
> > my environment):
> > 
> > ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j
> > DROP
> > ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j
> > DROP
> > 
> > If my understanding of the ebtables usage as a brouter, and the
> > kernel's interaction between all components involved, this should
> > work. However, as noted, no change in operation is observed.
> 
> Yes, based on your description of the network you are going to need
> the
> above rules.
> 

I've added the above rules, no change:

root@h4222:~# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 2, policy: ACCEPT
-p 802_1Q -i eth0 --vlan-id 3 -j DROP
-p 802_1Q -i eth0 --vlan-id 2 -j DROP

Thank you,

--Tim

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message ----- 
> I get the scenario but not the why. Is it a subset of specific things
> you need to do a layer 2 bridge for or do you need it for something
> else.
>
> For example I have a firewall where I need to forward broadcast (
> 255.255.255.255 ,xxx.xxx.xxx.255) messages between different
> segments in the network. Most people would think of bridging for
> this but I did something completely different involving setting both
> interfaces to a /32, adding a static route for each subnet, adding a
> static arp table entry on each interface for the broadcast IP
> addresses mapped to the broadcast mac addresses then simple iptables
> rules.

In this case, there is a device on a switchport (untagged VLAN 3) which needs to have layer 2 access to/from devices connected to a different broadcast domain, available on a different switchport. Both the untagged network, as well as VLAN3 networks are available to this 'host in the middle'. Given an inability to manage the switch in this very specialized case, I'd like to make that bridge happen within the connected host.

Would you be open to providing more specifics on your /32 setup you noted?

--Tim

Re: Bridging / VLANs / ebtables

[Tim Nelson]

----- Original Message -----
> I get the scenario but not the why. Is it a subset of specific things
> you need to do a layer 2 bridge for or do you need it for something
> else.
> 
> For example I have a firewall where I need to forward broadcast
> (255.255.255.255,xxx.xxx.xxx.255) messages between different segments
> in the network. Most people would think of bridging for this but I
> did
> something completely different involving setting both interfaces to a
> /32, adding a static route for each subnet, adding a static arp table
> entry on each interface for the broadcast IP addresses mapped to the
> broadcast mac addresses then simple iptables rules.
> 

Greetings Paul-

I believe you mentioned this previously. While the mechanism is 'different', does the end result still operate the same, allowing a device on one interface to have an IP from the other interface, and still operate as though a bridge was in place?

Thank you,

--Tim

Re: Bridging / VLANs / ebtables

[Paul Robert Marino]

unfortunately no.

The problem you have unfortunately requires you to use two physical
untagged interfaces according to every test I've done in the past.


The only thing Ive found related but not exactly what you are doing is
this from http://ebtables.netfilter.org/misc/brnf-faq.html but on the
surface it almost the opposite of what you want to do but may work.
You could try then adding the base interface and the vlan interface to
the bridge, I haven't tested it so I can not be sure. Also what this
means is that 3rd vlan you don't want to bridge may need special
handling as well.

quote from " http://ebtables.netfilter.org/misc/brnf-faq.html"
"
How do I let vlan-tagged traffic go through a vlan bridge port and the
other traffic through a non-vlan bridge port? Suppose eth0 and eth0.15
are ports of br0. Without countermeasures all traffic, including
traffic vlan-tagged with tag 15, entering the physical device eth0
will go through the bridge port eth0. To make the 15-tagged traffic go
through the eth0.15 bridge port, use the following ebtables rule:

ebtables -t broute -A BROUTING -i eth0 --vlan-id 15 -j DROP

With the above rule, 15-tagged traffic will enter the bridge on the
physical device eth0, will then be brouted and enter the bridge port
eth0.15, the vlan header will be stripped, after which the packet is
bridged. The packet thus enters the BROUTING chain twice, the first
time with input device eth0 and the second time with input device
eth0.15. The other chains are only traversed once. All other traffic
will be bridged with input device eth0.
"
That said I still think you will need to split the traffic across 2
physical interfaces to make this work, and I think it needs a revers
matching rule to make the communications work in both directions.


On Mon, Dec 22, 2014 at 10:24 AM, Tim Nelson <tnelson@rockbochs.com> wrote:
> ----- Original Message -----
>> I get the scenario but not the why. Is it a subset of specific things
>> you need to do a layer 2 bridge for or do you need it for something
>> else.
>>
>> For example I have a firewall where I need to forward broadcast
>> (255.255.255.255,xxx.xxx.xxx.255) messages between different segments
>> in the network. Most people would think of bridging for this but I
>> did
>> something completely different involving setting both interfaces to a
>> /32, adding a static route for each subnet, adding a static arp table
>> entry on each interface for the broadcast IP addresses mapped to the
>> broadcast mac addresses then simple iptables rules.
>>
>
> Greetings Paul-
>
> I believe you mentioned this previously. While the mechanism is 'different', does the end result still operate the same, allowing a device on one interface to have an IP from the other interface, and still operate as though a bridge was in place?
>
> Thank you,
>
> --Tim
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html