Video: Eukaryopolis - The City of Animal Cells: Crash Course Biology #4 2025
Layer 3 spørgsmål vedrører pakker, selvfølgelig. Generelt, jo højere op i protokollen stakken et problem ligger, jo flere ting der kan være forkert med det. Ved ruteringslaget (et tidligt navn til Layer 3) kan ruter til en given destination være fraværende, kan sløjfe eller kan sende pakker til et sort hul.
Inden for router-netværket er værktøjer til at undersøge funktionen af protokollerne selv, som f.eks. Visningsruteprotokollen ospf eller vise bgp summariske operationelle tilstandskommandoer. Du kan bruge disse kommandoer til at få indsigt i driften af henholdsvis OSPF og BGP routing protokoller.
Som du allerede har set, er problemer på Layer 3 imidlertid ofte forårsaget af Layer 2-begivenheder. Alligevel kan du stole på SNMP-polling og fælder og Ethernet OAM for at indhente problemer på netværkets router-linkniveau. Tag et kig på et problem, der faktisk er et problem på pakkelaget. Her bruger du et typisk slutbrugerværktøj - traceroute - for at isolere routeren, der forårsager problemet.
Traceroute sender en pakke hop-by-hop fra en router til en anden, indtil destinationsværten er nået. Hvis en pakke ankommer til en router, der ikke har nogen rute til destinationen, sendes en destination ikke tilgængelig ICMP-meddelelse tilbage til originatoren.
Når du bruger traceroute, skal du huske på, at problemet normalt ligger ikke i sidste forsøg på at reagere på traceroute, men ud over den sidste reagens.
Når alt er godt, er destinationen normalt fem humle væk fra kildeværten. En ændring i responderens netværksadresse er en indikation på, at pakken er flyttet fra en stor del af netværket til en anden (fra kundenetværk til serviceudbydernetværket, for eksempel).
I det følgende skal du bemærke, hvordan routerne normalt svarer til en traceroute på vej til Dest-Host:
bruger @ vært> traceroute 10. 2. 2. 1 traceroute til 10. 2. 2. 1 (10 2. 2. 1), 30 humle maks. 40 byte pakker 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)
Se nu hvad der sker, hvis linket - den eneste link forresten - mellem kundens router (Cust-Router2) og router til tjenesteudbyderen (Prov-Rtr1) fejler:
user @ host> traceroute 10.2. 2. 1 traceroute til 10. 2. 2. 1 (10. 2. 2. 1), 30 humle max, 40 byte pakker 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
Den! H angiver, at du får ICMP-værtens uopnåelige meddelelser fra den anden router. Det kan se ud som om denne Cust-Router2-enhed er problemet, men bemærk at pakkerne har fundet deres vej til Cust-Router2 og tilbage uden nogen problemer overhovedet.
Nej, problemet er ud over dette sidste hop, på forbindelsen mellem kunden og tjenesteudbyderen. Der er ingen nyttig rute til destinationen på Cust-Router2, så det! H udstedes.
