tomue58
Goto Top

Wireless Traffic Unterbrechung, aber kein Log-Eintrag

Hallo,

ich habe hier einen merkwürdigen Fehler: Seit einiger Zeit gibt es alle paar Stunden (manchmal öfter, manchmal seltener) in drei meiner Wireless-Verbindungen Aussetzer unterschiedlicher Länge (mal ein paar Sekunden, aber auch schon mal bis zu einer Minute), die trotz gesetztem "Wireless Debug" überhaupt nicht in der Log erscheinen. In der Winbox geht auch das "R" für "running" nicht weg, aber es gibt in der Zeit keinen Datendurchsatz und auch das anpingen ist nicht möglich. Ich habe keinen Zusammenhang mit einer bestimmten Uhrzeit oder mit dem Traffic feststellen können. Auch die Verbindungsfeldstärke ändert sich im Fehlerfall nicht.

In den Bildern sieht man das ganz gut – der Multipingtest

8da64f0a773bf299216538ad5fcedd05
zeigt die Aussetzer (16.06 und 16.34 Uhr) und zeitgleich ist in der Log

dc2f6521415f87a08bc842b772fb7ddb
nichts zu sehen, außer, daß die bestehenden Userverbindungen nicht arbeiten (Radius ... no responde).

In einem weiteren Bild

f50d20d61424ed0fb43f6317f2713392
habe ich das Netz mal skizziert. Die roten Linien sind die betroffenen Wireless-Verbindungen.

Das ROS wird immer aktuell gehalten (derzeit 6.10). Alle RBs hängen in einer Brücke mit festen Adressen (x.x.x.yy).
Funkkarten sind CM9 von Atheros. Antennen sind Grids mit 24 dB. Die Frequenzen liegen im 5GHz-Bereich. Die weiteste Verbindung liegt zwischen 74 und 79 dBm, Signal to Noise um die 20 dB (siehe auch die wlan1 im Bild winbox, das ist die station-bridge der 47 km - Verbindung).
Protocol-Mode in den Brücken ist RSTP. Anfangs hatte ich noch wds (dyn.) genutzt, aber das lief ganz instabil. Jetzt nutze ich diese mikrotikeigene Variante AP-Bridge / Station-Bridge.

Ich probiere und suche schon eine ganze Weile, aber ich komme nicht weiter. Ich habe die Security Profiles geändert (keine Sonderzeichen mehr drin), ein Tipp in irgendeinem Beitrag war, die Periodic Calibration ganz abzuschalten (das habe ich mich nicht getraut, ich habe sie nur auf enable mit einem Zeitintervall von 30 Min. gesetzt), habe aus Verzweiflung das ganze Board (x.x.x.21) neu gekauft und ausgetauscht, habe die Priority der Brücken verändert, habe in die Connect-List der Station-Bridge-Seiten die MAC der Gegenseite eingetragen und Default Authenticate ausgeschaltet, manuell die Bridge-Port-Settings auf Edge oder Point-To-Point gesetzt – alles umsonst.
Ich konnte beim suchen im Netz auch keinen solchen Fehler finden, nur endlose ungelöste Diskussionen über „no beacons received“ oder „group key ... timeouts“. Auch im Mikrotik-Wiki und dem Forum-Beitrag von normis http://forum.mikrotik.com/viewtopic.php?f=7&t=13748
steht darüber nichts.

Ich weiß auch leider nicht so ganz genau, seit wann dieser Fehler auftritt, ob es mit einem Update zu tun hat oder von Außen kommt (Funkstörung?). Jedenfalls läuft das Netz in dieser Form seit etwa 5 Jahren, aber dieser Fehler ist erst seit ein paar Wochen da.

So – jetzt habe ich wohl erst mal alles versucht zu erklären und zu beschreiben und hoffentlich nichts Wichtiges vergessen. Wenn noch wichtige Infos fehlen – bitte schreiben.

Und schon mal vorab vielen Dank für Hilfe!

Viele Grüße

tomue

Content-Key: 232115

Url: https://administrator.de/contentid/232115

Ausgedruckt am: 28.03.2024 um 15:03 Uhr

