Internettfrakt. Ketil Danielsen August 23, 2004

Transkript

1 Internettfrakt Ketil Danielsen August 23, 2004 Maskiner har behov for å utveksle digital informasjon (bilde, tekst, dokument, database, banktransaksjon, video, lyd). Informasjonsmengden er digital (en mengde 1 og 0) som først deles opp og pakkes inn i (fortsatt digitale) pakker. Hver pakke sendes inn i et datanett som sammenkobler maskiner som samarbeider. Notatet tar ikke opp viktige algoritmer som for eksempel beregning av optimale ruter, sjekksummer for feilkontroll eller belastningsregulering. Det er ment å være overordnet, myntet på en som ikke har studert temaet tidligere men av ulike årsaker bare må begynne å sette seg inn i stoffet. Internettet for pakkefrakt I dette notatet fokuseres det på det i dag velkjente Internett, som består av en mengde maskiner som er spesialisert til å videresende pakker mellom avsender og mottaker. Våre kontormaskiner og servere er endemaskiner og står for det meste av utsending, men av og til kan også maskinene som står imellom, ruterene, også stå som avsender; for det meste vil jo ruterne være viderebefordrere av trafikk utsendt av andre. Alle maskiner i Internettet (også endemaskinene) har en IP-prosess (som er en del av operativsystemet) som tar imot innkomne pakker, behandler disse og sender de videre. Disse følger en standard for pakkebehandling som er definert av organet Internet Engineering Task Force (IETF) i standard RFC791. Denne standarden spesifiserer også at alle pakkene skal følge samme pakkeformat. Alle IP-pakker skal ha et pakkehode (IP packet header) som sier hvilke maskiner som er avsender og mottaker. Maskinen bruker sin egen IP-adresse som avsender, og henter mottakeradressen fra den som skal ha sendt pakken. I tillegg legges det med en sjekksum slik at maskiner underveis, og hos mottaker kan vurdere om innholdet er uendret, om det er intakt. Hodet inneholder også en TTL-verdi (TTL betyr Time To Live) som angir hvor mange hopp pakken skal overleve før den slettes, altså før den stoppes i sin ferd mot mottaker. Endel annet er også lagt med i pakkens hode, men blir diskutert nærmere senere. Internettet kan introduseres gjennom verktøyet traceroute, som viser ruten en pakke vanligvis tar mellom to maskiner i Internettet (A og B i eksemplene). 1 1 I eksemplene er det tatt utgangspunkt i programvare installert på et NetBSD v Parametre og oppførsel kan være annerledes i andre operativsystem. 1

