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-...
Maybe Antonio wants to add more things to this discussion.
Kind regards, Sven
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-...
Maybe Antonio wants to add more things to this discussion.
Kind regards, Sven
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
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
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,
b.a.t.m.a.n@lists.open-mesh.org