Ethernet, svitsjer og ARP

To typer adresser, og broen mellom dem

Hver enhet på internett har to adresser — en IP-adresse og en MAC-adresse. Hvorfor begge? Og hvordan finner en maskin MAC-adressen til en annen når den bare kjenner IP-adressen?

IP-adressen er en logisk adresse. Den avhenger av hvor du befinner deg i nettverket — flytter du laptopen fra universitetet til hjemmet, får du en ny IP. Routere bruker IP-adresser for å sende pakker på tvers av hele internett. Men på selve lenken — det siste hoppet fra router til deg, eller mellom to verter på samme svitsj — er det ikke IP-adressen som brukes. Der trengs en fysisk, hardwired adresse: MAC-adressen.

En MAC-adresse er 48 bit lang, typisk skrevet i heksadesimal med bindestreker: 1A-2F-BB-76-09-AD. Den er (i teorien) unik for hvert nettverkskort i verden — produsentene får tildelt adresseblokker fra IEEE, og brenner adressen inn i ROM-en på kortet. En god analogi: IP-adressen er som en postadresse (endrer seg om du flytter), MAC-adressen er som et personnummer (følger deg).

Hvorfor trenger vi begge?

Kunne vi ikke bare brukt IP hele veien? I teorien, men det bryter lagdelingen. Lenkelaget må kunne fungere uten å vite noe om IP — på en Ethernet-lenke kan det godt være at pakken inni er AppleTalk eller IPX istedenfor IP. Lenkelaget trenger sin egen adressetype. Og MAC-adressen har en praktisk egenskap IP ikke har: den er portabel. Du kan flytte et nettverkskort mellom subnet uten å endre MAC, men IP-en må byttes.

Problemet: IP vet ikke MAC

Her er situasjonen: verten A vil sende et IP-datagram til verten B på samme LAN. A kjenner B sin IP-adresse (for eksempel fra en DNS-oppslag). Men for å legge datagrammet i en Ethernet-ramme og sende den på kabelen, trenger A MAC-adressen til B. Hvordan finner A den?

Hvordan ARP fungerer

Hver node har en liten tabell (ARP-cachen) med oppføringer som <IP, MAC, TTL>. TTL er typisk 20 minutter. Når A vil sende til B:

1. Er B allerede i cachen? Ja — bruk den lagrede MAC-en og send. Ferdig.
2. Nei? A lager en ARP-query som spør «Hvem har IP 137.196.7.14? Si fra til meg.»
3. Denne meldingen kapsles inn i en Ethernet-ramme med destinasjon FF-FF-FF-FF-FF-FF — broadcast-adressen. Alle på LAN-et mottar den.
4. Alle verter sjekker: «Er det min IP?» Alle sier nei, unntatt B, som svarer med en ARP-reply som inneholder MAC-adressen sin. Svaret er ikke broadcast — det er unicast direkte tilbake til A.
5. A mottar svaret, lagrer <B.IP, B.MAC, TTL=1200> i cachen, og kan nå sende sitt opprinnelige datagram.

Hva hvis målet ikke er på samme LAN?

ARP fungerer bare innenfor ett LAN — du kan ikke ARP-e deg til en server på andre siden av internett. Hvis A vil sende til en IP som ligger i et annet subnet, sender A ikke rammen direkte til målverten. Istedenfor sender A rammen til første-hopp-routeren (default gateway). Rammen har routerens MAC-adresse som destinasjon — men IP-datagrammet inni har fortsatt sluttvertens IP-adresse som mål.

Routeren mottar rammen, trekker ut IP-datagrammet, slår opp i sin rutetabell hvor datagrammet skal videre, pakker det inn i en ny ramme med ny kilde- og destinasjons-MAC (ARP på neste lenke), og sender det videre. IP-adressene er uendret hele veien. MAC-adressene byttes ved hvert hopp.

Den seirende LAN-teknologien

Ethernet ble funnet opp av Robert Metcalfe på 70-tallet. Det skulle ha dødd ut for lenge siden — konkurrenter var mer sofistikerte, raskere, bedre designet. Men Ethernet overlevde alle. Hvorfor?

Svaret: enkelhet og billig pris. Ethernet ble aldri den teknisk fineste løsningen, men den var «god nok» og veldig lett å implementere. Mens token ring og ATM slet med kompliserte protokoller, skalerte Ethernet fra 10 Mbit/s opp til 400 Gbit/s uten å endre fundamentalt på rammestrukturen eller adressesystemet. I dag er Ethernet den dominerende kablede LAN-teknologien — og har vært det i flere tiår.

Fra buss til stjerne

