Ich möchte hier anschließen an das Thema VLAN Gluon Config mit dem V2022.1 Release. Ich knüpfe an an das, was @Aiyion.Primehier geschrieben hat.
Mein Szenario ist:
Ich will auf einem ERX alle Ports (eth0-eth4) separat mit untagged VLAN deklarieren, so dass auf jedem Port separat gemesht werden kann.
Der entscheidende Teil von /etc/config/gluon sieht dann so aus:
config interface 'iface_wan_vlan10'
option name 'eth0'
list role 'uplink'
config interface 'iface_lan_vlan20'
option name 'eth1'
list role 'mesh'
config interface 'iface_lan_vlan30'
option name 'eth2'
list role 'mesh'
config interface 'iface_lan_vlan40'
option name 'eth3'
list role 'mesh'
config interface 'iface_lan_vlan41'
option name 'eth3.41'
list role 'client'
config interface 'iface_lan_vlan50'
option name 'eth4'
list role 'mesh'
config interface 'iface_lan_vlan51'
option name 'eth4.51'
list role 'client'
Hier haben wir nun also auf den eth’s1-4 mesh, dazu auf eth3+4 noch eine getaggte VLAN Client IP.
Das Problem: gluon-reconfigure führt nun dazu, dass sämtliche Mesh-Ports in der /etc/config/network in eine Mesh Gruppe geworfen werden. Das sieht im File dann so aus:
config interface 'mesh_other'
option igmp_snooping '0'
list ifname 'eth1'
list ifname 'eth2'
list ifname 'eth3'
list ifname 'eth4'
option index '4'
option vxlan '0'
option proto 'gluon_wired'
option type 'bridge'
Wie man hier sieht, landen die ganzen schönen neuen ungetaggten Mesh-Interfaces nun in einem gemeinsamen Block. Was dazu führt, dass der ERX in diesem Fall innerhalb dieser Gruppe wie ein Switch agiert - und genau das will ich nicht. Der Traffic soll separat bleiben.
Ich finde den neuen Ansatz von /etc/config/gluon im Sinne der Updatefestigkeit grundsätzlich gut. Jetzt fehlt mir nur noch der entscheidende Hinweis, wie ich hier automatisch unterschiedliche mesh_iface_lan_vlan50 Interfaces bauen lassen kann.
Die richtige Lösung wäre ein Image zu bauen welches auf dem aktuellen Stand von v2022.1.x oder master basiert.
Ich weiß nicht warum du da multiple bridges hast welche br-mesh_eth[1-4] hast und nicht eine mit dem Namen br-mesh_other.
Am besten schmeißt du alle anderen Änderungen in network weg. Wie du schon festgestellt hast erledigt das gluon-reconfigure beiläufig.
Und dann kannst du dir die isolation bis zum nächsten gluon-reconfigure (passiert auch bei updates) reinkonfigurieren:
gluon-reconfigure
uci set network.eth1=device
uci set network.eth1.name="eth1"
uci set network.eth1.isolate="1"
uci commit network.eth1
uci set network.eth2=device
uci set network.eth2.name="eth2"
uci set network.eth2.isolate="1"
uci commit network.eth2
uci set network.eth3=device
uci set network.eth3.name="eth3"
uci set network.eth3.isolate="1"
uci commit network.eth3
uci set network.eth4=device
uci set network.eth4.name="eth4"
uci set network.eth4.isolate="1"
uci commit network.eth4
/etc/init.d/network restart
Jedoch ist da irgendwas aktuell noch kaputt und es ist sehr gut möglich das isolation mit dem ER-X nicht oder nicht richtig funktioniert.
Es wäre aber trotzdem hilfreich wenn du das ausprobieren würdest und von deinen Beobachtungen berichten könntest.
Achso und dein VLAN Zeugs brauchst du damit überhaupt nicht mehr. Das kann dann weg. Die Ports sind ja eh in einer bridge aber mit dem isolated flag dann halt voneinander isoliert.
Besten Dank für die Erleuchtung - habe das heute mit mehreren ERXen durchgespielt. Hier meine Erkenntnisse:
Mit den o.g. uci set Befehlen habe ich erfolgreich das Isolation Flag gesetzt bekommen.
Ich habe das Setting auf 3 produktiven Nodes getestet. 2 Nodes mit Mesh-only Links, 1 Node mit WAN und Mesh. Sämtliche Nodes haben das Isolation Flag zwar gesetzt, im tatsächlichen Betrieb aber ignoriert.
„Ignoriert“ heißt, dass die Mesh Partner hinter den aktualisierten Nodes alle übrigen Mesh-Partner des aktualisierten Nodes gesehen haben. Womit sie dann genau das Verhalten gezeigt haben, was unerwünscht ist.
Letztlich habe ich das Problem dann händisch gelöst, indem ich in der /etc/config/network separate Einträge für die Mesh Bridges gemacht habe. Das sieht dann so aus:
config interface 'mesh_eth1'
option igmp_snooping '0'
list ifname 'eth1'
option index '4'
option vxlan '0'
option proto 'gluon_wired'
option type 'bridge'
option macaddr '36:df:55:aa:17:c1'
config interface 'mesh_eth2'
option igmp_snooping '0'
list ifname 'eth2'
option index '4'
option vxlan '0'
option proto 'gluon_wired'
option type 'bridge'
option macaddr '36:df:55:aa:17:c3'
config interface 'mesh_eth3'
option igmp_snooping '0'
list ifname 'eth3'
option index '4'
option vxlan '0'
option proto 'gluon_wired'
option type 'bridge'
option macaddr '36:df:55:aa:17:c5'
config interface 'mesh_eth4'
option igmp_snooping '0'
list ifname 'eth4'
option index '4'
option vxlan '0'
option proto 'gluon_wired'
option type 'bridge'
option macaddr '36:df:55:aa:17:c7'
In diesem Setting ist es dann nicht mehr nötig, die oben genannten uci set Befehle abzusetzen. Die Separation der Ports funktioniert dann auch so. Getestet wurde das Ganze auf der Basis von Gluon2022.1.1.
Nachteil dieser Lösung ist, dass sie nicht updatefest ist. Jedes gluon-reconfigure überbügelt die Datei.
Da ich eine ganze Menge ERXe betreue, bin ich durchaus offen für weitere Experimente. Mein Ziel ist, diese Link Isolation updatefest implementiert zu bekommen. Weitere Ideen dazu sind willkommen.
