Seperate mesh-on-LAN links

[MPW1412]

Hello,

in the very typical setup of three routers connected over mesh-on-lan like this

A <--LAN--> B <--LAN-->C

Batman sees only one hop between A and C instead of two, because the packages are switched directly in the build in switch of router B and don't go through the CPU and Batman there.

I want to suggest to change this behavior. Although there might be advantages in this configuration in special situations, it generally distorts the topology of the network and leads to ”all routers see all routers over one hop“ in bigger setups, that are connected over lan.

The behavior of Linux software bridges can be altered by this ebtables command (typically used in L2TP gateway setups, where all vpn interfaces are connected through one bridge):

ebtables -A FORWARD --logical-in $IFACE -j DROP

This forces all packages to cycle through the CPU and by so through batman. So the topology of cable-connected networks would be correctly represented in Batman.

I would like to start a discussion about weather this is possible for the hardware switches to disable the direct switching and weather we might want to make this the standard behavior in Gluon?

One drawback would definitely be, that if A is the uplink router, the speed available at C, might be slower than with the bridged setup, because the packages have to go through the CPU at B aswell. (CPU+Batman switching is generally slower than hardware based switching.)

Regards, Matthias

[neocturne]

Another argument in favour of this proposal:

• The hardware switches of cheap nodes don't speak STP, so a switch loop would currently break the network.

Another argument for keeping the current behaviour:

• Gluon doesn't touch the switch configuration at all at the moment. Separating the LAN ports introduces hardware-specific configuration I'd like to avoid for now.

We have plans to encapsulate wired mesh traffic in VXLANs (and I'm working on patches for that); I'd like to defer this discussion at least until we have sorted that out.

[Adorfer]

it would be a very usefule enhancement for situations like

And even if it sacrifices performance in some aspects, i would tolerate that for a "cleaner" network structure, reflecting the real physical links.

[jplitza]

We experimented with gathering neighbor information from LLDP instead of batman-adv, which would combine the "real" network topology with keeping the switching behavior (which I would strongly favor, as it is far more performant and resilient). In the end, you are apparently arguing about the ways of displaying information, not about network topology. So gather the right information and display it adequately instead of changing the topology.

Also, if you connect nodes to a common switch, you will still get full meshes, regardless of this change.

[Adorfer]

and this is the reason why I do not want to connect large number of nodes via layers switches. If you look at it just from visual perspective (or consider others to do that): that's wrong. this is about OGM on 100TX.

[MPW1412]

Thanks for your comment, @NeoRaider. I didn't know, you were working on that.

@jplitza, this is not just about displaying a network. The topology is wrong. If two routers arent connected directly, Batman should be able to make a distinction.

@all, does someone know, how I can set this input separating rule temporarily? Maybe reboot but not update persistent? It's probably a command for the build in hardware switch

[jplitza]

The topology is wrong. If two routers arent connected directly, Batman should be able to make a distinction.

To make it clear, we are talking about two different kinds of topologies here:

• Layer 2 topology: What ethernet cable goes where? Or: What device in between does switching based on MAC addresses? This is what LLDP would provide, and what you apparently want to be able to see on the map. But at this level, switches are involved, and they aren't running Gluon and thus don't provide the info we need to fully gather this topology.
• Batman topology: What device speaks batman-adv with which other device? That's what we currently have, and the only layer where we can reasonably assume that most devices participating are running Gluon and thus cooperating in our information gathering.

does someone know, how I can set this input separating rule temporarily? Maybe reboot but not update persistent? It's probably a command for the build in hardware switch

What exactly do you mean? The ebtables rule can persist updates if you put it in /lib/gluon/ebtables/, the separate VLANs per port are a bit more difficult and are configured in /etc/config/network

[Adorfer]

@jplitza "To make it clear, we are talking about two different kinds of topologies here:"

anway, the "display of topology" is a point you brought up here. I am not shure if this is the point of this issue. (nevertheless it's worth discussing it)

My point would just be: I want at least an option to separate the ports of the "yellow switch" on batman level. (and i do not care about represenation in some kind of map, i just want it separated on batman-adv layer in order to reduce ogm load on the ethernet-l2 and to avoild risk of loops.)

[jplitza]

@Adorfer I interpreted your screenshot as "this looks ugly". I do not care about display.

[Adorfer]

@jplitza "I interpreted your screenshot as "this looks ugly". I do not care about display." Why do you then interpret the screenshot on optical aspects, if you tell me, you would not care about display? And why do you keeping ranting about meshviewer/hopglass display on an issue with a totally different topic? (and in plus not a primary scope of gluon anyway) What is your point?

[MPW1412]

As VXLAN is in Gluon Master now as question to the people who have worked on its implementation: Does VXLAN support the seeked behavior of this issue, @NeoRaider?

[lemoer]

@NeoRaider had a new idea during the Gluon meeting 2022-02: We could maybe use the hairpin mode on gluons bridges to implement this.

(I think this would require DSA.)

[belzebub40k]

I don't know if this is meant with hairpinning as the term is somewhat new to me but I think it pushed me in the right direction to find a solution that should be easy to implement for devices with DSA. As the switch is now a simple bridge with each port being a separate interface we can set the isolation mark on those ports. I tries this on an ERX-SFP and it seems to work. The two nodes connected to it were able to see each other until it set the isolation mark on their ports on the ERX-SFP.

root@dsa-node:~# bridge link set dev eth3 isolated on
root@dsa-node:~# bridge link set dev eth4 isolated on
root@dsa-node:~# batctl n
[B.A.T.M.A.N. adv 2021.1-openwrt-8, MainIF/MAC: primary0/ae:39:f5:de:99:8b (bat0/44:d9:e7:f5:e9:4d BATMAN_IV)]
IF             Neighbor              last-seen
     mesh-vpn	  02:20:0a:56:40:a1    6.848s
   vx_mesh_other	  32:94:eb:56:bf:a8    0.324s
   vx_mesh_other	  42:65:02:1b:55:68    5.092s

root@test-node1:~# batctl n
[B.A.T.M.A.N. adv 2021.1-openwrt-8, MainIF/MAC: primary0/32:94:eb:56:bf:ab (bat0/18:a6:f7:6e:16:20 BATMAN_IV)]
IF             Neighbor              last-seen
   vx_mesh_uplink	  ae:39:f5:de:99:8c    2.332s

root@test-node2:~# batctl n
[B.A.T.M.A.N. adv 2021.1-openwrt-8, MainIF/MAC: primary0/42:65:02:1b:55:6b (bat0/f0:9f:c2:f5:96:e4 BATMAN_IV)]
IF             Neighbor              last-seen
   vx_mesh_uplink	  ae:39:f5:de:99:8c    5.088s

[neocturne]

Hairpinning is a different feature. The feature we mentioned in the meetup was port isolation.

It's good to know that this works as expected with VXLAN.