2 Med rute menes en liste over maskiner pakken har vært innom underveis. Med traceroute sendes en serie pakker ut fra A. Disse pakkene er utstyrt slik at maskinene underveis provoseres til å sende en feilmelding tilbake til A, noe som gjør det enkelt for A å finne ut hvem som har svart. Pakkers levetid, mål og rekkevidde Hver node i Internettet vil inspisere mottakerfeltet og finne ut hvilken videre vei pakken skal ta. Men, før dette, vil det første en maskin gjør med en pakke, være å redusere pakkens TTL. Hvis TTL har nådd 0 slettes pakken, den videresendes altså ikke. Dette ble tidlig ansett viktig for å oppnå loop avoidance, en forsikring mot at pakker går i evig løkke fra maskin til maskin, uten å nå endelig mottaker. Disse ville aldri dø, og leder heller ikke til noe produktivt, og til slutt anta et volum som ville kvele produksjonen. I IP-standarden er en TTL på 60 angitt som fastverdi, men ulike operativsystem har andre fastverdier. Manglende konnektivitet i et verdensomspennende bedriftsnett kan forårsakes av for lav fastverdi for TTL i det operativsystem bedriften bruker; pakkene dør før de kommer frem. Mekanismen kan også brukes for å redusere pakkens nedslagsfelt. Hvis A setter alle sine utsendte pakkers TTL til 2 er A sikker på at pakkene slettes etter det andre hoppet! For en bedrift der alle klienter er ett eller to hopp fra hverandre representerer dette en enkel men ukomplett sikring mot at informasjon lekker ut (det finnes andre lekkasjeformer). For det meste er det to maskiner som samsnakker, altså unicast, eksempelvis en filserver og en klient der brukeren sitter. Enkelte konferanseprogram bruker multicast, som er en annen form for IPruting som kan spre en pakke til flere mottakere. Pakkens mottaker må da være en multicast gruppeadresse (som er annerledes enn unicast-adresser). Maskinene (som forstår den nyere multicasting) vil da kopiere pakkene videre inn i nettet, i retninger av mottakere som abonnerer på gruppeadressen. Multicastpakker blir vanligvis TTL-sikret med lave TTL. Det er nemlig vanskelig for sender å alltid vite hvor mange abonnenter det er, og hvor mange kopier dette vil medføre. En bevisst lav TTL sikrer mot utilsiktet spredning av multicastpakker. Feilmeldinger og målinger Altså slettes en pakke fra den ruteren som reduserer pakkens TTL til null. I tillegg sender ruteren en feilmelding tilbake til avsender, mer spesifikt en ICMP Time Exceeded. En IT-avdeling skal være observant på feilmeldinger, og helst reagere hvis det dreier seg om pakker som ved feiltakelse sendes lenger enn bedriften ønsker. Men, i dette notatet vil feilmeldingene være den særdeles nyttige og ønskede respons som utnyttes av program som trenger å vite noe om nettet, deriblant traceroute som skal finne ut ruten mellom A og B. Første hopp avdekkes av traceroute, ved å sende K datapakker med TTL lik 1, neste hopp avdekkes med K pakker som har TTL lik 2, og så videre. Grunnen til at en kan sende flere pakker (K) er at det er nyttig å få flere 2

3 målinger for hvert hopp, det gir bedre målesikkerhet. Med parameter -q kan bruker overstyre valget av K fra det som er fast, vanligvis 3. I tillegg til adressen til hver maskin i ruten, vil traceroute for hver feilmelding beregne rundetiden (round-trip time) mellom A og hver maskin. Med K slike rundetider kan traceroute beregne et snitt og variasjon som da også rapporteres. Ikke alle knutepunkt er IP-rutere, men svitsjer på lavere lag. Disse vil ikke rapportere feilmeldinger, da de ikke inspiserer selve pakkehodet. Noen maskiner kan frastå fra å sende slike feilmeldinger, enten for å ikke frigi sin identitet (driftspersonalet har eksplisitt bedt om dette), eller fordi de ikke ønsker å bruke produksjonskapasitet til dette. Meldingen droppes her i det stille. Etter noe venting gir traceroute opp og skriver en stjerne * eller lignende på skjermen. For å unngå evig venting på svar fra disse, kan en med parameter -w bestemme antall sekund som en maksimum skal vente for denne TTL-verdi. Med parameter -t kan brukeren overstyre hva første TTL-verdi skal være. Dette er mulig, antakeligvis fordi brukeren kjenner de første få hopp og skal slippe å vente på den tid det unektelig vil ta før informasjon om resten av ruten ankommer. Et annet parameter er -m som lar brukeren oppgi maksimum TTL, og derved sikre at søket ikke går lenger utover enn nødvendig. Hvis denne ikke oppgis vil eksempelvis 30 være et fast maksimum. Rutesymmetri Det eneste argument som alltid skal oppgis er B, altså den maskinen man vil undersøke ruten A-B for. Internettet vil kunne rute pakker fra B til A annerledes enn de som går A til B, noe som kalles asymmetriske ruter. Årsaken ligger i at noen av linkene kan være enveis. Det kan også være administrative sperrer som ligger i veien for returveien. Asymmetriske ruter vil også kunne ha ulike lengder, og er de like lange er det heller ikke sikkert at de er symmetriske. Brukeren kan bruke parameter -l for å få rapportert feilmeldingens (ikke datameldingens) TTL; hvis denne varierer er det et symptom på asymmetriske ruter. Men, vanligvis er rutene symmetriske, i den forstand at det er de samme maskiner som videresender, at rutene derfor også er av lik lengde. Den eneste forskjell er at ruten fra A til B er motsatt av den fra B til A. Adresser og navn Alle maskiner (klienter, servere, rutere) har numeriske adresser som kalles IP-adresse. Disse er på 32 bit og brukes for avsender og mottakerfeltet i pakken. Maskiner som skal vidersende pakker må ha en slik numerisk adresse. Merk, at en maskin som har flere linker inn og ut (typisk en ruter) av ulike årsaker har forskjellige IP-adresser for hver slik link! Høgskolens ruter med 17 linker har minst 17 IP-adresser tilordnet. IP-adressen er trettito 1 ere og 0 ere som maskinene forstår, men som er vanskelig å uttrykke i menneskers dagligtale. Derfor brukes en dotted decimal notation a.b.c.d, der a er desimalverdien for de første åtte bit i IP-adressen, 3

