De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
traceroute In dit document wordt beschreven hoe de opdracht op verschillende systemen werkt.
Voorwaarden
Vereisten
Lezers van dit document moeten basiskennis hebben van een van deze besturingssystemen:
-
Cisco IOS®-software
-
Linux
-
Microsoft Windows
Gebruikte componenten
De informatie in dit document is van toepassing op de volgende software- en hardware-versies:
-
Cisco router waarop Cisco IOS-softwarerelease 12 wordt uitgevoerd
-
PC met Red Hat Linux
-
PC waarop MS Windows wordt uitgevoerd
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Conventies
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Achtergrondinformatie
Het
traceroute bevel staat u toe om de weg te bepalen een pakket neemt om aan een bestemming uit een bepaalde bron te krijgen door de opeenvolging van hop terug te keren het pakket heeft overgestoken. Dit hulpprogramma wordt geleverd met uw host-besturingssysteem (bijvoorbeeld Linux of Microsoft (MS) Windows) en met Cisco IOS-software.
Algemene werking
Als u de
traceroute ip-address opdracht op een bronapparaat (zoals een host, of een router die als host fungeert), stuurt het IP-pakketten naar de bestemming met Time To Live (TTL)-waarden die worden verhoogd tot de maximale opgegeven hoptelling. Standaard is dit 30. Doorgaans wordt elke router in het pad naar de bestemming door één eenheid in het TTL-veld afgedrukt terwijl deze pakketten worden doorgestuurd. Wanneer een router in het midden van het pad een pakket vindt met TTL = 1, reageert het met een ICMP-bericht (Internet Control Message Protocol) dat de "tijd heeft overschreden" aan de bron. Dit bericht laat de bron weten dat het pakket die bepaalde router als hop oversteekt
Er zijn enkele verschillen met de manier waarop het
traceroute commando wordt geïmplementeerd in de verschillende besturingssystemen die in dit document worden besproken.
Cisco IOS en Linux
De TTL voor de aanvankelijke User Datagram Protocol (UDP)-datagramsonde is ingesteld op 1 (of de minimale TTL, zoals door de gebruiker gespecificeerd in de uitgebreide
traceroute opdracht. De bestemmingsUDP haven van de aanvankelijke datagramsonde wordt geplaatst aan 33434 (of zoals die in de uitgebreide
traceroute beveloutput wordt gespecificeerd). Het uitgebreide
traceroute commando is een variatie van het normale
traceroute commando, die het mogelijk maakt de standaardwaarden van de parameters die worden gebruikt door de operatie, zoals TTL en het
traceroute bestemmingspoortnummer, te wijzigen.
Zie Uitgebreide ping en Uitgebreide traceroute
traceroute opdrachten begrijpen voor
meer informatie over het gebruik van de uitgebreide opdracht. De bron UDP poort van de eerste datagramsonde is willekeurig en heeft een logische operator OF met 0x8000 (zorgt voor een minimale bronpoort van 0x8000). Deze stappen illustreren wat er gebeurt wanneer het UDP-datagram wordt gestart:
Opmerking: de parameters kunnen worden geconfigureerd. Dit voorbeeld begint met n = 1 en eindigt met n = 3.
-
Het UDP-datagram wordt verzonden met TTL = 1, bestemmings-UDP-poort= 33434 en de gerandomiseerde bronpoort.
-
De UDP-bestemmingshaven wordt verhoogd, de UDP-bronpoort wordt gerandomiseerd en het tweede datagram wordt verzonden.
-
Stap 2 wordt herhaald voor maximaal drie sondes (of zo vaak als gevraagd in een uitgebreide traceroute opdrachtoutput). Voor elk van de verzonden sondes, ontvangt u een "TTL overschreden" bericht, dat wordt gebruikt om een stap-voor-stap pad naar de doelhost te bouwen.
-
TTL wordt verhoogd, en dit programma herhaalt zich met de incrementele poortnummers van de bestemming, als het ICMP-bericht over overschrijding van de tijd wordt ontvangen. U kunt ook een van deze berichten ontvangen:
-
Een ICMP-type 3, code 3 (bestemming onbereikbaar, poort onbereikbaar) bericht, dat aangeeft dat een host is bereikt.
-
Een host onbereikbaar, net onbereikbaar, maximum TTL overschreden, of een time-out type bericht, wat betekent dat de sonde aanwezig is.
Cisco-routers verzenden UDP-sonde-pakketten met een willekeurige bronpoort en een incrementele doelpoort (om de verschillende sondes te onderscheiden). Cisco-routers verzenden de ICMP-berichttijd die is overschreden, terug naar de bron waar het UDP/ICMP-pakket is ontvangen.
De Linux
traceroute -opdracht is gelijk aan de Cisco-routerimplementatie. Het maakt echter gebruik van een vaste bronpoort. Het
-n de optie in de
traceroute opdracht wordt gebruikt om een verzoek aan een naamserver te vermijden.
Microsoft Windows
De
tracert opdracht MS Windows maakt gebruik van ICMP-echoverzoek datagrammen in plaats van UDP-datagrammen als sondes. ICMP-echoverzoeken worden gestart met het verhogen van TTL en dezelfde bewerking als die wordt beschreven in Cisco IOS en Linux vindt plaats. De betekenis van het gebruiken van ICMP datagrammen van het echoverzoek is dat de definitieve hop niet zich op de reactie van een onbereikbaar bericht ICMP van de bestemmingsgastheer baseert. Het vertrouwt in plaats daarvan op een ICMP echo antwoordbericht.
De opdrachtsyntaxis is:
tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name
In deze tabel worden de opdrachtparameters uitgelegd:
Parameter | Beschrijving |
---|---|
-d | Specificeert niet om adressen aan computernamen op te lossen. |
-h maximum_hop | Specificeert het maximum aantal hop om naar een doel te zoeken. |
-j computerlijst | Specificeert een losse bronroute langs computer-lijst. |
-w time-out | Wacht op het aantal milliseconden dat is opgegeven door de time-out voor elk antwoord. |
target_name | Naam van de doelcomputer. |
ICMP-beperking van onbereikbare snelheden
ICMP-onbereikbaar is beperkt tot één pakket per 500 ms (als bescherming voor DoS-aanvallen (Denial of Service)) in een Cisco-router. Van Cisco IOS-softwarerelease 12.1 en hoger is deze snelheidswaarde configureerbaar. De geïntroduceerde opdracht is:
Router(config)#ip icmp rate-limit unreachable ?
<1-4294967295> Once per milliseconds
DF code 4, fragmentation needed and DF set
Deze beperking geldt voor het geaggregeerde percentage van alle onbereikbare ICMP-bestanden, zoals deze output laat zien. Raadpleeg RFC 792 voor meer informatie.
type = 3, code
0 = net unreachable;
1 = host unreachable;
2 = protocol unreachable;
3 = port unreachable;
4 = fragmentation needed and DF set;
5 = source route failed.
Deze beperking is niet van invloed op andere pakketten zoals ICMP-echoverzoeken of ICMP-berichten met een tijd overschreden.
Voorbeelden
Deze netwerktopologie wordt gebruikt voor de voorbeelden:
In elk van de drie voorbeelden, wordt een verschillend Apparaat A gebruikt. Van Apparaat A, wordt het
traceroute 10.1.4.2 bevel uitgevoerd aan Apparaat 7C.
In elk van de voorbeelden
debug ip packet detail de opdracht wordt uitgevoerd op apparaat 11A.
Cisco router met Cisco IOS-software
Dit uitgebreide
traceroute opdrachtvoorbeeld toont de opties die u kunt wijzigen wanneer u een
traceroute opdracht uitvoert vanaf een Cisco-router. In dit voorbeeld, wordt alles verlaten standaard:
rp-10c-2611#traceroute
Protocol [ip]:
Target IP address: 10.1.4.2
Source address: 10.1.1.1
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.1.4.2
1 10.1.1.2 4 msec 0 msec 4 msec
2 10.1.2.2 4 msec 4 msec 0 msec
3 10.1.3.2 0 msec 0 msec 4 msec
4 10.1.4.2 4 msec * 0 msec
rp-11a-7204#
*Dec 29 13:13:57.060: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Dec 29 13:13:57.060: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Dec 29 13:13:57.064: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Dec 29 13:13:57.068: ICMP type=11, code=0
In deze debug-uitvoer, stuurt Apparaat 11A ICMP-tijd overschreden berichten naar de bron van de sondes (10.1.1.1). Deze ICMP berichten zijn in antwoord op de eerste sondes die een TTL=1 hadden. Apparaat 11A decreteert de TTL naar nul, en reageert met de tijd overschreden berichten.
Opmerking: de UDP-sondes in deze debug-uitvoer worden om twee redenen niet weergegeven:
-
Apparaat 11A is niet de bestemming van de UDP-sondes.
-
TTL is decremented to zero en het pakket wordt nooit gerouteerd. Daarom herkent debug nooit het pakket.
*Dec 29 13:13:57.068: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.068: UDP src=40309, dst=33437
*Dec 29 13:13:57.068: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.068: ICMP type=11, code=0
*Dec 29 13:13:57.072: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.072: UDP src=37277, dst=33438
*Dec 29 13:13:57.072: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.072: ICMP type=11, code=0
*Dec 29 13:13:57.076: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.076: UDP src=36884, dst=33439
*Dec 29 13:13:57.076: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.076: ICMP type=11, code=0
Deze debug-uitvoer toont de UDP-sonde van bron 10.1.1.1 die bestemd is voor 10.1.4.2.
Opmerking: bij deze sondes TTL=2 (dit kan niet worden gezien met debug). Apparaat 11A verlaagt de TTL tot 1 en stuurt de UDP-pakketten door naar apparaat 7A. Apparaat 7A decreteert de TTL naar nul, en reageert met ICMP-tijd overschreden berichten.
*Dec 29 13:13:57.080: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.080: UDP src=37479, dst=33440
*Dec 29 13:13:57.080: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.080: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.084: UDP src=40631, dst=33441
*Dec 29 13:13:57.084: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.084: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39881, dst=33442
*Dec 29 13:13:57.088: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.088: ICMP type=11, code=0
U ziet de volgende drie UDP-sondes in deze debug-uitvoer. De TTL voor deze sondes is 3. Apparaat 11A bepaalt TTL tot 2 en stuurt ze door naar apparaat 7A. Apparaat 7A decreteert de TTL naar 1 en stuurt de pakketten door naar Apparaat 7B, dat de TTL naar nul decreteert en reageert met ICMP-tijd overschreden berichten.
*Dec 29 13:13:57.088: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39217, dst=33443
*Dec 29 13:13:57.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.092: ICMP type=3, code=3
*Dec 29 13:13:57.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.096: UDP src=34357, dst=33444
*Dec 29 13:14:00.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 28, forward
*Dec 29 13:14:00.092: UDP src=39587, dst=33445
*Dec 29 13:14:00.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 13:14:00.092: ICMP type=3, code=3
U kunt de laatste drie UDP-sondes in deze debug-uitvoer zien. De oorspronkelijke TTL van deze sondes was 4. De TTL werd verlaagd tot 3 door Apparaat 11A, vervolgens verlaagd tot 2 door Apparaat 7A, en vervolgens verlaagd tot 1 door Apparaat 7B. Apparaat 7C antwoordt met ICMP poort onbereikbare berichten, omdat het de bestemming van de sondes was.
Opmerking: Apparaat 7C verstuurt alleen twee ICMP-poortonbereikbare berichten vanwege de snelheidsbeperking.
PC met Linux
[root#linux-pc]#traceroute -n 10.1.4.2
traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets
1. 10.1.1.2 1.140 ms 0.793 ms 0.778 ms
2. 10.1.2.2 2.213 ms 2.105 ms 3.491 ms
1. 10.1.3.2 3.146 ms 2.314 ms 2.347 ms
1. 10.1.4.2 3.579 ms * 2.954 ms
rp-11a-7204#
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
In deze debug-uitvoer, stuurt Apparaat 11A ICMP-tijd overschreden berichten naar de bron van de sondes (10.1.1.1). Deze ICMP berichten zijn in antwoord op de eerste sondes die een TTL=1 hadden. Apparaat 11A decreteert de TTL naar nul, en reageert met de tijd overschreden berichten.
U ziet de UDP-sondes niet in deze debug-uitvoer om twee redenen:
-
Apparaat 11A is niet de bestemming van de UDP-sondes.
-
TTL is decremented to zero en het pakket wordt nooit gerouteerd. Daarom herkent debug nooit het pakket.
*Jan 2 07:17:27.894: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.894: UDP src=33302, dst=33438
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33439
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33440
*Jan 2 07:17:27.902: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.902: ICMP type=11, code=0
Opmerking: in deze debug-uitvoer ziet u nu de UDP-sonde uit bron 10.1.1.1 die bestemd is voor 10.1.4.2.
Opmerking: bij deze sondes TTL=2 (dit kan niet worden gezien met debug). Apparaat 11A verlaagt de TTL tot 1 en stuurt de UDP-pakketten door naar apparaat 7A. Apparaat 7A decreteert de TTL naar nul, en reageert met ICMP-tijd overschreden berichten.
*Jan 2 07:17:27.902: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.902: UDP src=33302, dst=33441
*Jan 2 07:17:27.906: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.906: ICMP type=11, code=0
*Jan 2 07:17:27.906: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.906: UDP src=33302, dst=33442
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0
*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33443
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0
De volgende drie UDP-sondes worden nu in deze debug-uitvoer gezien. De TTL voor deze sondes is 3. Apparaat 11A bepaalt TTL tot 2 en stuurt ze door naar apparaat 7A. Apparaat 7A decreteert de TTL naar 1 en stuurt de pakketten door naar Apparaat 7B, dat de TTL naar nul decreteert en reageert met ICMP-tijd overschreden berichten.
*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33444
*Jan 2 07:17:27.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.914: ICMP type=3, code=3
*Jan 2 07:17:27.914: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.914: UDP src=33302, dst=33445
*Jan 2 07:17:32.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
g=10.1.2.2, len 40, forward
*Jan 2 07:17:32.910: UDP src=33302, dst=33446
*Jan 2 07:17:32.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
g=10.1.1.1, len 56, forward
*Jan 2 07:17:32.914: ICMP type=3, code=3
Dit debug output toont de laatste drie UDP sondes. De oorspronkelijke TTL van deze sondes was 4. De TTL werd verlaagd tot 3 door Apparaat 11A, vervolgens verlaagd tot 2 door Apparaat 7A, en vervolgens verlaagd tot 1 door Apparaat 7B.
Apparaat 7C reageert dan met ICMP poort onbereikbare berichten, omdat het de bestemming van de sondes was.
Opmerking: Apparaat 7C verstuurt alleen twee ICMP-poortonbereikbare berichten vanwege de snelheidsbeperking.
PC - MS Windows uitvoeren
C:\>tracert 10.1.4.2
1 <10 ms <10 ms <10 ms 10.1.1.2
1 <10 ms <10 ms <10 ms 10.1.2.2
1 <10 ms <10 ms <10 ms 10.1.3.2
1 <10 ms 10 ms 10 ms 10.1.4.2
Trace complete
rp-11a-7204#
*Dec 29 14:02:22.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 78, forward
*Dec 29 14:02:22.236: UDP src=137, dst=137
*Dec 29 14:02:22.240: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:22.240: ICMP type=3, code=3
*Dec 29 14:02:23.732: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 78, forward
*Dec 29 14:02:23.732: UDP src=137, dst=137
*Dec 29 14:02:23.736: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:23.736: ICMP type=3, code=3
*Dec 29 14:02:25.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 78, forward
*Dec 29 14:02:25.236: UDP src=137, dst=137
*Dec 29 14:02:25.236: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:25.240: ICMP type=3, code=3
*Dec 29 14:02:26.748: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Dec 29 14:02:26.748: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0
In deze debug-uitvoer, stuurt Apparaat 11A ICMP-tijd overschreden berichten naar de bron van de sondes (10.1.1.1). Deze ICMP-berichten worden verzonden in reactie op de eerste sondes, die ICMP-echopakketten met een TTL=1 zijn. Apparaat 11A decreteert de TTL naar nul en reageert met de ICMP-berichten.
Opmerking: bovenaan zie je de NETBIOS-naamaanvragen. Deze verzoeken worden gezien als UDP-pakketten met bron- en doelpoorten van 137. Omwille van de duidelijkheid worden de NETBIOS-pakketten uit de rest van de debug-uitvoer verwijderd. U kunt de -d optie in de tracert opdracht gebruiken om het NETBIOS-gedrag uit te schakelen.
U ziet de ICMP-sondes in deze debug-uitvoer om twee redenen niet:
-
Apparaat 11A is niet de bestemming van de sondes ICMP.
-
TTL is decremented to zero en het pakket wordt nooit gerouteerd. Daarom herkent debug nooit het pakket.
*Dec 29 14:02:32.256: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.256: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.260: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.260: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.264: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.264: ICMP type=8, code=0
*Dec 29 14:02:32.264: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.264: ICMP type=11, code=0
In deze debug-uitvoer ziet u nu de ICMP-sonde van bron 10.1.1.1 die bestemd is voor 10.1.4.2.
Opmerking: in deze sondes, de TTL=2 (dit kan niet worden gezien met debug). Apparaat 11A verlaagt de TTL tot 1 en stuurt de UDP-pakketten door naar apparaat 7A. Apparaat 7A decreteert de TTL naar nul, en reageert met ICMP-tijd overschreden berichten.
*Dec 29 14:02:37.776: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.776: ICMP type=8, code=0
*Dec 29 14:02:37.776: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.776: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.780: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.780: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.784: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.784: ICMP type=11, code=0
U ziet de volgende drie ICMP-sondes in deze debug-uitvoer. De TTL voor deze sondes is 3. Apparaat 11A bepaalt TTL tot 2 en stuurt ze door naar apparaat 7A. Apparaat 7A decreteert de TTL naar 1 en stuurt de pakketten door naar Apparaat 7B, dat de TTL naar nul decreteert en reageert met ICMP-tijd overschreden berichten.
*Dec 29 14:02:43.292: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.292: ICMP type=8, code=0
*Dec 29 14:02:43.296: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.296: ICMP type=0, code=0
*Dec 29 14:02:43.296: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.296: ICMP type=8, code=0
*Dec 29 14:02:43.300: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.300: ICMP type=0, code=0
*Dec 29 14:02:43.300: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.300: ICMP type=8, code=0
*Dec 29 14:02:43.304: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.304: ICMP type=0, code=0
Dit debug uitvoer toont de laatste drie ICMP sondes. De oorspronkelijke TTL van deze sondes was 4. De TTL werd verlaagd tot 3 door Apparaat 11A, vervolgens verlaagd tot 2 door Apparaat 7A, en vervolgens verlaagd tot 1 door Apparaat 7B. Apparaat 7C antwoordt dan met ICMP echo antwoordberichten (type=0, code=0), aangezien het de bestemming van de sondes was.
Opmerking: de ICMP-echo-antwoordberichten zijn niet beperkt, aangezien de ICMP-poort onbereikbare berichten bevatte. In dit geval, ziet u alle drie het antwoordberichten van het Icmp- echo verzonden.
Aanvullende opmerkingen
In Cisco-routers zijn de codes voor een
traceroute opdrachtantwoord:
! -- success
* -- time out
N -- network unreachable
H -- host unreachable
P -- protocol unreachable
A -- admin denied
Q -- source quench received (congestion)
? -- unknown (any other ICMP message)
Als u de opdracht vanuit UNIX uitvoert
traceroute , dient u rekening te houden met deze items:
-
U kunt traceroute: icmp socket: Permission denied berichten.
traceroute
-
Het programma maakt gebruik van de Network Interface Tap (NIT) om in het netwerk te snuffelen. Dit apparaat is alleen toegankelijk via wortel. U moet het programma als root uitvoeren of de gebruikers-id voor root instellen.
Samenvatting
Dit document heeft aangetoond hoe de opdracht het
traceroute pad bepaalt dat een pakket uit een bepaalde bron naar een bepaalde bestemming voert met behulp van UDP- en ICMP-pakketten. De mogelijke typen ICMP-berichten in de uitgangen zijn:
-
Als de TTL in transit wordt overschreden, type=11, code=0, dan wordt het pakket teruggestuurd door de doorgangsrouter in alle gevallen waar TTL van de sonde pakketten verloopt voordat de pakketten de bestemming bereiken.
-
Als de poort onbereikbaar is, type=3, code=3, dan wordt het pakket teruggestuurd in reactie op de UDP-sonderpakketten wanneer deze de bestemming bereiken (de UDP-toepassing is niet gedefinieerd). Deze pakketten zijn beperkt tot één pakket per 500 ms. Dit verklaart waarom de reactie van de bestemming (zie de output voor de router van Cisco en Linux ) in de gelijke reacties ontbrak. Apparaat 7C genereert het ICMP-bericht niet en het traceroute opdrachtoutput in elk apparaat meer dan een seconde lang wacht. In het geval van MS Windows tracert opdrachtoutput, wordt het ICMP-bericht gegenereerd omdat UDP-poort 137 niet bestaat in een Cisco-router.
-
Als er een echo is, type=8, code=0, dan wordt het pakket van de echosonde verzonden door MS Windows PC.
-
Als er een echoantwoord, type=0, code=0 is, dan wordt een antwoord op het vorige pakket verzonden wanneer de bestemming wordt bereikt. Dit is alleen van toepassing op de MS Windows tracert uit.
Gerelateerde informatie
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
16-Oct-2023 |
Hercertificering |
1.0 |
11-Apr-2002 |
Eerste vrijgave |