Wireless Traffic Unterbrechung, aber kein Log-Eintrag

Hallo,

danke für die Antworten.

"MrNetman
Wenn du die interne Aufzeichnung nutzt - gibt es da Auffälligkeiten im Protokoll (Wireshark L2)
Gibt es Bäume, die gewachsen sind?
Hat es irgend etwas mit dem Wetter zu tun? Regen, Nebel, Uhrzeiten
Ist eine andere Polarisation auch betroffen oder läßt sie sich ändern? Antennen drehen face-sad
Ich kann ja nicht erkennen, ob die lokalen Stationen einen Abgriff haben und überwacht werden. Gibt es Probleme mit der Stromversorgung?"

- Bitte: Was genau verstehst Du unter "interne Aufzeichnung" ? Mit Wireshark habe ich wenig Erfahrung - wenn es da eine Möglichkeit gibt, hier was Genaueres zu protokollieren, bitte beschreibe mir das mal kurz.
- Bäume: Die Standorte der Masten sind immer auf Bergen, die Antennenhöhe ist nochmal ~45m über Boden und selbst wenn da was reinwächst, dann doch nicht auf allen Strecken zugleich. - Also: optisch, Bäume - nein. Per Goo-Earth kann man testen, ob man schon in die Fresnelzone kommt - das habe ich von Anfang an ausgeschlossen. Höhe = Sicherheit.
- Wetter / Regen / Nebel / Uhrzeit: Das schrieb ich z.T. schon - da kann ich eben keinen Zusammenhang herstellen. Es tritt sporadisch auf, auch bei gutem Wetter, was wir hier ehhh meistens haben.
- Ich arbeite mit vertikaler Polarisation. Die zu ändern ist schwierig, weil ich dazu die Direktoren der Antennen drehen müßte. So richtig kann ich das auch schwer nachvollziehen, wenn es 5 Jahre ging.
- Stromversorgung: Das ist hier ein all zu bekanntes Problem, deshalb betreibe ich alle Stationen gepuffert über Auto-Batterien. Aufbau: Stromnetz 230V, alles (auch die Masten) gut geerdet - Spannungskonstanthalter - Ausgang 110V, nochmal geerdet - Kabel nach oben - Sicherungsautomat 110V - Ladegerät für den Akku - Akku - Sicherungsautomat 12V - Akkuwächter gegen Tiefentladung - RBs. Seit 5 Jahren habe ich kein Board wegen Strom-/Gewitterschäden wechseln müssen, zweimal hat es bei Gewitter einen Spannungskonstanthalter getroffen und etwa 6 oder 7 der Ladegeräte habe ich, ebenfalls nach Gewittern, wechseln müssen, aber, wie gesagt, noch kein RB.
Aber "Spitzen" im Netz wären dennoch nicht ausgeschlossen - nur auch dann müßte doch irgendwann mal was in der Log stehen oder es sollte auch mal Stationen außerhalb der "RSTP-Schleife" betreffen.

"kaiand1":
Hmm, die Unterbrechung ist da, auch von "der anderenSeite" gesehen. Kurioserweise eben "nur" im Datenfluß. Deshalb schaltet auch RSTP nicht um. Optische Kontrolle - siehe oben. Es ist ja eben auch nicht nur eine Strecke. Und Bäume mit mehr als 40m Höhe sind auch hier außerhalb vom Urwald eher selten.

"exchange
welche genaue Frequenz fährst Du auf welcher Strecke mit welcher Leistung? DFS an?"

Derzeit: Die 24 Km auf 5260, die 47 Km auf 5240, die 25 Km auf 5320, die 38 Km auf 5220 und die 7 Km auf 5825. Aber ein Wechsel hat keinen Einfluß, außer, daß die Verbindung schlechter wird. Da habe ich schon sehr viel "rumgespielt". Leistung ist "default". DFS Mode ist "none".

"Ggf. Leistung runter und DFS aus (wenn es die Entfernung erlaubt)."

Auch mit dem "TX-Power-Mode" habe ich schon versucht, was zu ändern, aber am Ende bin ich zu dem Resultat gekommen, daß es mit der "default"-Einstellung am stabilsten läuft. Einen Einfluß auf diese misteriösen Ausfälle hatte eine Änderung dort nicht. Die traten trotz "mehr Power" auf.

"Hast Du den Fehler auch, wenn Du eine Strecke absichtlich deaktivierst?"

Ja. Wenn ich eine Strecke in der "Schleife" unterbreche, tritt es dennoch auf. Außerhalb dieser "Schleife" habe ich noch mehrere Strecken, die aber keine Schleifen bilden und dort habe ich das Problem nicht, außer auf der Verbindung zum Gateway, die ja auch nicht in der Schleife liegt. Dort scheint es aber weg zu sein, seit ich gestern Abend die Priorität an die x.x.x.41 gegeben habe. Diese Verbindung hatte seit jetzt 23 Stunden keinen Ausfall mehr.
Bisher lief das Netz am stabilsten, wenn das Board x.x.x.21 die niedrigste RSTP-Priorität hatte. Wenn ich die RSTP-Priorität so ändere, daß eine andere Station (z.B. x.x.x.41 in dem Bild) die niedrigste Priorität hat (also die "Steuerung" übernimmt), wandert der "Ausfall" mit. Je nachdem, welche Station die niedrigste RSTP-Bridge-Priorität hat, wird die Schleife vom System an einer anderen Stelle "unterbrochen", die Ausfälle treten dann auch auf einer anderen Strecke auf, aber sie sind eben da, auch bei absichtlich unterbrochener Schleife. Und sie werden nie gelogt. Im Gegensatz dazu kann ich bei Änderung der Frequenz eine schwächere Verbindung provozieren, dann erscheint das auch mit "extensive data loss" oder "no beacons received" in der Log.

