Eksamensprediksjon 6 av 7 · våren 2026

Prediksjon 6 — «Regnestykke-settet»

Det mest konsistente mønstret over alle fem analyserte eksamener er at minst 30 % av poengene er ren tallregning: forsinkelse, subnetting, sockets-telling, P2P-tid, throughput, ALOHA-effektivitet, CRC-rest, kø. Dette settet henter ut formlene og kjører dem mot nye tall, slik at du har drillet hver familie minst én gang på fersk konfigurasjon. Del I: 14 spørsmål (42 p). Del II: 5 oppgaver (58 p).

Strategi for dette settet

Formel-pakke å pugge: L/R, (N+P−1)·L/R, 2^32−x−2, N(N−1)/2, F/u_s, F/d_min, NF/(u_s+Σu_i), 1/e og 1/(2e).
Ny konfigurasjon hver gang: ingen oppgaver er kopi av eks 1–5; tallene er endret slik at du ikke kan resirkulere et utenat-svar.
Vis utregning: Del II gir delpoeng for korrekt metode selv ved regnefeil — skriv mellomledd.

Del I — Automatisk rettede spørsmål

14 flervalg (3p) + 1 sant/usant-blokk (5p) + 1 koble-oppgave (4p) · 51 poeng totalt

Hver oppgave er ren tallregning — bruk papir og blyant. Avsluttes med en sant/usant-blokk om regnestykker som ofte misforstås, og en koble-oppgave for formler.

Spørsmål 1 3 poeng Kap. 1 · Pipelining

En sti har 3 rutere mellom kilde og mål (totalt 4 lenker). Hver lenke har rate R = 50 Mbps, og pakkestørrelsen er L = 5000 bit. P = 7 pakker sendes back-to-back. Propageringen er neglisjerbar. Hva er minimum tid før alle pakker er mottatt?

A 0,7 ms
B 1,0 ms
C 1,4 ms
D 2,8 ms

Vis fasit

Riktig svar: B — 1,0 ms

Pipelining-formelen: (N + P − 1)·L/R der N er antall lenker.

L/R = 5 000 / 50·10⁶ = 100 µs per lenke.

(N + P − 1) = 4 + 7 − 1 = 10. Total: 10 · 100 µs = 1 000 µs = 1,0 ms.

Felle: D er hva du ville fått om hver pakke gikk gjennom hver lenke uten pipelining (4·7·100 µs = 2,8 ms).

Pensum: Kap. 1 — Pipelining

Spørsmål 2 3 poeng Kap. 4 · Subnetting

Hvor mange brukbare verts-adresser er det i et /27-subnett?

A 30
B 32
C 62
D 64

Vis fasit

Riktig svar: A — 30

2³²⁻²⁷ − 2 = 2⁵ − 2 = 32 − 2 = 30. Trekker fra nettverksadresse (alle host-bits = 0) og broadcastadresse (alle = 1).

Felle: B og D er brutto antall adresser uten å trekke fra de to reserverte.

Pensum: Kap. 4 — Subnetting

Spørsmål 3 3 poeng Kap. 3 · TCP-sekvensnr

Host A og B kommuniserer over TCP. B har mottatt alt opp til byte 1 200. A sender to segmenter back-to-back. Det første har sekvensnr=1 201, kilde-port=4502, dest-port=80, og 150 byte data. Det andre har 200 byte data. Hva er (sekvensnr, kilde-port, dest-port) i det andre segmentet?

A (1 351, 4502, 80)
B (1 351, 80, 4502)
C (1 401, 4502, 80)
D (1 201, 4502, 80)

Vis fasit

Riktig svar: A — (1 351, 4502, 80)

Sekvensnr i andre segment = sekvensnr₁ + lengde₁ = 1 201 + 150 = 1 351. Portene byttes ikke siden begge segmenter går samme retning (A → B).

Felle: B er ACK-en fra B til A (motsatt retning). C teller med andre segments lengde også (feil).

Pensum: Kap. 3 — TCP-segmenter

Spørsmål 4 3 poeng Kap. 1 · Throughput