Mitglied: MrNetman
MrNetman 09.03.2014 um 03:41:22 Uhr
Goto Top
Zitat von @tomue58:
Ich weiß auch leider nicht so ganz genau, seit wann dieser Fehler auftritt, ob es mit einem Update zu tun hat oder von Außen kommt (Funkstörung?). Jedenfalls läuft das Netz in dieser Form seit etwa 5 Jahren, aber dieser Fehler ist erst seit ein paar Wochen da.
Das ist allerdings eine schwierige Situation, aber auch äußerst schwer ohne externe Messmittel nachzuzeichnen.

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?

Gruß
Netman
Mitglied: kaiand1
kaiand1 09.03.2014 um 14:15:00 Uhr
Goto Top
Moin
Nun ich weiß nicht von wo du nach wo Pingst und was genau wegfällt.
Hast du mal hinter jeden Wlan Access Point ein Extra PC abgestellt der nur den Wlan Access point auf seiner Seite per Ping prüft?
Du stellst eine Unterbrechung da ja fest weiß du jedoch von welcher Seite die genau kommt?
Hast du auch mal die STrecke Optisch kontroliert auf veränderungen jeglicher Art?
Mitglied: exchange
exchange 09.03.2014 um 16:31:47 Uhr
Goto Top
Hallo,
welche genaue Frequenz fährst Du auf welcher Strecke mit welcher Leistung? DFS an?
Ggf. Leistung runter und DFS aus (wenn es die Entfernung erlaubt).

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

Gruß
Mitglied: tomue58
tomue58 10.03.2014 um 00:40:25 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 10.03.2014 um 09:18:38 Uhr
Goto Top
Die Funktfeldbeschreibungen sind leidlich ok und selbst profesionelle Funksysteme sind nicht anders aufgebaut und laufen nicht mit höheren Leistungen,
Warum ich nach Nebel und Sonne frage? Die Kombination kann tödlich sein. Selbst bei vollkommen freien Fresnellzoen, oder gerade bei einer super freien Fresnellzone kann der aufsteigende Nebel ein Funktfeld ablenken.

Nach deinen Ausführungen würde ich auf eine aktive Funktion von RSTP, Rapid Spanning Tree, tippen.
Da kann ich aber nicht weiter helfen.

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.
Wegen Wireshark.
Mittels des Abgreifens des Datenverkehrs kann man Informationen zum benutzen Verkehr erhalten. Da man so eine Aufzeichnung auch mittels Filtern machen kann, kann man den Nutzverkehr draußen lassen und z.B: nur den RSTP-Verkehr betrachten, der eigentlich in einem Log eingetragen sein müsste.

Gruß
Netman
Mitglied: tomue58
tomue58 10.03.2014 um 23:19:38 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 11.03.2014 um 00:06:26 Uhr
Goto Top
Zu Wireshark und RSTP.
Man kann den Verkehr auch auf den Routerboards an einen andern Port kopieren und hat somit Zugriff auf die Daten.
Zum Filter, da du ja sehr lange aufzeichnen musst, ist es unnötig den Nutzverkehr zu protokollieren. Du willst nur sehen, was alles im RST abläuft. Das Filter dazu ist recht einfach: STP siehe http://wiki.wireshark.org/STP

Wireshark resourcen gibt es sehr viele. Übung gehört trotzdem dazu. Für dich ist ja nur wichtig zu sehen,und das kannst du vorher durch deine oben erwähnten Test checken, ob es einen ursächlichen, zeitlichen Zusammenhang zwischen Ausfall und Aufbau des RSTP Baumes gibt.
oder als video: http://www.youtube.com/watch?v=yltiEqPQXJI

zu den Zwischenstationen.
Wenn die beiden APs nur mit den Ethernet-Schnittstellen verbunden werden, nenn ich das Back to Back. Es ist praktisch kein Abgriff nötig oder möglich, da kein Kabel abgeht und auch kein Strom für ein weiteres Gerät zur Verfügung steht. Aslo eine typische Situation für eine Repeater-Station.

Gruß
Netman
Mitglied: tomue58
tomue58 11.03.2014 um 12:06:33 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 11.03.2014 um 13:44:44 Uhr
Goto Top
Ja, es gibt Möglichkeiten RSTP zu konfigurieren. Aber da kann ich nicht weiter helfen.