Zu meiner Andeutung "Funkstörung": Der Gateway und die zugehörige Station (x.x.x.11) ist in einer größeren Stadt und da wimmelt es natürlich von Sendern aller Art und leider auch mit Sicherheit nicht nur solchen, die mit der erlaubten Leistung arbeiten. Aber dann sollte (jedenfalls meiner bescheidenen Meinung nach), doch auch nur die Verbindung zwischen dem Gateway-Board (x.x.x.11) und dem ersten "Schleife-Board" (x.x.x.21) betroffen sein. Die anderen Stationen stehen, nach europäischer Vorstellung, eher am Urwaldrand, also noch ziemlich frei von möglichen Störungen.

Viele Grüße

tomue

Hallo,

danke für die Antwort. Zuerst muß ich mich korrigieren - auch auf der Strecke zum Gateway kam es heute früh wieder zu einem kurzen nichtgeloggten Ausfall.

Zu Nebel und Sonne - ja, da hast Du wohl recht, MrNetman. Ich kenne viele HF-Phänomene, auch noch von "ganz früher", vom Amateurfunk und auf Kurzwelle. Und sicher tritt sowas hier auch mal auf, aber dann kann man beobachten, wie die Werte schlechter werden, die Verbindung wegbricht und findet einen Logeintrag dazu. Diese Fehler, um die es mir hier geht, treten wirklich wetter- und zeitunabhängig auf.

"Die Frage nach den Zwischenstationen und deren Monitoring. Man kann die Verbindungen von RF-Device zu RF-Device verbinden und hat damit keine Einfluß oder Zugriff auf diese Verbindung. Das scheint bei dir der Fall zu sein."

Mit diesen Ausführungen kann ich leider nicht viel anfangen. Was meinst Du damit? Ich habe ja Zugriff auf die Boards und die Verbindung. Wenn ein solcher Ausfall auftritt und wie oben beschrieben, "lang genug" bestehen bleibt, kann ich durch kurzes manuelles deaktivieren und wieder aktivieren der betroffenen Wlan die Verbindung sofort dazu bringen, daß sie wieder arbeitet. Oft ist die Unterbrechung aber nicht so lang und fängt sich von selbst schon nach ein paar Sekunden. Und wenn sie länger ist, fängt sie sich auch. Aber immer ohne Logeintrag, ohne erkennbare Ursache.

Zu RSTP und Wireshark:

Über RSTP weiß ich leider auch nur soviel, daß es dazu dienen soll, daß die Datenpakete eindeutig und nicht doppelt oder überlappt an einem Ziel ankommen, wenn es mehrere Wege zu diesem Ziel gibt (Schleifen eben). RSTP soll ja auch automatisch und deutlich schneller als das ältere STP dafür sorgen, daß auf einen anderen Weg umgeschaltet wird, wenn eine Strecke in der Schleife ausfällt. Das klappt ja auch, wenn man eine Strecke bewußt deaktiviert. Wie das aber zusammenhängt mit anderen Protokollen oder z.B. den WDS-Einstellungen, übersteigt meine genaue Kenntnis.
Aber irgendwas muß doch bei meinen jetzigen Einstellungen oder von Außen beeinflußt "schief" laufen mit diesem RSTP. Ich suche ja nun auch ständig weiter und heute habe ich mal folgenden Versuch gemacht:
Wenn ich manuell die Priorität von einem Board zu einem anderen Board umschalte, kann ich im gesamten Netz mit dem Multipingtest kurze Ausfälle in dem Umschaltmoment sehen, wenn also der "Schleifen-Baum" druch die Umschaltung neu aufgebaut wird. Und siehe da - diese kurzen Ausfälle (3 - 5 Sekunden), werden auch an keiner Station (außer der, wo ich umschalte) gelogt. Also scheint das RSTP doch irgendwie die Ursache des Fehlers zu sein. Nun kann ich das in einem provozierten Umschaltmoment ja verstehen und verkraften, wenn aber die gleichen Ausfälle sporadisch im laufenden Betrieb relativ häufig auftreten, dann will ich schon gern die Ursache finden, um was dagegen tun zu können.

So, nun bin ich bei Wireshark. Ich habe damit leider bisher wenig Erfahrungen sammeln können und wie man im Wireshark die Filter setzen muß, damit man eben genau nur dieses RSTP-Zeugs sieht und dort dann auf den Fehler, also die Ursache für die Unterbrechungen, schließen kann, weiß ich leider nicht. Kannst Du oder jemand anderes mir da bitte ein wenig helfen - entweder mit ein paar guten Tipps oder mit einer Stelle im Netz, wo man sich dazu informieren kann? Vor allem habe ich ein paar Bedenken in dem laufenden Netz weitere oder noch größere Ausfälle zu produzieren, weil da ja immer die lieben Kunden dran hängen und die haben wenig Verständnis für wartungsbedingte Ausfälle...