Tre lenker i en sti har rater R₁ = 800 Mbps, R₂ = 250 Mbps, R₃ = 100 Mbps. To samtidige TCP-økter bruker stien og deler kapasiteten rettferdig på flaskehalsen. Hva er maks gjennomstrømning per økt?

A 50 Mbps
B 100 Mbps
C 125 Mbps
D 400 Mbps

Vis fasit

Riktig svar: A — 50 Mbps

Flaskehalsen er min(R₁, R₂, R₃) = 100 Mbps. To økter deler den likt → 50 Mbps per økt.

Felle: C er hva du får ved å dele R₂ i to (men R₃ < R₂ så det er R₃ som er flaskehalsen).

Pensum: Kap. 1 — Flaskehals

Spørsmål 5 3 poeng Kap. 8 · Nøkler

En klasse på 12 studenter skal kunne kommunisere parvis konfidensielt med symmetriske nøkler. Hvor mange nøkler trengs totalt?

A 12
B 24
C 66
D 132

Vis fasit

Riktig svar: C — 66

N(N−1)/2 = 12·11/2 = 66 nøkler. Hver nøkkel deles av nøyaktig to personer.

Til kontrast: med offentlig nøkkel-kryptografi trenger man bare 2N = 24 nøkler (et par per person), eller bare N = 12 nøkkelpar. Det er mye mer skalerbart.

Pensum: Kap. 8 — Symmetrisk kryptografi

Spørsmål 6 3 poeng Kap. 2 · Sockets

En TCP-server lytter på port 8080 og har 7 aktive klientforbindelser. Hvor mange sockets eksisterer på serverprosessen totalt?

A 1 — alle klienter deler samme port
B 7
C 8
D 14

Vis fasit

Riktig svar: C — 8

1 lyttende «welcoming socket» + 7 forbindelses-sockets (én per klient, opprettet av accept()). Hver TCP-forbindelse identifiseres av (kilde-IP, kilde-port, dest-IP, dest-port).

Generelt: K aktive forbindelser → K + 1 sockets på server. UDP-server klarer seg med kun 1.

Pensum: Kap. 2 — Socket-programmering

Spørsmål 7 3 poeng Kap. 2 · P2P

Distribuér en fil F = 80 Mbyte til N = 30 peers via P2P. Serveropplastingsrate u_s = 80 Mbps. Hver peer: u_i = 5 Mbps, d_i = 16 Mbps. Hva er minste distribusjonstid?

A 8 s
B 40 s
C 84 s
D 480 s

Vis fasit

Riktig svar: C — 84 s

F = 80·8 = 640 Mbit. Tre kandidater i max-uttrykket:

F/u_s = 640/80 = 8 s
F/d_min = 640/16 = 40 s
NF/(u_s+Nu_i) = 30·640 / (80 + 30·5) = 19 200 / 230 ≈ 83,5 s

Maks ≈ 84 s. Den totale opplastingskapasiteten i systemet er flaskehalsen — ikke noen enkelt peer eller serveren alene.

Pensum: Kap. 2.6 — P2P

Spørsmål 8 3 poeng Kap. 6 · ALOHA

N noder bruker slotted ALOHA. Hver node sender med sannsynlighet p per slot. Hvilken p maksimerer effektiviteten, og hva er den maksimale effektiviteten?

A p = 1/N, effektivitet ≈ 1/(2e) ≈ 0,18
B p = 1/N, effektivitet ≈ 1/e ≈ 0,37
C p = 1/(2N), effektivitet ≈ 0,5
D p = 1, effektivitet → 1 når N er stor

Vis fasit

Riktig svar: B — p = 1/N, ≈ 0,37

Sannsynligheten for at nøyaktig én node sender = N·p·(1−p)^N−1. Maksimer mhp p: p* = 1/N. I grensen N → ∞ er max ≈ 1/e ≈ 0,37.

Pure ALOHA halverer det fordi kollisjonsvinduet er dobbelt: max ≈ 1/(2e) ≈ 0,18.

