Nettverkslaget:
Kontrollplanet
Hvordan rutere i et digert nettverk blir enige om hvor pakkene dine skal — og hvordan de roper om hjelp når noe går galt.
- Hva kontrollplanet faktisk er
- Forskjellen på forwarding og routing
- Per-router vs. sentralisert kontroll
- Grunnleggende rutingprinsipper og klassifisering
- Hvordan ICMP fungerer under panseret
- Hvorfor
tracerouteer genialt
Problemet kontrollplanet løser
Før vi snakker om algoritmer og protokoller: hvorfor trenger vi i det hele tatt et "kontrollplan"?
Tenk deg at du sender en e-post fra laptoppen din i Trondheim til en venn i Tokyo. Pakken din må gjennom titalls rutere — kanskje hundre — før den kommer frem. På hver eneste ruter underveis må noen ta en beslutning: hvilken utgang skal denne pakken ut av? Det er ikke én enkelt avgjørelse. Det er tusenvis av mikro-beslutninger som må være konsistente med hverandre, ellers havner pakken i en løkke eller i en blindvei.
Kurose og Ross deler derfor nettverkslaget i to deler, og skillet er helt essensielt for å forstå resten av kapittelet:
De to planene
Dataplanet (data plane) gjør selve jobben: det flytter en pakke fra innganger på en ruter til riktig utgang. Dette skjer i nanosekunder — milliarder av ganger i sekundet på en stor ruter. Operasjonen er enkel fordi tabellen allerede ligger klar.
Kontrollplanet (control plane) bygger den tabellen. Det bestemmer hvilken utgang som er riktig for hver mulige destinasjon. Dette skjer på en mye langsommere tidsskala — sekunder til minutter — og involverer at rutere snakker med hverandre for å bli enige om nettverkets form.
Analogien som hjelper: dataplanet er som en postsorterer som leser adressen på konvolutten og legger den i riktig binge. Kontrollplanet er rutelaget som bestemte hvilken binge som skal gå hvor — det er bakromjobben som ingen kunde ser, men uten den kaster postsortereren bare ting tilfeldig.
To måter å organisere kontrollplanet
Det finnes grovt sett to filosofier for hvordan kontrollplanet skal bygges:
1. Per-ruter kontroll (tradisjonell). Hver ruter kjører sin egen lille routing-algoritme, snakker med sine naboer, og bygger sin egen lokale forwarding-tabell. Ingen sjef. Alle er likeverdige. Dette er typisk for det åpne internettet, så mange eksempler her handler om denne modellen.
2. Logisk sentralisert kontroll (Software Defined Networking, SDN). En sentral kontroller et sted i nettverket beregner alle forwarding-tabeller og dytter dem ut til alle ruterne. Ruterne blir "dumme" — de bare gjør det kontrolleren sier. Begge organiseringene er pensum fra kapittel 5.1 i læreboken; SDN er vanlig blant annet i datasentre og egne driftsnett.
Hvordan rutere finner gode veier
Målet er enkelt å beskrive, men fryktelig vanskelig å løse: finn en god vei fra avsender til mottaker gjennom et nettverk du ikke har oversikt over.
En rutingprotokoll har ett hovedmål: bestemme gode ruter (paths) fra sendende verter til mottakende verter, gjennom nettverket av rutere. La oss pakke opp den setningen nøye, for hvert ord betyr noe.
En rute (eller path) er rett og slett sekvensen av rutere en pakke passerer gjennom, fra startverten til destinasjonen. Hvis du sender en pakke fra laptoppen din og den går gjennom rutere R1 → R4 → R7 → R9 før den når målet, så er det ruten.
Men hva betyr "god"? Det kommer an på hva du optimerer for. Vanlige tolkninger er lavest kostnad (kanskje målt i antall hopp, kanskje i båndbredde, kanskje i pengeleieavtaler mellom ISP-er), raskest (minst forsinkelse), eller minst overbelastet (unngå lenker der det står i kø). Hver ruterprotokoll gjør sine egne valg om hva "god" betyr — og det er en del av grunnen til at ruting regnes som en av de klassiske "topp 10"-utfordringene innen nettverk.
To akser for klassifisering
Rutingalgoritmer kan klassifiseres langs to uavhengige akser. Forstår du disse to, forstår du grunnstrukturen til alt vi snakker om videre.
Akse 1 — Global eller desentralisert informasjon?
Global betyr at alle rutere på en eller annen måte kjenner hele nettverkets topologi: hvilke rutere finnes, hvilke lenker de har mellom seg, og hva kostnaden på hver lenke er. Med full kunnskap kan hver ruter uavhengig beregne den beste stien til alle destinasjoner. Dette er ideen bak link-state-algoritmer.
Desentralisert betyr at ingen har hele bildet. Hver ruter kjenner bare kostnaden til sine direkte naboer i starten. Så snakker rutere med naboene sine, utveksler det de vet, og gradvis blir alle enige om de beste stiene gjennom en iterativ prosess. Dette er ideen bak distance-vector-algoritmer.
Akse 2 — Statisk eller dynamisk?
Statiske ruter endres sjelden (kanskje når en nettverksadministrator manuelt konfigurerer noe). Dynamiske ruter oppdateres fortløpende — enten med jevne mellomrom eller som respons på at en lenke endrer kostnad eller forsvinner. Moderne nettverk bruker nesten alltid dynamiske algoritmer, fordi internett endrer seg for ofte til å holde tritt manuelt.
ICMP: når nettverket må snakke med seg selv
Rutingprotokoller bestemmer hvor pakker skal. Men hva skjer når noe går galt underveis? Det er her ICMP kommer inn.
Tenk deg at du sender en pakke til en IP-adresse som ikke finnes. Hva skjer? Noen må fortelle deg det — ellers sitter du og venter for alltid på et svar som aldri kommer. Eller: en pakke har levd for lenge i nettverket (kanskje den gikk i en løkke) og må kastes. Hvem gir beskjed til avsenderen? Svaret på begge spørsmål er ICMP — Internet Control Message Protocol.
ICMP er nettverkets signalspråk. Det brukes av verter og rutere til å utveksle nettverks-nivå-informasjon med hverandre. De to viktigste kategoriene av meldinger er:
Feilrapportering. Når noe går galt — destinasjonsvert er utilgjengelig, nettverk er utilgjengelig, port er stengt, protokoll finnes ikke — sender en ruter eller vert en ICMP-melding tilbake til avsenderen som sier hva som gikk galt.
Echo request/reply. Det er dette kommandoen ping bruker. Du sender en "er du der?"-melding, og hvis mottakeren lever, sender den et "ja!" tilbake.
Hvor passer ICMP i stakken?
Her er en detalj som ofte forvirrer: ICMP regnes som en del av nettverkslaget, men ICMP-meldinger transporteres inni IP-datagram. Så strengt tatt ligger ICMP "oppå" IP, selv om begge regnes som del av nettverkslaget. Tenk på ICMP som en liten hjelpeprotokoll som snylter på IP for å komme fram.
ICMP-meldinger har type- og code-felt (tabellen nedenfor). I tillegg inneholder typiske feilmeldinger en kopi av IP-headeren og de første 8 bytene av det IP-datagrammet som utløste ICMP-meldingen, slik at avsenderen kan identifisere hvilken opprinnelig pakke det gjelder — slik Kurose og Ross beskriver i kapittel 5.6.
De viktigste ICMP-typene
Her er tabellen over de ICMP-meldingene du kommer til å møte oftest. Legg spesielt merke til type 0 og 8 (som ping bruker) og type 11 (som traceroute er avhengig av — mer om det snart).
| Type | Code | Beskrivelse |
|---|---|---|
| 0 | 0 | echo reply (svaret på ping) |
| 3 | 0 | destinasjonsnett utilgjengelig |
| 3 | 1 | destinasjonsvert utilgjengelig |
| 3 | 2 | destinasjonsprotokoll utilgjengelig |
| 3 | 3 | destinasjonsport utilgjengelig |
| 3 | 6 | destinasjonsnett ukjent |
| 3 | 7 | destinasjonsvert ukjent |
| 4 | 0 | source quench (ikke i bruk) |
| 8 | 0 | echo request (selve ping-forespørselen) |
| 9 | 0 | route advertisement |
| 10 | 0 | router discovery |
| 11 | 0 | TTL expired (pakken levde for lenge) |
| 12 | 0 | feil i IP-headeren |
IPv6 har tilsvarende funksjon gjennom ICMPv6 (RFC 4443), med blant annet typen «Packet Too Big» for MTU-problemer på IPv6-stier.
Traceroute: et genialt hack
Hvordan kan du finne ut hvilke rutere pakkene dine passerer gjennom på vei til en destinasjon — uten å ha tilgang til noen av dem? Svaret er et av nettverks-verdens fineste triks.
Programmet traceroute viser deg en liste over rutere en pakke passerer på vei til et mål. Det er nyttig når du feilsøker — men hvordan klarer den det? Du kan jo ikke spørre hver ruter underveis om navnet sitt. De vet ikke engang at du prøver å nå dem.
Trikset utnytter en feature som egentlig er laget for å hindre at pakker lever evig: TTL-feltet (Time To Live) i IP-headeren. TTL er et tall som dekrementeres med 1 hver gang en pakke passerer en ruter. Når TTL treffer 0, kaster ruteren pakken og sender en ICMP-melding tilbake til avsenderen: "type 11, code 0 — TTL expired". Og — dette er nøkkelen — den meldingen inneholder ruterens egen IP-adresse.
Ser du hvor dette bærer?
Traceroute-trikset
Hvis du sender en pakke med TTL = 1, vil første ruter dekrementere det til 0 og returnere en TTL-expired-melding. Du får vite første ruters adresse.
Send så en pakke med TTL = 2. Den overlever første ruter, men blir droppet av den andre, som returnerer en TTL-expired-melding. Du får vite andre ruters adresse.
Fortsett til TTL = 3, 4, 5, ... og du har hele stien.
Det er så enkelt det er, og så vakkert. Traceroute misbruker TTL-mekanismen for å tvinge hver ruter på ruten til å "avsløre" seg selv, én etter én.
Slik fungerer det steg for steg
Kildemaskinen sender ut sett av UDP-segmenter (vanligvis tre per TTL-verdi, for å kunne måle RTT-variasjon). Hver pakke i et sett har samme TTL.
- Sett 1 har TTL = 1 → dør på ruter 1 → ruter 1 sender "TTL expired"
- Sett 2 har TTL = 2 → dør på ruter 2 → ruter 2 sender "TTL expired"
- Sett 3 har TTL = 3 → dør på ruter 3 → ruter 3 sender "TTL expired"
- ... og så videre
Når ICMP-meldingen kommer tilbake, registrerer avsenderen rundtrippstiden (RTT) og ruterens IP. Den viser dem fortløpende på skjermen din — det er det du ser mens traceroute kjører.
Når stopper det?
To ting kan skje som avslutter traceroute:
1. UDP-segmentet når til slutt faktisk frem til destinasjonen (når TTL er stor nok). Nå er det ikke noen ruter som dropper den — men destinasjonen har sannsynligvis ikke en tjeneste som lytter på UDP-porten traceroute brukte (den velger bevisst en usannsynlig port). Så destinasjonen svarer med en ICMP "destination port unreachable"-melding (type 3, code 3).
2. Kilden ser denne meldingen og skjønner: aha, vi har nådd målet. Den stopper.