Viele Grüße

tomue

Hallo MrNetman,

danke für die schnellen Antworten und Deine Hilfe.

"Zu Wireshark und RSTP.
Man kann den Verkehr auch auf den Routerboards an einen andern Port kopieren..."

Gut, dann werde ich mir mal raussuchen, wie das geht und es probieren. Das habe ich noch nie gemacht. Der Filter sieht dann ja einfach aus.

Noch eine Frage direkt zu RSTP: Gibt es eine "Empfehlung" oder irgendwelche Hinweise, welches der Boards in einem Netz mit Schleife(n) die niedrigste Priorität für den RSTP-Mode bekommen sollte? Eigentlich sollte es ja egal sein, wenn ohne manuelle Festlegung per default einfach die niedrigste MAC genommen wird. Aber je nachdem, wie ich das festlege, "arbeitet" das Netz ja unterschiedlich und da läßt sich vielleicht auch noch was "optimieren".

Viele Grüße

tomue

Hallo,

wie ich es auch anfange, ich bekomme mit Wireshark bis jetzt keine Auskunft zu dem Problem. Ich weiß auch nicht genau, ob es so überhaupt gehen kann, da sich die Wireshark-Aufzeichnungen ja immer "nur" auf die Verbindung zwischen meinem PC / Laptop und dem Port des RB, mit dem ich verbunden bin, beziehen.
Jedenfalls hat stundenlanges Protokollieren mit dem Capture-Filter STP keine Aufzeichnungen gebracht. Kurze Aussetzer hat es aber in der Zeit gegeben und RSTP läuft ja doch ständig - man sollte meinen, da muß doch mal was zu sehen sein.

Dabei habe ich mich sowohl eine Weile wireless direkt an der am meisten betroffenen Station in das Netz eingelogt, als auch von meinem eigentlichen Zugangspunkt zum Netz.

Entweder also mache ich da was falsch oder es gibt eine andere Ursache für die nicht gelogten Unterbrechnungen.

Viele Grüße

tomue

Hallo,

dann wird das wohl an mir liegen: Spiegeln kann man, so wie ich das verstanden habe, doch nur ether-Ports in einem Switch. Das habe ich aber nicht. Nur auf zwei Stationen läuft der Verkehr überhaupt über Ethernet von einem RB zum anderen, der Rest ist alles Wlan. Und die Ethernets dort sind dann als Port in der jeweiligen Brücke gesetzt. Da die Stationen aber im Betrieb alle hoch oben auf Gittermasten hängen, komme ich an die Ethernet-Ports nicht ran, um den Laptop anzustöpseln.

Auf die Wlan-Ports kann ich mich direkt und "von unten" einklinken. Es ist ja mein Netz und ich kenne meine Schlüssel. Ich brauche meinem Laptop nur eine freie Adresse des Netzes zu geben (ist alles eine Brücke und auf der läuft das RSTP), die Verschlüsselung einzutragen und so kann ich mich an jedem AP einklinken. Wenn ich das mache und bei Wireshark keine Capture-Filter setze, kann ich dort den Verkehr sehen. Setze ich STP als Capture-Filter, kommt nichts.

Viele Grüße

tomue

Danke, MrNetman,

Stichwort Monitoring Modus. Das wollte ich probieren, da will mein Linux irgendwas mit "libpcap" haben. Ist das ein Paket oder was ist das? Ich habe es gestern nicht mehr geschafft, das zum Laufen zu bringen und dann gab es Gewitter, also "Abbruch der Maßnahme".
Kannst Du mir da einen Tipp geben? Ich arbeite mit KDE-Ubuntu.
Wenn die 230 (!) L/m², die es seit gestern geregnet hat, wieder versickert sind, kann ich im Gelände weiter machen.

Viele Grüße

tomue

Tante Edit: Gerade gefunden und installiert - libpcap0.8-dev und libpcap-dev.

Hallo MrNetman,

- Die Zeitverschiebung ist z.Z. 4 Std. zu MEZ. Auf allen RBs läuft ein NTP-Client und sorgt für gleiche Zeiteinstellung. Unter System - Clock habe ich die Time Zone eingestellt, so daß die geloggten Zeitangaben mit der Realität auch übereinstimmen.

- Alle RBs laufen als Bridge im gleichen IP-Bereich. Auf allen Bridges ist RSTP ein. Bei den Bridge-Ports ist dort, wo "dahinter" keine Schleife mehr kommt, "point to point" gesetzt und wo keine Bridge mehr dahinter kommt, ist "edge" gesetzt. Wenn ich diese manuellen Einstellungen nicht mache, also die Ports alle auf "auto" lasse, geht es auch, aber ich las irgendwo, daß man mit dem setzen von edge bzw. p t p unnütze RSTP-Abfragen (also Zeit und Traffic) spart.

- Pro Strecke ist immer nur ein Kanal aktiv, 1 Kanal pro Karte und pro Antenne.