http://wiki.mikrotik.com/wiki/Manual:IP/Traffic_Flow Netflow für Dauermonitoring aller Applikationen aber auf einem externen Server/Datenbank
http://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features und hier unter dem Stichwort Port Mirroring

Gruß
Netman
Mitglied: tomue58
tomue58 18.03.2014 um 01:15:18 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 18.03.2014 um 08:20:18 Uhr
Goto Top
Siehst du ohne Filter etwas, wenn du nach der Anleitung den Port spiegelst?
Ungespiegelte Ports am Mikrotik zeigen logischerweise nichts.
Und STP läuft auch nur auf den Interfaces, auf denen es konfiguriert wird. Es muss ja lokal ausgewertet werden.

Wie kannst du mit dem Wireshark wireless mitschneiden wenn du eine saubere Verschlüsselung hast?
Und auch Wireless müssen die STP Protokolle zu sehen sein, sie gehen ja da rüber, ist ja der einzige Weg.
Wireles bei der betroffenen Station einloggen erfordert miondestens zwei Kanäle zu monitoren, da ja zwei Funkstrecken dran sind.
Wenigstens alternativ. Und auch dort müssten STP Protokolle auftauchen.

Gruß
Netman
Mitglied: tomue58
tomue58 18.03.2014 um 23:41:33 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 19.03.2014 um 09:13:24 Uhr
Goto Top
Zur Übersicht und zum Verständnis gibt es in wireshark auch eine Kommunikationsstatistik.
Diese kann man auf Layer2 und auf Layer3 nutzen und man kann eine Statistik der Protokolle sehen. Das reduziert den Aufwand einen Trace durchzusehen enorm.
Wenn die WLAN-Verbindungen über ein Transportnetz laufen, dann kann man den zu beobachtenden Verkehr sehr leicht eingrenzen.
Für eine etwas längere Aufzeichnung könntest du dann die aufgezeichnete Paketlänge reduzieren um die Datenmenge zu reduzieren. Fürs Erste würde sogar ein Monitoring Modus ohne Aufzeichnung genügen um zu sehen was so läuft.
Der RSTP muss ja zu erkennen sein, wenn er funktionieren soll. Und er muss aktiv sein, sonst ginge die Konfiguration mit den Alternativwegen ja kaum.

Bei statischen Keys kann man je nach Verschlüsselung auch an der Luft hören.

Ich drück dir die Daumen.
Netman
Mitglied: tomue58
tomue58 19.03.2014 aktualisiert um 21:39:15 Uhr
Goto Top
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.
Mitglied: MrNetman
MrNetman 19.03.2014 um 23:49:26 Uhr
Goto Top
Ja, das ist der Unterbau, den Wireshark für Linux braucht.
Unter Windows ist es winpcap.

Wie viele Stunden Zeitverschiebung hast du zu MEZ (= UTC+1 Stunde)

Ich muss noch etwas weiter fragen.
Du verwendest Mini-PCI-Karten CM9 mit einer Antenne für 5GHz
Die RB Router auf den Relaystationen werden im selben Netz betrieben oder laufen die mit einer andern IP?
Oder laufen die als Switch/Bridge mit RSTP im selben IP-Range?
Hast du mehrere RF-Kanäle pro Strecke aktiv? 1 Kanal pro Karte 4 Kanäle pro Antenne oder so.
Werden diese über getrennte Bridges versorgt? Oder über VLANs?

