10
Nur Teile eines Netzes erreichbar
Hallo,
zu meinem Problem gab es schon mal einen Beitrag von mir, diesen habe ich geschlossen da das Problem vom Kunden nicht mehr als Problem eingestuft wurde.
Jetzt hat der Kunde aber festgestellt das es doch ein Problem ist.
Folgende Situation.
Lokales Netz ---- Cisco 3900 als VPN Device ---- Internet ----- Cisco 877 VPN Gegenstelle ----- L2 Cisco 2960 Switch --- entferntes Netz
Also ein klassischer VPN Aufbau wie er wohl tausendfach in Betrieb ist.
Nur, im entfernten Netz sind nicht alle Endgeräte erreichbar.
Ich erreiche per netscan den Cisco 877 sowie einen Teil des entfernten Netzes, mit Ausnahme von 8 IP Adressen (aufeinander folgend) , darunter der Switch, die mitten im Netzwerk liegen.
Auch ein direkter Ping auf die Maschinen ist nicht möglich
Vom Router aus kann ich alle Endgeräte im Netz anpingen, inklusive Switch. Auf allen Geräten ist der Cisco 877 als Gateway eingetragen.
Ein Techniker vor Ort konnte alle Geräte über netscan erreichen.
Bei genauerer Analyse habe ich festgestellt das auf dem Switche diverse "runts" also zu kleine Pakete gezählt werden.
Runts sind Pakete die kleiner sind als64 KB und daher vom Switch verworfen werden.
Kennt einer die mögliche Ursachen für runts?
Es gibt in der Verkabelung in den Einzelnen Schaltschränken (Maschinenbau) Hutschienenadapter von R+M auf die das Verlegekabel in Schneidklemmen eingepresst wird.
Bei diesen Adaptern fehlen die Abdeckungen mit denen die Kabel in die Stecker eingepresst werden. Ein Elektriker vor Ort beim Kunden meinte "sieht so aus als wären die Kabel mit dem Schraubendreher eingedrückt worden".
Ich vermute mal das hier zumindest ein Teil des Problems herrührt.
Hat jemand noch eine andere Idee?
Da der Kunde nicht in Europa sitzt ist es ein bisschen umständlich komplett neue Stecker zuliefern und neu auflegen zu lassen.
brammer
zu meinem Problem gab es schon mal einen Beitrag von mir, diesen habe ich geschlossen da das Problem vom Kunden nicht mehr als Problem eingestuft wurde.
Jetzt hat der Kunde aber festgestellt das es doch ein Problem ist.
Folgende Situation.
Lokales Netz ---- Cisco 3900 als VPN Device ---- Internet ----- Cisco 877 VPN Gegenstelle ----- L2 Cisco 2960 Switch --- entferntes Netz
Also ein klassischer VPN Aufbau wie er wohl tausendfach in Betrieb ist.
Nur, im entfernten Netz sind nicht alle Endgeräte erreichbar.
Ich erreiche per netscan den Cisco 877 sowie einen Teil des entfernten Netzes, mit Ausnahme von 8 IP Adressen (aufeinander folgend) , darunter der Switch, die mitten im Netzwerk liegen.
Auch ein direkter Ping auf die Maschinen ist nicht möglich
Vom Router aus kann ich alle Endgeräte im Netz anpingen, inklusive Switch. Auf allen Geräten ist der Cisco 877 als Gateway eingetragen.
Ein Techniker vor Ort konnte alle Geräte über netscan erreichen.
Bei genauerer Analyse habe ich festgestellt das auf dem Switche diverse "runts" also zu kleine Pakete gezählt werden.
Runts sind Pakete die kleiner sind als64 KB und daher vom Switch verworfen werden.
Kennt einer die mögliche Ursachen für runts?
Es gibt in der Verkabelung in den Einzelnen Schaltschränken (Maschinenbau) Hutschienenadapter von R+M auf die das Verlegekabel in Schneidklemmen eingepresst wird.
Bei diesen Adaptern fehlen die Abdeckungen mit denen die Kabel in die Stecker eingepresst werden. Ein Elektriker vor Ort beim Kunden meinte "sieht so aus als wären die Kabel mit dem Schraubendreher eingedrückt worden".
Ich vermute mal das hier zumindest ein Teil des Problems herrührt.
Hat jemand noch eine andere Idee?
Da der Kunde nicht in Europa sitzt ist es ein bisschen umständlich komplett neue Stecker zuliefern und neu auflegen zu lassen.
brammer
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: 168406
Url: https://administrator.de/contentid/168406
Ausgedruckt am: 13.11.2024 um 22:11 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
wenn es wirklich an der Verkabelung liegt, dann könnte man doch mal versuchen, die betreffenden Geräte an einen anderen Port des Patchfeldes zu hängen? Deine runts sind definitiv zerstückelte Datenpakete, daher könnte man schon auf mangelhafte Verkabelung / Isolierung tippen.
Funktionieren denn die 8 Geräte im entfernten Netz tadellos?
Viele Grüße
Allyfied
wenn es wirklich an der Verkabelung liegt, dann könnte man doch mal versuchen, die betreffenden Geräte an einen anderen Port des Patchfeldes zu hängen? Deine runts sind definitiv zerstückelte Datenpakete, daher könnte man schon auf mangelhafte Verkabelung / Isolierung tippen.
Funktionieren denn die 8 Geräte im entfernten Netz tadellos?
Viele Grüße
Allyfied
Hallo,
@allyfield
die Kommunkation im LAN funktioniert einwandfrei.
brammer
@allyfield
die Kommunkation im LAN funktioniert einwandfrei.
brammer
Noch mal abseits der Verkabelung: Wenn eines der betroffenen Geräte mal testweise eine IP bekäme, die nicht in dem betroffenen Bereich liegt, könnte man das Ganze doch schon mal eingrenzen.
(Wer weiß, wer da am Switch/Router gespielt hat...)
(Wer weiß, wer da am Switch/Router gespielt hat...)
Runts sind in der Regel wirklich Störungen auf dem Layer 1 oder aber Paket Fragemente die durch Störungen ausgelöst werden. Das würde aber im Resultat immer nur einen sehr sporadischen Ausfall bewirken aber niemals einen Komplettausfall das Teile gar nicht erreichbar sind. Die Tatsache das vom lokalen Router alles problemlos pingbar ist erhärtet das ja auch.
Das lässt vermuten das das Problem dann eher auf der WAN Strecke oder den lokalen Komponenten liegt. Ein Klassiker den du in Betracht gezogen hast ist sicher das Thema MTU innerhalb des VPN was aber bei einem Ping mit 64 Byte oder 128 Byte nicht greift. Die sollten auch bei falscher MTU immer sicher durchgehen.
Lokale Firewalls wollen wir mal auch nicht stressen, denn das hast du als Profi Netzwerker sicher gecheckt und im Griff.
Was einmal interessant wäre eins der nicht erreichbaren Clients auf einen Snifferport am Switch zu monitoren und von remote mal einen Ping anzustossen.
Hier müsste man nun den ARP Prozess vom VPN Router und wenigstens das ICMP Echo Request Paket sehen was über die VPN Leitung kommt und an das Ziel geht. Dieser Trace wäre sehr interessant. Auch der ARP Cache des VPN Routers ob dort z.B. diese nicht erreichbaren IPs und ihre Macs sichtbar sind.
Zusätzlich wäre mal zu klären was denn auf dem Rückweg passiert ?? Kann denn z.B. einer der nicht erreichbaren Clients "zurückpingen" also den Sender erreichen ? Auch hier wäre ein Sniffer Trace mal ganz spannend.
Da wirst du dir vermutlich Bits und Bytes ansehen müssen.
Der Vorschlag von oben einmal ein anderes Endgerät mit eben dieser nicht erreichbaren IP auszustatten und erneut testen wäre auch sinnvoll. Vorzugsweise sollte das ein Gerät sein was keinerlei Firewalls oder sowas in SW hat also ein Switch oder Router. Noch besser natürlich eines der Endgeräte die normal erreichbar sind.
Schon ein Problem was etwas strange ist !
Das lässt vermuten das das Problem dann eher auf der WAN Strecke oder den lokalen Komponenten liegt. Ein Klassiker den du in Betracht gezogen hast ist sicher das Thema MTU innerhalb des VPN was aber bei einem Ping mit 64 Byte oder 128 Byte nicht greift. Die sollten auch bei falscher MTU immer sicher durchgehen.
Lokale Firewalls wollen wir mal auch nicht stressen, denn das hast du als Profi Netzwerker sicher gecheckt und im Griff.
Was einmal interessant wäre eins der nicht erreichbaren Clients auf einen Snifferport am Switch zu monitoren und von remote mal einen Ping anzustossen.
Hier müsste man nun den ARP Prozess vom VPN Router und wenigstens das ICMP Echo Request Paket sehen was über die VPN Leitung kommt und an das Ziel geht. Dieser Trace wäre sehr interessant. Auch der ARP Cache des VPN Routers ob dort z.B. diese nicht erreichbaren IPs und ihre Macs sichtbar sind.
Zusätzlich wäre mal zu klären was denn auf dem Rückweg passiert ?? Kann denn z.B. einer der nicht erreichbaren Clients "zurückpingen" also den Sender erreichen ? Auch hier wäre ein Sniffer Trace mal ganz spannend.
Da wirst du dir vermutlich Bits und Bytes ansehen müssen.
Der Vorschlag von oben einmal ein anderes Endgerät mit eben dieser nicht erreichbaren IP auszustatten und erneut testen wäre auch sinnvoll. Vorzugsweise sollte das ein Gerät sein was keinerlei Firewalls oder sowas in SW hat also ein Switch oder Router. Noch besser natürlich eines der Endgeräte die normal erreichbar sind.
Schon ein Problem was etwas strange ist !
Hallo,
das mit der MTU werde ich morgen pürfen, allerdings wundert mich ja das konstant die selben Geräte nicht erreichbar sind. Wenn das togglen würde, und immer mal andere Geräte nicht erreichbar wären käme MTU für mich in Betracht, aber da der Anfang des Netzes erreichbar ist, dann ein Teil nicht und der Rest wieder erreichbar ist glaube ich nicht an die MTU.
Darüberhinaus müsste ich beim Marokkanischen Provider erstmal rausfinden mit welcher MTU ich arbeiten müsste oder ich setze die MTU runter und schaue was passiert.
Lokale Firewalls gibt es nicht. Fällt also aus.
Das mit dem Mirroring ist schwierig da ich im Prinzip alles Remote machen müsste und vor Ort nur einen Elektriker habe der noch andere Aufgaben hat und der mit der Materie nicht vertraut ist.
Den ARP Cahce habe ich schon ausgelesen, nicht erreichbare Geräte werden also von hier auch als unbekannt bezeichnet, vor Ort sind die Einträge im ARP table normal.
Ein anderes Gerät mit einer der fehlenden IP Adressen werde ich morgen prüfen.
Allerdings hat mein Elektriker inzwischen definitv festgestellt das im Hutschienenstecker zwei kleine Teile fehlen.
Zwei kleine Kunststoffabdeckungen die eigentlich für das Einpressen der Kabel in die Schneidklemmen da sind, fehlen schlich und ergreifend. Außerdem hat irgendein technisches Genie vor Ort den Belegungsstandard (568B) geflissentlich ignoriert.
Und mit der Verlegung der Kabel ist mein Elektriker auch nicht zufrieden, Biegeradius war für das technihsche Genie wohl auch eher ein Fremdwort.
brammer
das mit der MTU werde ich morgen pürfen, allerdings wundert mich ja das konstant die selben Geräte nicht erreichbar sind. Wenn das togglen würde, und immer mal andere Geräte nicht erreichbar wären käme MTU für mich in Betracht, aber da der Anfang des Netzes erreichbar ist, dann ein Teil nicht und der Rest wieder erreichbar ist glaube ich nicht an die MTU.
Darüberhinaus müsste ich beim Marokkanischen Provider erstmal rausfinden mit welcher MTU ich arbeiten müsste oder ich setze die MTU runter und schaue was passiert.
Lokale Firewalls gibt es nicht. Fällt also aus.
Das mit dem Mirroring ist schwierig da ich im Prinzip alles Remote machen müsste und vor Ort nur einen Elektriker habe der noch andere Aufgaben hat und der mit der Materie nicht vertraut ist.
Den ARP Cahce habe ich schon ausgelesen, nicht erreichbare Geräte werden also von hier auch als unbekannt bezeichnet, vor Ort sind die Einträge im ARP table normal.
Ein anderes Gerät mit einer der fehlenden IP Adressen werde ich morgen prüfen.
Allerdings hat mein Elektriker inzwischen definitv festgestellt das im Hutschienenstecker zwei kleine Teile fehlen.
Zwei kleine Kunststoffabdeckungen die eigentlich für das Einpressen der Kabel in die Schneidklemmen da sind, fehlen schlich und ergreifend. Außerdem hat irgendein technisches Genie vor Ort den Belegungsstandard (568B) geflissentlich ignoriert.
Und mit der Verlegung der Kabel ist mein Elektriker auch nicht zufrieden, Biegeradius war für das technihsche Genie wohl auch eher ein Fremdwort.
brammer
Hallo brammer,
es wäre hilfreich, wenn man das Netz und die Subnetmask kennen würde.
Des weiteren welche IP-Bereiche erreichbar sind und welche nicht.
Vielleicht gibt es irgendwo eine ACL oder das Routing bezieht sich nicht auf das gesamte Subnetz vor Ort .
Dies gilt es auch bei den betroffenen Clients und dem remote Router zu prüfen (IP, Mask, Gateway).
So etwas kann passieren, weil man bei Installation ggf. von weniger Endgeräten ausgegeangen ist und hat (kleinere)Subnetze mit anderen Masks verwendet, deren Grenze man jetzt überschritten hat.
Also: erstmal alle Routings, ACLs (auch übers VPN) und lokalen IP-Einstelluingen prüfen.
Zu den runts: Das können physische Fehler sein. Sollten aber nicht die Ursache für dein eig. Problemn sein. Sonst wären die Geräte auch lokal nicht erreichbar !
Runts können auch bei falschen duplex-settings auftreten. Also auch das mal prüfen ...
mfg
x-window
es wäre hilfreich, wenn man das Netz und die Subnetmask kennen würde.
Des weiteren welche IP-Bereiche erreichbar sind und welche nicht.
Vielleicht gibt es irgendwo eine ACL oder das Routing bezieht sich nicht auf das gesamte Subnetz vor Ort .
Dies gilt es auch bei den betroffenen Clients und dem remote Router zu prüfen (IP, Mask, Gateway).
So etwas kann passieren, weil man bei Installation ggf. von weniger Endgeräten ausgegeangen ist und hat (kleinere)Subnetze mit anderen Masks verwendet, deren Grenze man jetzt überschritten hat.
Also: erstmal alle Routings, ACLs (auch übers VPN) und lokalen IP-Einstelluingen prüfen.
Zu den runts: Das können physische Fehler sein. Sollten aber nicht die Ursache für dein eig. Problemn sein. Sonst wären die Geräte auch lokal nicht erreichbar !
Runts können auch bei falschen duplex-settings auftreten. Also auch das mal prüfen ...
mfg
x-window
Hallo,
innerhalb eines Netzes mit einer /25 sind ein Teil der IP Adressen nicht erreichbar.
Genauer: 10.25.25.129 -131 sind erreichbar, 132-140 nicht erreichbar. 141 - 180 sind dann wieder erreichbar.
ACL gibt es hier keine die greifen, repsektive es gibt keine ACLs die auf einzelne IP Adressen gebunden sind.
Routing bezieht sich ebenfalls aufs gesamte Netz.
Die Netzwerk Einstellungen auf allen Maschinen wurden geprüft und stimmen (inklusive der Gateway Einstellungen)
Die Speed Einstellungen stehen alle auf "Auto",, und innerhalb des Netzes handelt es sich um mehrere Maschinen mit unterschiedlichen Aufgaben, aber quasi derselben Netzwerkhardware.
Im Moment wird die Verkabelung geprüft.
brammer
innerhalb eines Netzes mit einer /25 sind ein Teil der IP Adressen nicht erreichbar.
Genauer: 10.25.25.129 -131 sind erreichbar, 132-140 nicht erreichbar. 141 - 180 sind dann wieder erreichbar.
ACL gibt es hier keine die greifen, repsektive es gibt keine ACLs die auf einzelne IP Adressen gebunden sind.
Routing bezieht sich ebenfalls aufs gesamte Netz.
Die Netzwerk Einstellungen auf allen Maschinen wurden geprüft und stimmen (inklusive der Gateway Einstellungen)
Die Speed Einstellungen stehen alle auf "Auto",, und innerhalb des Netzes handelt es sich um mehrere Maschinen mit unterschiedlichen Aufgaben, aber quasi derselben Netzwerkhardware.
Im Moment wird die Verkabelung geprüft.
brammer
Hallo,
das Problem ist gelöst.
Dei Verkabelung war schlicht und ergreifend Müll.
Ein Teil der Stecker war nicht korrekt zusammengebaut. (Ich stehe schon mit dem Hersteller in Kontakt, vielleicht wird die Bastelanleitung überarbeitet.)
Außerdem waren die Kabel mit einem Schraubendreher auf die Patchfelder aufgelegt, LSA+ war der Kabel Firma vollkommen unbekannt.
Seitdem die Kabel sauber aufgelegt sind und die Stecker korrket zusammengebaut sind passt alles, und alle Geräte sind erreichbar.
brammer
das Problem ist gelöst.
Dei Verkabelung war schlicht und ergreifend Müll.
Ein Teil der Stecker war nicht korrekt zusammengebaut. (Ich stehe schon mit dem Hersteller in Kontakt, vielleicht wird die Bastelanleitung überarbeitet.)
Außerdem waren die Kabel mit einem Schraubendreher auf die Patchfelder aufgelegt, LSA+ war der Kabel Firma vollkommen unbekannt.
Seitdem die Kabel sauber aufgelegt sind und die Stecker korrket zusammengebaut sind passt alles, und alle Geräte sind erreichbar.
brammer
Alles wird gut 
Manchmal sind es nur die einfachen Dinge die einen zu Fall bringen ! Gut wenn nun alles klappt wie es soll !
Manchmal sind es nur die einfachen Dinge die einen zu Fall bringen ! Gut wenn nun alles klappt wie es soll !
Hallo,
ich bin froh dass das Problem gelöst ist.
Das die Kabel Firma Mist gebaut hat werden sie an der Rechnung bemerken.
brammer
ich bin froh dass das Problem gelöst ist.
Das die Kabel Firma Mist gebaut hat werden sie an der Rechnung bemerken.
brammer
