Wireshark oder Paket Sniffer - FRAGE
Ein gesundes Hallo an die Runde,
ich hoffe das Euch allen (+ Familien) gut geht und man weiterhin gesund bleibt!
Für die jenigen von Euch, die es doch erwischt hat wünsche ich "Gute Besserung" !
Nun zu meiner kleinen Frage :
Das Problem sieht wie folgt aus :
Diesen massiven Verlust habe ich, seit dem ich 4 x PTP-Links (Mikrosoft Wire Dish) als Ersatz für überlastete 5Ghz/AC D/T ins Spiel gebracht habe.
Ohne 60GHz - Anbindung hatte ich diesen "PPPOE-Verfall" nicht ! Dort (TimeOut) stand dann bei mehr als doppelter Request - Paket-Anzahl eine 13 !
Nun würde ich gern mir die Pakete anzeigen lassen bzw. aufzeichnen und auswerten, welche dieses Probleme aufzeigen und wo sie her kommen!
Hat einer eine Idee welche Pakete das sind? Ist es ein Session-Problem oder sind es die Anfragen … also Discovery ?
Oder sind es gar bestehen PPPOE-Tunnel und das Problem findet sich an der lokalen Bridge (127.0.0.1)
Info RADIUS-Server:
- 1x CCR1036 - Mikrotik/ mit Userman (480 aktive PPPOE-Profile)
- eine Bridge mit einem PPPOE-Server ; Bridge-Ports sind 12x PTP-Link-Interfacen mit eigenen Subnetzen
- keine Filter auf Bridge
- keine NAT (User bekommen dynamisch externe IPs/v4 über ein Profil)
- CPU-Last 25-35% bei 700MBit/s (sonst 9-15% bei 200MBit/s)
Ich konnte bis dato (Paket-Sniffer) leider nichts Verwertbares finden .
Kurze Info zur PTP-Anbindung :
Die alten 5GHz-Links haben die Liegenschaften über MPLS bzw. VPLS (WLAN to WLAN) versorgt.
Bei den Wire Disch von Mikrotik gab es mit gleichen VPLS-Tunneln massive Problem. Es wurden viele Pakete nicht gelabelt.
Warum weis ich bis heute nicht ! Ich habe die Geräte dann im Auslieferzustand eingebunden.
Zusätzlich noch IPs vergeben und Routen gesetzt. IP wird benötigt!
Vor der Nutzung der Mikrotik 60GHz-Strecken sah es so aus :
Für ein paar Infos zur Lokalisierung der fehlerhaften Verbindungen oder Pakete wäre ich dankbar und verbleibe mit freundlichen Grüßen !
Danke !
ich hoffe das Euch allen (+ Familien) gut geht und man weiterhin gesund bleibt!
Für die jenigen von Euch, die es doch erwischt hat wünsche ich "Gute Besserung" !
Nun zu meiner kleinen Frage :
Das Problem sieht wie folgt aus :
Diesen massiven Verlust habe ich, seit dem ich 4 x PTP-Links (Mikrosoft Wire Dish) als Ersatz für überlastete 5Ghz/AC D/T ins Spiel gebracht habe.
Ohne 60GHz - Anbindung hatte ich diesen "PPPOE-Verfall" nicht ! Dort (TimeOut) stand dann bei mehr als doppelter Request - Paket-Anzahl eine 13 !
Nun würde ich gern mir die Pakete anzeigen lassen bzw. aufzeichnen und auswerten, welche dieses Probleme aufzeigen und wo sie her kommen!
Hat einer eine Idee welche Pakete das sind? Ist es ein Session-Problem oder sind es die Anfragen … also Discovery ?
Oder sind es gar bestehen PPPOE-Tunnel und das Problem findet sich an der lokalen Bridge (127.0.0.1)
Info RADIUS-Server:
- 1x CCR1036 - Mikrotik/ mit Userman (480 aktive PPPOE-Profile)
- eine Bridge mit einem PPPOE-Server ; Bridge-Ports sind 12x PTP-Link-Interfacen mit eigenen Subnetzen
- keine Filter auf Bridge
- keine NAT (User bekommen dynamisch externe IPs/v4 über ein Profil)
- CPU-Last 25-35% bei 700MBit/s (sonst 9-15% bei 200MBit/s)
Ich konnte bis dato (Paket-Sniffer) leider nichts Verwertbares finden .
Kurze Info zur PTP-Anbindung :
Die alten 5GHz-Links haben die Liegenschaften über MPLS bzw. VPLS (WLAN to WLAN) versorgt.
Bei den Wire Disch von Mikrotik gab es mit gleichen VPLS-Tunneln massive Problem. Es wurden viele Pakete nicht gelabelt.
Warum weis ich bis heute nicht ! Ich habe die Geräte dann im Auslieferzustand eingebunden.
Zusätzlich noch IPs vergeben und Routen gesetzt. IP wird benötigt!
Vor der Nutzung der Mikrotik 60GHz-Strecken sah es so aus :
Für ein paar Infos zur Lokalisierung der fehlerhaften Verbindungen oder Pakete wäre ich dankbar und verbleibe mit freundlichen Grüßen !
Danke !
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 560477
Url: https://administrator.de/forum/wireshark-oder-paket-sniffer-frage-560477.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
8 Kommentare
Neuester Kommentar
Das Einfachste ist einen einfachen, kleinen Layer 2 Switch in den Link einzuschleifen und über den Monitoring Port dann den Wireshark:
https://www.heise.de/select/ct/2020/4/2000808565231407370
Z.B. Zyxel GS1200-5
https://www.amazon.de/5-Port-Gigabit-Managed-Switch-GS1200-5/dp/B0798PVT ...
oder ähnlich. So gut wie alle kleinen VLAN Switches supporten einen Monitor Port.
Alternative ist dann mit einer Netzwerk Brücke zu arbeiten am Laptop über einen 2ten Port oder wenn der nicht vorhanden ist mit einem preiswerten USB Ethernet Adapter:
https://www.amazon.de/Rankie-Netzwerkadapter-Ethernet-Netzwerk-Konverter ...
bzw.
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Weitere Alternative direkt am Mikrotik sniffern und den PCAP File spaäter im Wireshark analysieren:
https://wiki.mikrotik.com/wiki/Manual:Tools/Packet_Sniffer
Damit lassen sich die Fehler dann sehr schnell aufdecken.
Grund ist vermutlich das die Seite der Bridge die die Radius Pakete über die Funkstrecke schicken muss durch eine sehr schlechte oder gestörte Funkstrecke gehandicapped ist. Vermutlich ist die HF Linkreserve auf dem Funklink sehr schlecht und dadurch kommt es zu diesen erheblichen Retransmissions und Timeouts.
Gut möglich das der Bridge Link auch überlastet ist.
In der Regel ist es immer ziemlich kontraproduktiv über so einen Link zu bridgen. Inspesondere wenn diese 2 LANs verbindet also Site to Site macht.
Der gesamte Broad- und Multicast Traffic BEIDER Seiten belastet dann erheblich die ohnehin Bandbreiten schwächere Funkstrecke und überlastet diese. Aus diesem Grunde sollte man intelligenterweise immer routen über Funklinks und niemals dummes, flaches Bridging machen.
Alles mögliche häufige Gründe durch Design Fehler. Aber natürlich erstmal nur geraten ohne Wireshark Trace.
https://www.heise.de/select/ct/2020/4/2000808565231407370
Z.B. Zyxel GS1200-5
https://www.amazon.de/5-Port-Gigabit-Managed-Switch-GS1200-5/dp/B0798PVT ...
oder ähnlich. So gut wie alle kleinen VLAN Switches supporten einen Monitor Port.
Alternative ist dann mit einer Netzwerk Brücke zu arbeiten am Laptop über einen 2ten Port oder wenn der nicht vorhanden ist mit einem preiswerten USB Ethernet Adapter:
https://www.amazon.de/Rankie-Netzwerkadapter-Ethernet-Netzwerk-Konverter ...
bzw.
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Weitere Alternative direkt am Mikrotik sniffern und den PCAP File spaäter im Wireshark analysieren:
https://wiki.mikrotik.com/wiki/Manual:Tools/Packet_Sniffer
Damit lassen sich die Fehler dann sehr schnell aufdecken.
Grund ist vermutlich das die Seite der Bridge die die Radius Pakete über die Funkstrecke schicken muss durch eine sehr schlechte oder gestörte Funkstrecke gehandicapped ist. Vermutlich ist die HF Linkreserve auf dem Funklink sehr schlecht und dadurch kommt es zu diesen erheblichen Retransmissions und Timeouts.
Gut möglich das der Bridge Link auch überlastet ist.
In der Regel ist es immer ziemlich kontraproduktiv über so einen Link zu bridgen. Inspesondere wenn diese 2 LANs verbindet also Site to Site macht.
Der gesamte Broad- und Multicast Traffic BEIDER Seiten belastet dann erheblich die ohnehin Bandbreiten schwächere Funkstrecke und überlastet diese. Aus diesem Grunde sollte man intelligenterweise immer routen über Funklinks und niemals dummes, flaches Bridging machen.
Alles mögliche häufige Gründe durch Design Fehler. Aber natürlich erstmal nur geraten ohne Wireshark Trace.
Am CCR ist noch ein Interface frei, welcher in der Bridge ist. Also voll nutzbar für Notebook mit Wireshark.
OK, Grundlagen auch hier dazu:https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
aber ich weis nicht nach was ich suchen soll.
Das ist ja ein Radius Server der da rennt und die Authentisierung macht. Folglich suchst du also nach Radius Frames. Port 1812 und die Radius Server IP filtert all den relevanten Traffic.Lass den erstmal eine zeitlang reinlaufen und sniffer alles mit. Der Wireshark zeigt dir von sich aus dann schon die Fehler.
Dafür sorgen eine Handvoll Bridge-Filter
Wie oben schon gesagt. Das ist grundfalsch das so zu läsen, denn in einem Layer 2 Bridging Konzept kannst du nur einen Bruchteil filtern. Der Rest belastet weiter massiv die Leitung.Als Netzwerker kennst du den goldenen Grundsatz: "Route wherever you can, bridge where you must !"
Den hast du leider ignoriert.
Ein geroutetes Design ist ohne wochenlange Anpassung in 30 Minuten up and running ohne all diese (überflüssige) Fricklei die du beschreibst.
Du solltest also besser grundsätzlich dein Konzept nochmal überdenken.
aber bestimmte Seiten wurden einfach beim User nicht aufgebaut!
Typisches MTU Problem und hättest du mit dem Setzen des MSS Wertes sofort fixen können ! Anfängerfehler ?!Siehe dazu hier:
https://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
EOIP wollte ich nicht nutzen UND nen ovpn - Tunnel auf die schnell erst recht nicht!
Nein, ist auch Unsinn !Was ist das ? Ein simples LAN zu LAN ??
Da machst du stinknormales IP Routing:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
nutze ich ja auch nur einen PPPOE-Server.
Sinnloser Overhead normalerweise. Was ist das denn ? Eine normale LAN zu LAN Kopplung zweier einfacher Netze ?Oder bist du sowas wie ein Provider und bei dir loggen sich Kunden mit PPPoE ein ?
Auch wenn sich von den knapp 490 Usern keiner meldet
Wie bitte ??? 490 User über eine flache dumme Bridge Verbindung ?? Aber ich hab das Design wohl missverstanden bzw. du hast mit keinem Wort gesagt was du da eigentlich machst ?? Oben redest du ja einzig nur vom Radius.Was hällst du von den EOIP - Tunneln? Hatte ich vor der VPLS
Kommt drauf an. Muss man erstmal verstehen was du da machst. GRE ist auch eine Option:Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
(Das IPsec musst du dir wegdenken wenn du keine Security benötigst !)
Am besten und einfachsten ist es immer ein nur routen ohne irgendwelchen Overhead mit GRE, EoIP oder VPLS.
dachte eigentlich, dass ich die gesuchte Info bekomme, ohne zu Erklären wie das Netz für welche Dienste aufgebaut ist.
Musst du auch nicht, es erleichtert nur für andere die es ja nur schriftlich hier erfassen können das Verständnis. Wir können ja nichts verbal erfragen ! Dein generelles Problem ist das du Liegenschaften bridgest via Layer 2. Jeder Netzwerker weiss das sowas niemals skaliert. In WAN Umgebungen routet man deshalb immer bzw. wenn immer möglich. Grundlegende Probleme hast du hier also schon im Design was die Skalierbarkeit und damit Performance anbetrifft.
Denn vor dem Wechsel zu diesen, hatte ich KEIN Problem !
Dann ist es das auch ganz sicher. Das ist eindeutig !Es reicht dann den Authentisierungs Traffic rein nur dieser Komponenten anzusehen im Wireshark.
warum ich über MPLS/VPLS (nur auf den 60GHz Strecken)bestimmte Seiten nicht geöffnet bekomme. Viele gehen. Einige aber nicht.
Zu 99% ein MTU bzw. MSS Problem. Bei doppelter Encapsulierung über eine Tunnelstrecke musst du zwangsweise die MTU im Tunnel und die MSS in den beteiligten LAN Segmenten anpassen.Kennst du ein Seite, wo das nochmal richtig beschrieben wird?
Ja, die von Cisco am Peispiel der PPPoE Encapsulation:https://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
Deinen Overhead und ide MTU/MSS Settings kannst du dir ausrechnen lassen:
https://baturin.org/tools/encapcalc/
warum habe ich dann, bei gleicher Config, also :
Vermutlich reagieren die Dienste dann richtig auf den MTU Path Discovery Frame. Das müsste man mal sniffern um dem auf den Grund zu gehen. Typischerweise sind solche Probleme manche Webseiten gehen, manche nicht immer MTU/MSS Probleme wenn man in einem Umfeld mit Encapsulations arbeitet.Ich hatte auch den Usermanager von Mikrotik in verdacht … der hat so sein eigenes "Leben".
Könnte auch sein. Ein richtiger Radius Server ist das nämlich keineswegs.