Pensum: Kap. 6.3 — ALOHA

Spørsmål 9 3 poeng Kap. 1 · Cut-through

En pakke på 10 000 bit sendes A → svitsj → B. Lenkene har rate R₁ = R₂ = 100 Mbps. Svitsjen bruker cut-through: starter videresending så snart de første 1000 bit er mottatt. Propagering neglisjerbar. Hvor lang tid tar det fra første bit forlater A til siste bit ankommer B?

A 100 µs
B 110 µs
C 200 µs
D 1 010 µs

Vis fasit

Riktig svar: B — 110 µs

A bruker 10 000 / 10⁸ = 100 µs på å sende. Svitsjen starter videresending etter 1 000 / 10⁸ = 10 µs. Siste bit må sende på lenke 2: 100 µs etter at videresending starter, totalt fra start = 10 + 100 = 110 µs.

Til sammenlikning: med store-and-forward = 100 + 100 = 200 µs. Cut-through sparer 90 µs ved å ikke vente på hele pakken.

Pensum: Kap. 1 — Cut-through vs store-and-forward

Spørsmål 10 3 poeng Kap. 3 · Sjekksum

Beregn Internet-checksummen over de to 16-bits ordene 0110 0110 0110 0110 og 0101 0101 0101 0101. Hva blir checksum-feltet (16 bit)?

A 1011 1011 1011 1011
B 0100 0100 0100 0100
C 0001 0001 0001 0001
D 0011 0011 0011 0011

Vis fasit

Riktig svar: B — 0100 0100 0100 0100

Steg 1: addere ordene (binær addisjon).

0110 0110 0110 0110 = 0x6666
+ 0101 0101 0101 0101 = 0x5555
= 1011 1011 1011 1011 = 0xBBBB (ingen carry-out)

Steg 2: ingen wrap nødvendig (ingen carry).

Steg 3: ones' complement (flip alle bit):

NOT(1011 1011 1011 1011) = 0100 0100 0100 0100

Mottakeren regner samme uttrykk over alle ordene inkludert checksumen — resultatet skal være alle ettall, dvs. 1111 1111 1111 1111.

Pensum: Kap. 3 — Internet checksum

Spørsmål 11 3 poeng Kap. 4 · Køforsinkelse

En FIFO-kø har én utgående lenke som tar 1 tidsenhet per pakke. Sju pakker ankommer ved tidene 0, 0, 0, 1, 2, 3, 4. Hva er gjennomsnittlig køforsinkelse for de 7 pakkene? (Køforsinkelse = tid fra ankomst til sending starter.)

A 0,5 tidsenheter
B 1,0 tidsenheter
C 1,57 tidsenheter
D 3,0 tidsenheter

Vis fasit

Riktig svar: C — 1,57 tidsenheter

Tabell (ankomst, sending starter, kø-tid):

P1: ankomst 0, send 0–1, kø = 0
P2: ankomst 0, send 1–2, kø = 1
P3: ankomst 0, send 2–3, kø = 2
P4: ankomst 1, send 3–4, kø = 2
P5: ankomst 2, send 4–5, kø = 2
P6: ankomst 3, send 5–6, kø = 2
P7: ankomst 4, send 6–7, kø = 2

Sum kø-tid = 0 + 1 + 2 + 2 + 2 + 2 + 2 = 11. Snitt = 11/7 ≈ 1,57.

Felle: D regner kun for de tre som kom samtidig på t=0; de senere ankomstene reduserer snittet fordi de allerede har gått inn i en kortere kø.

Pensum: Kap. 4 — Køforsinkelse

Spørsmål 12 3 poeng Kap. 2 · HTTP

En HTML-side på 100 kbit har 3 innebygde objekter à 100 kbit. RTT = 100 ms, lenke = 100 Mbps. Hva er total responstid med non-persistent HTTP, ingen parallelle forbindelser? (L/R for ett objekt = 1 ms.)

A 201 ms
B 404 ms
C 804 ms
D 1004 ms

Vis fasit

Riktig svar: C — 804 ms