4 b for de neste åtte bit, c de nest siste åtte bit, og d de siste åtte bit. Laveste verdi som åtte bit kan uttrykke er , høyeste er I desimalform tilsvarer dette 0 og 255, som er laveste og høyeste verdi for a, b, c og d. Brukeren oppgir vanligvis B som domenenavn, i en annen form som er lettere å huske og forstå. Likens vil traceroute rapportere domenenavn for hvert hopp. Derfor må traceroute oversette fra numeriske adresser (som den finner i feilmeldingens avsenderfeil) til domenenavn. Selve oversettingen kalles name resolution (norsk: oppløsning) og gjøres vanligvis av en DNS-tjener på en annen maskin og kan ta noe tid. Oversettingen går to veier: Hvis en har det logiske navnet og trenger det numeriske er det name-to-address, ellers er det address-to-name). Det er ikke alle adresser som er representert med logiske navn i DNS, og disse vises da (etter at DNS har returnert feilmelding) som numeriske IP-adresser. For å slippe ventingen kan en i traceroute velge bort oversetting med parameter -n (numeric). Autonome System og organisering Pakken rutes gjennom ett eller flere Autonome System (AS). Innenfor ett AS kan pakken være innom en eller flere IP-rutere. Hvis brukeren vil vite hvilke AS som frakter pakken, kan parameter -a brukes. Det betyr at traceroute (for hver oppdagede maskin i ruten) må spørre en spesiell server for å finne ut hvilket AS som eier den aktuelle maskin. For å bruke en annen server brukes parameter -A. Manualsiden for traceroute angir et forbehold om at det ikke disse serverne ikke alltid vil ha oppdatert informasjon. I Norge kobles alle AS sammen i et NIX (Network Inter-eXchange) i Oslo. Ved traceroute fra maskin A i UNINETT til en maskin B i Telenor s område vil en se at domenenavnene endres akkurat i overgangen der NIX ligger. 2 Innenfor UNINETT ligger alle høgskoler og universitet tilkoblet, hver med sin egen driftsavdeling som administrerer lærestedets lokale nettverk. Disse er ikke egne AS; det er UNINETT som er ASet. Støy og tap Linker i Internettet kan være utsatt for støy. Spesielt over radio og mikrobølger, kan vær og fysiske hindringer gi kortvarige forstyrrelser. Over kobber kan elektromagnetisk støy i korte perioder også forvrenge og ødelegge for mottaket, i motsetning til fiber som er immun mot støy. Slik støy gir altså bitfeil og kan oppdages av mottaker eller maskiner underveis. I pakkens hode ligger det en sjekksum som sender har beregnet på grunnlag av innholdet i pakken. Når mottaker mottar innholdet, beregner mottakeren sin egen sjekksum. Hvis mottaker ser at den beregnede sjekksum avviker fra den vedlagte sjekksum i pakkehodet, er det feil i pakken og maskinen dropper den, den sendes ikke videre. I og med at traceroute skal måle rundetider mest mulig presist kan beregning av sjekksum slås av med parameter -x. 2 Les mer på 4

