13
Dynamisch wiederkehrende Probleme im entfernten Subnetz
Guten Morgen an Alle ...
ich hab seit geraumer Zeit ein stetig wiederkehrenden Fehler in einem Subnetz. Diesen möchte ich nun gern loswerden, denn ER nervt!
Das Subnetz ist über einen Link (Mikrotik) am Server gebunden. Genutzt wird eine EoIP-Tunnel welcher über zwei RB911-Karten realisiert wird.
Lokal befindet sich eine Gigabit-Verkabelung(Cu)
Nun zum Fehler :
Wie im Bild zu sehen ist, sind einige NETGEAR-Switche(FS/GS-Serie) ROT und ein paar GRÜN. Normalerweise kommt die Färbung vom nicht beantworteten Service "PING".
Aber das ist hier nicht so. Selbst die in GRÜN gehaltenen lassen sich nicht vom Server anpingen. Nur der OVS57 antwortet. Mit ihm lässt sich auch normal Arbeiten.
Wenn ich den Switch OVS97 Pinge... kommt keine Antwort. Aber das Webinterface geht ... wenn auch sehr sehr langsaaaam !
Selbst der locale-PING vom RB911 aus bringt nur ein "time out"!
Nur die 4 x DR-Knoten(zum Auslesen von Verbrauchszählern) lassen sich ohne Probleme vom Server aus anpingen. Dem Zugriff (FTP) steht hier auch nichts im Weg. Sie sind ohne Probleme zu erreichen.
Starte ich alle nach einander neu ... gibt es eine bestimmte Zeit X überhaupt keine Probleme. Alles geht ... ohne Ärger! Mal 2 Wochen ... dann wieder 3 Monate!
Was habe ich alle geprüft/getauscht :
Switch OVS 57 getauscht
Mac-Adressen der Switche untereinander sind bekannt. Auch auf dem RB911 lokal sind sie alle zu sehen.
OSPF geprüft ... hier gibt es keine Fehler. Adressbereich passt und wird sauber weitergegeben
Mit WireShark zugehört ... Pakete für Ping gehen raus ...
EoIP-Tunnel gegen MPLS/VPLS getauscht, auch WDS probiert ... Problem kommt wieder!
"Lustiger Weise" steht im Syslog mehrmals täglich, dass bestimmte Switche "wieder" DA SIND! Und ne Stunde später sind sie weg um erneut wieder aufzutauchen!(s.Bild OVS2)
Über Hilfe wäre ich sehr dankbar. Denn die Ports lokal zu schalten(was funktioniert) kostet Zeit und Geld. Sind gute 12km zu fahren.
...noch was... die Benutzer der Ports benötigen PPPOE.
DANKE im vorraus !
ich hab seit geraumer Zeit ein stetig wiederkehrenden Fehler in einem Subnetz. Diesen möchte ich nun gern loswerden, denn ER nervt!
Das Subnetz ist über einen Link (Mikrotik) am Server gebunden. Genutzt wird eine EoIP-Tunnel welcher über zwei RB911-Karten realisiert wird.
Lokal befindet sich eine Gigabit-Verkabelung(Cu)
Nun zum Fehler :
Aber das ist hier nicht so. Selbst die in GRÜN gehaltenen lassen sich nicht vom Server anpingen. Nur der OVS57 antwortet. Mit ihm lässt sich auch normal Arbeiten.
Wenn ich den Switch OVS97 Pinge... kommt keine Antwort. Aber das Webinterface geht ... wenn auch sehr sehr langsaaaam !
Selbst der locale-PING vom RB911 aus bringt nur ein "time out"!
Nur die 4 x DR-Knoten(zum Auslesen von Verbrauchszählern) lassen sich ohne Probleme vom Server aus anpingen. Dem Zugriff (FTP) steht hier auch nichts im Weg. Sie sind ohne Probleme zu erreichen.
Starte ich alle nach einander neu ... gibt es eine bestimmte Zeit X überhaupt keine Probleme. Alles geht ... ohne Ärger! Mal 2 Wochen ... dann wieder 3 Monate!
Was habe ich alle geprüft/getauscht :
Switch OVS 57 getauscht
Mac-Adressen der Switche untereinander sind bekannt. Auch auf dem RB911 lokal sind sie alle zu sehen.
OSPF geprüft ... hier gibt es keine Fehler. Adressbereich passt und wird sauber weitergegeben
Mit WireShark zugehört ... Pakete für Ping gehen raus ...
EoIP-Tunnel gegen MPLS/VPLS getauscht, auch WDS probiert ... Problem kommt wieder!
"Lustiger Weise" steht im Syslog mehrmals täglich, dass bestimmte Switche "wieder" DA SIND! Und ne Stunde später sind sie weg um erneut wieder aufzutauchen!(s.Bild OVS2)
Über Hilfe wäre ich sehr dankbar. Denn die Ports lokal zu schalten(was funktioniert) kostet Zeit und Geld. Sind gute 12km zu fahren.
...noch was... die Benutzer der Ports benötigen PPPOE.
DANKE im vorraus !
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: 309080
Url: https://administrator.de/forum/dynamisch-wiederkehrende-probleme-im-entfernten-subnetz-309080.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
was für Switche sind das?
Welcher Hersteller?
welches Modell?
Ist alles in einem VLAN oder gibt es sowas wie ein Management VLAN?
Wie ist die Auslastung der Switche?
Wieviel Last läuft auf Leitungen?
brammer
was für Switche sind das?
Welcher Hersteller?
welches Modell?
Ist alles in einem VLAN oder gibt es sowas wie ein Management VLAN?
Wie ist die Auslastung der Switche?
Wieviel Last läuft auf Leitungen?
brammer
Sorry vergessen ... sind 100% NETGEAR GS/FS-Serie. Alles läuft ohne VLAN.
Die Last ist eher gering ... eher Fast-Ethernet. Zu den Spitzenzeiten laufen 40-60MBit über die Strecke.
Die Last ist eher gering ... eher Fast-Ethernet. Zu den Spitzenzeiten laufen 40-60MBit über die Strecke.
Prüf doch mal Stichprobenartig ob die Ports CRC fehler aufweisen. Vielleicht hat ein Kabel ein hau.
Welche Timejobs laufen über das Netzwerk? Irgendwelche Backup Images die täglich über das WAN flitzen?
Habt ihr eine Firewall die den traffic summiert aufzeigt?
Schon Wireshark mal ausgepackt und die pakete mal gesnifft? Eventuell laufen Dienste die das Netz überlasten.
Welche Timejobs laufen über das Netzwerk? Irgendwelche Backup Images die täglich über das WAN flitzen?
Habt ihr eine Firewall die den traffic summiert aufzeigt?
Schon Wireshark mal ausgepackt und die pakete mal gesnifft? Eventuell laufen Dienste die das Netz überlasten.
... Hi !
Ist nen guter Ansatz ...!
Aber "leider" keine Fehler zu sehen. Bei über 2.750.000.000 /Paket übertragen/empfangen habe ich ein einziges fehlerhaftes Paket!
Ein wirkliche Last habe ich nicht. Auch eine FW-Regel die hier stören könnte ... gibt es weder auf den beiden RB noch auf dem Server.
Denn wie gesagt, starte ich alles neu ... ist der Fehler weg und ich komme überall hin bis zum Zeitpunkt X.
Auch das angesprochene Sniffen zeigt, dass es sehr ruhig im Netzsegment zugeht. Man sieht halt nur die PPPOE - Anmeldung wie auch die Daten aus den Sessions und OSPF, SNMP wie auch NTP oder DHCP-Pakete von Client und "Servern". Also eher ganz "liebe" User die HTTP wie auch VoIP nutzen. Auch die Pingzeiten vom User aus sind wirklich Klasse.
Bevor ich die RB´s getauscht hatte, gab es den Fehler auch schon. Da war die Anbindung zum RB auf dem Dach eine 100MBit-Strecke. Sind so 30m bis zum Board. Jetzt ist es GB.Dachte mit dem Tausch ist es weg ... ABER NIX DA!
Wegen der Netzlast lokal ... alle Ports sind begrenzt auf 40MBit(außer die GB-Ports) im Bereich rx bzw. tx. Die PPPOE - Profile gehen auch nur bis 25MBit (außer Admin).
Danke aber trotzdem!
MFG
Ist nen guter Ansatz ...!
Aber "leider" keine Fehler zu sehen. Bei über 2.750.000.000 /Paket übertragen/empfangen habe ich ein einziges fehlerhaftes Paket!
Ein wirkliche Last habe ich nicht. Auch eine FW-Regel die hier stören könnte ... gibt es weder auf den beiden RB noch auf dem Server.
Denn wie gesagt, starte ich alles neu ... ist der Fehler weg und ich komme überall hin bis zum Zeitpunkt X.
Auch das angesprochene Sniffen zeigt, dass es sehr ruhig im Netzsegment zugeht. Man sieht halt nur die PPPOE - Anmeldung wie auch die Daten aus den Sessions und OSPF, SNMP wie auch NTP oder DHCP-Pakete von Client und "Servern". Also eher ganz "liebe" User die HTTP wie auch VoIP nutzen. Auch die Pingzeiten vom User aus sind wirklich Klasse.
Bevor ich die RB´s getauscht hatte, gab es den Fehler auch schon. Da war die Anbindung zum RB auf dem Dach eine 100MBit-Strecke. Sind so 30m bis zum Board. Jetzt ist es GB.Dachte mit dem Tausch ist es weg ... ABER NIX DA!
Wegen der Netzlast lokal ... alle Ports sind begrenzt auf 40MBit(außer die GB-Ports) im Bereich rx bzw. tx. Die PPPOE - Profile gehen auch nur bis 25MBit (außer Admin).
Danke aber trotzdem!
MFG
Moin,
Hast Du da wirklich bis zu 10 switches als Kette hintereinander? Das dürfte deutlich spürbare Latenzprobleme verursachen.
Versch mal eine deutlich flacheren switch-Baum zu machen.
Aucb wenn die 5-4-3-Regel mit modernen switches nicht mehr ganz so streng gilt, sind die Latenzen doch nicht zu vernachlässigen.
lks
Hast Du da wirklich bis zu 10 switches als Kette hintereinander? Das dürfte deutlich spürbare Latenzprobleme verursachen.
Versch mal eine deutlich flacheren switch-Baum zu machen.
Aucb wenn die 5-4-3-Regel mit modernen switches nicht mehr ganz so streng gilt, sind die Latenzen doch nicht zu vernachlässigen.
lks
Hallo,
allerdings sollte die etwas problematische Struktur nicht wirklich Einfluss darauf haben das der 2 oder 3. Switche nicht mehr antwortet, der 10 aber schon noch...
Um welche Strecken zwischen den einzelnen Switchen geht es eigentlich?
Wieviele Teilnehmer hängen an den Switchen?
brammer
Hast Du da wirklich bis zu 10 switches als Kette hintereinander?
allerdings sollte die etwas problematische Struktur nicht wirklich Einfluss darauf haben das der 2 oder 3. Switche nicht mehr antwortet, der 10 aber schon noch...
Um welche Strecken zwischen den einzelnen Switchen geht es eigentlich?
Wieviele Teilnehmer hängen an den Switchen?
brammer
Zitat von @brammer:
allerdings sollte die etwas problematische Struktur nicht wirklich Einfluss darauf haben das der 2 oder 3. Switche nicht mehr antwortet, der 10 aber schon noch...
allerdings sollte die etwas problematische Struktur nicht wirklich Einfluss darauf haben das der 2 oder 3. Switche nicht mehr antwortet, der 10 aber schon noch...
Ich denke, daß in so eine rStruktur das Verhalten eher indeterminischisch ist und daher durchaus möglich.
lks
PS: Irgendwann muß ich doch mal zwei dutzend Switches zusammenstöpseln und messen.
Guten Morgen ...
laut Zeichnung habe ich max. 6 Switche in Reihe. Jeder Switch steht für eine Wohneinheit(4-16 User je Einheit). Die Gesamtstrecke zwischen OVS57 und 97 sind vielleicht 90m. Und von Switch zu Switch immer 10-12m.Außer bei OVS57 zur 87.Dort liegt ein Erdkabel mit gute 20m.
Die Einwahl per PPPOE klappt überall. Der Ping zum Server liegt bei 6-8ms. Zum Google DNS(8.8.8.8) gute 18ms.
Vom Server über AP zum Station liegt bei 2-3ms.
Ich denke, dass das Problem nicht die Längen zu den Switchen sein kann. Denn selbst vom OVS57 zur 61, welche gerade mal 25m beträgt , ist nun nicht der Grenzbereich bei einer CAT 6 - Verkabelung.
Was mich verwundert ist, dass der letzte Switch, also die OVS97, kein Time out bringt. Aber alle anderen davor sich halt nicht anpingen lassen.
Ich vermute das Problem nicht in der passiven Technik. Es liegt im Bereich L2-3. Denn der Auslöser für dieses Phänomen kommt ja nach dem Neustart. Aber nicht direkt ... sondern sehr zeitversetzt. Wäre es die Verkabelung ... könnte man drauf warten und müsste nicht teils 2 Monate warten. Und die Netzwerklast ist ein Witz gegenüber andere angebundene Liegenschaften.
Vielleicht gibt es ein Usergerät was den Fehler verursacht, sobald es einschaltet wird.. Zum Beispiel Loop . Auch wenn RSTP überall läuft.
Denn ich hatte, soweit ich mich erinnern kann, mal einen Rootpath mit 20010 Cost.
Wenn Du sonst noch Ideen hast ... nehme ich sie dankend an. Habe gestern erst mal in einer schweißtreibenden Aktion alle Switche
deaktiviert und neu gestartet.
Mit freundlichen Grüßen
laut Zeichnung habe ich max. 6 Switche in Reihe. Jeder Switch steht für eine Wohneinheit(4-16 User je Einheit). Die Gesamtstrecke zwischen OVS57 und 97 sind vielleicht 90m. Und von Switch zu Switch immer 10-12m.Außer bei OVS57 zur 87.Dort liegt ein Erdkabel mit gute 20m.
Die Einwahl per PPPOE klappt überall. Der Ping zum Server liegt bei 6-8ms. Zum Google DNS(8.8.8.8) gute 18ms.
Vom Server über AP zum Station liegt bei 2-3ms.
Ich denke, dass das Problem nicht die Längen zu den Switchen sein kann. Denn selbst vom OVS57 zur 61, welche gerade mal 25m beträgt , ist nun nicht der Grenzbereich bei einer CAT 6 - Verkabelung.
Was mich verwundert ist, dass der letzte Switch, also die OVS97, kein Time out bringt. Aber alle anderen davor sich halt nicht anpingen lassen.
Ich vermute das Problem nicht in der passiven Technik. Es liegt im Bereich L2-3. Denn der Auslöser für dieses Phänomen kommt ja nach dem Neustart. Aber nicht direkt ... sondern sehr zeitversetzt. Wäre es die Verkabelung ... könnte man drauf warten und müsste nicht teils 2 Monate warten. Und die Netzwerklast ist ein Witz gegenüber andere angebundene Liegenschaften.
Vielleicht gibt es ein Usergerät was den Fehler verursacht, sobald es einschaltet wird.. Zum Beispiel Loop . Auch wenn RSTP überall läuft.
Denn ich hatte, soweit ich mich erinnern kann, mal einen Rootpath mit 20010 Cost.
Wenn Du sonst noch Ideen hast ... nehme ich sie dankend an. Habe gestern erst mal in einer schweißtreibenden Aktion alle Switche
deaktiviert und neu gestartet.
Mit freundlichen Grüßen
... Morgen ! An den Switchen hängen momentan 22 User . Die Switche haben eine Link über max. 12 Meter. Außer vom OVS57 zur 87,61, 83. Denn dort liegt das Kabel im Boden mit einer Länge von gut 20-30m.
Wie ich eben geschrieben habe, vermute ich den Fehler an einem Userport. Denn das würde den dynamischen Effekt der Auftretens erklären.
An der Verkabelung denke ich liegt es nicht. Auch wenn ich Längenfehler habe vom Dach(RB) zum Switch.Das kann nicht die Ursache sein. Denn selbst wenn ich den Fehler mit Fast Ethernet bekomme erklärt es nicht, warum ich alle am OVS57 angeschlossenen Geröäte nicht erreiche.
Denn ein Ping vom RB zum Switch OVS57 liegt bei 1er ms.
Wenn Du sonst noch ein Idee hast ... her damit
Mit freundlichen Grüßen und Danke
Wie ich eben geschrieben habe, vermute ich den Fehler an einem Userport. Denn das würde den dynamischen Effekt der Auftretens erklären.
An der Verkabelung denke ich liegt es nicht. Auch wenn ich Längenfehler habe vom Dach(RB) zum Switch.Das kann nicht die Ursache sein. Denn selbst wenn ich den Fehler mit Fast Ethernet bekomme erklärt es nicht, warum ich alle am OVS57 angeschlossenen Geröäte nicht erreiche.
Denn ein Ping vom RB zum Switch OVS57 liegt bei 1er ms.
Wenn Du sonst noch ein Idee hast ... her damit
Mit freundlichen Grüßen und Danke
Falsch. laut Deine Zeichnung gibt es switche, zwichen denen 10 andere switche hängen: OVs97 und DR-OvS69-71, also insgesamt 12 switche in Reihe..
Und das wirkt sich auch auf das Gesamtnetz aus, obwohl nur mit OvSCent kommuniziert werden soll.
lks
Wenn man es so sieht, dann hast du natürlich recht. GANZ KLAR ! Mein Fehler !
Da es aber bei diesem Ansatz um die Latenz ging, ist der Weg das Ziel. Und dann habe ich keine 10 Switche in Reihe. Denn bis zum RB durchlaufe ich keine 10 Switche sondern nur 6. Denn ich glaube nicht, dass die verbindungsrelevanten Datenpakete vom OVS97 über den OVS87 bis hoch zur OVS69 läuft und dann zum GW in den OVS57 zurück.
Unabhängig von dieser meinen Fehlinterpretation ...
... ein Ping vom OVS97 zur 57 und zur 69 zeigt mir, dass der geprüfte Ansatz zur Fehlerbestimmung, nicht die vorherrschende Verkabelung ist ."Leider"!
Der Fehler liegt momentan verborgen ... bis der Ping zu lange dauert und sich erneut meldet. WERDE DANN WOHL MAL SCHAUEN, wer sich dann aus diesem Bereich angemeldet hat.
Danke ...
Da es aber bei diesem Ansatz um die Latenz ging, ist der Weg das Ziel. Und dann habe ich keine 10 Switche in Reihe. Denn bis zum RB durchlaufe ich keine 10 Switche sondern nur 6. Denn ich glaube nicht, dass die verbindungsrelevanten Datenpakete vom OVS97 über den OVS87 bis hoch zur OVS69 läuft und dann zum GW in den OVS57 zurück.
Unabhängig von dieser meinen Fehlinterpretation ...
... ein Ping vom OVS97 zur 57 und zur 69 zeigt mir, dass der geprüfte Ansatz zur Fehlerbestimmung, nicht die vorherrschende Verkabelung ist ."Leider"!
Der Fehler liegt momentan verborgen ... bis der Ping zu lange dauert und sich erneut meldet. WERDE DANN WOHL MAL SCHAUEN, wer sich dann aus diesem Bereich angemeldet hat.
Danke ...
Ich kenne die switche nicht, aber wenn sie managed sind wird es für die wohl auch logs geben!?
Schau doch mal bitte nach und poste ggf. ein paar interessante Zeilen.
Natürlich zensiert! ;)
Schau doch mal bitte nach und poste ggf. ein paar interessante Zeilen.
Natürlich zensiert! ;)
... Klar!!!! UND klar, haben sie! ;)!
Kann ich machen. Schaue mal rein und suche nach was Anrüchigem !
Danke !
Kann ich machen. Schaue mal rein und suche nach was Anrüchigem !
Danke !