Opprinnelig var Ethernet en bussteknologi: alle maskiner var koblet til én lang koaksialkabel, og alle hørte alt. Kollisjoner var vanlige — derav CSMA/CD. Dette fungerte, men det ga ett kollisjonsdomene for hele nettverket, og båndbredden ble delt mellom alle.

Moderne Ethernet er svitsjet: hver vert har sin egen dedikerte kabel til en sentral svitsj. Hver lenke er et eget kollisjonsdomene med bare to endepunkter — verten og svitsjen. Kollisjoner blir i praksis umulig, og full-duplex er standarden: begge sider kan sende samtidig uten å forstyrre hverandre. CSMA/CD eksisterer fortsatt i spesifikasjonen, men den aktiveres kun i sjeldne tilfeller der en vert går i half-duplex-modus.

Ethernet-rammen

La oss se på hvert felt:

• Preamble (8 byte). Syv byte med 10101010 etterfulgt av én byte med 10101011. Brukes til å synkronisere mottakerens klokke med senderens — de siste to bitene «11» signaliserer at ramma starter nå.
• Destinasjons-MAC (6 byte). Hvem skal ha den. Hvis NIC-en ser sin egen adresse (eller broadcast FF-FF-FF-FF-FF-FF), leverer den innholdet opp til nettverkslaget. Ellers kastes rammen.
• Kilde-MAC (6 byte). Hvem som sendte den.
• Type (2 byte). Hvilken protokoll ligger inni? 0x0800 = IP, 0x0806 = ARP, osv. Mottakerens nettverkskort bruker dette til å demultiplekse oppover — riktig protokoll på nettverkslaget får pakken.
• Data (46–1500 byte). Nyttelasten. Minimum 46 byte — korteere pakker må padres — fordi CSMA/CD trenger en minimumslengde for å oppdage kollisjoner. Maksimum 1500 byte er MTU-grensen (Maximum Transmission Unit).
• CRC (4 byte). CRC-32 over hele rammen. Feil → rammen kastes umiddelbart.

Upålitelig og connectionless

Ethernet er connectionless: det er ingen handshake mellom NIC-ene før data sendes. Og det er upålitelig: mottakeren sender ikke ACK ved suksess og ingen NAK ved feil — den bare kaster rammer med feil. Hvis data går tapt, er det opp til høyere lag (TCP) å oppdage og retransmittere. Dette er helt bevisst. På moderne kablede lenker er feilraten så lav at ende-til-ende-pålitelighet er langt mer effektivt enn per-hopp-pålitelighet.

Den ydmyke, usynlige helten

Hvis du har et Ethernet-LAN i dag, har du minst én svitsj. De er «plug-and-play», lærer opp seg selv, og verter vet ikke engang at de finnes. Magien ligger i hvordan de oppdager hvor ting er.

En svitsj er en enhet på lenkelaget — lag 2 — som videresender rammer basert på MAC-adresser. Den tar imot en ramme på én port, kikker på destinasjons-MAC, og sender rammen videre kun på den ene porten der den vet at mottakeren befinner seg. Alle andre porter forblir uberørt. Det betyr at flere par med verter kan kommunisere samtidig uten å forstyrre hverandre. En svitsj med seks porter kan ha tre uavhengige samtaler i gang på en gang.

Svitsjer er transparente: vertene ser dem ikke. Du trenger ikke å konfigurere verten for å snakke gjennom en svitsj. Du trenger ikke konfigurere svitsjen heller — den lærer opp seg selv. Plugg inn, og det virker. Denne «plug-and-play»-egenskapen er en av hovedgrunnene til at svitsjer fortrengte hubber og gamle bussnettverk.

Svitsjtabellen

Hjertet i svitsjen er forwarding-tabellen. Hver oppføring er en trippel (MAC-adresse, port, tidsstempel). Den forteller svitsjen: «Verten med denne MAC-adressen nås via denne porten, og jeg lærte det på dette tidspunktet.» Tidsstempelet lar gamle oppføringer utløpe — hvis en vert har vært taus lenge (typisk noen minutter), slettes den fra tabellen.

Hvordan lærer svitsjen — self-learning-algoritmen

Svitsjen starter med en helt tom tabell. Når den mottar en ramme:

1. Lær. Se på kilde-MAC og porten rammen kom inn på. Lagre denne koblingen i tabellen (eller oppdater tidsstempelet hvis den finnes fra før).
2. Slå opp. Se på destinasjons-MAC. Finnes den i tabellen?
3. Hvis ja: Hvis destinasjonen er på samme port som rammen kom inn fra — kast den (mottakeren har jo allerede hørt den). Ellers, videresend den kun på den porten der mottakeren er.
4. Hvis nei: Flood. Send rammen ut på alle porter unntatt den den kom inn på. Mottakeren vil svare, og da lærer svitsjen hvor mottakeren er.

