<pre> 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. </pre>

networking/icmp.txt · Last modified: 2009/05/25 00:35 (external edit)
CC Attribution-Noncommercial-Share Alike 4.0 International
Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0 ipv6 ready