Im Mikrotik wiki (http://wiki.mikrotik.com/wiki/Manual:Interface/Bridge) wird auch auf die Wikipedia-Seite verlinkt: http://wiki.mikrotik.com/wiki/Manual:Interface/Bridge

Egal, der Fehler tritt ja erst seit ein paar Wochen auf.
Also muss ja STP zu erkennen sein.

Aber auch eine Frage von @exchange sollte beantwortet werden.
Arbeitest du mit DFS und TPM? wie es Vorschrift ist.
Hast du beantwortet: beides aus.
Die Gründe für DFS und TPM kennst du:
  • DFS: Ausweichen bei Störungen von z.B: Radar.
  • TPM wird inklusive der Antennen berechnet. Bei deinen Entfernungen wirst du das wohl gut genutzt haben. Dafür braucht es nur eine 15dB Antenne.

DFS ist natürlich eine Art Worst Case in so einem Szenario. Der Kanal wird durch äußere Einflüsse geändert.
Loggen die Karten den irgendwelche Daten?

Gruß
Netman
Mitglied: tomue58
tomue58 20.03.2014 um 18:01:42 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 21.03.2014 aktualisiert um 09:25:49 Uhr
Goto Top
Dann komme ich von hier auch nicht weiter. Evtl. hat @aqui eine Idee, Er kennt die Mikrotiks sehr gut.
Mein Schwerpunkt sind eher die Funkstrecken mit allen Ausbreitungsparametern und den Widrigkeiten im realen Wetterumfeld.
Was mich immer noch wundert ist, dass du keine STP-Pakete im wireshark (LAN oder WLAN) erkennen kannst.

lg Netman
Mitglied: tomue58
tomue58 21.03.2014 um 11:19:20 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 21.03.2014 um 12:55:22 Uhr
Goto Top
Zu dem berühmten Wireshark Modus.
Ist heute nicht mehr so wichtig.
Das nennt sich Promiscuous Mode.
Das ist im WLAN kaum möglich. Im LAN auch nur sinnvoll, wenn man zum Monitoren noch Hubs hat. Diese verteilen wirklich alle Arten von Paketen und auch defekte. Die Switches und Router tun dies aber nicht. Da reicht der normale Modus der NIC vollkommen aus. Die sieht dann schon genug.
Dass du ausserhalb deines Netzes die STP Pakete nicht sehen kannst, ist logisch, die werden ja nicht geroutet und in Internet verteilt.

Dann wünsch ich dir etwas weniger Regen und viel Grlück bei der Fehelrsuche.
P.S: gestern waren es hier übe 20 Grad bei toller Sonne.Heute nicht mehr, aber man kann raus gehen.

Gruß
Netman
Mitglied: tomue58
tomue58 27.03.2014 um 22:17:35 Uhr
Goto Top
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
Mitglied: tomue58
tomue58 28.03.2014 um 23:18:08 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 29.03.2014 um 09:05:16 Uhr
Goto Top
Kann es.
Auch im Wireshark habe ich schon mein blaues Wunder erlebt, wenn die Zweitzonen oder Zeiten nicht korrekt gewesen sind. Solange man allein ist, stört das kaum, aber bei Systemen, die zeitsynchronisiert arbeiten und betrachtet werden ist das von Bedeutung, selbst wenn es für Menschen gleich wäre.
also 14 Uhr Sommerzeit ist 13 Uhr ohne Offset.

Zu Wine kann ich wenig sagen, habe immer noch dominant Windows von MS in alen Varianten.

Sieht aber gut für dich aus.

Gruß
Netman
Mitglied: tomue58
tomue58 08.04.2014 um 02:20:54 Uhr
Goto Top
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
Mitglied: aqui
aqui 15.04.2014 aktualisiert um 11:11:19 Uhr
Goto Top
Kollege Netman hat recht. Es muss ja irgendeine Art von Spanning Tree laufen in dem Netzwerk ?!
So wie es hier jetzt aussieht betreibst du den "Würfel" ja als Bridged Netzwerk in einer gemeinsamen Layer 2 Domain und hättest hier aus Ethernet Sicht ja ohne STP einen Loop gebaut was nicht sein dürfte.
Folglich MUSS hier zwingend ein Spanning Tree Protokoll zum Einsatz kommen was das verhindert und einen Port in den Blocking Mode versetzt je nachdem WO die Root Bridge ist ?!
Das Problem ist hier das es, wenn es zu kurzzeitigen Ausfällen der anderen Links kommt zu einem STP Recalculation Prozess und einem Topology Change Event kommt. Alle Bridges flushen daraufhin ihre Mac Tables und es kommt zu einem Ausfall des Netzes.
Ein normaler Prozess der in einem flachen L2 LAN mit STP ja nicht weiter auffällt aber in einem Bridged WLAN mit redizierter Bandbreite diese Ausfälle erzeugen kann. Gerade auf Ringstrukturen die besonders anfällig für sowas sind da es dann unnatürlich hohe Recovering Zeiten im STP gibt.
Ein Grund warum man im Ethernet Umfeld L2 Ringstrukturen wenn irgend möglich unter jeden Umständen vermeiden sollte und hier immer routen sollte ! Jeder Provider ist hier Vorbild.

Das zeigt auch schon den generellen Design Fehler in diesem Netz !
Niemals hätte man eine redundante "Ring" Kopplung so in ein gemeinsames Bridged Netz nehmen dürfen. Kein kundiger Netzwerker macht das so !
Sinnvoll wäre hier gewesen die Funkstecken des "Würfels" oben als geroutete P2P Netze auszulegen und ein dynamische Routing darüber zu realisieren.
Das hätte 2 gravierende Vorteile gehabt:
  • 1.) Der gesamte Broad- und Multicast Traffic der die Funkstecken bei L2 Bridging grundbelastet bei der limitierten Bandbreite wäre verschwunden, was zur Performancesteigerung (Durchsatz) sehr hilfreich wäre.
  • 2.) Durch das Routing entfällt komplett der (Rapid) Spanning Tree und damit auch Port Blocking und Topology Changes. Alle Links wären permanent aktiv und das dyn. Routing sorgt dafür das bei kurzzeitigem Ausfall durch Wetter bedingte Störungen usw. sofort dynamisch ein anderer Link verwendet wird. Endgeräte würden das gar nicht merken.
