Assuming MTU is great enough (1528 right? 1500+24 batman-adv+4 VLAN), can the bat0 interface act as trunk for VLANs?
2 Nodes: bat0: eth1
bridge0: eth0|bat0
device connected to node1-eth0 tags vlan20, does that traverse the bat0 mesh and come out node2-eth0 with tag in-tact? Does it traverse node1-eth0 at all?
I have another post on how to manage PtP radios in-line a batman-adv link, wondering if I can configure them to a management VLAN bat0-eth0 native vlan bat1-eth0.10 <- radio interface vlan10 ...
and if so, how does that effect the possibility of trunking VLANs across bat0.
in theory, bat0 fully encapsulates packets entering node1-eth0 so the VLAN is invisible 'outside' batman-adv encapsulation so bat-eth0.10 should work, but I just don't know how batman-adv handles VLANs...
thanks
On Mittwoch, 8. Februar 2017 16:40:38 CET dan wrote:
Assuming MTU is great enough (1528 right? 1500+24 batman-adv+4 VLAN), can the bat0 interface act as trunk for VLANs?
2 Nodes: bat0: eth1
bridge0: eth0|bat0
device connected to node1-eth0 tags vlan20, does that traverse the bat0 mesh and come out node2-eth0 with tag in-tact? Does it traverse node1-eth0 at all?
Afaik, the VLANs not on configured on batX will be rejected since TT was made VLAN aware [1]. I think Simon and Antonio can clarify this.
Kind regard, Sven
[1] https://git.open-mesh.org/batman-adv.git/blob/HEAD:/net/batman-adv/translati...
On Thu, Feb 09, 2017 at 08:33:13AM +0100, Sven Eckelmann wrote:
On Mittwoch, 8. Februar 2017 16:40:38 CET dan wrote:
Assuming MTU is great enough (1528 right? 1500+24 batman-adv+4 VLAN), can the bat0 interface act as trunk for VLANs?
2 Nodes: bat0: eth1
bridge0: eth0|bat0
device connected to node1-eth0 tags vlan20, does that traverse the bat0 mesh and come out node2-eth0 with tag in-tact? Does it traverse node1-eth0 at all?
Afaik, the VLANs not on configured on batX will be rejected since TT was made VLAN aware [1]. I think Simon and Antonio can clarify this.
I agree with Sven. The Translation Table (TT) component should complain by printing the message that you can see in the link.
This happens because TT needs to know about all the VLANs in order to learn the MAC addresses of the clients.
However, TT gets to know a new VLAN only when this is actually created (i.e. by creating bat0.X).
The solution would be to create a VLAN on top of bat0 (i.e. bat0.20) and let the tagging happen at the node.
Cheers,
On Thursday, February 9, 2017 3:44:17 PM CET Antonio Quartulli wrote:
On Thu, Feb 09, 2017 at 08:33:13AM +0100, Sven Eckelmann wrote:
On Mittwoch, 8. Februar 2017 16:40:38 CET dan wrote:
Assuming MTU is great enough (1528 right? 1500+24 batman-adv+4 VLAN), can the bat0 interface act as trunk for VLANs?
2 Nodes: bat0: eth1
bridge0: eth0|bat0
device connected to node1-eth0 tags vlan20, does that traverse the bat0 mesh and come out node2-eth0 with tag in-tact? Does it traverse node1-eth0 at all?
Afaik, the VLANs not on configured on batX will be rejected since TT was made VLAN aware [1]. I think Simon and Antonio can clarify this.
I agree with Sven. The Translation Table (TT) component should complain by printing the message that you can see in the link.
This happens because TT needs to know about all the VLANs in order to learn the MAC addresses of the clients.
However, TT gets to know a new VLAN only when this is actually created (i.e. by creating bat0.X).
The solution would be to create a VLAN on top of bat0 (i.e. bat0.20) and let the tagging happen at the node.
To be a bit more precise, do something like this on each node:
vconfig add bat0 20 vconfig add eth0 20 brctl addbr bridge-vlan20 brctl addif bat0.20 brctl addif eth0.20
repeat those steps for other VLANs you want to use.
We are aware that this is not "proper trunking" - I would think it would be better to let batman-adv automatically detect and handle VLANs in the TT code. But this isn't done currently, so you need to cope with this workaround.
Cheers, Simon
b.a.t.m.a.n@lists.open-mesh.org
-
Antonio Quartulli -
dan -
Simon Wunderlich -
Sven Eckelmann