8
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 !
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 560477
Url: https://administrator.de/contentid/560477
Ausgedruckt am: 22.11.2024 um 07:11 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.
Hallo aqui,
danke für deinen Anstoß !
Zum Thema Switch : wird nicht nötig sein. Am CCR ist noch ein Interface frei, welcher in der Bridge ist. Also voll nutzbar für Notebook mit Wireshark.
Habe ja auch hier schon mitgeschnitten … aber ich weis nicht nach was ich suchen soll. Ich sehe alles vom PPPOE-Traffic. Auch alles was über IP angefragt oder beantwortet wird bzw. werden muss. Das ist nicht viel … nur SSH zu den RB´s, ein wenig SNMP ind ICMP zu Dude. Mehr nicht!
Sinnlose Daten gibt dank der wochenlangen Anpassungen nicht.
Dafür sorgen eine Handvoll Bridge-Filter (Input/Output/Forward) an allen User-Ports bzw. Interface-Listen .Das kann es wirklich auch nicht sein.
Es ist restlos alles entfern wurden. Angefangen von IGMP, IPV6, Protokolle wie 6970(Sonos) oder HomePlug AV bis hin zu AVM-Audio.
Es gibt nur PPPOE-Session bzw. Anmeldungen. Dann alle Privaten IP-Adress-Bereich werden gedropt(auch ARP).
Übertragen werden nur Daten aus dem Produktiv-Netzwerk und ein wenig Management.
Den angesprochenen "schlechten Link" schließe ich auch aus. RSSI liegt bei 67-71 und der Pegel auf dem Link bei 90-95.Bei einer Strecke (998m)sind es 57 RSSI und 80 beim Pegel. Speedtest (Speedtest.net)sagt ja auch , dass es keine Probleme gibt. Ganz sauberer … Upload und Download mit 3-17 ms zum MDCC-Gateway.
https://www.speedtest.net/result/8276704772
Auch der Speedtest innerhalb Mikrotik zeigt Werte, die ich nie benötige.
Ich vermute eher die Konfiguration der 8 x Wire Dish Geräte .
Ich hatte versucht, wie bei den 802.11ac - RB´s auf MPLS zu setzen. Der VPLS-Tunnel steht auch sauber … aber bestimmte Seiten wurden einfach beim User nicht aufgebaut! Habe das Problem auch bei einem 2. Link genauso vor gefunden. Google geht auf, aber die Links zu vielen Ergebnissen gingen einfach nicht auf. Warum weis ich nicht! Denke, manche Pakete werden nicht gelabelt.
EOIP wollte ich nicht nutzen UND nen ovpn - Tunnel auf die schnell erst recht nicht!
Darum habe ich es so gelassen, wie ausgeliefert. Was hältst du von der Grundkonfig (wenn du sie kennst)?
Am Anfang habe ich es nicht gemerkt. Nachdem ich aber 3 weitere ins Netzwerk genommen habe, bin ich zufällig drauf gestoßen.
Ich will halt nur wissen, welche Filter ich in Wireshark setzen muss, um das Problem Pakettechnisch sichtbar zu machen.
Denn schaue ich in Pakete mit DePort bzw. ScPort 1812 und 1813, finde ich keine TTL -Angaben. Auch auf der Bridge(127.0.0.1 Interface) wo die Tunnel enden, sind keine Infos zu Time Out zu finden. Mir fehlt lediglich die Info, welches Protokoll(Mac,IP, etc), welche Pakete die Statistik auswertet und hier aufzählt.
Ich habe Testweise früh am Morgen die 4 Links mal rausgenommen. Danach ändert sich sofort die Statistik !
Auch wenn sich von den knapp 490 Usern keiner meldet … macht mich sowas nicht glücklicher.
Leider ...
danke für deinen Anstoß !
Zum Thema Switch : wird nicht nötig sein. Am CCR ist noch ein Interface frei, welcher in der Bridge ist. Also voll nutzbar für Notebook mit Wireshark.
Habe ja auch hier schon mitgeschnitten … aber ich weis nicht nach was ich suchen soll. Ich sehe alles vom PPPOE-Traffic. Auch alles was über IP angefragt oder beantwortet wird bzw. werden muss. Das ist nicht viel … nur SSH zu den RB´s, ein wenig SNMP ind ICMP zu Dude. Mehr nicht!
Sinnlose Daten gibt dank der wochenlangen Anpassungen nicht.
Dafür sorgen eine Handvoll Bridge-Filter (Input/Output/Forward) an allen User-Ports bzw. Interface-Listen .Das kann es wirklich auch nicht sein.
Es ist restlos alles entfern wurden. Angefangen von IGMP, IPV6, Protokolle wie 6970(Sonos) oder HomePlug AV bis hin zu AVM-Audio.
Es gibt nur PPPOE-Session bzw. Anmeldungen. Dann alle Privaten IP-Adress-Bereich werden gedropt(auch ARP).
Übertragen werden nur Daten aus dem Produktiv-Netzwerk und ein wenig Management.
Den angesprochenen "schlechten Link" schließe ich auch aus. RSSI liegt bei 67-71 und der Pegel auf dem Link bei 90-95.Bei einer Strecke (998m)sind es 57 RSSI und 80 beim Pegel. Speedtest (Speedtest.net)sagt ja auch , dass es keine Probleme gibt. Ganz sauberer … Upload und Download mit 3-17 ms zum MDCC-Gateway.
https://www.speedtest.net/result/8276704772
Auch der Speedtest innerhalb Mikrotik zeigt Werte, die ich nie benötige.
Ich vermute eher die Konfiguration der 8 x Wire Dish Geräte .
Ich hatte versucht, wie bei den 802.11ac - RB´s auf MPLS zu setzen. Der VPLS-Tunnel steht auch sauber … aber bestimmte Seiten wurden einfach beim User nicht aufgebaut! Habe das Problem auch bei einem 2. Link genauso vor gefunden. Google geht auf, aber die Links zu vielen Ergebnissen gingen einfach nicht auf. Warum weis ich nicht! Denke, manche Pakete werden nicht gelabelt.
EOIP wollte ich nicht nutzen UND nen ovpn - Tunnel auf die schnell erst recht nicht!
Darum habe ich es so gelassen, wie ausgeliefert. Was hältst du von der Grundkonfig (wenn du sie kennst)?
Am Anfang habe ich es nicht gemerkt. Nachdem ich aber 3 weitere ins Netzwerk genommen habe, bin ich zufällig drauf gestoßen.
Ich will halt nur wissen, welche Filter ich in Wireshark setzen muss, um das Problem Pakettechnisch sichtbar zu machen.
Denn schaue ich in Pakete mit DePort bzw. ScPort 1812 und 1813, finde ich keine TTL -Angaben. Auch auf der Bridge(127.0.0.1 Interface) wo die Tunnel enden, sind keine Infos zu Time Out zu finden. Mir fehlt lediglich die Info, welches Protokoll(Mac,IP, etc), welche Pakete die Statistik auswertet und hier aufzählt.
Ich habe Testweise früh am Morgen die 4 Links mal rausgenommen. Danach ändert sich sofort die Statistik !
Auch wenn sich von den knapp 490 Usern keiner meldet … macht mich sowas nicht glücklicher.
Leider ...
… ich nochmal aqui…
du hattest vorhin das Thema "Bridge-Überlastung" angesprochen.
Da ich ja nur eine Bridge mit 12x Interface zu den Funkstrecken habe, nutze ich ja auch nur einen PPPOE-Server.
Ist hier was bedenklich ? Sollte man es vielleicht auf je eine Bridge/Interface und je einen PPPOE-Server bringen?
Gibt's da Erfahrungen …
Da ich sonst ja nur IP-WAN Filter habe … also keine Bridgefilter … muss auch nicht viel geändert werden.
Was hällst du von den EOIP - Tunneln? Hatte ich vor der VPLS - Thematik mal. Ist ja noch ein durchaus nutzbare Alternative
zu dem Thema OpenVPN-Tunnel.
Hardware ist ja wirklich mit Leistung gesegnet. Vor allem, weil maximal 400MBit/s bis dato für die knapp 200 User anlagen
Die CPU an Station und Bridge hatte 4-8% Last. Wenn EoIP gespannt wird, wird es ein wenig mehr. Der Server sollte das abkönnen.
Danke für deine Einschätzung!
du hattest vorhin das Thema "Bridge-Überlastung" angesprochen.
Da ich ja nur eine Bridge mit 12x Interface zu den Funkstrecken habe, nutze ich ja auch nur einen PPPOE-Server.
Ist hier was bedenklich ? Sollte man es vielleicht auf je eine Bridge/Interface und je einen PPPOE-Server bringen?
Gibt's da Erfahrungen …
Da ich sonst ja nur IP-WAN Filter habe … also keine Bridgefilter … muss auch nicht viel geändert werden.
Was hällst du von den EOIP - Tunneln? Hatte ich vor der VPLS - Thematik mal. Ist ja noch ein durchaus nutzbare Alternative
zu dem Thema OpenVPN-Tunnel.
Hardware ist ja wirklich mit Leistung gesegnet. Vor allem, weil maximal 400MBit/s bis dato für die knapp 200 User anlagen
Die CPU an Station und Bridge hatte 4-8% Last. Wenn EoIP gespannt wird, wird es ein wenig mehr. Der Server sollte das abkönnen.
Danke für deine Einschätzung!
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.
Guten Morgen …
dachte eigentlich, dass ich die gesuchte Info bekomme, ohne zu Erklären wie das Netz für welche Dienste aufgebaut ist. ;)
Es ging ja nur um die Protokollart bzw. den Port welche ich mitschneiden muss, um zu sehen, welche User betroffen sind.
Die Pakete aus und an Port 1812 und 1813 hatte ich schon auf dem Tisch, leider keine farbliche Abhebung oder Time(TTL) Werte im Paket zu finden. Vielleicht habe ich ja was übersehen … muss ja sein.
Zum Netzwerk :
Die Zentrale (CCR) versorgt über gebridgte Interface mehrere (10)Liegenschaften(PTP/PTMP) mit dem RADIUS-Dienst bis zu den ganzen Userports. Daher die Thematik EoIP, MPLS/VPLS oder Open VPN-Tunnel. Mit diesen Methoden bekomme ich das hin. Oder kennst du noch was anderes?
Das Thema IP ist hier doch sekundäre Last. Müsste ich nicht mal haben(außer für den VPLS-Tunnel über den Link), wenn ich keine Messwerte 1x im Monat abfragen müsste. Auf die ganzen externen ganzen CRS324/CRS354 komme ich auch ohne IP.
Ich bin also ein kleiner Provider .
Die Fehler (Resends und Bad Replies)für diese Radiusanbindung vermutete ich in den 4 x WireDish Links. Denn vor dem Wechsel zu diesen, hatte ich KEIN Problem ! Mehr als 4 Jahre nicht.
Interessant finde ich noch immer, warum ich über MPLS/VPLS (nur auf den 60GHz Strecken)bestimmte Seiten nicht geöffnet bekomme. Viele gehen. Einige aber nicht.Dazu gehören Seiten von Geldinstituten . Auf den 5GHzac-RBs (RB911G/912G) habe ich auch VPLS .Da gibt es die Probleme nicht.
Du sagst, es liegt am MSS-Wert der ja aufgrund der Verbindungen neu gesetzt werden muss.
Kennst du ein Seite, wo das nochmal richtig beschrieben wird?
Denn auf dem CCR wurde automatisch die Regel gesetzt.
Würde ich gern nochmal nachlesen … welche Werte wo richtig zu setzen sind.
Ich versuche das Ganze nochmal parallel mit VPLS über die WireDish aufzubauen. Hatte damals nur keine Zeit den Fehler zu finden.
Auch die PPPOE-Pakete schaue ich mir nochmal an … wie gesagt, vielleicht doch was übersehen.
Ich sage mal ganz nett DANKE aqui !!!
Solltest du noch Gedankenschübe haben … nehme ich gern alles auf !
THX
dachte eigentlich, dass ich die gesuchte Info bekomme, ohne zu Erklären wie das Netz für welche Dienste aufgebaut ist. ;)
Es ging ja nur um die Protokollart bzw. den Port welche ich mitschneiden muss, um zu sehen, welche User betroffen sind.
Die Pakete aus und an Port 1812 und 1813 hatte ich schon auf dem Tisch, leider keine farbliche Abhebung oder Time(TTL) Werte im Paket zu finden. Vielleicht habe ich ja was übersehen … muss ja sein.
Zum Netzwerk :
Die Zentrale (CCR) versorgt über gebridgte Interface mehrere (10)Liegenschaften(PTP/PTMP) mit dem RADIUS-Dienst bis zu den ganzen Userports. Daher die Thematik EoIP, MPLS/VPLS oder Open VPN-Tunnel. Mit diesen Methoden bekomme ich das hin. Oder kennst du noch was anderes?
Das Thema IP ist hier doch sekundäre Last. Müsste ich nicht mal haben(außer für den VPLS-Tunnel über den Link), wenn ich keine Messwerte 1x im Monat abfragen müsste. Auf die ganzen externen ganzen CRS324/CRS354 komme ich auch ohne IP.
Ich bin also ein kleiner Provider .
Die Fehler (Resends und Bad Replies)für diese Radiusanbindung vermutete ich in den 4 x WireDish Links. Denn vor dem Wechsel zu diesen, hatte ich KEIN Problem ! Mehr als 4 Jahre nicht.
Interessant finde ich noch immer, warum ich über MPLS/VPLS (nur auf den 60GHz Strecken)bestimmte Seiten nicht geöffnet bekomme. Viele gehen. Einige aber nicht.Dazu gehören Seiten von Geldinstituten . Auf den 5GHzac-RBs (RB911G/912G) habe ich auch VPLS .Da gibt es die Probleme nicht.
Du sagst, es liegt am MSS-Wert der ja aufgrund der Verbindungen neu gesetzt werden muss.
Kennst du ein Seite, wo das nochmal richtig beschrieben wird?
Denn auf dem CCR wurde automatisch die Regel gesetzt.
Würde ich gern nochmal nachlesen … welche Werte wo richtig zu setzen sind.
Ich versuche das Ganze nochmal parallel mit VPLS über die WireDish aufzubauen. Hatte damals nur keine Zeit den Fehler zu finden.
Auch die PPPOE-Pakete schaue ich mir nochmal an … wie gesagt, vielleicht doch was übersehen.
Ich sage mal ganz nett DANKE aqui !!!
Solltest du noch Gedankenschübe haben … nehme ich gern alles auf !
THX
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/
… ja, ist ganz sicher! Mit den 5GHz - VPLS - strecken KEIN RADIUS - Problem !Kein Problem mit "nicht vorhanden Webseiten" !
Die laufen wirklich alle sehr sauber … selbst über PTMP!
Der Wechsel zum 60GHz - System war nur wegen der nutzbaren Kanäle notwendig.
Wir nehmen mal an, es liegt wirklich am Change der MSS-Werte … warum habe ich dann, bei gleicher Config, also :
VPLS-Tunnel mit gleicher IP (auf beiden Systemen)
gleiche MPLS Interface
gleiche Bridge mit gleichen Ports
die Fehler nur auf dem 60GHz Spot und eben nicht auch auf den ganzen 5GHz-Systemen?
Denn auf beiden Systemen sind keine MSS-Change Rules hinterlegt ?
Das Thema MSS/MTU … passt natürlich! Gerade bei Banken … hinsichtlich DDos !
Aber danke für die beiden Links … werde ich aufarbeiten und wer weiß, vielleicht ändert das die Situation.
Zum Fehler am RADIUS :
Ich hatte auch den Usermanager von Mikrotik in verdacht … der hat so sein eigenes "Leben".
Da ja kein User meckert … ich aber den Fehler los werden möchte, komme ich nicht drum herum, deinen Ansatz mal aus zu probieren.
Danke !
Die laufen wirklich alle sehr sauber … selbst über PTMP!
Der Wechsel zum 60GHz - System war nur wegen der nutzbaren Kanäle notwendig.
Wir nehmen mal an, es liegt wirklich am Change der MSS-Werte … warum habe ich dann, bei gleicher Config, also :
VPLS-Tunnel mit gleicher IP (auf beiden Systemen)
gleiche MPLS Interface
gleiche Bridge mit gleichen Ports
die Fehler nur auf dem 60GHz Spot und eben nicht auch auf den ganzen 5GHz-Systemen?
Denn auf beiden Systemen sind keine MSS-Change Rules hinterlegt ?
Das Thema MSS/MTU … passt natürlich! Gerade bei Banken … hinsichtlich DDos !
Aber danke für die beiden Links … werde ich aufarbeiten und wer weiß, vielleicht ändert das die Situation.
Zum Fehler am RADIUS :
Ich hatte auch den Usermanager von Mikrotik in verdacht … der hat so sein eigenes "Leben".
Da ja kein User meckert … ich aber den Fehler los werden möchte, komme ich nicht drum herum, deinen Ansatz mal aus zu probieren.
Danke !
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.
