L2TPv2, L2TPv3, GRE og VPWS: vel etter nyttelasta

Dei fleste L2TP mot GRE-diskusjonar fell saman av same grunn: namna ligg på ulike lag av problemet. To av dei skildrar innkapsling du konfigurerer på dine eigne rutarar. Eitt skildrar ein teneste som nokon andre sel deg. Start med nyttelasta endepunkta må bere, og samanlikninga blir ei kort liste med konsekvensar i staden for ein kamp om funksjonar.

Nyttelasta fyrst, protokollen etterpå

I praksis er nyttelasta éin av fire ting: ei PPP-økt, ei rå Ethernet-ramme, ein IP-pakke eller ei MPLS-ramme som blir overlevert til ein leverandør. Kvar stiller ulike krav til adressering, handsaming av kringkasting og feildeteksjon. Tek du feil av denne lista, reddar inga justering av innkapslinga designet.

Alt utanfor desse radene blir lagt til seinare, som kryptering, komprimering eller trafikkforming. Vel rada fyrst.

L2TPv2 og L2TPv3 deler eit namn og nesten ingenting anna

L2TPv2 finst for å bere PPP-økter over eit IP-nettverk, og derfor blir det lese som ein fjernaksessprotokoll snarare enn ein generell rammetransport. L2TPv3 generaliserer den ideen: ei kontrollforbinding forhandlar om økter, og kvar økt ber ei definert foring på lag 2 mellom to IP-endepunkt. Same familienamn, annan kontrollprotokoll, annan øktmodell. Eit krav som berre seier L2TP, er ufullstendig, og ein mal kopiert frå feil versjon vil ikkje eingong forhandle.

Treng du PPP, er L2TPv2 det einaste realistiske medlemmet av familien; treng du Ethernet-rammer over ein ruta kjerne, er du på L2TPv3-territorium.

Transportdetaljane skil seg på måtar som kjem fram under ein brannmur-gjennomgang. L2TPv3 kan reise direkte over IP-protokoll 115 eller inne i UDP, vanlegvis på port 1701, medan L2TPv2 blir på UDP 1701 med PPP inni. Ein policy skriven for éin versjon kan sjå heilt riktig ut og likevel droppe den andre.

GRE er eit hovud, ikkje ein teneste

GRE pakkar ei nyttelast inn i eit firebyte-hovud med eit valfritt nøkkel- og sekvensfelt og gir deretter resultatet til IP for levering. Det seier ingenting om kva nyttelasta betyr, så implementasjonar kan tunnele IPv4, IPv6 eller Ethernet om desse protokolltypane er støtta. Generelt er ikkje det same som universelt: stadfest protokolltypen og fragmenteringsåtferda på den faktiske eininga.

Nøkkelfeltet er det som gjer GRE nyttig når fleire tunnelar deler eit par endepunktadresser, fordi mottakaren demultipleksar på den verdien. GRE over IPv4 kostar omtrent 24 byte før eventuelle ekstra alternativ, og det byrjar å bety noko på lenkjer som allereie er dimensjonerte for 1500-byte-rammer. Åleine tilbyr GRE ingen konfidensialitet, så det vanlege mønsteret parar det med IPsec og lèt IPsec eige kryptogrensa. Den paringa fungerer, men MTU-budsjettet må då dekkje båe hovuda.

GRE ber òg multicast og kringkasting gjennom tunnelen når nyttelasta er Ethernet, noko ein vanleg unicast-IP-tunnel ikkje kan. Det er den eigenskapen, snarare enn forkortinga, som vanlegvis får eit design til å velje det.

VPWS blir kjøpt, det blir ikkje konfigurert

Ein teneste for virtuell privat linje leverer ei punkt-til-punkt-forbinding på lag 2 gjennom nettverket til ein leverandør. Tilkoplingskrinsen din terminerer på ei rand-eining hos leverandøren, og pseudowiren gjennom kjernen tilhøyrer leverandøren. Spørsmåla som betyr noko, er driftsmessige: kvar demarkasjonen ligg, kven som eig den fyrste og siste mila, og kva leverandøren gjer med overstore rammer.

Det er her samanlikninga snur. L2TPv3 og GRE er ting du driftar ende til ende, så du feilsøkjer dei med dine eigne påloggingsdetaljar og dine eigne opptak. VPWS er ein kontrakt med ei overlevering, så eit avbrot startar med ein billett i staden for eit pakkeopptak. Ingen av modellane vinn ubetinga; dei feilar på ulike stader, og valet avheng av om du vil eige den siste mila.

Etikettstakken til pseudowiren blir inne i nettverket til leverandøren, så han endrar ikkje MTU-aritmetikken din slik eit synleg tunnelhovud gjer.

Vel éi rad og skriv ho ned

Noter avgjerda som éin setning med tre delar: nyttelast, innkapsling og transporteigar. Fest deretter tala som gjer ho kontrollerbar.

For kvar kandidat skriv du ned overhengskostnaden på lenkja, den største ramma banen godtek, og det fyrste hoppet som ville rapportere eit MTU-problem. Stadfest at båe endepunkta støttar protokolltypen eller økttypen du valde, ikkje berre marknadsføringsomgrepet i databladet. Bestem korleis multipleksing ville sjå ut om ein annan krets dukkar opp neste år, fordi GRE-nøklar og L2TPv3-økt-ID-ar ikkje er innbyrdes utskiftbare løysingar på det problemet. Send deretter éi overstor og éi normal ramme; det paret fangar dei fleste designa som såg bra ut på papiret.

Å samanlikne tunnelar etter namn held fram med å skape diskusjonar ingen kan avgjere. Å samanlikne dei etter nyttelast, overhengskostnad og eigarskap gir ei avgjerd på ein ettermiddag, pluss prova som trengst for å forsvare ho seinare.