Passing VID-aware ethernet frames on plain batX interfaces

Passing VID-aware ethernet frames on plain batX interfaces

[Alessandro Bolletta]

Hi,

if I pass tagged ethernet traffic inside a bat0 interface (without
creating an alias that uses the linux vlan stack for transparent
tagging), is this being allowed by batman-adv?

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

On Friday, 11 September 2020 12:48:52 CEST Alessandro Bolletta wrote:
> if I pass tagged ethernet traffic inside a bat0 interface (without
> creating an alias that uses the linux vlan stack for transparent
> tagging), is this being allowed by batman-adv?

Not since batman-adv was made VLAN aware.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Alessandro Bolletta]

So you mean that it is not feasible to create a (single) linux network
interface that let me send traffic on the batman-adv network in an
untagged or tagged way, though the same interface I mean?

Il giorno ven 11 set 2020 alle ore 14:01 Sven Eckelmann
<sven@narfation.org> ha scritto:
>
> On Friday, 11 September 2020 12:48:52 CEST Alessandro Bolletta wrote:
> > if I pass tagged ethernet traffic inside a bat0 interface (without
> > creating an alias that uses the linux vlan stack for transparent
> > tagging), is this being allowed by batman-adv?
>
> Not since batman-adv was made VLAN aware.
>
> Kind regards,
>         Sven

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On Friday, 11 September 2020 14:19:59 CEST Alessandro Bolletta wrote:
> So you mean that it is not feasible to create a (single) linux network
> interface that let me send traffic on the batman-adv network in an
> untagged or tagged way, though the same interface I mean?

batman-adv is depending on the Linux code telling it what VLAN it should 
handle (through ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid). So something 
like the 8021q driver or the bridge code for vlans. Only when this was done, 
it will also handle the addresses in TT. So no, bat0 is not enough to 
transport something like an ethernet frame tagged as vlan1. You also need 
bat0.1 (assuming this is the vlan interface for VID 1). But it is then not 
really relevant for it whether the data was send through bat0.1 or was somehow 
else tagged and then put into bat0.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On Friday, 11 September 2020 14:48:19 CEST Sven Eckelmann wrote:
> On Friday, 11 September 2020 14:19:59 CEST Alessandro Bolletta wrote:
> > So you mean that it is not feasible to create a (single) linux network
> > interface that let me send traffic on the batman-adv network in an
> > untagged or tagged way, though the same interface I mean?
> 
> batman-adv is depending on the Linux code telling it what VLAN it should 
> handle (through ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid). So something 
> like the 8021q driver or the bridge code for vlans. Only when this was done, 
> it will also handle the addresses in TT. So no, bat0 is not enough to 
> transport something like an ethernet frame tagged as vlan1. You also need 
> bat0.1 (assuming this is the vlan interface for VID 1). But it is then not 
> really relevant for it whether the data was send through bat0.1 or was somehow 
> else tagged and then put into bat0.

Btw. why are you now using VLANs on top of bat0 - weren't you trying before to 
have multiple mesh clouds by using VLAN (or VLAN-like) technologies below 
bat0?

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Passing VID-aware ethernet frames on plain batX interfaces

[dan]

I see value in both methods, but for my use case I'm most interested
in bat0 as the 'fabric' so the batman-adv nodes don't need any
additional configuration to carry the VLANs.

so, based on the previous statement, is the way to make bat0 agnostic
about VLANs to create a bridge br0 and put bat0 in br0 and then make a
br0.10 vlan interface?


On Fri, Sep 11, 2020 at 6:50 AM Sven Eckelmann <sven@narfation.org> wrote:
>
> On Friday, 11 September 2020 14:48:19 CEST Sven Eckelmann wrote:
> > On Friday, 11 September 2020 14:19:59 CEST Alessandro Bolletta wrote:
> > > So you mean that it is not feasible to create a (single) linux network
> > > interface that let me send traffic on the batman-adv network in an
> > > untagged or tagged way, though the same interface I mean?
> >
> > batman-adv is depending on the Linux code telling it what VLAN it should
> > handle (through ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid). So something
> > like the 8021q driver or the bridge code for vlans. Only when this was done,
> > it will also handle the addresses in TT. So no, bat0 is not enough to
> > transport something like an ethernet frame tagged as vlan1. You also need
> > bat0.1 (assuming this is the vlan interface for VID 1). But it is then not
> > really relevant for it whether the data was send through bat0.1 or was somehow
> > else tagged and then put into bat0.
>
> Btw. why are you now using VLANs on top of bat0 - weren't you trying before to
> have multiple mesh clouds by using VLAN (or VLAN-like) technologies below
> bat0?
>
> Kind regards,
>         Sven

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