Zusätzlich macht z..B. OSPF ECMP, also ein Load Balancing über parallele Links, was so bei RSTP technisch gar nicht möglich wäre. Das Netzwerk wäre also merklich Störungs unempfindlicher und die Links würden besser ausgenutzt.

Fazit: So mit diesem eigentlich falschen, weil flachen L2 Netzwerk Design, sind diese Störungen vorprogrammiert und auch aus Netzwerksicht völlig normal.
Das zeigt auch deine RSTP Root Bridge Prio Settings, die verständlicherweise daran nichts ändern können.
Das ganze Design krankt vollständig daran das es ein reines L2 Bridging Netzwerk ist und das noch in der für Ethernet sehr ungünstigen Ring Struktur. Genau das ist das grundlegende Problem und schafft diese Fehler.
In einem WLAN als Backbone über solche Entfernungen ist das immer ein NoGo. Das würde man nichtmal so mit drahtbasierten Verbindungen machen, denn bei sowas gilt immer der goldene Netzwerk Grundsatz: "Route where you can, bridge where you must" ! Kein Provider baut ein Backbone mit einem L2 Design wie hier. Gerade nicht mit einem Mikrotik der ja schon per se ein Router ist, also prädestiniert für solche L3 Designs.
Vermutlich musst du also damit dann leben wenn du nicht das Design verändern willst.
Um genau zu sehen WAS im RSTP das auslöst müsste man in der Tat mal den Wireshark bemühen. Es sollte aber auch im MT Log stehen, denn dort sollten RSTP Topology Changes eigentlich geloggt werden.
Mitglied: tomue58
tomue58 19.04.2014 um 02:20:23 Uhr
Goto Top
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
Mitglied: aqui
aqui 19.04.2014 aktualisiert um 12:40:39 Uhr
Goto Top
das Projekt, alles auf OSPF umzustellen, was ich seit zwei Jahren in der Schublade liegen habe, doch umsetzen
Das wäre von Anfang an das richtige Konzept gewesen. Was du jetzt gemacht hast ist einen Sackgasse wie du ja jetzt schmerzlich erfahren musst.
Du baust ja quasi ein Backbone auf und da ist Routing auf den Point to Point Teilstrecken immer ein Muss ! Nimm dir ein Beispiel an allen Providern die das ebenso machen. Wenn du unsicher bist nimm dir jemanden an die Hand der weiss was er da macht, obwohl das bei deinem banalen Szenario recht einfach ist und man mit 1 oder 2 Stunden Downtime schnell umgesetzt bekommt.
on einem "Experten" übernommen
Sorry, aber jemand der sowas macht ist mitnichten ein "Experte". Bastler würde es eher treffen !
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.
Das ist hier Tagesgeschäft im Forum. 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 !
Beim überlasteten 2,4 Ghz tummeln sich zudem noch Nachbar WLANs, drahtlose Kopfhörer, Mäuse und Tastaturen, Bluetooth, Babyphones, Mikrowellnherde, Video Sender usw. usw.
Also vielleicht hat einer der Nachbarn sich eine neue Mikrowelle gekauft und immer wenn der seine Suppe warmmacht dann passiert das halt. Oder andere Funkteilnehmer die dein Spektrum überlagern und stören. Klingt zum Lachen...ist aber so. Du überwachst das 2,4 Ghz Spektrum ja nicht, denn sonst könntest du es sehen und ganz sicher erklären. 2,4 Ghz liegt zudem im Absorptionsspektrum von Wasserdampf, deshalb ist dieses band terrestrisch von geringer wirtschaftlicher Relevanz. Also auch Witterungsbedingungen wie Nebel, Regen usw. haben massiven Einfluss auf deine Linkstabilität und gerade wegen deiner doch erheblichen Entfernungen die schon an der Machbarkeitsgrenze mit legaler WLAN Sende. bzw. Strahlungsleistung liegen ! Vergiss das nicht....du hast es hier mit HF zu tun. Für völlige Störungsfreiheit must du ein Glasfaser verbuddeln
Auf 2,4 Ghz wird es also eher schlimmer als besser. Ein Grund auf 5 Ghz Strecken auszuweichen zumal du dort auch größere HF Strahlungsleistungen verwenden kannst.
Und diese liegen halt in der Nähe zweier großer Städte
Spricht massiv für Störungen durch andere Dienste oder WLAN Netze im 2,4 Ghz Bereich !
Aber es ist echt so, daß diese Aussetzer nicht in der Log erscheinen.
Das muss es auch nicht, denn ein RSTP Topology Change ist ja quasi ein gewollter Vorgang in einem STP Umfeld. Nicht alle Komponenten loggen sowas mit oder nur dann wenn man den Log Level entsprechend erhöht. Du siehst das dann nur am Wechsel der Mac Adressen in der L2 Forwarding Database.
Du bist Dir also sicher, daß ich derartige Fehler nicht mehr haben werde, wenn ich das Netz auf dynamisches Routing (OSPF) umstelle?
Ganz sicher !
Das ist allgemein üblicher Standard. Ausserdem hast du statt Ausfall dann einen sub second Failover auf die redundanten Links. D.h. auch wenn ein Link ausfällt merkt es keiner durch die L3 Redundanz !
Hilfe für dein Testsetup gibts ja auch hier face-wink
In Grundlagen in diesem Tutorial:
Mit einem WLAN zwei LAN IP Netzwerke verbinden
Mitglied: tomue58
tomue58 19.04.2014 um 15:10:09 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 19.04.2014 um 15:23:07 Uhr
Goto Top
Da kommen wieder meine Stärken.
Antennen mit doppelter Polarisation für den Betrieb als n- mit 2 Antennen oder gar besser, die beiden Radios arbeiten auf unterschiedlichen Polarisationen und mit unterschiedlichen Frequenzen. Gegen externe Störungen ist Frequenzdiversity etwas besser geschützt. Aber auch die andere Polarisationsebene kann helfen.

