7
Ping geht nicht raus
Hi ich habe ein kleines Problem mit einem unserer Fileserver.
Ich kann von einem XPClient den Rechner anpingen, doch wenn ich vom Fileserver einen Ping absetzen will, geht der Ping nicht über das Standardgateway und ich bekomme
"Request out of time".
Meine Daten:
Fileserver:
Windows Server 2003
IP: 10.1.40.1
Subnet: 255.255.255.0
Standardgateway: 10.1.40.254
Client:
Windows XP
IP: 10.1.3.66
Mein Pathping sieht wie folgt aus:
0 10.1.40.1
1 * * *
Warum will er hier nicht über das Standardgateway????
Der Server ist nicht als Router eingerichtet!!!!!
Hat jemand eine Idee?? Freue mich über jeden Tipp.
Ich kann von einem XPClient den Rechner anpingen, doch wenn ich vom Fileserver einen Ping absetzen will, geht der Ping nicht über das Standardgateway und ich bekomme
"Request out of time".
Meine Daten:
Fileserver:
Windows Server 2003
IP: 10.1.40.1
Subnet: 255.255.255.0
Standardgateway: 10.1.40.254
Client:
Windows XP
IP: 10.1.3.66
Mein Pathping sieht wie folgt aus:
0 10.1.40.1
1 * * *
Warum will er hier nicht über das Standardgateway????
Der Server ist nicht als Router eingerichtet!!!!!
Hat jemand eine Idee?? Freue mich über jeden Tipp.
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: 58937
Url: https://administrator.de/contentid/58937
Ausgedruckt am: 24.11.2024 um 20:11 Uhr
7 Kommentare
Neuester Kommentar
Ob der Server Router ist oder nicht spielt keine Rolle ! Ping und Traceroute Packete sendet er immer aus.
Es ist möglich das dein Gateway ICMP Typ 8 Packete filtert oder generell ICMP filtert aus Sicherheitsgründen. Ich denke mal das tracert (traceroute) genau das gleiche Ergebnis liefert, oder ?
Wichtig ist das du erstmal klärst ob du dein Gateway 10.1.40.254 überhaupt pingen kannst als es netztechnisch erreichen kannst. Darüber schreibst du leider nichts
Klappt das kannst du dich ertsmal nur Hop für Hop zum Ziel hangeln und sehen wo es hakt.
Also erstmal das lokale Gateway/Router pingen....klappt das ???
Dann das ausgehende Interface des Gateways/Routers pingen....klappt das ???
Ggf. den Router connecten und direkt von dort das Ziel und die Quelle pingen..klappt das ???
In so gut wie allen dieser Fälle ist auf dem Ziel ein falsches oder gar kein Gateway konfiguriert so das Packete den Weg nicht zurückfinden.
Wenn es dir nur um das pathping oder traceroute Verhalten geht ist es möglich das der Router eben dies filtert. Pathping ist eine Kombination aus ICMP Typ 8 (TTL) Packeten und Ping. Bei traceroute ist es nur ICMP Typ 8 oder bei neuren Linux/Unix OSes auch UDP Port 33434 bis 33534 und ICMP Typ 8.
Es ist möglich das dein Gateway ICMP Typ 8 Packete filtert oder generell ICMP filtert aus Sicherheitsgründen. Ich denke mal das tracert (traceroute) genau das gleiche Ergebnis liefert, oder ?
Wichtig ist das du erstmal klärst ob du dein Gateway 10.1.40.254 überhaupt pingen kannst als es netztechnisch erreichen kannst. Darüber schreibst du leider nichts
Klappt das kannst du dich ertsmal nur Hop für Hop zum Ziel hangeln und sehen wo es hakt.
Also erstmal das lokale Gateway/Router pingen....klappt das ???
Dann das ausgehende Interface des Gateways/Routers pingen....klappt das ???
Ggf. den Router connecten und direkt von dort das Ziel und die Quelle pingen..klappt das ???
In so gut wie allen dieser Fälle ist auf dem Ziel ein falsches oder gar kein Gateway konfiguriert so das Packete den Weg nicht zurückfinden.
Wenn es dir nur um das pathping oder traceroute Verhalten geht ist es möglich das der Router eben dies filtert. Pathping ist eine Kombination aus ICMP Typ 8 (TTL) Packeten und Ping. Bei traceroute ist es nur ICMP Typ 8 oder bei neuren Linux/Unix OSes auch UDP Port 33434 bis 33534 und ICMP Typ 8.
Hi,
das sieht eher so aus, als wäre am Client die (XP) Firewall oder eine andere Desktop Firewall aktiv.
Gruß
cykes
das sieht eher so aus, als wäre am Client die (XP) Firewall oder eine andere Desktop Firewall aktiv.
Gruß
cykes
Danke für die schnelle antwort.
Ping erreicht mein Gateway 10.1.40.254.
Ein Phänomen ist, wenn ich einen anderen Client mit der IP-Adresse 10.103.*.*; 10.2.*.*; 10.3.*.* oder 10.1.130.* anpinge oder trace absetze, nutzt der Server das Gateway.
Trace sieht hier wie folgt aus:
10.1.40.1
10.1.40.254
usw...
jedoch bei einem Trace auf die 10.1.3.*
kommt sofort "Request out of time".
Ping erreicht mein Gateway 10.1.40.254.
Ein Phänomen ist, wenn ich einen anderen Client mit der IP-Adresse 10.103.*.*; 10.2.*.*; 10.3.*.* oder 10.1.130.* anpinge oder trace absetze, nutzt der Server das Gateway.
Trace sieht hier wie folgt aus:
10.1.40.1
10.1.40.254
usw...
jedoch bei einem Trace auf die 10.1.3.*
kommt sofort "Request out of time".
an der Firewall kommt leider nichts davon an.
Wir haben keine Desktop Firewall, sondern eine externe Firewall.
Sorry für die fehlenden Infos.
Firewall ist hierfür freigeschalten.
Wir haben keine Desktop Firewall, sondern eine externe Firewall.
Sorry für die fehlenden Infos.
Firewall ist hierfür freigeschalten.
Hast du in dem Server 2 oder mehr Netzwerkkarten ???
Wenn ja nutzt der Server eventuell für das 10.1.3.x/24 Subnetz ein anderes Interface.
Wenn du keine weitere NIC im Server hast, dann kann es eigentlich nur ein falscher statischer Routeeintrag auf dem Server oder dem def. Gateway sein, der Traffic ans 10.1.3.x/24er Subnetz an ein nicht existentes Gateway schickt oder eine falsche oder nichtexistente IP Adresse für dies Gateway benutzt.
Das kannst du checken indem du mal route print in der Eingabeaufforderung eingibst. Ggf. befindet sich dort ein falscher statischer Routeeintrag für dies 10.1.3.x Subnetz.
Diese falsche Route, kann sich allerdings auch auf dem Router/Gateway selber befinden wenn der Server sauber sein sollte. Auch das solltest du checken !
Wenn nicht, kann es eigentlich nur ein Firewall oder Accesslisten Problem handeln. Das ist das einzige was noch überbleibt !
Wenn ja nutzt der Server eventuell für das 10.1.3.x/24 Subnetz ein anderes Interface.
Wenn du keine weitere NIC im Server hast, dann kann es eigentlich nur ein falscher statischer Routeeintrag auf dem Server oder dem def. Gateway sein, der Traffic ans 10.1.3.x/24er Subnetz an ein nicht existentes Gateway schickt oder eine falsche oder nichtexistente IP Adresse für dies Gateway benutzt.
Das kannst du checken indem du mal route print in der Eingabeaufforderung eingibst. Ggf. befindet sich dort ein falscher statischer Routeeintrag für dies 10.1.3.x Subnetz.
Diese falsche Route, kann sich allerdings auch auf dem Router/Gateway selber befinden wenn der Server sauber sein sollte. Auch das solltest du checken !
Wenn nicht, kann es eigentlich nur ein Firewall oder Accesslisten Problem handeln. Das ist das einzige was noch überbleibt !
Der Server (HP DL 380) besitzt 2 Netzwerkkarten, jedoch sind diese über ein Tool "HP Network Utility 7" welches die 2 Netzwerkkarten zu ein Team zusammenfügt und nur über eine IP-Adresse verfügt.
Route print hat für das Netz 10.1.3.x keinen eintrag.
Es gibt nur einen eintrag für 0.0.0.0 Mask 0.0.0.0 Gateway 10.1.40.254.
Standardgateway 10.1.40.254
Laut Tracert komm ich ja nicht einmal bis zum Gateway. Wo können sich auf dem Windows 2003 Server überall ACL´s befinden????? Nur in Route.exe oder gibt es hierfür noch andere Pfade, Dateien oder Regkeys???
@all: Vielen Dank für eure Unterstützung.
Route print hat für das Netz 10.1.3.x keinen eintrag.
Es gibt nur einen eintrag für 0.0.0.0 Mask 0.0.0.0 Gateway 10.1.40.254.
Standardgateway 10.1.40.254
Laut Tracert komm ich ja nicht einmal bis zum Gateway. Wo können sich auf dem Windows 2003 Server überall ACL´s befinden????? Nur in Route.exe oder gibt es hierfür noch andere Pfade, Dateien oder Regkeys???
@all: Vielen Dank für eure Unterstützung.
Dann können die nur noch in der Firewall hängen bleiben wenn dort eine Rule für das 10.1.3.x Subnetz eingetragen ist, das ist die einzige Möglichkeit die dann noch verbleibt. Am IP Stack selber kann es ja nicht liegen wenn Packete für alle anderen Subnetze problemlos rausgehen !
Allerdings lauert auch hier die Gefahr am Router 10.1.40.254 ! Dort kann es z.B. das 10.1.3.x Subnetz doppelt geben oder auch gar nicht geben. Dann würde das Packet auch hier verworfen werden.
Was du mal machen solltest ist den Server mal über einen kleinen Hub ans Netzwerk bringen. (Geht auch einbeinig) An diesen Hub schliesst du dann mal einen Packet Sniffer wie den Wireshark (www.wireshark.com) an und siehts mal ob dieses Packet ins 10.1.3.x Netz überhaupt gesendet wird. Bzw. wenn ja an welche Layer 2 (MAC Adresse) das geht ! Ist diese MAC mit dem lokalen Router identisch ???
Wenn du den Aufwand scheust kannst du Wireshark oder auch das Windows eigene Tool Net Monitor verwenden und den Trace auf dem Server direkt machen:
http://www.microsoft.com/downloads/details.aspx?familyid=AA8BE06D-4A6A- ...
Allerdings ist das dann SW die du auf dem Server installierst was ja nicht immer gewollt ist.
Noch ein Wort zu deinem Adapter Teaming:
Dir sollte klar sein das wenn du so ein Adapter Teaming aktivierst zur Bandbreitenerhöhung dies auch unbedingt auf der Switchseite geschehen muss !!! Teaming nutzt LACP nach IEEE 802.3ad was auch entsprechend auf dem Switch aktiviert sein muss !!! Ansonsten funktioniert es nicht !
Machst du das nicht blockt in der Regel der Switch intern einen Port. Geht nun gerade das Packet auf diesem Port ins Netz ist das Ergebnis klar !!
Da es aber scheinbar ja geht bei dir, ist anzunehmen das du hoffentlich die entsprechende Konfiguration der beiden Ports ebenfalls auf dem Switch erledigt hast !!!
Um diesen Fehler sicher auszuschliessen, kannst du den Server einmal testweise nur einbeinig (Der Link der 2ten Karte muss physisch down sein !) anschliessen.
Allerdings lauert auch hier die Gefahr am Router 10.1.40.254 ! Dort kann es z.B. das 10.1.3.x Subnetz doppelt geben oder auch gar nicht geben. Dann würde das Packet auch hier verworfen werden.
Was du mal machen solltest ist den Server mal über einen kleinen Hub ans Netzwerk bringen. (Geht auch einbeinig) An diesen Hub schliesst du dann mal einen Packet Sniffer wie den Wireshark (www.wireshark.com) an und siehts mal ob dieses Packet ins 10.1.3.x Netz überhaupt gesendet wird. Bzw. wenn ja an welche Layer 2 (MAC Adresse) das geht ! Ist diese MAC mit dem lokalen Router identisch ???
Wenn du den Aufwand scheust kannst du Wireshark oder auch das Windows eigene Tool Net Monitor verwenden und den Trace auf dem Server direkt machen:
http://www.microsoft.com/downloads/details.aspx?familyid=AA8BE06D-4A6A- ...
Allerdings ist das dann SW die du auf dem Server installierst was ja nicht immer gewollt ist.
Noch ein Wort zu deinem Adapter Teaming:
Dir sollte klar sein das wenn du so ein Adapter Teaming aktivierst zur Bandbreitenerhöhung dies auch unbedingt auf der Switchseite geschehen muss !!! Teaming nutzt LACP nach IEEE 802.3ad was auch entsprechend auf dem Switch aktiviert sein muss !!! Ansonsten funktioniert es nicht !
Machst du das nicht blockt in der Regel der Switch intern einen Port. Geht nun gerade das Packet auf diesem Port ins Netz ist das Ergebnis klar !!
Da es aber scheinbar ja geht bei dir, ist anzunehmen das du hoffentlich die entsprechende Konfiguration der beiden Ports ebenfalls auf dem Switch erledigt hast !!!
Um diesen Fehler sicher auszuschliessen, kannst du den Server einmal testweise nur einbeinig (Der Link der 2ten Karte muss physisch down sein !) anschliessen.