5 En annen årsak til at en pakke slettes og ikke sendes videre er at det er stor pågang ut på en linje og utkøen dit er full. For de enkleste køordninger (første inn går først ut) er det den sist ankomne som droppes. Andre køordninger som kan brukes er former som gir ulike trafikkgrupper en form for garanti på ressurstilgang i travle perioder. Ved fulle bufre kan nyankomne pakker med høyere prioritet eller en eller annen kapasitetsgaranti, forfordeles ved å droppe lavprioritets-pakker som sitter i køen og venter. Tjenestekrav og kvalitet I og med at Internettet kan tape enkelte pakker grunnet støy og fulle buffer, er det viktig for de fleste tjenester at korrektheten overvåkes. En manglende pakke (blant mange korrekt mottatte) kan bety lite hvis det er et uviktig bilde av en blomst som sendes. Er det derimot et røntgenbilde som skal diagnostiseres over distanse, er det mer viktig. All tekst og banktransaksjon er også mediatyper som vanligvis skal mottas feilfritt. I Internettet er de to viktigste tjenestetypene UDP og TCP, og de baserer seg begge på den upålitelige sendetjenesten fra IP. De er forlengst standardisert og dokumentert i RFC768 og RFC793 fra Det er et viktig prinsipp i Internettet, at ruterne underveis ikke belemres med uviktig ekstraarbeid. Derved sikres høyest mulig transportkapasitet. Derfor er det ikke ruterne som kontrollerer påliteligheten, men endesystemene. Mer spesifikt er det mottakerne (i samarbeid med avsenderne) som skal ta det absolutt meste av arbeide med kontroll og eventuell oppretting. UDP (User Datagram Protocol) vil lage en sjekksum på det som sendes, men ikke be om gjentaking hvis det oppdages feil hos mottaker. Derfor regnes UDP som en noe upålitelig transporttjeneste. TCP (Transmission Control Protocol) er derimot regnet som en pålitelig tjeneste. I TCP skal mottakeren returnere positiv bekreftelse på pakker som mottas feilfritt (ACK, acknowledgement), og negative bekreftelser (NACK) på pakker med feil. Bekreftelsen er stort sett i form av en peker til hvor langt i materialet mottakeren har kommet. Sendes det bekreftelse på 352, betyr det at alle byte fra nummer 0 til nummer 352 i forsendelsen er korrekt mottatt. Hvis bekreftelsen uteblir vil en retransmission timer etterhvert ringe hos avsender, og gjøre at denne gjentar det som ikke er bekreftet. Dette koster mer i kontroll og gjentakelser, men gir mye til de brukere som er avhengige av korrekt overføring. I pakkehodet kan senderen angi hvilken tjenestekvalitet den ønsker. Dette er veldig upresise angivelser som egentlig bare sier litt om hva slags kategori senderen tilhører. Derfor kalles dette type-of-service (TOS), og det er avsatt 8 bit til dette slik at en kan oppgi verdier mellom 0 og 255. Her kunne Internettet endt opp med 256 ulike graderinger, men istedet har normen blitt at en bruker de 8 bit helt spesielt. En sender kan indikere at han enten er følsom for venting (ønsker low-delay), noe som ikke alltid tas hensyn til. En kunne tenke seg at ruterne hadde to utkøer, der en var for de med ønske om lav forsinkelse og alltid ble betjent først. 5