Per objekt non-persistent: 2·RTT + L/R = 200 + 1 = 201 ms. 4 objekter (1 base + 3 embedded): 4 · 201 = 804 ms.

Til sammenlikning: med parallelle TCP-forbindelser = 2 · 201 = 402 ms; med persistent uten pipelining = RTT (oppsett) + 4·(RTT + L/R) = 100 + 4·101 = 504 ms.

Pensum: Kap. 2 — HTTP-ytelse

Spørsmål 13 3 poeng Kap. 6 · CRC

For data D = 110010 og generator G = 1001, hva blir CRC-resten R?

A 011
B 100
C 110
D 101

Vis fasit

Riktig svar: B — 100

Legg til |G|−1 = 3 nuller etter D: 110010000. Modulo-2-divisjon med G = 1001 (XOR, ingen carry):

   110010000
   1001
   ----
    101 10000     (XOR ved bit 0)
    1001
    ----
     0011 0000   (XOR ved bit 1)

Etter trinn 2: 000100000 — leading 1 nå ved bit 3.

     000100000
        1001
        ----
        0001 00 (XOR ved bit 3)

Etter trinn 3: 000000100. Ingen flere divisjoner mulig.

Rest = de tre siste bitene = 100

Send D || R = 110010 100. Mottaker deler hele strengen på G — rest = 0 ⇒ ok.

Pensum: Kap. 6 — CRC · øving 3 task 5

Spørsmål 14 3 poeng Kap. 2 · Klient-server

Distribuér F = 100 Mbit til N = 50 klienter via tradisjonell klient-server. Serveropplasting u_s = 200 Mbps. Klientnedlasting d_i = 25 Mbps (alle like). Minste distribusjonstid?

A 0,5 s
B 4 s
C 25 s
D 50 s

Vis fasit

Riktig svar: C — 25 s

Klient-server: D_cs = max(NF/u_s, F/d_min).

NF/u_s = 50·100/200 = 25 s
F/d_min = 100/25 = 4 s

Maks = 25 s. Server-opplasting er flaskehals fordi den må sende fil-ekvivalenter til alle 50 klienter, mens nedlastingskapasiteten per klient er rikelig.

P2P ville løst dette mye raskere fordi peers bidrar med opplasting.

Pensum: Kap. 2.6 — Filfordeling

Spørsmål 15 5 poeng Kap. 1–6 · Regne-feller

Avgjør om hver av påstandene er sann eller usann. 1 poeng per riktig svar.

Vis fasit

Riktige svar

Sant — i en linjesvitsjet krets «leies» en dedikert ende-til-ende-bane med konstant rate. Pakkesvitsjet legger derimot på L/R per lenke (store-and-forward).
Usant — /29 har 2³²⁻²⁹ − 2 = 8 − 2 = 6 brukbare vertsadresser. Trekk fra nettverks- og broadcastadressene.
Usant — flere økter deler flaskehalsen rettferdig. To økter på en flaskehals R deler typisk like mye → R/2 hver.
Sant — pure ALOHA: 1/(2e) ≈ 0,18; slotted: 1/e ≈ 0,37. Synkronisering halverer kollisjonsvinduet.
Usant — det er 5 forbindelses-sockets pluss 1 lyttende welcoming socket = 6 totalt.

Pensum: Kap. 1 · Kap. 2 · Kap. 6

Spørsmål 16 4 poeng Kap. 1–8 · Formler

Koble hvert beregnings-scenario til formelen som bør brukes. Velg én bokstav per rad. 1 poeng per riktig kobling.

Selectable Items

(N + P − 1) · L/R
2^32−x − 2
N(N−1)/2
max(F/u_s, F/d_min, NF/(u_s+Σu_i))
1/(2e)

#	Scenario	Ditt valg
1	P pakker sendt back-to-back gjennom N rutere på lik rate
2	Antall brukbare vertsadresser i et /x-subnett
3	Antall symmetriske nøkler for parvis konfidensiell kommunikasjon i en gruppe på N personer
4	Minste distribusjonstid i en P2P-arkitektur til N peers

