Nettverkslaget:
Kontrollplanet

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:

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 slik internett er bygget i dag, og det er det vi fokuserer på i dette kapittelet.

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. Dette er moderne, og brukes i store datasentere, men er utenfor rammen for dette kapittelet.

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.

Link-state: "jeg har kartet"

Link-state-algoritmer bygger på en enkel, men sterk idé: hvis hver ruter har et komplett kart over nettverket, kan hver enkelt beregne de beste stiene helt alene, uten å måtte spørre noen. Spørsmålet blir da: hvordan skaffer man seg det kartet?

Løsningen er flooding. Hver ruter lager en liten melding — en Link-State Advertisement (LSA) — som beskriver alle lenkene den selv har og hva de koster. Så sender den LSA-en til alle sine naboer. Naboene videresender den til sine naboer. Osv. Etter kort tid har hver ruter i nettverket mottatt LSA-er fra alle andre, og har dermed kunnskap om hele topologien.

Når en ruter har dette komplette kartet, kjører den en kortest-sti-algoritme (typisk Dijkstras algoritme) lokalt for å finne den beste stien til hver mulige destinasjon. Resultatet fylles inn i forwarding-tabellen, og dataplanet er klart til å flytte pakker.

Distance-vector: "jeg stoler på naboene mine"

Distance-vector-algoritmer tar en helt annen tilnærming. I stedet for at alle skal ha hele kartet, har hver ruter bare en distansevektor — en tabell som sier "til destinasjon X, er min beste avstand Y, og jeg sender pakken ut via nabo Z". Ruteren får ikke noe globalt overblikk; den får bare sin egen lille liste.

Slik fungerer det i praksis:

Steg 1 — Informasjonsdeling. Hver ruter sender sin egen distansevektor til sine direkte naboer. "Slik ser verden ut fra mitt ståsted," sier den.

Steg 2 — Oppdatering. Når en ruter mottar en naboene sine sin vektor, sammenligner den: "Hmm, nabo B sier den kan nå destinasjon X med kostnad 5. For å nå nabo B koster det meg 2. Så hvis jeg sender via B, kan jeg nå X med kostnad 7. Er det bedre enn det jeg hadde?" Hvis ja, oppdaterer den sin egen tabell.

Steg 3 — Konvergens. Hver gang en ruters tabell endres, sender den ut sin nye vektor til naboene, som kanskje oppdaterer sine tabeller, som kanskje sender ut nye vektorer, osv. Etter en stund stabiliserer alt seg, og alle rutere har konsistente og (forhåpentligvis) optimale tabeller.

Sammenligning

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.

En ICMP-melding inneholder tre hovedfelter:

• Type — hvilken kategori melding dette er (f.eks. 3 = "destination unreachable", 8 = "echo request")
• Code — en underkategori som gir mer detaljer (f.eks. type 3 + code 1 = "host unreachable")
• De første 8 bytene av IP-datagrammet som forårsaket feilen — slik at avsenderen vet hvilken pakke ICMP-meldingen gjelder

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).

Og til slutt: nettverksadministrasjon

Rutingalgoritmer og ICMP er byggesteinene. Men noen må sette alt sammen, overvåke det, og fikse det når det går i stykker.

Et moderne autonomt system — det tekniske ordet for "et nettverk drevet av én organisasjon", for eksempel en ISP, et universitet eller en stor bedrift — består av tusenvis av samhandlende maskinvare- og programvarekomponenter. Å holde orden på noe så komplekst krever et eget fagfelt: nettverksadministrasjon.

Den klassiske definisjonen fra Saydam & Magedanz (1996) fanger bredden godt: nettverksadministrasjon omfatter utrulling, integrering og koordinering av maskinvare, programvare og menneskelige elementer for å overvåke, teste, konfigurere, analysere, evaluere og kontrollere nettverket og dets ressurser — slik at kravene til ytelse og tjenestekvalitet møtes til en rimelig kostnad.

Oversatt til hverdagsspråk: noen må sørge for at lyset er på, at ingenting er på fyr, og at brukerne ikke ringer og klager. Andre komplekse systemer har samme type utfordring — et passasjerfly, et atomkraftverk, en stor fabrikk — alle må overvåkes og kontrolleres kontinuerlig for ikke å kollapse.