On Friday, 11 September 2020 15:25:17 CEST dan wrote:
> so, based on the previous statement, is the way to make bat0 agnostic
> about VLANs to create a bridge br0 and put bat0 in br0 and then make a
> br0.10 vlan interface?

Not at the moment.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Alessandro Bolletta]

I see.
Ok for transmission purposes, but what if I want to receive a tagged
ethernet frame coming from the batman network?
Should I must only rely to the related 802.1q interface (eg. bat0.1)
or can I receive the whole traffic (untagged and tagged) from the
plain bat0 interface, just listening for the incoming traffic on it?
If the answer is the first choice, is it possible to have an approach
where I can receive coming from bat0 leveraging on a single interface
anyway? Could a linux bridge br0 on the top of bat0 interface make it
possible?
For example, if I connect an openvswitch port configured as trunk to a
linux bridge br0 that enslaves bat0, could I expect to see the whole
traffic inside the batman-adv mesh network (so I mean, both tagged and
untagged traffic) also flowing inside the OvS switch?
Is there also a wait to get rid of the linux bridge br0?

Thank you.

Il giorno ven 11 set 2020 alle ore 14:50 Sven Eckelmann
<sven@narfation.org> ha scritto:
>
> On Friday, 11 September 2020 14:48:19 CEST Sven Eckelmann wrote:
> > On Friday, 11 September 2020 14:19:59 CEST Alessandro Bolletta wrote:
> > > So you mean that it is not feasible to create a (single) linux network
> > > interface that let me send traffic on the batman-adv network in an
> > > untagged or tagged way, though the same interface I mean?
> >
> > batman-adv is depending on the Linux code telling it what VLAN it should
> > handle (through ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid). So something
> > like the 8021q driver or the bridge code for vlans. Only when this was done,
> > it will also handle the addresses in TT. So no, bat0 is not enough to
> > transport something like an ethernet frame tagged as vlan1. You also need
> > bat0.1 (assuming this is the vlan interface for VID 1). But it is then not
> > really relevant for it whether the data was send through bat0.1 or was somehow
> > else tagged and then put into bat0.
>
> Btw. why are you now using VLANs on top of bat0 - weren't you trying before to
> have multiple mesh clouds by using VLAN (or VLAN-like) technologies below
> bat0?
>
> Kind regards,
>         Sven

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On Friday, 11 September 2020 15:03:13 CEST Alessandro Bolletta wrote:
> I see. Ok for transmission purposes, but what if I have to receive a tagged
> frame?

It should not have been send to the other node when there is no TT entry for 
this mac + VID from the receiver.

> Should I only rely to the 8021q interface (eg. bat0.1) or receive the whole
> traffic (untagged and tagged) from the plain bat0 interface?

Hm?

> If this is not feasible, is it possible to handle in someway this?

Hm?

> A linux
> bridge on the top of bat0 interface could make it possible?

No, the bridge must also enable the vlan for this bat0 interface.

See also
https://www.open-mesh.org/projects/batman-adv/wiki/Faq#BATMAN-Advanced-VLAN-questions

Maybe Antonio wants to add more things to this discussion.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Alessandro Bolletta]

Hi Sven,

I'm sorry for being not so clear in my statements. You can read my
last "refactored" mail, which is easier to understand:

Should I must only rely to the related 802.1q interface (eg. bat0.1)
or can I receive the whole traffic (untagged and tagged) from the
plain bat0 interface, just listening for the incoming traffic on it?

If the answer is the first choice, is it possible to have an approach
where I can receive coming from bat0 leveraging on a single interface
anyway? Could a linux bridge br0 on the top of bat0 interface make it
possible?

For example, if I connect an openvswitch port, configured as trunk port, to a
linux bridge br0 that enslaves bat0, could I expect to see the whole
traffic inside the batman-adv mesh network (so I mean, both tagged and
untagged traffic) also "flowing" inside the other OvS switch ports
that are attached to that vlans?
Moreover, just out of curiosity, is there also another known way to
get rid of the linux bridge br0 in order to get this done (attaching
the bat0 directly to the OvS switch, for example)?

