11
Ping funktioniert nur in 1 Richtung
Hallo,
ich habe folgendes Problem.
Ich kann nicht auf die Filefreigabe meines Fileservers zugreifen. Ich habe einen WAN-simulator aufgebaut und wollte damit nun testen.
Ich habe auch 2 Riverbeds um zu testen in wie weit sich der Datendurchsatz dann verbessert.
In einem Test zuvor hat es schon mal funktioniert. jedoch nun funktioniert es nicht weil. Was ich dort geändert habe war das ich einen Switch zwischen Netapp und Riverbed gehängt habe. Davor lief der Verkehr über einen Managed switch und dort habe ich keine eindeutigen auswertungen bekommen, weil über den switch auch anderer Datenverkehr läuft.
Hier mal ein Bild meiner Konfiguration. Vielleicht kann man jemand drüber schauen. Vielleicht handelt es sich ja um ein einfaches Problem.
Netapp Vfiler - 164.30.70.7
|
Switch - Keine IP-Adresse
|
Riverbed - 164.30.70.57
|
Nist Wanemulator - 164.30.70.60 und 192.168.0.3
|
Riverbed - 192.168.0.101
|
Switch - Keine IP-Adresse
|
Client (Vista und Windows 7) 192.168.0.6 und 192.168.0.7
folgende Route sind festgelegt auf der Netapp
Destination Gateway Flags Refs Use Interface
192.168/16 164.30.70.60 UGS 0 132 e0c
Subnetzmaske im 192er Netz 255.255.0.0
Subnetzmaske im 164er Netz 255.255.255.192
Der Ping funktioniert von beiden Clients aus zu jeder Netzkomponente.
Von der Netapp aus kann ich auch alles anpingen ausser die beiden Clients.
Ich kann von den Clients aus auch auf keine Freigaben von der Netapp zugreifen. Dies hat aber funktioniert solange der managed Switch drin war.
Ich hoffe jemand hat einen Vorschlag für mich. Vielen Dnak
mfg DerChirurg
ich habe folgendes Problem.
Ich kann nicht auf die Filefreigabe meines Fileservers zugreifen. Ich habe einen WAN-simulator aufgebaut und wollte damit nun testen.
Ich habe auch 2 Riverbeds um zu testen in wie weit sich der Datendurchsatz dann verbessert.
In einem Test zuvor hat es schon mal funktioniert. jedoch nun funktioniert es nicht weil. Was ich dort geändert habe war das ich einen Switch zwischen Netapp und Riverbed gehängt habe. Davor lief der Verkehr über einen Managed switch und dort habe ich keine eindeutigen auswertungen bekommen, weil über den switch auch anderer Datenverkehr läuft.
Hier mal ein Bild meiner Konfiguration. Vielleicht kann man jemand drüber schauen. Vielleicht handelt es sich ja um ein einfaches Problem.
Netapp Vfiler - 164.30.70.7
|
Switch - Keine IP-Adresse
|
Riverbed - 164.30.70.57
|
Nist Wanemulator - 164.30.70.60 und 192.168.0.3
|
Riverbed - 192.168.0.101
|
Switch - Keine IP-Adresse
|
Client (Vista und Windows 7) 192.168.0.6 und 192.168.0.7
folgende Route sind festgelegt auf der Netapp
Destination Gateway Flags Refs Use Interface
192.168/16 164.30.70.60 UGS 0 132 e0c
Subnetzmaske im 192er Netz 255.255.0.0
Subnetzmaske im 164er Netz 255.255.255.192
Der Ping funktioniert von beiden Clients aus zu jeder Netzkomponente.
Von der Netapp aus kann ich auch alles anpingen ausser die beiden Clients.
Ich kann von den Clients aus auch auf keine Freigaben von der Netapp zugreifen. Dies hat aber funktioniert solange der managed Switch drin war.
Ich hoffe jemand hat einen Vorschlag für mich. Vielen Dnak
mfg DerChirurg
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 155780
Url: https://administrator.de/contentid/155780
Printed on: April 23, 2024 at 07:04 o'clock
11 Comments
Latest comment
Das ist wie immer in 99% aller dieser Fälle ein Firewall oder ACL Filter Problem. Irgendwo wird ICMP Echo oder Echo Reply (Typ 8 oder Typ 0 ICMP) gefiltert !
Das gilt es herauszufinden. Ggf. hilft dir Traceroute (tracert) dabei.
Möglich ist auch eine inkonsistent vergebene IP Subnetzmaske.
Die Gefahr besteht bei dir, weil du bei einer klassischen Class C IP Adresse 192.168.0 mit normal 24 Bit Maske eine 16er Maske nutzt. Wenn einer dann unbedarft eine 24er annimmt bei einer Endgeräte Konfig weil Default nimmt das Unglück seinen Lauf.
Bedenke zudem auch das manche IP Stacks nicht mit CIDR Masken umgehen können die kleiner sind als Masken der eigentlichen Adressklasse. Auch das solltest du sicher klären.
Ob der Switch dazwischen manged oder nicht ist, spielt keinerlei Rolle. Es sei denn, dein sog. "managed" Switch war ein Layer 3 (Routing) Switch der zwischen mehreren Segmenten geroutet hat.
Dann hast du mit einem dummen L2 Switch als Ersatz natürlich ein Problem !
Das gilt es herauszufinden. Ggf. hilft dir Traceroute (tracert) dabei.
Möglich ist auch eine inkonsistent vergebene IP Subnetzmaske.
Die Gefahr besteht bei dir, weil du bei einer klassischen Class C IP Adresse 192.168.0 mit normal 24 Bit Maske eine 16er Maske nutzt. Wenn einer dann unbedarft eine 24er annimmt bei einer Endgeräte Konfig weil Default nimmt das Unglück seinen Lauf.
Bedenke zudem auch das manche IP Stacks nicht mit CIDR Masken umgehen können die kleiner sind als Masken der eigentlichen Adressklasse. Auch das solltest du sicher klären.
Ob der Switch dazwischen manged oder nicht ist, spielt keinerlei Rolle. Es sei denn, dein sog. "managed" Switch war ein Layer 3 (Routing) Switch der zwischen mehreren Segmenten geroutet hat.
Dann hast du mit einem dummen L2 Switch als Ersatz natürlich ein Problem !
Hallo, wieso hat es dann funktioniert bis ich den Switch getauscht habe?
Wieso komm ich dann vom Client aus per Ping zur Netapp?
Ausser mir verwendet nur noch ein Kollege dieses Netz (vorerst). Dieser Kollege hat das Netz aber mit aufgebaut.
Das Netz jetzt auf eine Subnetzmaske mit 255.255.255.0 umzubauen wäre sehr aufwendig und würde nicht unbedingt das Problem lösen.
Ich kann ja durch das komplette netzt von unten nach oben durchpingen und zurück. (Also der Ping kommt an)
Nur von der Netapp aus erreich ich die Clients nicht. Wenn etwas an der Konfiguration komplett falsch wäre würde ich ja auch nicht mehr in der Netzsegment 192.168.0.0 kommen. Deswegen weiß ich derzeit nicht genau wo ich den fehler suchen soll.
Könntest du mir helfen wenn ich nen trace ziehen und mir sagen woren es liegen könnte?
ich kann einen Trace von der Netapp aus machen und einen vom Client.
Wieso komm ich dann vom Client aus per Ping zur Netapp?
Ausser mir verwendet nur noch ein Kollege dieses Netz (vorerst). Dieser Kollege hat das Netz aber mit aufgebaut.
Das Netz jetzt auf eine Subnetzmaske mit 255.255.255.0 umzubauen wäre sehr aufwendig und würde nicht unbedingt das Problem lösen.
Ich kann ja durch das komplette netzt von unten nach oben durchpingen und zurück. (Also der Ping kommt an)
Nur von der Netapp aus erreich ich die Clients nicht. Wenn etwas an der Konfiguration komplett falsch wäre würde ich ja auch nicht mehr in der Netzsegment 192.168.0.0 kommen. Deswegen weiß ich derzeit nicht genau wo ich den fehler suchen soll.
Könntest du mir helfen wenn ich nen trace ziehen und mir sagen woren es liegen könnte?
ich kann einen Trace von der Netapp aus machen und einen vom Client.
Der Rückweg von der Netapp ist also gestört. Vermutlich ist dort das Routing in die Cleitnetze nicht korrekt.
Du musst also checken ob dort bzw. an den Gateways (Router) über die die Rückpakete gehen alle Subnetze bekannt sind (Routing Tabelle)
Wenn du eien Client im Netapp Segment hast mach von da einen Traceroute in die beiden Clientnetze es sei denn die Netapp kann selber tracerouten.
Alternativ checke in den Routern die sies Netze verbinden die Routing Tabelle.
Das hört sich zu 90% nach einer falschen Subnetzmaske oder fehlerhaften Routing Einträgen an.
Ggf. war der getausche Switch wirklich ein Layer 3 Switch der selber noch geroutet hat...dann hast du natürlich ein Problem.
Du musst also checken ob dort bzw. an den Gateways (Router) über die die Rückpakete gehen alle Subnetze bekannt sind (Routing Tabelle)
Wenn du eien Client im Netapp Segment hast mach von da einen Traceroute in die beiden Clientnetze es sei denn die Netapp kann selber tracerouten.
Alternativ checke in den Routern die sies Netze verbinden die Routing Tabelle.
Das hört sich zu 90% nach einer falschen Subnetzmaske oder fehlerhaften Routing Einträgen an.
Ggf. war der getausche Switch wirklich ein Layer 3 Switch der selber noch geroutet hat...dann hast du natürlich ein Problem.
Hallo,
ich habe den Switch getauscht. Jetzt hängt definitiv ein Layer 2 Switch drin.
Das alte könnte ein Layer 3 Switch gewesen sein. Das Routing in das Netz 192 hat er aber sicher nciht übernommen, weil Dieses Netz von mir nur für diesen Test aufgesetzt worden ist. Davon hat die Netzwerkgruppe nichts mitbekommen. Das Routing zwischen den Netzen übernimmt in diesem Fall der Wanemulator. Er besitzt 2 Netzwerkkarten.
Wieso funktioniert dann der Ping vom Client aus und kommt zurück.
Die Netapp kann Traceroute befehle. ICh werde ihn ausführen und hier posten. Ebenso werde ich den Traceroute vom Client aus ausführen.
ich habe den Switch getauscht. Jetzt hängt definitiv ein Layer 2 Switch drin.
Das alte könnte ein Layer 3 Switch gewesen sein. Das Routing in das Netz 192 hat er aber sicher nciht übernommen, weil Dieses Netz von mir nur für diesen Test aufgesetzt worden ist. Davon hat die Netzwerkgruppe nichts mitbekommen. Das Routing zwischen den Netzen übernimmt in diesem Fall der Wanemulator. Er besitzt 2 Netzwerkkarten.
Wieso funktioniert dann der Ping vom Client aus und kommt zurück.
Die Netapp kann Traceroute befehle. ICh werde ihn ausführen und hier posten. Ebenso werde ich den Traceroute vom Client aus ausführen.
Hier die Auswertung der Traceroute von der Netapp.
grb32@grb40> traceroute 192.168.06
traceroute to 192.168.06 (192.168.0.6), 30 hops max, 40 byte packets
1 164.30.70.60 (164.30.70.60) 0.999 ms 0.000 ms 0.000 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
vom Client bekomm ich die Rückmeldung der er einmal über den 192.168.0.3 springt und dann direkt bei der Netapp ankommt.
Wenn der Ping nicht funktioniert kann ich ja auch keine Netzlaufwerke mappen. Und auch nicht auf Freigaben der Netapp zugreifen.
Ich werde einen Trace ziehen und dann nach fehlern suchen. Wird aber etwas dauern bis cih den Trace bereit stellen kann.
grb32@grb40> traceroute 192.168.06
traceroute to 192.168.06 (192.168.0.6), 30 hops max, 40 byte packets
1 164.30.70.60 (164.30.70.60) 0.999 ms 0.000 ms 0.000 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
vom Client bekomm ich die Rückmeldung der er einmal über den 192.168.0.3 springt und dann direkt bei der Netapp ankommt.
Wenn der Ping nicht funktioniert kann ich ja auch keine Netzlaufwerke mappen. Und auch nicht auf Freigaben der Netapp zugreifen.
Ich werde einen Trace ziehen und dann nach fehlern suchen. Wird aber etwas dauern bis cih den Trace bereit stellen kann.
Also so wie ich das sehe,
hast du das Problem beim NistWanemulator,
welcher nicht mehr weis, wohin mit der 192.168.0.6 IP.
Da er ja den Ping auf der 164.30.70.60 bekommt, müsste er nun eine Route haben,
die ihm das 192.168.0.* Netz bekannt macht.
Was bedeuten würde, dass er nicht vom 164.30.70.* Netz in das 192.168.0.* Netz Routen kann.
Weshalb hast du eigentlich in der Netapp eine Route eingetragen?
Die Netapp muss doch gar nicht Routen, wenn ich das anhand deiner Daten richtig
sehe.
Netapp Vfiler - 164.30.70.7
|
Switch - Keine IP-Adresse
|
Riverbed - 164.30.70.57
|
Nist Wanemulator - 164.30.70.60 und 192.168.0.3
|
Riverbed - 192.168.0.101
|
Switch - Keine IP-Adresse
|
Client (Vista und Windows 7) 192.168.0.6 und 192.168.0.7
hast du das Problem beim NistWanemulator,
welcher nicht mehr weis, wohin mit der 192.168.0.6 IP.
Da er ja den Ping auf der 164.30.70.60 bekommt, müsste er nun eine Route haben,
die ihm das 192.168.0.* Netz bekannt macht.
Was bedeuten würde, dass er nicht vom 164.30.70.* Netz in das 192.168.0.* Netz Routen kann.
Weshalb hast du eigentlich in der Netapp eine Route eingetragen?
Die Netapp muss doch gar nicht Routen, wenn ich das anhand deiner Daten richtig
sehe.
Netapp Vfiler - 164.30.70.7
|
Switch - Keine IP-Adresse
|
Riverbed - 164.30.70.57
|
Nist Wanemulator - 164.30.70.60 und 192.168.0.3
|
Riverbed - 192.168.0.101
|
Switch - Keine IP-Adresse
|
Client (Vista und Windows 7) 192.168.0.6 und 192.168.0.7
Ja, genau richtig ! Der netapp hat als default Gateway die 164.30.70.60 und schickt alles was er nicht kennt und in anderen IP Netzen leigt dorthin !
Das Gerät mit der IP 164.30.70.60 hat also KEINE gültige Route für das 192.168.0.0er Netz. Genau da musst du also suchen !!
Möglich wäre das dort auch eine Access Liste diese Packet filtert. Vermutlich fehlt aber nur eine entsprechende Route.
Übrigens: traceroute 192.168.06 ist ein ungültiger Befehl bzw. eine ungültige IP Adresse. Hoffe mal das das ein Dreckfuhler (richtig wäre natürlich 192.168.0.6) hier im Thread ist, denn mit der falschen IP muss ein traceroute (und auch alles andere) zwangsweise immer scheitern !!
Das Gerät mit der IP 164.30.70.60 hat also KEINE gültige Route für das 192.168.0.0er Netz. Genau da musst du also suchen !!
Möglich wäre das dort auch eine Access Liste diese Packet filtert. Vermutlich fehlt aber nur eine entsprechende Route.
Übrigens: traceroute 192.168.06 ist ein ungültiger Befehl bzw. eine ungültige IP Adresse. Hoffe mal das das ein Dreckfuhler (richtig wäre natürlich 192.168.0.6) hier im Thread ist, denn mit der falschen IP muss ein traceroute (und auch alles andere) zwangsweise immer scheitern !!
Hallo,
1 Fehler wurde von mir gefunden. In dem Wanemulator stand ein Flasches Standardgateway drin, das natürlich nicht mehr gültig ist weil ich den Switch getauscht hatte. Habe hier nun den Richtigen Gateway eingestellt. (Sich selbst)
Es funktioniert aber immer noch nicht. die Fehlersuche geht weiter.
1 Fehler wurde von mir gefunden. In dem Wanemulator stand ein Flasches Standardgateway drin, das natürlich nicht mehr gültig ist weil ich den Switch getauscht hatte. Habe hier nun den Richtigen Gateway eingestellt. (Sich selbst)
Es funktioniert aber immer noch nicht. die Fehlersuche geht weiter.
Irgendwo im gesamten Routing Pfad hast du noch ein weiteres falsches Gateway oder eine falsche Subnetzmaske...ganz sicher !!
was bekommst du denn nun bei dem "Traceroute" für ein ergebnis?
Hallo,
kann das an Priorisierten Paketen liegen in deinem Netz ? Die der Level 2 SW nicht tagged / untagged ?
Wird die MTU irgendwo überschritten oder gibt es Large Pakets ?
nach der Überschrift würde ich aber sagen es ist ein asyncrones routing (klassiker)
nur so überlegt
gruss
ulti
kann das an Priorisierten Paketen liegen in deinem Netz ? Die der Level 2 SW nicht tagged / untagged ?
Wird die MTU irgendwo überschritten oder gibt es Large Pakets ?
nach der Überschrift würde ich aber sagen es ist ein asyncrones routing (klassiker)
nur so überlegt
gruss
ulti