- DFS ist =none. Mir ist hier kein Radar bekannt.

- TPM kenne ich nur vom Begriff her. Auf den RBs bzw. den Wlankarten kann ich da nichts finden.

- Es wird schon ab und zu, bei z.B. ungünstigen Wetterbedingungen, mal ein Ausfall einer Strecke geloggt. Da steht dann auch (bei Wireless debug) die Ursache zu lesen. Meistens no beacons received oder extensive data loss, seltener auch mal unicast key exchange timeout (manchmal beim Wiederverbinden, obwohl ich das schon 100 mal kontrolliert und garantiert richtig gesetzt habe und nach 2 -3 Versuchen geht es dann auch) oder class 2 frame received (6). Das ist meiner Meinung nach bei den Distanzen auch nicht unnormal und genau deshalb habe ich ja diese Schleife aufgebaut, damit ich eben immer einen zweiten Weg habe. Beide zugleich waren auch nach meiner Beobachtung noch nie weg.
Auch die Hotspot-User werden geloggt (sieht man auch auf dem Bild im ersten Beitrag). Nur eben diese eine "Kategorie" nicht und ich finde da bei den möglichen Log-Einstellungen unter System - Logging nichts, was auf die Möglichkeit, STP zu erkennen, hinweist.

Viele Grüße

tomue

Hallo MrNetman,

mal vorweg: Vielen Dank für Deine Hilfe. Ich weiß, das ist ein ekeliger Fehler. Zumal er ja auch nicht ständig vorhanden ist. Manchmal sehe ich es einen ganzen Tag nicht.

Daß ich noch keine STP-Pakete gesehen habe, kann auch an mir liegen. Ich schrieb ja, daß ich mit Wireshark bisher wenig Erfahrung habe. Das Problem ist, daß ich von hier, "am Tisch", offenbar gar nichts sehen kann, da ich hier nicht direkt in das betroffene Netz komme. Und da schrieb irgendwer in den Weiten des Netzes, daß Wireshark dann nur protokolliert, wenn man in diesem Monitor-Mode arbeitet. Und das habe ich noch immer nicht hinbekommen.

Und "draußen" an den Masten, wo ich mich direkt in das Transportnetz einloggen kann, habe ich das Problem, daß ich da einige Kilometer in die "Pampa" fahren muß, was aber wegen Dauerregens seit fast einer Woche grade nicht geht. Aber sobald ich wieder rausfahren kann, werde ich da weiter probieren, erst mal überhaupt was zu fangen. Es ist ja dann auch noch die Frage, ob der Fehler dann gerade mal auftreten wird, wenn ich da zwei - drei Stunden sitze und warte... Aber wenigstens, da hast Du recht, sollte ich ja erst mal überhaupt STP-Pakete sehen.

Mich wundert das ja auch, daß Mikrotik sonst fast jeden Piepser loggt, aber in diesem Fall sehe ich Nichts. Ich gestehe aber auch, daß ich bei der reichen Auswahl an Logging-Möglichkeiten nicht weiß, ob eine davon vielleicht was anzeigen würde. Da bin ich zuwenig Fachmann...

Also - ich melde mich wieder, wenn ich wieder draußen war.

Viele Grüße

tomue

Hallo,

so, der Regen ist vorbei und ich habe die Zeit genutzt, meine Wlan-Karte im Laptop auch unter Linux im 5GHz-Bereich nutzen zu können. Das funktioniert jetzt gut und nun werden die STP-Pakete auch sichtbar.

Leider ist es mir nicht gelungen, hier eine Datei anzuhängen (geht das nicht oder bin ich zu blind?). Man sieht jedenfalls, daß die Bridge des Boards, welche die "RSTP-Steuerung" (also die niedrigste Bridge-Priorität gesetzt) hat, alle 2 Sekunden abfragt, ob es eine Änderung gibt. Wenn ich eine Änderung "provoziere", ist die Antwort bei "Topology Change" dann "Yes".

Allerdings protokolliert Wireshark eben nur das, was an dem (Wlan-)Port passiert, mit dem man gerade verbunden ist. Das hat zur Folge, daß ich nicht nur zur richtigen Zeit (wenn der Fehler mal auftritt), sondern auch am richtigen Ort angemeldet sein muß. Das ist mir bis jetzt noch nicht gelungen. Also - Geduld.

Falls das gelingt, werde ich mich gleich melden. Vielleicht kann mir jemand inzwischen verraten, ob und wie ich hier eine kleine Datei anhängen kann, damit wäre das besser zu erklären, als es zu beschreiben.

Viele Grüße

tomue

Hallo,

jetzt muß ich mich doch melden - mit einer Vermutung, mehr ist es nicht, aber es macht mich stutzig und könnte mit der Sache zusammenhängen.

Heute Mittag trat der gesuchte Fehler plötzlich ganz massiv auf, in der gesamten Schleife. Aussetzer über Aussetzer abwechselnd oder gleichzeitig auf allen Strecken in der Schleife, aber nichts in den Logs. Ich war natürlich gerade nicht draußen, um mich einloggen zu können... Murphy halt.
Erst das manuelle Abschalten einer Verbindung brachte Ruhe ins System.