Merk: én av de fem formlene er en distraktor.

Vis fasit

Riktige koblinger

Scenario	Formel
1 Pipelining	a — (N+P−1)·L/R
2 /x brukbare verter	b — 2^32−x−2
3 Symmetriske nøkler	c — N(N−1)/2
4 P2P-distribusjon	d — max(...)

Distraktor: e — 1/(2e) ≈ 0,18 er maksimal effektivitet for pure ALOHA. Slotted ALOHA er 1/e ≈ 0,37.

Pensum: oppsummert i Må-kunne-oversikten.

Del II — Åpne oppgaver

5 oppgaver · 58 poeng totalt

Vis utregning. Delpoeng for korrekt metode selv ved tallfeil.

Oppgave 1 14 poeng Kap. 2 · HTTP-ytelse

Du klikker en lenke. Nettleseren laster en HTML-side på 400 kbit som inneholder 6 innebygde bilder à 200 kbit. RTT = 150 ms, lenkerate = 20 Mbps. Tiden for å sende GET er neglisjerbar. Inkluder TCP-oppsett (1 RTT) per non-persistent objekt og 1 RTT for persistent.

a) Beregn responstid med non-persistent HTTP, ingen parallelle. (4p)

b) Med non-persistent HTTP, parallelle TCP-forbindelser (én per innebygd objekt). (4p)

c) Med persistent HTTP uten pipelining. (4p)

d) I hvilken av de tre er kostnaden av nye TCP-forbindelser størst andel av total tid? Begrunn kort. (2p)

Vis fasit

Forarbeide:

L_base/R = 400·10³ / 20·10⁶ = 20 ms
L_img/R = 200·10³ / 20·10⁶ = 10 ms

a) Non-persistent uten parallell:

Per objekt: 2·RTT + L/R. Base: 2·150 + 20 = 320 ms. Hvert bilde: 2·150 + 10 = 310 ms.

Total = 320 + 6·310 = 320 + 1 860 = 2 180 ms ≈ 2,18 s.

b) Non-persistent med parallell:

Base først (320 ms), så 6 bilder i parallell (én ny TCP-runde = 310 ms hver, men parallelt = 310 ms totalt for batchen).

Total = 320 + 310 = 630 ms ≈ 0,63 s.

c) Persistent uten pipelining:

1 TCP-oppsett (RTT = 150 ms) + base (RTT + L/R = 170 ms) + 6 bilder sekvensielt à (RTT + L/R = 160 ms).

Total = 150 + 170 + 6·160 = 150 + 170 + 960 = 1 280 ms ≈ 1,28 s.

d) Hvor er TCP-oppsett dyrest?

I (a). Hver av de 7 objektene betaler en full RTT for håndtrykket — det er 7·150 = 1 050 ms av de 2 180, dvs ~48 % av total tid. I (b) deles 7 håndtrykk på 2 RTT-er totalt; i (c) er det kun ett håndtrykk hele veien. Persistent + pipelining ville reduserer videre.

Pensum: Kap. 2 — HTTP-ytelse

Oppgave 2 12 poeng Kap. 4 · Subnetting

Du har fått tildelt blokken 10.50.16.0/20. Du skal dele den i tre subnett med følgende krav:

Subnett A: skal støtte minst 1000 grensesnitt
Subnett B: skal støtte minst 500 grensesnitt
Subnett C: skal støtte minst 250 grensesnitt

a) Hvor stor blokk (i /x-form) trenger du for hvert av A, B og C? Begrunn med formel. (3p)

b) Tildel konkrete adresseblokker a.b.c.d/x til hvert subnett ut fra 10.50.16.0/20. Vis at de ikke overlapper. (5p)

c) Hva er broadcast-adressen i hvert av de tre subnettene? (3p)

d) Hvor mange adresser er ubrukt etter tildelingen? (1p)

Vis fasit

a) Bestem prefiks-lengde:

