MikroTik EoIP-Tunnel

Warum ? Gibt es dafür einen Grund. Das erzeugt unsinnigerweise überflüssigen Overhead und geht auf Kosten der Link Performance !
Warum machst du hie rnicht einfach stinknormales Routing wie es üblicherweise gemacht wird und sinnvoll ist ?
Igitt....
Eigentlich kinderleicht mit einem dynamischen Routing Protokoll oder etwas Spanning Tree Anpassung
Ideal wäre es wenn du A, B und C im Dreieck oder irgendwie anders verbinden würdest egal ob Draht oder drahtlos.
Dann Routing aktivierst zwischen den 3 Standortnetzen per OSPF, fertig.
Damit hast du dann ein automatische Failover mit einer 3 Sek. Unterbrechung. Schneller würde es nur noch mit RSTP (Spanning Tree) gehen aber das wäre doof weil Layer 2.
Mit OSPF kannst du alle Links aktiv nutzen und musst nix frickeln.
Ansonsten gilt was Kollege nachfrage oben schon gesagt hat...
Es ist vollkommen unverständlich und wirr WAS für ein Redundanz Konzept du verfolgst. Einfach nur einen parallele Backup Link zw. B und C was dann einen irgendwie gearteten 2ten Link erfordert und RSTP auf den Switches.
Oder eben sinnigerweise auf L3 Basis mit einem dynamsichen Routing Protokoll wie RIPv2 oder OSPF.
Das sind ja die 2 grundlegenden Optionen die du hast. Nur welche willst du umsetzen ??

Das merkt man leider schmerzlich überall am Design des ganzen Netzwerkes. Du hast den typischen Laienfehler begangen und ein flaches Netzwerk über alle 3 Gebäude gezogen und das auch gleich noch für diverse VLANs.
Damit ist dann jegliches dynamische Backup via Layer 3 (dyn. Routing etc.) von vorn herein tot.
Vom negativen Einfluss das der gesamte Broad- und Multicast Traffic aller deiner Netze die Gebäudelinks massiv belasten mal gar nicht zu reden.
Bei Funk Links die größere Netzwerke oder Gebäude verbinden gilt immer die goldenen Netzwerker Regel: "Route where you can, bridge where you must !"
OK, als Laie kannst du die natürlich nicht kennen...
Übel ist das deshalb insbesondere für den WLAN Link, denn der hat eine sehr eingeschränkte Bandbreite. Durch den EoIP Overhead wird die nochmals geringer.
Keine guten Anfangvoraussetzungen also und langfristig solltest du mal über ein IP Redesign nachdenken.
Fazit:
Es bleiben dir nur noch Layer 2 Redundanztechniken und damit sind wir dann final bei Spanning Tree.

Eigentlich hast du das ideal und sehr richtig gemacht mit deinem beiden P2P Links und unterschiedlichen IP Netzen auf den Links. Genau so würde man es machen mit einem dynamischen L3 Link und das würde wunderbar klappen.
Wenn da nicht der Kardinalsfehler der übergreifenden Layer 2 Domains wäre sprich deiner übergreifenden IP Netze.
Du kannst das so laufen lassen MUSST aber zwingend RSTP auf allen Switches einschlaten im gesamten Netzwerk.
Das wird dann dazu fürhren das einer deiner EoIP Tunnel in den Blocking Mode geht am Switch, quasi also nur nutzlos rumdümpelt und die ganze Zeit wartet das der andere Link ausfällt.
Du siehst...kein gutes Design.
Die Lösung ist dann aber einfach:
Alles was Switch heisst und ist muss RSTP machen bzw. aktiviert haben (Rapid Spanning Tree)
Die gruseligen HPs können nur ein single Span Verfahren, du musst also sicherstellen das alle non HP Switches auch single Span RSTP machen, was in der Regel aber der Fall ist.
Dort wo dein Internet Zugang und zentral NAS, Server SatIP usw. ist solltest du den Root Switch definieren Das geht indem du die RSTP Priority hochsetzt in 4096er Schritten. Beim HP mit dem globalen Kommando:
spanning-tree rstp priority 4096
Mit dem Kommando show spann kannst du dir dann die Topologie ansehen und checken ob der Port der den 2ten WLAN Link hält in den Blocking Mode geht...sollte er.
Dem Nachbar Switch solltest du eine zweithöhere Priority geben 8192 den Rest der Switches im Netz solltest du auf der Default Priority (32768) laufen lassen.
Das wars.
Nicht gut aber so wird es in deinem Umfeld funktionieren.

