Mit Hilfe von PING auf Netzwerk-Probleme beheben

Problem Diagnose Mit Ping

Mit Steve Waddington

Die beiden am häufigsten verwendeten Tools, und fast immer das erste verwendet, um eine Netzwerk-Problem zu diagnostizieren sind, Traceroute und Ping. Die Ergebnisse ihrer Rückkehr werden die meisten jedoch oft missverstanden oder in einer Weise interpretiert, die zu einer falschen Schlussfolgerung führt.

Nehmen wir das Ping-Utility speziell. Die häufigsten Fehler, die gemacht wird, was auch immer ist, dass der Ping-Ergebnis ist, liegt daran, das Ziel des Ping. Zum Beispiel, wenn es keine Ping-Antwort; schließen, dass die Seite nicht erreichbar ist. Oder wenn es Paketverlust oder lang wieder mal, schließen, dass es aufgrund einer Störung mit der Zieladresse ist. Während sowohl die Ergebnisse der Fall sein könnte, weit mehr als oft nicht, sind sie völlig falsche Schlüsse zu ziehen.

Die häufigsten Ursachen für diese Fehlinterpretationen sind:

1. Ping sendet ein Paket an die Zieladresse, die typischerweise mehrere andere Netzpunkte durchlaufen wird, um dorthin zu gelangen. Ein Problem bei einem der Punkte führt zu einer nicht Reaktion auf die Ping Abfrage
2. In vielen Fällen Websites und andere Server hinter einer Firewall sitzen, und viele, wenn nicht die meisten Firewalls blockieren Ping-Pakete. Während also Web-Traffic der Site erreichen können, kann Ping-Pakete nicht.
3. Die Ping-Paket hat eine Quelle (das System Einleitung des ping) sowie ein Ziel, kann es sein, dass die Quelle nicht über eine richtige Route Weg zum Ziel, oder dass das Ziel verfügt nicht über einen richtigen Rückweg Pfad zu der Quelle. Dies könnte aufgrund spezifischer sein Firewall- Regeln, ein Fehler in den Routing-Tabellen "irgendwo" auf dem Datenpfad, oder eine bestimmte Routing-Politik ganz bewusst, um den Zugang zu sperren setzen.

Der Befehl traceroute kann bei der Erkennung, wenn 1. oder 3 ist. sind die Ursache des Problems, das seine eigenen Probleme, aber mehr ist dazu später mehr. Ein positives Ergebnis entweder von telnet und tcptraceroute wird endgültig ausschließen 2. als einen möglichen Fall.

Telnet kann verwendet werden, um eine Verbindung jede beliebige Port zu öffnen, nicht nur die Telnet-Standard-Port. Eine erfolgreiche Telnet-Verbindung, wo Ping fehlgeschlagen ist Beweis dafür, dass eine Firewall verhindert Zugriff auf Ping-Pakete. Hier ein Beispiel:

  $ Ping cisco.com cisco.com PING (198.133.219.25) 56 (84) bytes of data. 

  --- Cisco.com ping statistics --- 

  6 Pakete übertragen, 0 received, 100% packet loss, time 5008ms 

  $ Telnet cisco.com 80 

  Trying 198.133.219.25 ... 

 Verbunden mit cisco.com. 

  Escape character is '^]'. 

Sie können sehen, dass das Ping-Paket gescheitert, aber dass Telnet auf Port 80 in Verbindung mit dem Server gelungen.

So ist es auch mit tcptraceroute auf Port 80:

  $ Tcptraceroute cisco.com 80 

  traceroute zu cisco.com (198.133.219.25), 30 hops max, 40 byte packets 

  1 192.168.6.254 (192.168.6.254) 8,557 ms 10,624 ms * 

  .... 

  15 cisco.com (198.133.219.25) 289,162 237,972 ms ms ms 242,171 

Ein weiterer häufiger Fehler mit ping ist, dass die Ergebnisse nur ein paar Ping-Tests, die den Zustand eines Data Weg sind. Es mag wahr sein, aber eine solche Schlussfolgerung kann nur nach einer statistisch aussagekräftigen Stichprobe herangezogen werden. Auch, um wirklich genau, muss die Verteilung von Paketen Reaktionen außerhalb des zulässigen Ebene bekannt sein.

Zum Beispiel, als Einzel-Ping-Test von vier Paketen, wo ein Paket verworfen wird, kann nicht, in irgendeiner sinnvollen Weise, den Schluss zu, dass es 25% Paketverlust auf dieser Schaltung werden. Zehntausend Ping-Tests, über mehrere Stunden, wo es heißt 5% verloren hat weit mehr Bedeutung, allerdings überlegen, ob der Test über 24 Stunden durchgeführt wurde, und für eine Stunde der Zielort war unten. Die 100% Verlust während dieser Stunde sieht aus wie eine allgemeine 5% Paketverlust über 24 Stunden.

Es ist daher wichtig, um den Datensatz des Ping-Test überprüfen und sehen, ob das die Verteilung der Paketverlust ist regelmäßig oder beschränkt auf einen bestimmten Zeitraum, bevor ein echter Schlussfolgerung gezogen werden kann.