Ich drücke dir die Daumen.
Gruß Netman
Mitglied: aqui
aqui 19.04.2014 aktualisiert um 16:17:26 Uhr
Goto Top
ganze Backbonenetz läuft natürlich im 5 GHz-Bereich
Sorry, überlesen. Ich nehme alles zurück und behaupte das Gegenteil... face-smile
Aber auch der 5 GHz-Bereich ist in Stadtnähe hier nicht sooo ungestört.
Bei 40 Jahren Erfahrung weisst du natürlich auch das bei 5 Ghz WLAN nur Sekundärnutzer ist. Primärnutzer ist militärisches Flugradar und Wetteradar. Deshalb sind alles APs zwangsweise mit DFS ausgestattet. Erkennen die einen solches Radarsignal wird sofort die Frequenz gewechselt was dann zwangsweise auch einen Abbruch der Verbindung für eine kurze Zeit zur Folge hat !
...- -.-- --... ...--
Mitglied: tomue58
tomue58 19.04.2014 um 22:54:05 Uhr
Goto Top
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
Mitglied: aqui
aqui 21.04.2014 um 09:45:40 Uhr
Goto Top
Mir ist kein Radar in unmittelbarer Nähe bekannt
Militärisches Radar (z.B. Flugabwehr) ist fast immer mobil...
Und ja das wirkt sich bei Routing natürlich genauso aus. Es betrifft ja immer den HF Link direkt. Welche Netzwerk Mechanismen ob im L2 oder L3 darauf laufen ist davon erstmal völlig unerheblich. Da hast du Recht.
Allerdings ist es hier ein himmelweiter Unterschied ob du nun L2 Redudanzmechanismen (STP) oder Routing verwendest. Beim Routing sind alle deine Pfade aktiv beim STP eben nicht.
Wird im Routing ein Link gestört geht der Traffic gleich über den parallelen (z.B. bei OSPF). Bei STP unterbricht vollständig die Verbindung. Dann statet STP einen neuen Learning Prozess und wenn der durch ist geht der Port erst wieder in Forwarding.
Das Ergenbnis also was im netz passiert ist fundamental unterschiedlich.
DFS ist gesetztlich fest vorgeschrieben und muss man nicht aktivieren. Es ist fest in der Firmware enthalten udn darf deshalb nicht manipulierbar sein in so fern hast du keine Möglichkeit das zu beeinflussen.
Beim Frequenzwechsel schaltet der betroffene AP den Sender ab und macht einen Scan auf einen radarfreien Kanal, bleibt da einen Moment um zu sehen obs wirklich frie ist und aktiviert dann wieder sienen Sender mit der SSID und BSSID Beacon. Der Client auf der anderen Seite scannt nach dieser SSID oder BSSID und sowie die wiederin der Luft ist assoziiert er sich mit der BSSID.
DFS geht immer einher mit automatische Anpassung der Leistung: Transmit Power Control (TPC) und sind im Standard 802.11h definiert !
Hier hast du weitergehende Infoas:
http://www.elliottlabs.com/documents/dynamic_frequency_selection_combin ...
http://www.wlan-skynet.de/docs/wlan-standards/ieee80211h.shtml
Am besten beschreibt es der IEEE Standard 802.11h direkt mit dem es definiert ist:
Mitglied: exchange
exchange 21.04.2014 um 21:24:39 Uhr
Goto Top
Hallo,
versorgst Du mit deiner Technik andere Leute mit einem Internetzugang sog. WISP (Wireless Internet Service Provider)? Wenn ja, darfst Du dich an die Regulierungsbehörde wenden und das 5,8 GHz Band nutzen. Dort muss ein Zettel ausgefüllt werden und Du bekommst den Kanal für deine Dienste zugewiesen. Stichwort ist hier: Broadband Fixed Wireless Access - BFWA
Offiziell hättest Du dich da eh dran wenden müssen, wenn Du Grundstücksübergreifend sendest aber das kontrolliert kein Mensch.

