Video: Network down: stress op kantoor! 2024
Laag 3-kwesties betreffen natuurlijk pakketten. Over het algemeen geldt dat hoe hoger in de protocolstack een probleem ligt, hoe meer dingen er verkeerd aan kunnen zijn. Op de routeringslaag (één vroege naam voor laag 3) kunnen routes naar een bepaalde bestemming ontbreken, kunnen lussen of kunnen pakketten in een zwart gat worden verzonden.
Binnen het netwerk van de router zijn hulpmiddelen aanwezig om de werking van de protocollen zelf te onderzoeken, zoals het show-route-protocol ospf of bgp-samenvatting tonen van operationele bedieningsopdrachten. U kunt deze opdrachten gebruiken om inzicht te krijgen in de werking van respectievelijk de OSPF- en BGP-routeringsprotocollen.
Echter, zoals je al hebt gezien, worden problemen bij Laag 3 vaak veroorzaakt door gebeurtenissen in Laag 2. Desondanks kunt u vertrouwen op de SNMP-polling en traps en Ethernet OAM om problemen vast te leggen op het niveau van de netwerkrouterverbinding. Bekijk nu een probleem dat eigenlijk een probleem is in de pakketlaag. Hier gebruikt u een typisch hulpprogramma voor eindgebruikers - traceroute - om de router te isoleren die het probleem veroorzaakt.
Traceroute verzendt een pakket hop-by-hop van de ene router naar de andere totdat de bestemmingshost is bereikt. Als een pakket arriveert bij een router die geen route naar de bestemming heeft, wordt een bestemming niet bereikbare ICMP-bericht teruggestuurd naar de originator.
Wanneer u traceroute gebruikt, moet u onthouden dat het probleem meestal niet is bij de laatste hop om te reageren op de traceroute, maar na op het laatste apparaat.
Als alles goed is, is de bestemming normaal gesproken vijf hops verwijderd van de bronhost. Een wijziging in het netwerkadres van de responder is een indicatie dat het pakket is verplaatst van een belangrijk deel van het netwerk naar een ander (bijvoorbeeld van klantnetwerk naar serviceprovider-netwerk).
In het volgende ziet u hoe de routers normaal reageren op een traceroute onderweg naar Dest-Host:
user @ host> traceroute 10. 2. 2. 1 traceroute naar 10. 2. 2. 1 (10 2. 2. 1), 30 hops max, 40 byte pakketten 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)
Kijk nu wat er gebeurt als de link - de enige link trouwens - tussen de klantrouter (Cust-Router2) en de router van de serviceprovider (Prov-Rtr1) mislukt:
gebruiker @ host> traceroute 10.2. 2. 1 traceroute naar 10. 2. 2. 1 (10. 2. 2. 1), 30 hops max, 40 byte pakketten 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
The! H geeft aan dat u ICMP-host onbereikbare berichten van de tweede router ontvangt. Het lijkt erop dat dit Cust-Router2-apparaat het probleem is, maar merk op dat de pakketten zonder enige moeite naar Cust-Router2 zijn gegaan en terug zijn.
Nee, het probleem is na deze laatste stap, op de link tussen de klant en de serviceprovider. Er is geen handige route naar de bestemming op Cust-Router2, dus de! H is uitgegeven.