Und du willst dann die Bonding Links über das WLAN übertragen ???
Vergiss das. 802.3ad Bonding mit LACP macht keine Laufzeit Recovery. Der Standard sieht das nicht vor. Es werden Sessions nach einen Hashing Verfahren (Mac oder IP Adresse) auf die Bonding Links verteilt.
Tödlich für dich ist aber die unterschiedliche Laufzeit auf dem WLAN mit seinen dynamischen Connectraten.
Das tödliche hier ist das die APs zwar an dem Switch connecten und dem ein Kabel vorgaukeln der reine Funklink aber eine dynamische Bandbreite hat die der Bonding Prozess nicht erkennen kann. Das kommt dann zu sehr hohen Packet Drops und Session Abbrüchen auf solchen Links...also gleich vergessen.
In der Theorie hast du Recht mit der Nutzung der beiden Links aber mit der Praxis nicht. 802.3ad Bonding erzwingt eine identische und konstante Bandbreite auf beiden Seiten, ist also fixiert auf Kabel und Glasfaser.
Hier findest du ein paar Details dazu:
Cisco LAG-LACP an Synology RS3614xs+ Bonding Bandbreite zu niedrig
Mit Kabel ja mit WLAN oder gemischt Kabel WLAN niemals. Sowas ist nicht supportet. Theorie ja, Praxis NEIN...nicht supportet.

Schade ist vielleicht der falsche Kommentar Bei deinem Design bleibt nicht mehr viel. Da ist dann Spanning Tree der einzige Weg das zu machen. Nicht das Optimum wird aber das machen was es soll.

Der Knackpunkt ist dein falsches oder sagen wir mal nicht optimales Netzwerk Design. Es wäre besser gewesen du hättest bei der Anforderung die Gebäude in separate Netze segmentiert wie es generell üblich ist bei sowas.
Dann hätte man mit OSPF ECMP arbeiten können auf den MTs was dir eine gleichzeitige Nutzung der beiden Links plus Failover Option beschert hätte.
Es wäre auch noch denkbar das du das in deinem Setup umsetzt. Dazu musst du die MTs aber auf beiden Seiten in separate Netze segmentieren, aktivierst dann OSPF und gut iss.
Um identische IP Netze in allen Gebüden zu betreiben bist du dann aber zwingend auch IP Layer 2 Tunneltechnologien angewiesen. EoIP oder die VPLS Funktion beim Mikrotik können das beide.
Der MT ist in dieser Beziehung ja ein wahrer Tausendsassa.
Realisierbar ist das mit einer kleinen Designänderung aber die Frage ist ob dir der immense Aufwand das zu konfigurieren im Verhältnis steht.
RSTP ist da dümmer weil ein Link quasi tot bleibt für den Ausfall aber der Konfig Aufwand für die andere Option ist schon aufwändiger sofern du dein obiges Design partout weiter behalten willst.

Nein das war vielleicht missverständlich, sorry.
Wenn du rein routest zw. den Gebäuden dann ist das alles kein Thema, dann arbeitest du am besten mit dynamischen Routen und ECMP. Irgendeine Art von Tunneling ist dann natürlich nicht erforderlich.
Die Problematik besteht nur wenn du geroutete Links zwischen den Gebäuden etablierst aber innerhalb der Gebäude identische IP Segmente betreibst die gebäudeübergreifend ein Layer2 Netzwerk darstellen.
Dann musst du logischerweise mit Tunneltechnologien arbeiten (EoIP, VPLS usw.) um über die gerouteten Verbindungen mit einem Layer2 Tunnel diese Netze wieder zusammenzubringen.
Tunneln gilt also nur bei Netzgleichheit (Layer 2 Collision Domain) über die Gebäude hinweg also das was du derzeit hast.
Das Blöde hier iat aber auch wenn du wieder 2 parallel Tunnel hast dann verhält sich das aus Layer 2 Sicht wieder wie 2 parallele Kabel und damit hast du dann ein Loop wo dann schon wieder Spanning Tree RSTP in Erscheinung tritt und einen Tunnel blockt.
Wie gesagt..Layer 2 ist die Pest Gebäude übergreifend....
Wie war das noch gleich mit der goldenen Netzwerker Regel: "Route where you can, bridge where you must...!"