Nachdem ich eine Weile alles abgesucht habe, fiel mir auf, daß ich auf den Boards unterschiedliche Zeiten hatte. Daraufhin habe ich mir "System / Clock" und die Einstellung des ntp-Clients unter "System / NTP Client" angesehen. Ich verwende auf allen Boards schon immer die beiden Zeitserver der PTB (192.53.103.103 /...104) mit:

system ntp client print
enabled: yes
mode: unicast
primary-ntp: 192.53.103.103
secondary-ntp: 192.53.103.104
dynamic-servers:
status: synchronized

Dem Status nach schien das auch zu funktionieren.
Aber bei "clock" war auf vier Stationen die Zeit eine Stunde weiter und der gmt-offset stand auf -03:00 statt auf -04:00 wie bei den Stationen, wo die Zeit korrekt war. Diesen offset kann man auch nicht einstellen. In der Winbox ist er grau und die Konsole nimmt es auch nicht an.

sys clock print
time: 14:31:57 / 13:32:25
date: mar/28/2014
time-zone-name: America/Asuncion
gmt-offset: -03:00 / -04:00
dst-active: no

Die Boards hatten allerdings noch die 6.7-Version vom ROS. Erst als ich die Aktuelle 6.11 aufgespielt und rebootet habe, hat es wieder gestimmt, also der offset auf -04:00 und die Zeit war korrekt.

Kann sich also unterschiedliche Zeit auf den Boards bei RSTP so auswirken? Ich weiß es nicht. Im Moment ist Ruhe, also keine Aussetzer dieser Art.

Bei der Gelegenheit ist mir noch was aufgefallen – ein „unschöner Schönheitsfehler“ (tolles Wortspiel!).
Da ich aus gegebenem Anlaß dabei bin, alles auf Linux umzustellen, arbeite ich jetzt meistens mit Kubuntu. Die Winbox mit Wine läuft soweit auch gut, bringt aber irgendwie manche Zeichen durcheinander und damit kann man z.B. das Winbox-Menü „System – Clock“ nicht nutzen. Statt „Mar“ für den Monat März steht da „Mär“ und wenn man es richtig schreibt, kommt bei apply oder ok Fehler. Man muß Änderungen in der Konsole machen, da geht es und da ist bei „Print“ auch der Monat richtig geschrieben. Weiß da jemand, wie man dieser Sache abhelfen kann?

Viele Grüße

tomue

Hallo,

gefangen habe ich noch immer nichts, aber natürlich auch anderweitig weiter gesucht und probiert. Zuerst habe ich mir das Wiki zu (R)STP mal übersetzt, damit ich nichts übersehe beim einfachen Lesen. Daraus geht jedenfalls nicht hervor, wo die Rootbridge in einem "RSTP"-Netz sitzen soll. Es ist nach der Theorie egal, da ja, wenn man keine Priorität setzt, die niedrigste MAC genommen wird. Das Netz und RSTP sollten also funktionieren, egal wo die Rootbridge sitzt. Soweit die Theorie.

Wenn ich aber eine Bridge mit einer niedrigeren Priorität als Rootbridge setze und das mit unterschiedlichen Bridges im Netzwerk teste, ändert sich das gesamte Verhalten im Netz erheblich. Auch ist es nicht egal, ob ich nur einer Bridge eine niedrigere Priorität gebe und alle anderen auf dem Standardwert lasse oder ob ich zum Beispiel drei Bridges im Netz abweichend vom Standardwert niedrigere Prioritäten gebe (gemeint ist: Eine mit 5000, eine mit 6000, eine mit 7000 und alle anderen 8000). Auch das wirkt sich im Netz aus.

Am stabilsten, so habe ich festgestellt, läuft es, wenn ich der Bridge x.x.x.21 (siehe Bild im ersten Beitrag) als einziger eine niedrige Priorität gebe. (So hatte ich es auch etwa 5 Jahre lang, allerdings eher zufällig.) Dann kommen die Aussetzer selten, max. 1 - 2 Mal am Tag und kurz, einige Sekunden. Und der Fehler tritt nur rund um diese Bridge auf, nicht im ganzen Netz. Deshalb werden mir diese Aussetzer wohl auch nicht so schnell aufgefallen sein.
Alle anderen Versuche führen zu deutlich mehr und längeren Ausfällen und mehr oder weniger im ganzen Netz - erstaunlicherweise auch außerhalb der Schleife, obwohl die Ports dahin als "point to point" oder "edge" gesetzt sind, also für RSTP eigentlich uninteressant.

Nun habe ich vor einiger Zeit (und ich denke mal, seitdem ist mir dieser Fehler auch aufgefallen) das Board x.x.x.41 gegen ein Leistungsfähigeres ausgetauscht und, weil damit diese Wlan-Strecke bessere Verbindungswerte hatte, dieser Bridge (41) die niedrigste Priorität gegeben. Damit habe ich zwar erreicht, daß vorrangig diese bessere Verbindung als rootpath genommen wurde, aber die oben beschriebenen Fehler traten gehäuft auf.
Ich muß dazu sagen, daß ich auch nur die Ports mit "edge" oder "point to point" konfiguriert, nicht aber die Portprioritäten oder die Pathcosts verändert habe. Genau das werde ich jetzt mal vorsichtig versuchen, um das Netz auf diese Weise dazu zu bringen, den Path zu nehmen, den ich gern hätte und die Bridgepriorität dabei so zu lassen, wie sie jetzt ist.