6 tåler venting, men ønsker stort volum (throughput), der en med volum forstår mengde over et gitt tidsrom, byte per sekund. er mest opptatt av at pakken faktisk blir videresendt, uavhengig av hvor lenge den venter eller hvor stort volum senderen oppnår (reliability). vil betale minst mulig (low cost). Dette har ikke alltid relevans da store deler av Internettet organiserer betaling på andre måter, ikke i pakkerutingen. Verdt å merke seg, er at selv om avsendere markerer sine tjenestebehov er det ikke alltid de tas hensyn til ved utsending på de ulike linkene. Det enkleste er alltid å ha en enkelt utkø per linje, men det varierer altså hvordan dette gjøres. Ved måling av rute og rundetider kan det være interessant å be om lavest mulig forsinkelse, og i traceroute er det forsøket verdt å bruke parameteret -t til dette. Tjenesteporter Det aller meste av pakker i Internettet er rettet fra en klientport hos avsendermaskin, til en mottakermaskin, og til en gitt tjenesteport (serverport) hos denne maskinen. For eksempel er tjenesteport 80 på webserver no aktuell hvis jeg vil med min webklient vil lese timeplanen; min webklient (vanligvis Mozilla) er representert via en mer tilfeldig valgt og ledig klientport (numerisk adresse og port eksempelvis). Nye anrop rettes mot velkjente porter hos den maskin en vil betjenes av; hvis ikke må klienten på andre måter vite hva tjenesteporten er for å sikre seg at tjenesten nås. Pakker til porter som ikke lyttes på vil gi feilmelding ICMP Destination Port Unreachable (hvis mottakeren ikke rett og slett dropper den i det stille). For å fremprovosere en slik feilmelding fra mottakermaskinen, er pakken fra traceroute rettet til port B + N 1, der B vanligvis er og N lik det som er lengden på ruten. Overstyring av B gjøres med parameter -p. I traceroute er det ikke så viktig at informasjon kommer korrekt fram, da innholdet i pakken er urelevant. Det er også viktig at målingene ikke forstyrres av ekstra behandlingstid som TCP ufravikelig vil påføre. Derfor brukes UDP tjenestetype, og da mot en port hos maskin B som antakeligvis ikke er i bruk, og derved muligens forstyrre pågående produksjon. I traceroute blir da spesifisering av mottaker tredelt: Mottaker s adresse (B), port (diskutert over) og tjenestetype (UDP). Dette gir raskeste respons fra transportlaget UDP hos mottaker. Det finnes en enda raskere fra mottaker, nemlig ICMP Echo Reply, som er et ekko fra IP-laget. Til dette kreves at det fra avsender sendes ut en ICMP Echo Request, istedetfor en UDP-pakke. I traceroute fremtvinges dette alternativet med parameter -I. Ruting En maskin mottar en pakke og har som hovedoppgave å finne ut hvor denne skal videresendes (rutes). Til dette sjekkes maskinens egen rutetabell for å finne 6

7 ut hva som er beste neste-hopp. Valget er selvsagt basert på pakkens mottakeradresse. De 32-bits IP-adresser er todelt i nettadresse og maskinadresse. For å slippe å ha ruteangivelser for alle millioner maskiner er rutetabellen kondensert til å peke til ulike nett. Ruting betyr derfor at IP-prosessen leter opp det aktuelle mottakernett som er angitt i mottakerens IP-adresse. Først når pakken har ankommet mottakernettet blir pakken direktelevert til den maskin som er angitt i pakkens mottakeradresse. Rutetabellen oppdateres hvis det er nødvendig, slik at neste-hopp for en gitt mottakeradresse (eller mottakernett) er langs den korteste rute. Lengde måles vanligvis i antall hopp, men kan også være målt i tid (sekunder). En ruter som ikke finner ruten videre kan velge å sende en feilmelding. Hvis pakken har kommet frem til mottakerens nett uten at ruteren kan finne ut av direkte leveranse, returneres en ICMP Destination Host Unknown. Hvis pakken ikke kom så langt, men stoppet hos en ruter som ikke kjente til mottakernettet, returnerer denne ruteren en ICMP Destination Network Unknown. I traceroute vises disse som!h og!n. I feilsituasjoner vil en ruter returnere en feilmelding av typen Unreachable, som da ikke betyr at mottakeren er ukjent, men at den ikke kan nås. Flere ulike feilkoder nyttes til dette. I traceroute vises dette som!n der n er feilkoden. En vanlig kontormaskin er en maskin med en tut inn i Internettet. Det samme gjelder for servermaskiner. Disse ligger på Internettet s utkant, periferi (network edge, periphery). Neste maskin er ett hopp fra maskin A, og ett steg fra kanten. Vanligvis er dette en ruter, som har to og flere linker; en ruter med bare en link er ingen ruter. Fra avsendermaskin A er det vanligvis bare en aktuell vei videre, nemlig det som er default route eller default gateway. Denne peker videre til denne ruteren. Rutetabellene på disse periferimaskinene (klienter og servere) er vanligvis satt opp med statisk ruting der tabellen ikke endres automatisk. I målesammenheng kan det være at brukeren ønsker å sjekke en rute som ikke går den faste veien. Til dette kan brukes parameter -r og angi hvilken maskin som skal være første hopp på veien. Det er altså hver ruter underveis, som bestemmer videresendingen. En annen form for ruting er kilderuting (source routing). Her er det avsender som i pakkehodet legger med en ønsket rute. Hver ruter vil (hvis de tillater kilderuting) forsøke å videresende slik avsenderen har angitt. I løselig kilderuting (loose source routing) skal pakkene rutes innom de angitte maskinene, men det tillates at pakken er innom andre maskiner innimellom. I strikt kilderuting (strict source routing) skal pakken kun innom de angitte maskiner (og ingen andre!). I traceroute kan brukeren med parameter -g angi opptil åtte maskiner for løselig kilderuting. Ikke alle rutere støtter opp om slik kilderuting, men hvis de vil sender de en ICMP Source Route Failed feilmelding til avsender. Dette vises i traceroute som!s. For å spre belastning over flere nett eller sikre seg flere adkomstveier, kan spesielt servere være tilkoblet flere linjer. Disse maskiner er multi-homed og har da flere veier ut fra seg og likens, mange veier inn til seg. Dette har altså fordeler, men kan også være noe ugunstig, da det fører til kraftig økning hva 7