Il giorno ven 11 set 2020 alle ore 16:02 Sven Eckelmann
<sven@narfation.org> ha scritto:
>
> On Friday, 11 September 2020 15:03:13 CEST Alessandro Bolletta wrote:
> > I see. Ok for transmission purposes, but what if I have to receive a tagged
> > frame?
>
> It should not have been send to the other node when there is no TT entry for
> this mac + VID from the receiver.
>
> > Should I only rely to the 8021q interface (eg. bat0.1) or receive the whole
> > traffic (untagged and tagged) from the plain bat0 interface?
>
> Hm?
>
> > If this is not feasible, is it possible to handle in someway this?
>
> Hm?
>
> > A linux
> > bridge on the top of bat0 interface could make it possible?
>
> No, the bridge must also enable the vlan for this bat0 interface.
>
> See also
> https://www.open-mesh.org/projects/batman-adv/wiki/Faq#BATMAN-Advanced-VLAN-questions
>
> Maybe Antonio wants to add more things to this discussion.
>
> Kind regards,
>         Sven

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Friday, 11 September 2020 16:42:52 CEST Alessandro Bolletta wrote:
> I'm sorry for being not so clear in my statements. You can read my
> last "refactored" mail, which is easier to understand:
> 
> Should I must only rely to the related 802.1q interface (eg. bat0.1)

I already fail to parse this first sentence. I will not continue with this 
discussion.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

Hi Alessandro,

to use VLANs in batman-adv, you currently have to explicitly set up VLAN 
interfaces, as it was already explained. You can not just listen to bat0 and 
expected VLAN tagged frames to go through.

This is a limitation of the current code, which basically exists since we 
integrated VLANs into batman-adv. There were some ideas to register VLANs on 
the fly inside of batman-adv, but the current implementation relies on the 
setup of VLANs on top of bat0 provided by the system.

If you want to use those VLANs, you have to set up VLAN interfaces for each 
VLAN ID you want to use. This can get a bit messy if there are many VLANs, but 
it works. You can't just bridge bat0 to something else and expect VLAN tagged 
traffic to come out of bat0.

I can't say anything about OVS and to which extent bridges can be skipped, but 
you'll create VLAN devices in that case too.

We're open to patches to add VLANs on the fly without requiring explicit VLAN 
interfaces (maybe by snooping, similar to TT or BLA). I've also run into this 
scenario a couple of times, but the pain level wasn't high enough to change it 
yet. ;)

Cheers,
       Simon

On Friday, September 11, 2020 4:42:52 PM CEST Alessandro Bolletta wrote:
> Hi Sven,
> 
> I'm sorry for being not so clear in my statements. You can read my
> last "refactored" mail, which is easier to understand:
> 
> Should I must only rely to the related 802.1q interface (eg. bat0.1)
> or can I receive the whole traffic (untagged and tagged) from the
> plain bat0 interface, just listening for the incoming traffic on it?
> 
> If the answer is the first choice, is it possible to have an approach
> where I can receive coming from bat0 leveraging on a single interface
> anyway? Could a linux bridge br0 on the top of bat0 interface make it
> possible?
> 
> For example, if I connect an openvswitch port, configured as trunk port, to
> a linux bridge br0 that enslaves bat0, could I expect to see the whole
> traffic inside the batman-adv mesh network (so I mean, both tagged and
> untagged traffic) also "flowing" inside the other OvS switch ports that are
> attached to that vlans?
> Moreover, just out of curiosity, is there also another known way to
> get rid of the linux bridge br0 in order to get this done (attaching
> the bat0 directly to the OvS switch, for example)?
> 
> Il giorno ven 11 set 2020 alle ore 16:02 Sven Eckelmann
> 
> <sven@narfation.org> ha scritto:
> > On Friday, 11 September 2020 15:03:13 CEST Alessandro Bolletta wrote:
> > > I see. Ok for transmission purposes, but what if I have to receive a
> > > tagged
> > > frame?
> > 
> > It should not have been send to the other node when there is no TT entry
> > for this mac + VID from the receiver.
> > 
> > > Should I only rely to the 8021q interface (eg. bat0.1) or receive the
> > > whole
> > > traffic (untagged and tagged) from the plain bat0 interface?
> > 
> > Hm?
> > 
> > > If this is not feasible, is it possible to handle in someway this?
> > 
> > Hm?
> > 
> > > A linux
> > > bridge on the top of bat0 interface could make it possible?
> > 
> > No, the bridge must also enable the vlan for this bat0 interface.
> > 
> > See also
> > https://www.open-mesh.org/projects/batman-adv/wiki/Faq#BATMAN-Advanced-VLA
> > N-questions
> > 
> > Maybe Antonio wants to add more things to this discussion.
> > 
> > Kind regards,
> > 
> >         Sven


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Passing VID-aware ethernet frames on plain batX interfaces

[Antonio Quartulli]

On 11/09/2020 16:02, Sven Eckelmann wrote:
> Maybe Antonio wants to add more things to this discussion.

I believe you and Simon have already been fairly exhaustive.

batman-adv simply won't forward any VLAN tagged traffic to nodes that
don't have that specific VLAN set up.

That's because batman-adv will instantiate a number of internal data
structures, along with routing logic, only when the VLAN is created.

Regards,

-- 
Antonio Quartulli