Sammenkobling av svitsjer

Self-learning fungerer akkurat likt når flere svitsjer er koblet sammen i en trehierarki. Hver svitsj lærer på egen hånd, via sine egne porter, hvilken retning en gitt MAC-adresse ligger. Hvis verten A i den venstre enden vil sende til verten G langt til høyre, sender første svitsj floode-rammen ut, og underveis lærer samtlige svitsjer hvor A ligger (fordi de ser kilde-MAC). Når G til slutt svarer, lærer alle svitsjene hvor G ligger (fra G sin kilde-MAC i svaret). Etter én hver-vei-utveksling er ruten helt oppe og går, og fremtidige rammer sendes målrettet.

Svitsjer vs. routere

Dette forvirrer ofte. Både svitsjer og routere er «store-and-forward»-enheter — de tar imot en pakke, tenker, og sender den videre. Men de opererer på ulike lag og med ulike adresser.

En dag i livet til en web-forespørsel

Nå binder vi alt sammen. En student kobler laptopen til universitetsnettet og åpner google.com i nettleseren. Det virker enkelt. La oss se hvor mange protokoller som faktisk løper i gang.

Scenariet er dette: en ny laptop kobler seg til et kablet Ethernet på campus. Brukeren skriver www.google.com i nettleseren og trykker Enter. Vi sporer alt som skjer — fra det øyeblikket kabelen plugges i, til den første pikselen av Google-logoen dukker opp på skjermen.

Steg 1 — Få en IP-adresse med DHCP

Før laptopen kan sende noe som helst ut på internett, må den ha en IP-adresse. Den trenger også å vite IP-adressen til første-hopp-routeren (default gateway) og IP-adressen til en DNS-server. Alt dette løser DHCP (Dynamic Host Configuration Protocol).

Laptopen lager en DHCP-forespørsel, pakker den inn i UDP, så IP, så en Ethernet-ramme. Destinasjons-MAC er FF-FF-FF-FF-FF-FF — broadcast — fordi laptopen ikke vet hvem DHCP-serveren er ennå. Rammen floodes gjennom LAN-et til router (som kjører DHCP-serveren). Den svarer med laptopens nye IP-adresse, nettmaske, default gateway, og DNS-server. Etter denne ene utvekslingen har laptopen alt den trenger for å være på nettet.

Steg 2 — Finn routerens MAC med ARP

Laptopen vil til slutt nå en server utenfor sitt eget LAN. Alle slike pakker må gå via routeren. For å sende den første rammen til routeren, trenger laptopen routerens MAC-adresse. Den har bare IP-adressen fra DHCP-svaret.

ARP løser dette. Laptopen broadcaster: «Hvem har IP 68.80.2.1?» Routeren svarer med sin MAC. Nå er laptopen klar.

Steg 3 — Finn Googles IP med DNS

Brukeren har skrevet www.google.com, ikke en IP-adresse. Laptopen må konvertere navnet til en IP. Den lager en DNS-forespørsel, pakker den i UDP / IP / Ethernet, og sender den mot default gateway. Rammen har routerens MAC som destinasjon, men IP-datagrammet inni har DNS-serverens IP som mål.

Routeren mottar rammen, pakker ut IP-datagrammet, slår opp i rutetabellen (bygget av protokoller som OSPF og BGP), og videresender det mot DNS-serveren — typisk gjennom ISP-ens nett. DNS-serveren svarer med Googles IP-adresse, for eksempel 64.233.169.105. Svaret tar returveien gjennom flere routere og havner til slutt tilbake på laptopen.

Steg 4 — Sett opp TCP-forbindelsen

Nå vet laptopen Googles IP. Nettleseren åpner en TCP-socket og starter three-way handshake: SYN → SYNACK → ACK. Hver av de tre meldingene går som et eget IP-datagram, innkapslet i Ethernet-rammer ved hvert hopp, gjennom kanskje 15 routere på tvers av internett. Når handshake er ferdig, er det en pålitelig TCP-forbindelse mellom laptopen og Googles server.

Steg 5 — HTTP-forespørsel og -svar

Nettleseren skriver en HTTP-forespørsel inn i TCP-socketen: GET / HTTP/1.1. Den deles opp i segmenter av TCP, hvert segment blir et IP-datagram, hvert datagram blir en ramme på hvert hopp. Googles server mottar forespørselen, genererer HTML-svaret, og sender det tilbake gjennom den samme TCP-forbindelsen. Nettleseren parser HTML, ber om bilder og stilark (flere HTTP-forespørsler), rendrer siden — og endelig ser brukeren Google-logoen.