Kann mir Irgendwer mehr zu RSTP sagen - z.B. wo sollte in einem Netz günstiger weise die Rootbridge sitzen oder warum wirken sich die von mir beschriebenen unterschiedlichen Konfigurationen so aus? Kann es damit zu tun haben, daß ein Wlan-Netz im Allgemeinen weniger stabil ist als ein Ethernet-Kabel-Netz? Da lässt das Wiki mehr oder weniger alles offen und auch sonst sind kaum Beiträge mit Lösungen zum Thema RSTP im Web zu finden.

Viele Grüße

tomue

Hallo aqui und danke für Deine Analyse.

Hmmm, dann muß ich wohl das Projekt, alles auf OSPF umzustellen, was ich seit zwei Jahren in der Schublade liegen habe, doch umsetzen. Ich schiebe das vor mir her, weil ich das ja alles im laufenden Betrieb machen muß und eben leider nicht so sicher bin in diesen Dingen.

Die jetzige Struktur habe ich vor reichlich 5 Jahren mehr oder weniger von einem "Experten" übernommen, nachdem der verschwunden war und mich nebst der Kunden sitzen gelassen hat. Ich habe mir 6 Wochen lang Alles, was zu Mikrotik zu finden war, reingezogen und dann bin ich "gesprungen". Es hat ja auch ganz gut funktioniert.

Und da bin ich bei dem Punkt - auch wenn Du sicher zum größten Teil Recht hast, kann ich mir nicht erklären, wieso es so lange ohne diese eigenartige Störung lief und auch jetzt Stunden, manchmal Tage, ohne Probleme läuft. Ich kann eben keinerlei Zusammenhänge mit solchen Dingen wie erhöhten Traffic oder sich verschlechternde Funkverbindung feststellen. Auch bei besten "Funk-Voraussetzungen" tritt so ein Aussetzer ganz plötzlich auf. Oft dann mehrfach hintereinander, mit nur Minutenabständen. Und nach ein paar Minuten ist es wieder vorbei - für Stunden oder Tage. Eine möglich Erklärung wären Störungen durch Dritte. Der Fehler tritt ja auch nicht im ganzen Netz auf, sondern fast immer nur auf zwei Strecken. Und diese liegen halt in der Nähe zweier großer Städte, weil ich nur dort die Zugänge zur Glasfaser kaufen kann. Möglich wäre also, daß dort die Störungen durch Verstärker etc. zugenommen haben und dann genau der von Dir beschriebene Vorgang einsetzt. Wieder eigenartig dabei: Die am häufigsten betroffene Strecke liegt gar nicht in der Schleife, an dem "Ende" dieser Strecke läuft auf dem Mikrotik auch keine Brücke, also auch kein RSTP. Da läuft nur eine Wlan und die PPPoE-Einwahl.

Natürlich läuft RSTP sonst auf allen Brücken, das schrieb ich ja. Das Problem ist, im Fehlerfall an der richtigen Stelle und zur richtigen Zeit zu sein, um mit Wireshark etwas zu fangen, woraus man dann vielleicht auf die Ursache schließen kann. Aber es ist echt so, daß diese Aussetzer nicht in der Log erscheinen. Das sieht man ja auch ganz gut in den Bildern im ersten Beitrag hier von mir. Auch in der Winbox unter "Wireless - Interfaces" bleibt die Verbindung auf "Running", nur Daten gehen keine durch. Ein kurzer Klick auf das blaue "Enable-Häkchen" genügt und sofort ist die Verbindung wieder o.k. Also alles recht dubios.

Du bist Dir also sicher, daß ich derartige Fehler nicht mehr haben werde, wenn ich das Netz auf dynamisches Routing (OSPF) umstelle? Ich habe mich damit vor einiger Zeit mal beschäftigt. Da gibt es von Meconet ganz gute Unterlagen im Netz und ich habe auch schon mal einen Routingplan erstellt. Ich werde das mit vier RBs hier im Garten aufbauen und sehen, ob ich das hin bekomme. Und dann hoffe ich einfach, daß sich das Netz ohne Probleme und vor allem ohne lange Ausfälle für die Kunden umstellen läßt...

Jedenfalls nochmal Danke für Deine Hilfe und viele Grüße vom Urwaldrand

tomue

Hallo aqui,

"Du benutzt für die weiten Strecken 2,4 Ghz was auch schon ein großer Fehler in sich ist. Normalerweise macht man sowas im ungestörten 5 Ghz Bereich ! ..."

Dann hast Du aber meinen ersten Beitrag nicht richtig gelesen und auch die Antwort an "exchange" nicht, der das schon hinterfragt hatte. Ich bin zwar kein Netzwerkexperte, aber in HF-Bereich habe ich wenigstens 40 Jahre Erfahrung. Also - das ganze Backbonenetz läuft natürlich im 5 GHz-Bereich (siehe am Anfang meiner Anfrage). Aber auch der 5 GHz-Bereich ist in Stadtnähe hier nicht sooo ungestört. Es gibt zwar wohl ein Gesetz hier, was die max. Sendeleistung festlegt, aber es gibt kaum jemanden, der sich dran hält und noch weniger, die es kontrollieren oder durchsetzen...