1000 verter: 2^k − 2 ≥ 1000 → k ≥ 10 → trenger /22 (1 022 brukbare).
500 verter: 2^k − 2 ≥ 500 → k ≥ 9 → /23 (510 brukbare).
250 verter: 2^k − 2 ≥ 250 → k ≥ 8 → /24 (254 brukbare).

b) Tildeling:

Foreldreblokken /20 dekker 4 096 adresser: 10.50.16.0 – 10.50.31.255. Tildel største blokk først:

A (/22): 10.50.16.0/22 — dekker 16.0–19.255 (1 024 adresser).
B (/23): 10.50.20.0/23 — dekker 20.0–21.255 (512 adresser).
C (/24): 10.50.22.0/24 — dekker 22.0–22.255 (256 adresser).

Ingen overlapp. Til sammen brukt: 1 024 + 512 + 256 = 1 792.

c) Broadcast i hvert subnett:

A: 10.50.19.255
B: 10.50.21.255
C: 10.50.22.255

d) Ubrukt:

4 096 − 1 792 = 2 304 adresser (intervallet 10.50.23.0 – 10.50.31.255). Disse kan reserveres for fremtidig vekst eller deles videre.

Pensum: Kap. 4 — Subnetting · øving 2 task 5

Oppgave 3 12 poeng Kap. 3 · TCP cwnd

Tegn (eller beskriv) en TCP cwnd-graf med følgende hendelser:

cwnd starter på 1 MSS i runde 0.
I runde 0–4 dobles cwnd hver RTT (slow start, ssthresh = 32).
Etter runde 4 (cwnd = 16) inntreffer 3 duplikat-ACK (Reno-style): cwnd halveres til 8, så lineær økning (AIMD) per RTT.
I runde 12 (cwnd = 16) inntreffer timeout: ssthresh settes til cwnd/2 = 8, og cwnd resettes til 1 — slow start igjen.
Slow start fortsetter til ssthresh = 8, så AIMD.

a) Tegn grafen for runde 0 til 18. Marker tydelig hvor slow start, AIMD og fast recovery starter/slutter. (6p)

b) Hva er forskjellen i hvordan TCP Reno reagerer på 3 dupl. ACK versus timeout? Hvorfor forskjell? (3p)

c) I hvilken fase er TCP «mest aggressiv» med å øke cwnd, og hvorfor er det trygt der men ikke senere? (3p)

Vis fasit

a) Grafens nøkkelpunkter:

Runde	cwnd	Fase
0	1	Slow start
1	2	Slow start
2	4	Slow start
3	8	Slow start
4	16	Slow start (3 dup ACK her)
5	8	Fast recovery → AIMD
6	9	AIMD
...	...	+1 per RTT
12	16	AIMD (timeout her)
13	1	Slow start (ssthresh=8)
14	2	Slow start
15	4	Slow start
16	8	Slow start når ssthresh
17	9	AIMD
18	10	AIMD

b) 3 dup ACK vs timeout:

Ved 3 dup ACK reduserer Reno cwnd til halvparten og fortsetter i AIMD (fast recovery). Ved timeout settes cwnd til 1 og slow start starter på nytt.

Begrunnelse: 3 dup ACK indikerer at noen pakker fortsatt går igjennom — bare én er tapt. Timeout antyder at hele forbindelsen kanskje har brutt sammen — start forsiktig.

c) Mest aggressiv fase:

Slow start — eksponentiell vekst (dobler hver RTT). Trygt i starten fordi cwnd er liten og nettets reelle kapasitet er ukjent — vi vil finne ut raskt. Senere er nettverket nær mettningspunktet, så raskt vekst ville utløst tap; AIMD er konservativ for å holde fairness.

Pensum: Kap. 3 — TCP congestion control

Oppgave 4 10 poeng Kap. 6 · CRC

Avsender har data D = 10110011 og vil legge på en CRC med generator G = 1101.

a) Forklar metoden i tre steg. (3p)

b) Utfør modulo-2-divisjonen og finn rest R. Vis hver underdivisjon. (5p)

c) Hva sender avsenderen totalt? Hvordan verifiserer mottakeren at det ikke er feil? (2p)

Vis fasit