Lese Dir doch mal das folgende Dokument durch: http://www.meconet.de/cms/upload/public_dl/meconet/meconet_WISP-Konzept ...

Radar ist nicht gleich Radar. Die mobilen Dinger (AWACS) reichen beispielsweise weit über die 400km Grenze. Die normalen Luftraumradargeräte stehen an Flughäfen und reichen irgendwas um die 100km weit. Bei DFS wird nach speziellen Mustern gesucht und das funktioniert auch nicht immer zuverlässig.

Der DFS Schalter funktioniert bei MikroTik nur im AP mode. In verschiedenen Frequenzen darf darauf verzichtet werden.
Auf TPC kann auch verzichtet werden, wenn die Sendeleistung um 3 dBm verringert wird.
Mitglied: tomue58
tomue58 22.04.2014 um 01:12:28 Uhr
Goto Top
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
Mitglied: tomue58
tomue58 27.04.2014 um 04:47:48 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 27.04.2014 um 09:28:36 Uhr
Goto Top
Hi Tomue,

Dass du Aussetzer haben kannst ist dir ja bewusst.
Dass die Aussetzer mit Witterungs- / Umwelteinflüssen zu tun haben können auch.
Dass Aussetzer auch durch Störungen anderer Dienste oder Geräte passieren können ist auch klar.

Das kannst du nur durch Mehrfachkonzepte verringern.
Den mehrfachen Pfad hast du umgesetzt.
Bleiben noch Mehrfachfrequenzen über weitere Antennen.

