ICMP - Internet Control Message Protocol
Damir Horvat, damir@x-si.org
Ljubljana, $Date: 2002/07/08 06:16:38 $
Abstract
Ta dokument opisuje ICMP protokol, njegovo sestavo, delovanje in
uporabo v vsakdanjiku.
ICMP protokol lahko smatramo kot del IP plasti. Zadolzen je za
prenasanje sporocil o napakah in ostalih pogojih v omrezju, ki
zahtevajo pozornost. Internet Protocol (IP) ni absolutno zanesljiv,
zato ga ICMP dopolnjuje s povratnimi informacijami o tezavah v
omrezju.
Dokument je baziran na 4.4BSD sistemu.
Viri
RFC - Request For Comment (www.ietf.org/rfc/)
- RFC792 Internet Control Message Protocol
- RFC1191 Path MTU Discovery
- TCP/IP Illustrated Volume 1 (W. Richard Stevens)
Kaj je ICMP?
ICMP (Internet Control Message Protocol) je protokol, namenjen obvescanju
subjektov v omrezju o napakah in novostih, ter podaja informacije o stanju
omrezja.
ICMP uporablja osnovno podporo IP plasti kot visjenivosjki protokol, vendar
je dejansko integriran del IP plasti (layer 2). Ceprav je drugonivojski
protokol, ga lahko dolocene aplikacije (layer 4) uporabljajo neposredno
(ping).
TCP/IP plasti:
+-------------------------------+
+-->| Uporabniski procesi | (4) application layer
| +-------------------------------+
| | TCP | UDP | (3) transport layer
| +-------------------------------+
+-->| ICMP | IP | IGMP | (2) network layer
+-------------------------------+
| ARP | HW int. | RARP | (1) link layer
+-------------------------------+
|
V
media
ICMP sporocila se prenasajo v IP paketih:
|<-------------- IP paket ------------->|
+----------+----------------------------+
| IP glava | ICMP sporocilo |
+----------+----------------------------+
20 bytov
Prvi 4 byti vsakega ICMP sporocila imajo enako glavo (header), ostanek pa
je odvisen od tipa sporocila. Poznamo 15 razlicnih tipov ICMP sporocil,
nekatera med njimi pa uporaljajo vrednosti "code" za se podrobnejso
specifikacijo.
Glava (header) ICMP sporocila:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit Type | 8-bit Code | 16-bit Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Vsebina je odvisna od tipa (type) in kode (code) sporocila |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ko je ICMP sporocilo poslano, le ta vedno vsebuje IP header in prvih 8
bytov IP paketa, ki je povzrocilo posiljanje ICMP sporocila. S tem lahko
ICMP modul asociira sporocilo z enim od protokolov (TCP ali UDP - s pomocjo
protocol polja v IP headerju) in posameznim uporabniskim procesom (iz TCP
ali UDP stevilke porta). Tako lahko aplikacja sporoca uporabniku stanje v
omrezju.
ICMP sporocila o napakah pa se ne generirajo kot odgovor na:
- ICMP sporocilo o napaki (rekurzivnost)
- paket poslan na IP broadcast ali multicast naslov
- paket poslan kot link layer broadcast (ARP broadcast)
- fragmente, razen prvega
Ta pravila preprecujejo "broadcast storms", ki bi zelo obremenila omrezje.
ICMP "type" in "code" vrednosti za nekatere tipe sporocil:
+------+------+-----------------------------+-------+-------+
| type | code | Opis | query | error |
+------+------+-----------------------------+-------+-------+
| 0 | 0 | echo reply | X | |
+------+------+-----------------------------+-------+-------+
| 3 | | destination unreachable | | |
| | 0 | network unreachable | | X |
| | 1 | host unreachable | | X |
| | 2 | protocol unreachable | | X |
| | 3 | port unreachable | | X |
| | 4 | fragmentation needed but |
| | don't fragment bit set | | X |
| | 5 | source route failed | | X |
| | 6 | destination network unkn. | | X |
| | 7 | destination host unknown | | X |
-=- -=- -=- -=- -=- -=-
+------+------+-----------------------------+-------+-------+
| 5 | | redirect | | |
| | 0 | redirect for network | | X |
| | 1 | redirect for host | | X |
| | 2 | redirect for TOS & network | | X |
| | 3 | redirect for TOS & host | | X |
+------+------+-----------------------------+-------+-------+
-=- -=- -=- -=- -=- -=-
+------+------+-----------------------------+-------+-------+
| 8 | 0 | echo request | X | |
+------+------+-----------------------------+-------+-------+
-=- -=- -=- -=- -=- -=-
+------+------+-----------------------------+-------+-------+
| 11 | | time exceeded | | |
| | 0 | time-to-live = 0 in transit | | X |
| | 1 | time-to-live = 0 in reassem.| | X |
+------+------+-----------------------------+-------+-------+
Ostale tipe in kode najdete v RFC792.
Vsi tipi in njih kode niso nujno potrebni za delovanje Interneta. Spet,
nekateri pa, ce jih ne uporabimo oz. jih uporabimo z napacnim namenom,
lahko vplivajo na kakovost delovanja omrezja.
Posebno pozornost zahteva tip 3 koda 4 - fragmentation needed, but don't
fragment bit set. Detaljna razlaga kasneje.
Poglejmo si zgoraj nastete tipe v praksi.
Nase omrezje (192.168.2.0/24) je sestavljeno iz treh racunalnikov:
2.3 2.2 2.1
+-------+ SLIP +-----+ ETHERNET +-------+
| sun |-----------| bsd |---------------| linux |
+-------+ +-----+ +-------+
MTU=269 MTU=269 MTU=1500 MTU=1500
fxp0 eth0
Tipa 0/8 (echo reply/echo request)
----------------------------------
Tipa 0 in 8 uporablja program ping, s katerim lahko preverimo, ali je
dolocen racunalnik pravilno vkljucen v omrezje.
Poleg pa dobimo se informacijo, koliko casa potrebuje paket za obhodni
cas (RTT) in koliko paketov se je na poti izgubilo (Packet loss).
Vsak echo request ima TTL (Time To Live) vrednost (4.4BSD = 255). TTL se
z vsakim prehodom skozi usmerjevalnik (router) zmanjsa za 1.
Echo request/reply paket je sestavljen iz 8-bytov glave ICMP paketa
in 56-bytov podatkov.
Glava paketa ICMP echo request/reply:
0 7 8 15 16 31
+------------+----------+---------------------+
| type (0/8) | code (0) | checksum |
+------------+----------+---------------------+
| identifier | sequence number |
+------------+----------+---------------------+
| |
| opotional data |
| |
Identifier polje se nastavi na ID procesa (ping), tako da lahko hkrati
poganjamo vec enakih procesov brez da bi se med seboj mesali.
Sequence number je na zacetku 0 in se poveca za 1 z vsakim poslanim echo
request paketom. Ping izpise seq. num. za vsak vrnjen paket, tako da
lahko uporabnik spremlja, ce se paketi izgubljajo.
Za prikaz, bom iz hosta linux pingal bsd:
damir@linux:~/$ ping bsd
PING bsd (192.168.2.2): 56 data bytes
64 bytes from 192.168.2.2: icmp_seq=0 ttl=255 time=2.0 ms
64 bytes from 192.168.2.2: icmp_seq=1 ttl=255 time=1.9 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=255 time=1.9 ms
--- bsd ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.9/1.9/2.0 ms
Spodnja statistika nam pove stevilo poslanih/prejetih paketov, packet
loss in RTT case. RTT prvega echo replaya je navadno vecji od naslednjih
zaradi iskanja ARP naslova naslovnika.
Na hostu bsd tcpdump pokaze:
(tcpdump -i fxp0 -p -N -S -v icmp)
13:16:12.236559 linux > bsd: icmp: echo request (ttl 64, id 934)
13:16:12.236708 bsd > linux: icmp: echo reply (ttl 255, id 860)
13:16:13.234140 linux > bsd: icmp: echo request (ttl 64, id 937)
13:16:13.234292 bsd > linux: icmp: echo reply (ttl 255, id 863)
13:16:14.234020 linux > bsd: icmp: echo request (ttl 64, id 939)
13:16:14.234151 bsd > linux: icmp: echo reply (ttl 255, id 865)
Host linux posilje echo request na bsd, TTL je 64. Echo reply je vrnjen
nekaj tisocink kasneje, TTL pa je 255.
Dokler je ICMP 0/8 uporaben za ugotavljanje stanja omrezja, je z vidika
varnosti lahko nevaren. Program ping ima opcijo "flood ping", s katero
zasujemo naslovnika z paketi, ne cakajoc na njihove odogovore. Posledica
je verjetna nedostopnost naslovnika in velika poraba pasovne sirine (DOS
napad).
Priporocam, da ICMP 0/8 na pozarnih streznikih zaprete, ce pa ze morate
imeti to funkcoinalnost, pa vsaj omejite stevilo ICMP requestov na sekundo.
Tip 3/3 (port unreachable)
--------------------------
Da bi videli primer ICMP port unreachable sporocila bom uporabil UDP
pakete in sicer med hostoma linux in bsd. UDP poslje ICMP port unreachable
sporocilo posiljatelju paketa, ce je le ta namenjen na port, ki ne
odgovarja.
Za prikaz bom uporabil dva programa, tcpdump in tftp. Na hostu bsd bomo
poganjali tcpdump, medtem ko z hosta linux poganjamo tftp klienta:
damir@linux:~$ tftp bsd 8888
tftp> get tmp.foo
Transfer timed out.
tftp> quit
S tftp klientom se povezemo na bsd na port 8888. Ne tem portu na hostu bsd
ne poslusa nobeden daemon, zato dobimo odgovor "Transfer timed out".
Se prikaz poteka na hostu bsd:
(tcpdump -i fxp0 -p -N -S)
10:29:29.367318 linux.1029 > bsd.8888: udp 19
10:29:29.367587 bsd > linux: icmp: bsd udp port 8888 unreachable
10:29:34.363864 linux.1029 > bsd.8888: udp 19
10:29:34.364192 bsd > linux: icmp: bsd udp port 8888 unreachable
10:29:39.363954 linux.1029 > bsd.8888: udp 19
10:29:39.364296 bsd > linux: icmp: bsd udp port 8888 unreachable
10:29:44.364200 linux.1029 > bsd.8888: udp 19
10:29:44.364550 bsd > linux: icmp: bsd udp port 8888 unreachable
10:29:49.364430 linux.1029 > bsd.8888: udp 19
10:29:49.364761 bsd > linux: icmp: bsd udp port 8888 unreachable
ICMP port unreachable je takoj vrnjen, ampak tftp klient to mirno ignorira
in poizkusi se petkrat, priblizno na vsakih 5 sekund. Izmenjava ICMP
sporocil med linux in bsd poteka brez stevilke porta, medtem ko vsak
19-bytni paket potuje iz tocno dolocenega porta (1029) na tocno dolocen
port (8888).
V tem primeru je 19 bytov vsota 2-bytov "opcode" polja v headerju TFTP
paketa (RRQ/WRQ), 8-bytov "null terminated" ime datoteke (tmp.foo)
in 9-bytov "null terminated netascii" polja headerja TFTP paketa.
Podrobneje opisovanje TFTP headerja in paketa ni v skopu tega dokumenta.
ICMP type 3 je tip, ki skrbi za obvescanje o napakah, zato je
priporocljivo, da le tega ne zapirate s pozarnimi zidovi.
Tip 3/4 (fragmentation needed, but don't fragment bit set)
----------------------------------------------------------
Na poti od posiljatelja do naslovnika potuje paket skozi razlicne mrezne
naprave (network interface) in omrezne protokole.
Omrezni protokoli (Ethernet, Slip, FDDI, IEEE 802.3/802.2, ...) omogocajo
prenose paketov razlicnih velikosti, vsak pa ima natancno doloceno
zgornjo mejo - MTU (Maximal Transfer Unit).
Tabela tipicnih MTU vrednosti:
+---------------------------+------------+
| Omrezje | MTU (bytes |
+---------------------------+------------+
| Hyperchannel | 65535 |
| 16 Mbits/sec token ring | 17914 |
| 4 Mbits/sec token ring | 4464 |
| FDDI | 4352 |
| Ethernet | 1500 |
| IEEE 802.3/802.2 | 1492 |
| X.25 | 576 |
| Point-to-point | 269 |
+---------------------------+------------+
Usmerjevalnik sprejme paket in vprasa izhodno mrezno napravo za MTU in
ga primerja z velikostjo paketa. Ce je paket vecji, ga razdeli na vec
delov, tako da je vsak manjsi od MTU izhodne naprave. Tako razdeljen
paket potuje v takem stanju vse do naslovnika, kjer ga le-ta sestavi
nazaj na originalno velikost. Takemu razdeljevanju recemo fragmentacija.
IP header vsebuje 3-bitno polje "flags" in 13-bitno polje "fragment offset"
(8-bytne enote). Eden od bitov je "Don't Fragment" bit (DF). Ce je ta bit
vkljucen, IP ne bo fragmentiral paketa. Tako je paket odvrzen in ICMP
sporocilo o napaki "fragmentation needed, but don't fragment bit set" se
poslje posiljatelju paketa.
Ko je paket fragmentiran, je vsak fragment svoj paket. To omogoca, da
paketi pridejo do naslovnika v poljubnem vrstnem redu. V vsakem
fragmentiranem paketu je dovolj informacij, da jih naslovnik lahko
sestavi skupaj.
Ceprav IP fragmentacija poteka transparentno, se ob izgubi enega fragmenta,
zavrze celoten paket in mora biti le-te poslan se enkrat.
Za primer UDP fragmentacije bom uporabil program "sock". Ethernet MTU je
1500, kar nam pove, da imamo poleg 20-bytov IP headerja in 8-bytov UDP
headerja se 1472-bytov prostora za podatke v enem paketu.
sock bo generiral 4 pakete velikosti od vkljucno 1471-bytov do vkljucno
1474-bytov. Fragmentacija se zgodi od posiljanju tretjega paketa,
velikosti 1473-bytov:
damir@linux:~/$ sock -u -i -n1 -w1471 bsd discard
damir@linux:~/$ sock -u -i -n1 -w1472 bsd discard
damir@linux:~/$ sock -u -i -n1 -w1473 bsd discard
damir@linux:~/$ sock -u -i -n1 -w1474 bsd discard
tcpdump na hostu bsd pokaze:
11:14:34.3673514 linux.1068 > bsd.discard: udp 1471
11:14:35.6561465 linux.1070 > bsd.discard: udp 1472
11:14:36.1204826 linux.1072 > bsd.discard: udp 1473 (frag
26340:1480@0+)
11:14:36.1345987 linux > bsd: (frag 26340:1@1480)
11:14:36.8357024 linux.1074 > bsd.discard: udp 1474 (frag
26356:1480@0+)
11:14:37.0142265 linux > bsd: (frag 26356:2@1480)
Prva UDP paketa sta manjsa in enaka MTU Ethernet protokola zato
fragmentacija ni potrebna. Naslednji paket z 1473-bytov podatkov pa
zahteva MTU 1501, zato se zgodi fragmentcija. Enako se zgodi s cetrtim
paketom.
Ob fragmentaciji, tcpdump izpise dodatne informacije:
- frag 26340 (tretji paket)
- frag 26356 (cetrti paket)
ki pomenita vrednost identifikacijskega polja v IP headerju. Naslednja
stevilka (1480) je podatek o fragmentaciji. Prva fragmenta obeh paketov
(tretji in cetrti) vsebujeta 1480-bytov podatkov:
- 8-bytov UPD headerja
- 1472-bytov podatkov
(20-bytov IP headerja + 1480-bytov UPD headerja in podatkov je 1500 =
Ethernet MTU).
Drugi fragment prvega paketa vsebuje 1-byte podatkov (:1@1480). Enako
velja za drugi fragment drugega paketa (:2@1480). Stevilka za @ je
naslov, kje se zacnejo podatki v drugem fragmentu. Znak + na koncu prvega
fragmenta oznacuje, da sledi vsaj se en fragment.
V primeru da usmerjevalnik prejme paket vecji od MTU izhodne naprave in
je bit "Don't Fragment" aktiven, poslje ICMP sporocilo o napaki posiljatelu,
paket pa odvrze. To ICMP sporocilo koristi programu, ki odkriva
najmanjsi MTU med posiljateljem in naslovnikom - "Path MTU Discovery"
mehanizem.
Path MTU Discovery
------------------
Da bi videli PMTUd v akciji bom poslal 650-bytne UDP pakete iz hosta
linux na sun. Host sun je na SLIP povezavi. Ponovno slika nasega testnega
omrezje za lazjo predstavo:
2.3 2.2 2.1
+-------+ SLIP +-----+ ETHERNET +-------+
| sun |-----------| bsd |---------------| linux |
+-------+ +-----+ +-------+
MTU=269 MTU=269 MTU=1500 MTU=1500
fxp0 eth0
Naslednji ukaz poslje 3 650-bytne UDP pakete:
damir@linux:~/$ sock -u -i -n3 -w650 sun discard
Prvi paket je poslan z "DF" bitom in pricakovano, na hostu bsd, kjer
tece tcpdump, vidimo ICMP "can't fragment" sporocilo. Zanimivo je, da je
tudi ICMP sporocilo o napaki poslano z aktivnim DF bitom.
13:47:23.8575114 linux.1234 > sun.discard: udp 650 (DF)
13:47:24.0123659 bsd > linux: icmp:
sun ureachable - need to frag, mtu = 269 (DF)
13:47:29.6438763 linux.1234 > sun.discard: udp 650 (DF)
13:47:29.9823676 bsd > linux: icmp:
sun ureachable - need to frag, mtu = 269 (DF)
13:47:34.2973455 linux.1234 > sun.discard: udp 650 (frag
67925:272@0+)
13:47:34.5083459 linux > sun: (frag 67925:272@272+)
13:47:34.5083459 linux > sun: (frag 67925:114@554)
V tem primeru, host bsd v ICMP sporocilu vrne "next-hop MTU", tako da host
linux ve, koliksen je MTU izhodne naprave na hostu bsd. V nasprotnem
primeru, posiljatelj ob ICMP sporocilih poizkusa na slepo s posiljanjem
vedno manjsih fragmentov.
!!! POMEMBNO !!!
Ce ICMP sporocilo "fragmentation needed, but don't fragment bit set" zaradi
kakersnega koli razloga ne pride do posiljatelja (v tem primeru iz hosta
bsd do hosta linux), posiljatelj ne bo vedel, da mora izvesti
fragmentacijo! Na drugi strani pa bo host, kjer se prvikrat pojavi manjsi
MTU, kot je velikost paketa, zaradi DF bita metal pakete proc in
posiljal ICMP sporocila.
Tip 5 (redirect)
----------------
ICMP redirect sporocila posiljajo usmerjevalniki (routerji) v primeru, da
bi moral biti paket poslan dugemu usmerjevalniku:
+-------+
| host1 | 192.168.5.3
+-------+
|
|
=======================================
| |
+----+ 5.1 +----+ 5.2
| R1 | | R2 |
+----+ +----+ 8.1
| |
|
+-------+
| host2 | 192.168.8.35
+-------+
Iz hosta1 hocemo pingat host2.
host1 poslje paket na R1, ker ga ima za privzeti prehod. R1 preveri v
routing tabeli in ugotovi, da je za ta paket pravi naslov R2. Ko poslje
paket na R2, ugotovi, da je izsel preko iste mrezne naprave kot je
prisel. R1 poslje ICMP redirect na host in mu s tem pove, da naj v bodoce
pakete namenjene na ta naslov posilja na R2.
S tem postopkom ICMP pomaga razbremenjevati usmerjevalnike.
Primer:
damir@host1:~/$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.5.1 UGSc 15 0 eth0
127.0.0.1 127.0.0.1 UH 0 27769 lo
192.168.5 link#1 UC 2 0 eth0
Sedaj pingam host2, in takoj opzim, da mi je R1 javil ICMP redirect sporocilo.
Takoj po tem se routing tabela na hostu1 osvezi in host route je dodana za
host2.
damir@host1:~/$ ping host2
PING host2: 56 data bytes
ICMP Host redirect from gateway R1 (192.168.5.1) to R2 (192.168.5.2) for
host2 (192.168.8.35)
64 bytes from 192.168.8.35: icmp_seq=0 ttl=64 time=2.0 ms
64 bytes from 192.168.8.35: icmp_seq=1 ttl=64 time=1.9 ms
64 bytes from 192.168.8.35: icmp_seq=2 ttl=64 time=1.9 ms
^C
--- bsd ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.9/1.9/2.0 ms
Ce spet pogledamo routing tabelo na hostu1:
damir@host1:~/$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.5.1 UGSc 15 0 eth0
127.0.0.1 127.0.0.1 UH 0 27769 lo
192.168.5 link#1 UC 2 0 eth0
192.168.8.35 192.168.5.2 UGHD 2 0 eth0
Tip 11 (time exceeded)
----------------------
ICMP tip 11 se uporablja na mestih, kjer je pomemben cas. Prakticen primer tega
je program Traceroute, ki za delovanje potrebuje UDP, ICMP uporablja za
sporocanje napak, IP pa za TTL.
Traceroute TTL ima neko predefinirano vrednost (po RFC je to 64).
Ob vsakem prehodu skozi usmerjevalnik (router), se vrednost TTL zmanjsa za 1.
Namen tega je prepreciti neskoncne zanke, ki se lahko pojavijo pri prehajanju
skozi usmerjevalnike.
Ko usmerjevalnik dobi paket s TTL 0 ali 1, ga ne sme poslat naprej, ampak ignorirat
in posiljatelja obvestit o napaki s pomocjo ICMP sporocila "time exceeded".
Traceroute pa v tem sporocilu dobi IP od usmerjevalnika, kot "source IP".
Traceroute torej deluje na principu, da najprej poslje paket s TTL = 1 na koncno
destinacijo. Prvi usmerjevalnik, ki dobi ta paket, ga odvrze in poslje posiljatelju
"ICMP time exceeded". Po prejemu tega sporocila, posiljatelj ve, da je paket nasel
prvi hop na poti. Nato posiljatelj poslje naslednji paket s TTL = 2 in caka na
ICMP time exceeded sporocilo. Tako nadaljuje vse do 64. hopa, ce prej ne doseze
originalnega naslovnika.
Kako traceroute ve, kdaj je dosegel naslovnika? Traceroute posilja UDP pakete
naslovniku na port veci od 30,000. Ce paket doseze naslovnika, le ta sprozi ICMP
port unreachable error, kar pomeni, da je UDP paket prisel do visokega porta
(> 30,000) pri naslovniku.
Vse kar mora storiti traceroute je, da pregleda razlike med ICMP "time exceeded"
in "port unreachable" sporocili.
Za vsako vrednost TTL, traceroute poslje po tri pakete z enako TTL vrednostjo. To
omogoca izracun RTT (roud trip time) vrednosti.
Primer: Naredimo traceroute is hosta "linux" na host "sun".
damir@linux:~$ traceroute sun
traceroute to sun (192.168.2.3), 64 hops max, 40 byte packets
1 bsd (192.168.2.2) 0.20 ms 0.10 ms 0.10 ms
2 sun (192.168.2.3) 0.30 ms 0.20 ms 0.30 ms
Tcpdump na hostu bsd pokaze naslendnje:
15:34:39.8535674 linux.1276 > sun.33654: udp 12 [ttl 1]
15:34:40.2341452 bsd > linux: icmp: time exceeded in-transit
15:34:40.4343435 linux.1276 > sun.33655: udp 12 [ttl 1]
15:34:40.5602743 bsd > linux: icmp: time exceeded in-transit
15:34:40.7982640 linux.1276 > sun.33656: udp 12 [ttl 1]
15:34:40.8163765 bsd > linux: icmp: time exceeded in-transit
15:34:40.9159623 linux.1276 > sun.33657: udp 12
15:34:40.8163765 sun > linux: icmp: sun udp port 33657 unreachable
15:34:41.0297452 linux.1276 > sun.33658: udp 12
15:34:41.2879226 sun > linux: icmp: sun udp port 33658 unreachable
15:34:41.3937343 linux.1276 > sun.33659: udp 12
15:34:41.4620287 sun > linux: icmp: sun udp port 33659 unreachable
Poznamo 2 vrsti "time exceeded" sporocil, vsaka ima svojo "code" vrednost v
glavi sporocila (0 ali 1).
Primer ICMP "time exceeded" sporocila:
0 7 8 15 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type (11) | code (0 or 1) | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unset (must be 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IP header (z opcijami) + prvih 8 bytov orig. paketa |
| |
Sporocilo "time exceeded" je sporocilo z code 0, sporocilo z code 1, pa javlja
napako "time exceeded during reassembly", ce paketu zmanjka casa med sestavlanjem
fragmentov.
IP routing je pravilno dinamicne narave, traceroute pa, z omogocenimi opcijami,
zna "peljat" paket po bolj ali manj zacrtani poti. Opciji sta "strict source
routing" ali SSR in "loose source routing" ali LSSR.
Pri SSR traceroute programu povemo IP naslove usmerjevalnikov, preko katerih naj
poslje paket. Paket bo potoval izrecno samo preko teh usmerjevalnikov (ce se
zmotimo, paket ne pride do cilja).
LSSR opcija pa pove traceroute programu, preko katerih routerjev naj spelje paket.
Vmesne postaje izbira IP routing. S to opcijo lahko predvidimo tezave v omrezjih.
Primer:
Smo na hostu mail.x-si.org in nas zanima pot paketa do hosta www.google.com v obeh
smereh.
traceroute -g 216.239.39.101 mail.x-si.org
bo poslal paket preko prehoda (gateway-a) www.google.com na host mail.x-si.org.
Tako lahko vidimo pot paketa do prehoda(216.239.39.101) in nazaj. Pot v eno smer
ni nujno enaka poti v drugo.
Traceroute je nepogresljivo orodje za opazovanje omrezij in preprecevanje napak. Da
bi ga lahko uporabljali, je potrebno na pozarnih zidovih spuscati UDP pakete med
porti 33434 >< 33690 in ICMP pakete type 11.