"Ganz sicher!"

Dann werde ich das also angehen - vielleicht ergeben sich ja Fragen, dann wende ich mich wieder ans Forum und hoffe auf Hilfe.

Vielen Dank an Dich und alle Anderen!

tomue

Hallo und danke, ihr beiden.

MrNetman:

Das wären Optionen, wenn auch mit Aufwand verbunden. Aber den nehme ich dann halt in Kauf, wenn ich sicher weiß, es liegt daran, es sind Störungen und ich bekomme dann spürbare Verbesserungen. Wird also vorgemerkt.

aqui:

5GHz und Radar - ja, ich weiß, aber alles Gute ist eben nie beisammen. Nur: Mir ist kein Radar in unmittelbarer Nähe bekannt, deshalb ist DFS=none gesetzt. Der Flugplatz von Posadas (die größere Stadt hier) liegt noch ein ganzes Stück außerhalb und nicht direkt in meinen "Funkrichtungen". Außerdem gibt es den schon länger, nicht erst jetzt und somit hätte der von Anfang an stören müssen, oder? Eine andere Radarquellen kann ich natürlich nicht ausschließen. Aber Militär haben wir hier in der Nähe nach meiner Kenntnis nicht und wer verwendet das noch? Haben Fluß-Schiffe sowas? Hier fahren ab und zu ein paar alte Lastkähne auf dem Fluß.

Gleich noch zwei Fragen dazu: Wenn es Radar wäre - wirkt sich das denn bei dynamischem Routing dann nicht genau so aus? Das ist doch HF und keine Netzwerkfrage. Und: Ich verstehe nicht richtig, wo ich DFS dann einschalten muß (AP-Bridge-Seite oder Station-Bridge-Seite oder beide Seiten), damit es funktioniert. Das Wiki und die Beiträge im Netz dazu sagen da nicht viel oder sind widersprüchlich. Wenn bei "DFS ein und Radar tritt auf" die Frequenz gewechselt werden soll, dann muß das doch auf beiden Seiten der Funkstrecke zugleich und auf die gleiche neue Frequenz geschehen. Wie das aber gehen soll, habe ich aus den paar Beiträgen, die ich eben dazu gelesen habe, nicht verstehen können.

Viele Grüße und frohe Ostern!

tomue

Hallo,

danke für Eure Hilfe. Ich habe mir die Theorie zu Radar und DFS durchgearbeitet. Wenn ich das richtig verstanden habe, kann ich da mit den Mikrotik-RBs nichts ausrichten, wenn DFS nur auf der AP-Seite Wirkung zeigt, oder wie muß man das konfigurieren, damit der "Ausweich" funktioniert? Aber Radar wäre natürlich eine mögliche Erklärung, woher die Aussetzer kommen. Es kann auch sein, daß das Nachbarland Argentinien militärisch im weiteren Umfeld aktiv ist (wir sind hier direkt an der Grenze), das weiß halt ich nicht. Hier ist da eher nichts los, die haben kein Geld für teures Militär.

Eine "Regulierungsbehörde" in deutschem Sinn gibt es hier eher nicht. Es gibt eine staatliche Einrichtung, wo ich auch die Lizenz bekommen habe und an die ich für die WLAN-Nutzung eine Gebühr abführen muß. Die Fachkenntnis und Hilfe durch diese Leute ist allerdings mehr als fraglich und ich möchte da eigentlich nicht hingehen. Ich kenne den "Ingenero" in unserer Distrikthauptstadt - der muß bei jeder Frage in der Hauptstadt anrufen und bisher habe ich auch von da noch nie eine befriedigende Antwort auf irgendwas bekommen, nicht mal in Bezug auf deren eigene Formulare und Rechnungen... Der Gute hat zwar ein bissel Technik da in seinem Büro stehen, aber den Spektrum-Analysator, den er hat (ein 35.000 US$-Gerät) nutzt er zum Radiohören... Ergo muß ich mir also selber helfen.

Zu den Frequenzen gibt es hier keine Zuweisungen. Ich bin da in der Auswahl nur abhängig von der optimalen Funktion. Aber wenn es sich wirklich um Radarstörungen handelt, dann ist auch klar, warum ich selbst mit verschiedenen Frequenzen keine Erfolge habe. Ich habe alle von 5180 bis 5825 durchprobiert, manche laufen stabiler, andere weniger, aber die Aussetzer sind immer wieder da.

Das Meconet-Konzept kenne ich, das habe ich auch. Da gibt es noch mehr in der Richtung und daher habe ich auch die Idee, mein Netz um zu bauen. Nur getraut habe ich mich bis jetzt nicht. Aber ich werde das jetzt ernsthaft in Angriff nehmen, um wenigstens die Auswirkungen dieser Unterbrechungen zu minimieren. Die Vorteile, die aqui da nennt, sind schon bestechend.

Viele Grüße

tomue

Hallo nochmal,