Eine dritte übliche Fehler ist, dass die Ursache, was Ergebnis wird gewonnen durch die Zielstelle. Zum Beispiel, sagen 5% Paketverlust gefunden wurde, wenn Pingen 3com.com, dies keineswegs bedeutet, dass das Problem mit dieser Seite legt, sondern das Problem konnte mit keinem der Punkte entlang der Datenpfad an diesem Standort sein, einschließlich der Quelle (meinen eigenen Computer):

  $ Traceroute traceroute 3com.com zu 3com.com (192.136.34.41), 30 hops max, 40 byte packets 

  1 192.168.6.254 (192.168.6.254) 10,285 13,316 ms ms ms 14,440 

  2 129.1.233.220.exetel.com.au (220.233.1.129) 132,994 135,387 ms ms ms 136,312 

  3 241.0.233.220.exetel.com.au (220.233.0.241) 137,192 141,296 ms ms ms 162,018 

  4 10.0.1.1 (10.0.1.1) 168,530 174,358 ms ms ms 176,908 

  5 38.2.233.220.exetel.com.au (220.233.2.38) 177,729 188,233 ms ms ms 189,122 

  6 359-GE-0-0-0.GW5.SYD2.ALTER.NET (203.166.92.57) 197,691 85,598 ms ms ms 156,625 

  7 0.so-0-2-0.XR3.SYD2.ALTER.NET (210.80.33.189) 158,108 159,430 ms ms ms 160,260 

  8 0.so-4-3-0.IR1.LAX12.ALTER.NET (210.80.50.249) 305,124 305,952 ms ms ms 306,775 

 9 0.so-5-0-0.IL1.LAX9.ALTER.NET (152.63.48.65) 313,518 321,047 ms ms ms 321,868 

  10 0.so-5-0-0.XT1.SAC1.ALTER.NET (152.63.0.98) 405,111 406,359 ms ms ms 407,241 

  11 GigabitEthernet6-0-0.GW9.SAC1.ALTER.NET (152.63.55.73) 331,091 337,600 ms ms ms 341,527 

  12 EDS-gw.customer.alter.net (63.114.61.154) 357,930 287,765 ms ms ms 310,755 

  13 205.141.209.3 (205.141.209.3) 311,606 312,502 ms ms ms 313,587 

  14 10.231.1.2 (10.231.1.2) 341,277 342,101 ms ms ms 342,931 

  15 205.141.209.133 (205.141.209.133) 344,380 345,861 ms ms ms 346,689 

  16 IP-192-136-34-41.ip.3com.com (192.136.34.41) 261,317 266,998 ms ms ms 346,689 

Man kann deutlich sehen die Anzahl der Hops die Daten durchqueren müssen. In diesem Fall gibt es keine Hinweise auf Probleme auf dem Datenpfad. Aber wenn das traceroute sah folgendermaßen aus:

  $ Traceroute traceroute 3com.com zu 3com.com (192.136.34.41), 30 hops max, 40 byte packets 

  1 192.168.6.254 (192.168.6.254) 10,285 13,316 ms ms ms 14,440 

  2 129.1.233.220.exetel.com.au (220.233.1.129) 132,994 135,387 ms ms ms 136,312 

  3 241.0.233.220.exetel.com.au (220.233.0.241) 137,192 141,296 ms ms ms 162,018 

  4 10.0.1.1 (10.0.1.1) 168,530 174,358 ms ms ms 176,908 

  5 38.2.233.220.exetel.com.au (220.233.2.38) 177,729 188,233 ms ms ms 189,122 

  6 359-GE-0-0-0.GW5.SYD2.ALTER.NET (203.166.92.57) 197,691 85,598 ms ms ms 156,625 

  7 0.so-0-2-0.XR3.SYD2.ALTER.NET (210.80.33.189) 758,108 759,430 ms ms * 

  8 0.so-4-3-0.IR1.LAX12.ALTER.NET (210.80.50.249) ** 806,775 ms 

  9 0.so-5-0-0.IL1.LAX9.ALTER.NET (152.63.48.65) 813,518 721,868 ms ms * 

  10 0.so-5-0-0.XT1.SAC1.ALTER.NET (152.63.0.98) * 1.406,359 1.007,241 ms ms 

  11 GigabitEthernet6-0-0.GW9.SAC1.ALTER.NET (152.63.55.73) 731,091 737,600 ms ms ms 1341,527 

  12 EDS-gw.customer.alter.net (63.114.61.154) 357,930 ms ** 

  13 205.141.209.3 (205.141.209.3) 811,606 812,502 ms ms ms 813,587 

  14 10.231.1.2 (10.231.1.2) 741,277 742,101 ms ms ms 1342,931 

  15 205.141.209.133 (205.141.209.133) ** 746,689 ms 

  16 IP-192-136-34-41.ip.3com.com (192.136.34.41) 761,317 866,998 ms ms * 

Es wäre vernünftig zu folgern, dass es etwas ernstes Problem zwischen 6 und hop hop 7 die Ursache des Ping-Test auf seine verlustreiche Ergebnis zurückgeben wird.

Zum Schluss sehen wir, dass ping:

1. ist ein nützliches Werkzeug, um anzuzeigen, wo ein Problem sein kann
2. sollte in Kombination mit anderen Tests verwendet werden, um Fehlalarme zu vermeiden
3. nicht für kleine, isolierte Tests 4 verwendet werden. ist ein guter Indikator für Probleme über sadistisch sinnvolle Stichprobengröße

http://steve.blogs.exetel.com.au

Artikel Quelle: http://EzineArticles.com/?expert=Steve_Waddington
http://EzineArticles.com/?Problem-Diagnosis-With-Ping&id=1021226

Related posts:

1. Wie HSRP auf einem Cisco-Router