a) Tre steg:

Legg til |G|−1 = 3 nuller etter D: 10110011 000 (11 bit).
Modulo-2-divisjon (XOR — ikke vanlig divisjon, ingen carry) av dette med G = 1101.
Resten (3 bit) er CRC. Send D || R.

b) Divisjon (steg for steg):

Start:  10110011000
Trinn 1: XOR med 1101 ved bit 0:
        10110011000
        1101
        ----
        01100011000

Trinn 2: leading 1 ved bit 1, XOR med 1101 ved bit 1:
        01100011000
         1101
         ----
        00001011000

Trinn 3: leading 1 ved bit 4, XOR med 1101 ved bit 4:
        00001011000
            1101
            ----
        00000110000

Trinn 4: leading 1 ved bit 5, XOR med 1101 ved bit 5:
        00000110000
             1101
             ----
        00000001000

Ingen flere divisjoner mulig — leading 1 ved bit 8 lar oss
ikke plassere 1101 (vi har bare 3 bit igjen).

R = de tre siste bitene = 100

c) Sending og verifisering:

Avsender sender D || R = 10110011 100 (11 bit). Mottaker tar hele strengen og deler på G — hvis rest = 0, antas overføring uten feil. Ved rest ≠ 0 har bitfeil oppstått (ikke alle feil oppdages, men de aller fleste). Pakken kan da kastes.

Pensum: Kap. 6 — CRC · eks_4 3.1

Oppgave 5 10 poeng Kap. 4 · Forwarding

En ruter har følgende forwarding-tabell:

Prefiks	Utport
`10.0.0.0/8`	I0
`10.40.0.0/14`	I1
`10.40.32.0/19`	I2
`192.168.0.0/16`	I3
Default	I4

a) For hver av disse pakkene, finn riktig utport. Vis bit-for-bit-match for én av dem. (6p)

i) 10.40.32.50
ii) 10.41.50.10
iii) 10.50.20.5
iv) 192.168.30.5
v) 172.16.0.1

b) Forklar hvorfor lengste prefiks-match er rekkefølge-uavhengig (i motsetning til «første-match»). (4p)

Vis fasit

a) Forwarding:

i) 10.40.32.50 → I2. Match: /8, /14 (10.40–10.43), /19 (10.40.32.0–10.40.63.255). Lengste = /19.
ii) 10.41.50.10 → I1. Match: /8, /14 (41 er i 40–43). /19 krever andre oktett = 40 eksakt — 41 matcher ikke. Lengste = /14.
iii) 10.50.20.5 → I0. /8 matcher (10.x). /14 dekker 10.40–10.43; 50 er utenfor. Lengste = /8.
iv) 192.168.30.5 → I3. Bare /16 matcher.
v) 172.16.0.1 → I4 (default). Ingen prefiks matcher.

Bit-for-bit for ii) 10.41.50.10:

Binær: 00001010 00101001 00110010 00001010

/8 (10.0.0.0): første 8 bit = 00001010 ✓
/14 (10.40.0.0): første 14 bit av 10.40.0.0 = 00001010 001010. IP har 00001010 001010 (de to siste bit er 01, men /14 krever bare de første 6 av andre oktett) ✓
/19 (10.40.32.0): første 19 bit av 10.40.32.0 = 00001010 00101000 001. IP har 00001010 00101001 001 — ulik ved bit 16 (8.+8. er 00101001 ≠ 00101000) ✗

Lengste = /14 → I1.

b) Hvorfor rekkefølge-uavhengig:

Med lengste prefiks-match velger ruteren alltid den mest spesifikke ruten uavhengig av hvor den ligger i tabellen. Med «første-match» hadde det matter at /8 (10.x) sto før /19 (10.40.32.x) — da hadde 10.40.32.50 gått til I0 (feil!) i stedet for I2.

Lengste-match støtter også hierarkisk tildeling: ISP får /16 mot omverdenen, kunden inni får /22, og forwarding finner alltid mest spesifikk vei.

Pensum: Kap. 4 — Lengste prefiks-match