8 angår størrelse på enkelte rutingtabeller. Ruten som traceroute viser vil for slike maskiner, være forskjellig avhengig av hvilken linje som brukes. Eksakt spesifisering av hvilken linje som brukes gis med parameter -i. Fragmentering En pakke har en lengde tilsvarende det som ble pakket inn (som kom ovenfra ) pluss lengden på hodet. I tillegg må også dette pakkes videre inn for å fraktes over linjen som har egne pakkeregler. Ulike linjer har ulike maksimum pakkestørrelser, (MTU, Maximum Transfer Unit) og en pakke vil noen ganger måtte fragmenteres i to eller flere pakker for å passe. Dette er noe uheldig, da det tar tid å fragmentere og spesielt kostbart å defragmentere (sette sammen fragmentene til det som var opprinnelig pakke). For at ruterne (maskinene underveis) skal slippe å bruke produksjonskapasitet til defragmentering, er det en regel i standardverket som sier at det er mottaker (B) og ingen andre som skal defragmentere Hos mottaker skal en likevel sette sammen pakker til en større enhet, og mye av funksjonaliteten innhas derfor allerede. For å unngå fragmentering vil TCP og UDP underveis forsøke seg frem for å finne en MTU som ikke gir fragmentering, altså laveste MTU langs ruten. Dette kalles MTU Discovery, hvilket reflekterer at minste pakkestørrelse varierer blant rutene og derfor må oppdages for hver forbindelse mellom klient og tjener. Av ulike årsaker er det nødvendig for avsender å reservere seg mot fragmentering, ved å legge ved et flagg i pakkehodet som heter don t fragment. Istedetfor å fragmentere en slik pakke, vil ruteren returnere en feilmelding ICMP Fragmentation Needed, samt verdi for den link-mtu som gjorde at fragmentering var nødvendig. Dette er en mekanisme som muliggjør nevnte MTU-discovery. For å få traceroute til å be om do not fragment brukes parameter -u. Ved feilmelding skrives!f på skjermen, men siden traceroute bruker 40 Byte pakker hvis ikke annet er angitt, er det sjelden at stiens MTU overskrides. For spesielle målinger er det interessant å avdekke hele stiens MTU. En kan med parameter -P be traceroute om å følge opp ICMP feilmelding med å redusere pakkens størrelse slik at den passer i denne linjen der det ble midlertidig stopp. Administrative sperrer I tillegg til vanlig ruting (og TTL-inspeksjon) vil en ruter ha ekstra oppgaver relatert til sikkerhet. Sikring er ekstraarbeid, og var lite påtenkt i Internettets første leveår, da det var essensielt å maksimalisere produksjonskapasitet i det som i dag fortoner seg som særs svakt utrustede rutere. Hver pakke må da i tillegg, tilfredsstille visse regler for å bli videresendt. Disse ruterne bedriver pakkefiltrering (packet filtering), og reglene kalles filtering rules. Et slikt pakkefilter er en del av et større sperreverk som kalles brannvegg (firewall). Da det tar ekstra tid å behandle pakker gjøres det vanligvis ett sted, ved inngangen til en bedrifts lokale nettverk, i bedriftens aksessruter. Men, også internt kan 8

