Video: Probleme bei der Einwahl ins Wlan-Netzwerk mit Wlan Kennwort und Netzwerkschlüssel vermeiden 2025
Layer-3-Probleme betreffen natürlich Pakete. Allgemein gilt: Je höher oben im Protokollstapel ein Problem liegt, desto mehr Dinge können damit falsch sein. In der Routing-Schicht (ein früher Name für Layer 3) können Routen zu einem bestimmten Ziel fehlen, können sich schleifen oder Pakete in ein schwarzes Loch senden.
Im Router-Netzwerk befinden sich Werkzeuge, mit denen die Funktionsweise der Protokolle selbst überprüft werden kann, wie z. B. die Befehle show show protocol ospf oder show bgp summary operation mode. Sie können diese Befehle verwenden, um einen Einblick in die Funktionsweise der OSPF- bzw. BGP-Routing-Protokolle zu erhalten.
Wie Sie jedoch bereits gesehen haben, werden Probleme auf Layer 3 häufig durch Layer-2-Ereignisse verursacht. Trotzdem können Sie sich auf SNMP-Polling und Traps und Ethernet OAM verlassen, um Probleme auf der Netzwerkrouter-Verbindungsebene zu erfassen. Sehen Sie sich nun ein Problem an, das in der Paketschicht tatsächlich ein Problem ist. Hier verwenden Sie ein typisches Endbenutzer-Tool - traceroute -, um den Router zu isolieren, der das Problem verursacht.
Traceroute sendet ein Paket Hop-by-Hop von einem Router zum anderen, bis der Zielhost erreicht ist. Wenn ein Paket bei einem Router ankommt, der keine Route zum Ziel hat, wird eine Ziel nicht erreichbare ICMP-Nachricht an den Absender zurückgesendet.
Beachten Sie bei der Verwendung von traceroute, dass das Problem normalerweise nicht beim letzten Hop ist, um auf die Traceroute zu reagieren, aber darüber hinaus das letzte antwortende Gerät.
Wenn alles in Ordnung ist, ist das Ziel normalerweise fünf Hops vom Quellhost entfernt. Eine Änderung der Netzwerkadresse des Responders ist ein Hinweis darauf, dass sich das Paket von einem Hauptabschnitt des Netzwerks zu einem anderen bewegt hat (z. B. vom Kundennetzwerk zum Serviceanbieternetzwerk).
Beachten Sie im Folgenden, wie die Router normalerweise auf einem Traceroute auf dem Weg zu Dest-Host antworten:
user @ host> traceroute 10. 2. 2. 1 traceroute zu 10. 2. 2. 1 (10 2. 2. 1), 30 Hops max, 40 Byte Pakete 1 192. 168. 10. 1 (192. 168. 10. 1) 2. 617 ms 1. 690 ms 2. 851 ms (Cust-Router1) 2 192. 168. 10. 6 (192. 168. 10. 6) 3. 386 ms 3. 370 ms 5. 570 ms (Cust-Router2) 3 172. 16. 11. 1 (172. 16. 11. 1) 13. 513 ms 3. 905 ms 5. 060 ms (Prov-Rtr1) 4 172. 16. 44. 2 (172. 16. 44. 2) 3. 778 ms 5. 237 ms 5. 413 ms (Prov-Rtr2) 5 172. 16. 44. 27 (172. 16. 44. 27) 10. 867 ms 12. 568 ms 5. 991 ms (Dest-Host)
Jetzt sehen Sie, was passiert, wenn der Link - der einzige Link übrigens - zwischen dem Kunden-Router (Cust-Router2) und dem Dienstanbieter-Router (Prov-Rtr1) schlägt fehl:
user @ host> traceroute 10.2. 2. 1 Traceroute zu 10. 2. 2. 1 (10. 2. 2. 1), 30 Hops max, 40 Byte Pakete 1 192. 168. 10. 1 (192. 168. 10. 1) 1. 983 ms 2. 440 ms 2. 414 ms (Cust-Router1) 2 192. 168. 10. 6 (192. 168. 10. 6) 2. 883 ms! H 4. 136 ms ! H 2. 114 ms! H
Das! H gibt an, dass ICMP-Host-Nachrichten vom zweiten Router nicht erreichbar sind. Es könnte so aussehen, als sei dieses Cust-Router2-Gerät das Problem, aber beachte, dass die Pakete ohne Probleme zum Cust-Router2 und zurück gegangen sind.
Nein, das Problem ist jenseits dieses letzten Hops, auf der Verbindung zwischen dem Kunden und dem Dienstanbieter. Es gibt keine nützliche Route zum Ziel auf Cust-Router2, also die! H wird ausgegeben.