Wobei wir, und jetzt auch @aqui, helfen wollen ist die Realisierung eines kurzen Umschaltweges, der deine vorhandenen physikalischen Probleme minimiert.

Das ist ja auch ein Grund warum hier, in Deutschland, eine Regulierungsbehörde die Hand über Verbindungen hat, die öffentliche Flächen überstrahlen. Es gibt eben Einflüsse, die man sonst nicht sieht.
Aufwändige WLAN-Systeme haben noch diverse Monitoringfunktionen auf der HF-Ebene integriert um solche Probleme erkennen zu können. Aber das benötigt pro Funktion einen Empfänger und eine Antenne.

Viel Glück
Netman

P.S.: Ich musste schon eine Strecke in Betrieb nehmen, wo die Störungen von einem über 200km entfernten Sender gekommen sind. Damals konnte ich diesen Sender für die Beweisführung kurz abschalten lassen. Es waren ja nur etwa 1000 Telefonate drauf face-wink
Andere Störungen waren üblicherweise durch ein sauberes Design und saubere Verarbeitung zu minimieren.
Mitglied: aqui
aqui 27.04.2014 um 16:01:01 Uhr
Goto Top
Ausgeblendet bekommt man das meist mit stärker bündelnden Antennen, die natürlich auch umliegende Störung über die HF stark Dämpfen und das Nutzsignal erhöhen.
Man müsste mit einem Nagios oder einen ganz einfachen SNMP Tracker wie snmp-tg mal den RSSI Wert über einen längeren Zeitraum von ein paar Tagen loggen. Dort kann man sehen wie die Feldstärken sich verhalten und ob Feldstärke Einbrücke mit den Ausfällen korrelieren.
http://leonidvm.chat.ru
Mitglied: tomue58
tomue58 04.05.2014 um 22:53:15 Uhr
Goto Top
Hallo und danke für Eure Hilfe und Anteilnahme.

Dass du Aussetzer haben kannst ist dir ja bewusst.
Dass die Aussetzer mit Witterungs- / Umwelteinflüssen zu tun haben können auch.
Dass Aussetzer auch durch Störungen anderer Dienste oder Geräte passieren können ist auch klar.

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.

Wobei wir, und jetzt auch @aqui, helfen wollen ist die Realisierung eines kurzen Umschaltweges, der deine vorhandenen physikalischen
Probleme minimiert.

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 face-plain

Viele Grüße

tomue
Mitglied: aqui
aqui 05.05.2014 aktualisiert um 09:14:06 Uhr
Goto Top
warum diese (wenigen) Aussetzer dann nicht in der Logliste erscheinen.
Das kommt immer darauf an WIE die Firmware "Aussetzer" definiert !! Ob dort z.B. 3 Sekunden oder mindestens 10 Sek. ein Carrier Loss vorgefallen sein muss um eine Syslog Message auszulösen... Das ist wie gesagt Firmware. Da hilft sicher der Hersteller direkt weiter.

überlasse ich es dem Admin, den Beitrag eben als "teilgelöst" zu setzen, falls es das gibt face-plain
Nein. das gibt es hier im Forum nicht ! DU bist für deinen Thread hier verantwortlich ob du den schliessen willst oder nicht ! Ein Admin kann ja schwer deine Gedanken dazu lesen um dann für dich zu entscheoden, oder ?! Wäre ja auch unlogisch... face-wink
Mitglied: tomue58
tomue58 05.05.2014 um 18:04:01 Uhr
Goto Top
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
Mitglied: tomue58
tomue58 21.05.2014 aktualisiert um 03:42:25 Uhr
Goto Top
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

Wireless Protocol nv2

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
Mitglied: MrNetman
MrNetman 21.05.2014 um 08:36:32 Uhr
Goto Top
Wow,

das hebt die Firma ja schon auf das Niveau eines profesionellen Equipment Manufacturers.
Aber bei gut designten Strecken benötigt man natürlich das kompatible WLAN Protokoll nicht wirklich, da man ja nicht Rücksicht auf die vielen Nutzer auf dem Weg nehmen muss. Als Nebeneffekt dürfte die Nettobandbreite hoch gehen.

Glückwunsch dir und auch Mikrotik aus Lettland. Qualität und Ideen aus Europa.

Netman