9 det være behov for slik sikring, for eksempel mellom de ulike nett for ansatte og studenter ved en Høgskole. En ruter kan velge å sende feilmelding tilbake til sender hvis pakker må droppes grunnet slik filtrering. Tre ulike ICMP feilmeldinger kan nyttes til dette, nemlig Destination Network Administratively Prohibited, Destination Host Administratively Prohibited, eller Communication Administratively Prohibited by Filtering. I traceroute vises en!x for disse ruterne. Sekvensnummer og Duplikat (ping) Et annet nyttig verktøy, i tillegg til traceroute er ping som har navn etter ubåters sondering etter andre ubåter. Et hørbart ping ville resultere hvis det var andre i farvannet. En annen analogi er ønsket om å høre et ekko. Prinsippet i ping er at avsender A sender en ICMP Echo Request til en annen maskin, mottaker B. Til et slikt signal svarer B med en ICMP Echo Reply. Hos A jubles det over svaret, og en rundetid skrives ut. Med parameter -a lages et auditivt signal (pip) for hvert non-duplikat, altså svar som ikke har vært hørt før. Enhver (Echo) Request sendes ut med et sekvensnummer som gjentas av B i (Echo) Reply. Slik vet avsender hvilken Request som besvares. Med duplikat menes at flere Request ankommer hos avsender for samme sekvensnummer. Duplikater er mulig i Internettet, men er antakeligvis en feil og bør besvares med en oppryddingsaksjon fra driftspersonalet. Tenk på hvordan ruterne virker. De sletter alle pakker som av ulike årsaker ikke kan videresendes. Kun i multicast er det snakk om duplisering underveis. Derfor er det avsender som må ha laget duplikatet, og den mest sannsynlige årsaken er at avsender tror at den forrige pakken forsvant og derfor sender den om igjen. Den kan ha forsvunnet, men da er duplikater heller ikke mulig. Hvis mottaker ser et duplikat er det fordi den opprinnelige ikke hadde forsvunnet, men tatt en lengre runde gjennom nettet. Dette skal normalt ikke skje, da de fleste pakker følger samme rute gjennom nettet. Ruteendring skjer som følge av linkbrudd eller alvorlige belastnings-endring, et sted i nettet. Ved linkbrudd vil jo den opprinnelige pakken droppes fordi den ikke kan videresendes (og duplikat er umulig). Men ved kortvarige linkbrudd er det mulig at nabopakker tar vilt forskjellige veier. Med mindre driftsavdelingen kjenner til slike kortvarige brudd er duplikater et symptom om alvorlige feil internt i nettet. Med parameter -i angis avstand i tid mellom hver Request. Vanligvis vil ping sende Request med 1 sekunds mellomrom. Med parameter -c kan brukeren bestemme hvor mange som sendes før ping avslutter. Til slutt skrives en oversikt med statistikk og annet relatert til måleseansen. Her sendes altså neste Request før forrige Request er bekreftet. Det betyr at avsenderen må holde orden på hvilke som er bekreftet og hvilke som er ubekreftet. Med flodping sendes signalene uavbrutt med et bittelite opphold på 0.01 sekund (10 millisekund, mikrosekund). Dette ordnes med parameter -f og ping viser en prikk for hver utsendte Request og et backspace for hver mottatte Reply. 9