für die Umstellung (ospf / mpls / vpls) werde ich bei Fragen, die sicher kommen, ein neues Thema aufmachen. Ich habe schon mit dem Testaufbau begonnen.

Ich würde aber trotzdem gern noch mal auf den Anfang dieses Beitrags zurück kommen. Ich habe die Schleife in meinem Netz jetzt unterbrochen und auf allen Boards im Netz in allen Bridges RSTP deaktiviert (Protokoll=none). Und was soll ich sagen - diese Aussetzer, die in der Log nicht erscheinen, kommen immer noch. Also hat es mit RSTP auch nichts zu tun.
Ich habe unter System - Logging bereits ein paar Möglichkeiten mehr eingetragen, ohne Ergebnis. Mit "wireless - debug" werden alle "changes" gelogt, auch Aussetzer mit "no beacons received" oder "class 2 frame received (6)" treten mal auf, stehen aber dann auch in der Log.

Was aber kann das sein, genau das, was ich am Beginn dieses Beitrags beschrieben habe? Wenn diese Aussetzer durch Störungen irgend welcher Art verursacht werden - wieso zu Teufel finde ich keinen Log-Eintrag? Die Verbindung bleibt auf "Running", Signalstärke und Signal-Rausch-Abstand sind unverändert, aber es geht nichts durch. Was übersehe ich da, wo liegt der Fehler?

Ich hoffe ja, daß nach der Umstellung dieses Problem erledigt ist, aber es interessiert mich schon, was das ist. Zumal ich mir auch sicher bin, diese Aussetzer erst seit relativ kurzer Zeit zu haben, denn das wäre mir in den letzten 5 Jahren sicher eher schon mal aufgefallen.

Bitte lest nochmal den Eröffnungsbeitrag mit den Bildern. Ich kann dem nichts Neues hinzufügen, als was da schon beschrieben ist. Und wenn noch jemand eine Idee hat, bitte melden und sei es nur, um etwas zu lernen.

Viele Grüße

tomue

Hallo und danke für Eure Hilfe und Anteilnahme.


Ja, das ist schon alles klar. Mir geht es nur noch darum raus zu kriegen, warum diese (wenigen) Aussetzer dann nicht in der Logliste erscheinen. Das ist das Rätsel. Egal, was die Ursache ist (und das ist sicher ein HF-Problem, da habt Ihr ohne Zweifel recht), es gibt keinen Eintrag in der Log, während es sonst, für "andere Aussetzer", immer einen gibt.
Die Auswirkung hoffe ich ja dann mit dem neuen Konzept minimieren zu können, zur Not eben auch zusätzlich mit aufwändigeren HF-Verbindungen.


Und dafür meinen ganz herzlichen Dank, besonders Euch beiden.

Ich weiß jetzt nicht recht, ob ich dieses Thema beenden sollte. Für die fehlenden Logs habe ich keine Antwort, für mögliche Ursachen einige und für die Minimierung der Auswirkungen habe ich viele Anregungen. Eine weitere Diskussion zu Ursachen wird nichts bringen, die führen wir lieber in dem neuen Beitrag zur Umstellung des Netzes. Dort kann ich evtl. dann auch die Vorschläge von aqui noch anwenden, wenn die Aussetzer dann immer noch stören.

Wenn es also keine Antworten mehr gibt zu den fehlenden Log-Einträgen, überlasse ich es dem Admin, den Beitrag eben als "teilgelöst" zu setzen, falls es das gibt

Viele Grüße

tomue

Hallo aqui,

hast recht, ich werde das Problem mal an Mikrotik senden. Vielleicht bekomme ich da noch eine Antwort.

Den Beitrag werde ich dann nach einer Antwort von Mikrotik beenden. Wenn die antworten, stelle ich das noch rein.

Vielen Dank für die Hilfe.

Viele Grüße

tomue

Hallo noch mal,

hier nun der Schluß zum Beitrag:

Mikrotik hat tatsächlich den entscheidenden Tipp gehabt. Neben solchen Ratschlägen wie andere Funkkarten, von ROS 11 auf ROS 12 wechseln oder aes / tkip mal austauschen, kam auch der Vorschlag, es mit dem


zu versuchen. Und das isses! Nicht nur, daß keine ungeloggten Ausfälle mehr auftreten, es treten gar keine sichtbaren Aussetzer mehr auf. Dieses Protokoll arbeitet stabil und sicher. Ich habe es jetzt auf allen PtoP-Strecken seit zwei Tagen laufen und keinerlei Probleme mehr.
Da ich nur Mikrotiks verwende, ist die Kompatibilität ja auch kein Problem.

Wenn ich das nun richtig sehe, handelte es sich also nicht um Störungen, sondern um ROS-interne Probleme. Ab einem der neueren ROS (leider weiß ich eben nicht mehr genau, seit wann die Fehler auftraten), scheint da irgend etwas geändert worden zu sein, denn ich hatte die Fehler definitiv vor 7 - 8 Monaten noch nicht.

Also - Problem gelöst. Aber nichts desto trotz bin ich dabei, die Umstellung auf dynamisches Routing umzusetzen.

Nochmal vielen Dank allen, die mir hier geholfen haben.

Viele Grüße

tomue