10 Ruteopptak En viktig mulighet i Internettet er å be pakken selv huske ruten den følger. I hodet legger derfor hver ruter sin adresse, med den følge at hodet gror inntil det når mottaker. Dette kalles record route, og er et tilvalg i IP som sjelden brukes da det stjeler produksjonskapasitet. Det er heller ikke mulig å lagre mer enn åtte ruter. Men, i diagnostisering er det viktig. I ping vil en med parameter -R be om at ruten lagres i hodet. Hos mottaker B vil den lagrede ruten være komplett og i svaret (Reply) legges den med slik at avsender kan se hvilken vei pakkene tok. Sammendrag Med verktøyene traceroute og ping ble de viktigste deler av Internettet belyst. De utnytter viktige feilmeldinger som ruterne avgir. Begge er måleverktøy og derfor opptatt av litt andre egenskaper i Internettet enn vanlige brukerprogram som weblesere, tekstbehandlere og epost-program. Det kan godt nevnes at det finnes et utall andre testprogram som ligner eller gjenbruker deler av disse to verktøyene. VisualRoute og PingTool er eksempel, og gir grafiske fremstillinger ved å kontakte ulike karttjenester og annet som er nødvendig for å koble IP-adresse til AS og geografiske koordinat. Disse vil gi et mere interessant innblikk og sikkert gi raskere forståelse for en problemsituasjon. Men, for opplæringens skyld er det viktig å forklare det underliggende. Ved å ha lest og studert de to basisverktøyene vil det blant annet være lettere å skreddersy andre og mer omfattende grafiske verktøy. En kan også bruke verktøyene i program der en utnytter svar fra verktøyene i en større egenutviklet automatiserings-sammenheng. I problemsituasjoner er det altså uvurderlig å kjenne til hva ruterne gjør, hvorfor feil oppstår, hvorfor feilmeldinger ikke oppstår og hvordan diagnosen eventuelt kan stilles. Internettet er sammensatt av ulike AS med ansvar for sin egen del av nettet, og det er viktig å isolere feil slik at korrekt AS kan kontaktes. Enda viktigere er kanskje det å oppdage feil automatisk slik at nedetiden kan reduseres og uten bruk av kostbart IT-personale. Men, for å gjøre seg selv uunnværlig og derved sikre seg langvarig engasjement er det bedre å satse på solid grunnforståelse og unngå all automatikk. Oppgaver Repetisjon og grundigere forståelse oppnås ved å gjøre oppgavene under. 1. Hvordan er det mulig for traceroute hos avsender A å vite hvilken maskin som har sendt feilmeldingen? 2. Sitat fra eksamensoppgave ved Høgskolen i Agder, Juni 2004: Hva menes med at IP-adressen er abstrakt? 3. Hva skjer i traceroute hvis ruteren utstyrer feilmeldingen ICMP Time Exceeded med en TTL lik den som var i datameldingens TTL? 10

11 4. Hva er forskjell på stiens MTU og linkenes MTU? 5. Hvordan finner en ut hvor mange ubekreftede signal en har ved bruk av flodping? 6. Hva er formålet med flodping? Hva er ulempene? 7. Forklar kort forskjell mellom traceroute og ping som bruker IP-opsjonen Record Route. Hvordan oppdages ruten? Og, hvorfor trenger vi egentlig traceroute når vi har ping? 8. Lag en oversikt over alle IP-opsjoner som er mulig å ta i bruk. Her bruker du Internettet og søker etter IP options. 9. Hvilke felter i IP-pakkehodet er ikke nevnt i notatet, og hva brukes de til? 10. Lag oversikt over alle ICMP feilmeldinger som brukes i hvilken sammenheng de er nyttige for traceroute og ping. Forklar altså nøye hvorfor feilmeldingene blir nyttige. Hvilke feilmeldinger i ICMP er det som ikke har blitt belyst? Hint: Søk på google.com eller les den RFC som definerer ICMP. I UNIX kan du lese en opplisting i /usr/include/netinet/ip_ icmp.h 11. Hvorfor er det en fordel at traceroute slår av beregning av sjekksum? 12. Forklar litt om hvordan arbeidsoppgavene til IP-prosessen har blitt redusert for å derved maksimere produksjonskapasiteten. Minst tre tiltak har vært nevnt i notatet. 13. Hvorfor er det interessant å vurdere parametrene -x, -u og -t i bruken av traceroute? Hva er det man oppnår? 11