Å telje éi G.729-pakke gjennom ein IPsec-tunnel

Tale over IPsec vert oppgitt som ein codec-bitrate, og talet er feil ved kvar grense utanom codec-en si eiga. Lyden er 8 kbit/s, pakken som ber han er større, ESP-konvolutten er endå større, og Ethernet-ramma legg til innramming som eit opptak på tunnelen aldri viser. Å telje éi pakke frå eit oppgjeve format er den einaste måten å finne ut kva den fysiske lenkja faktisk må bera. Gjennomgangen nedanfor gjer det berre for éin retning, og kvart tal her er aritmetikk, ikkje måling.

Start med eit paketeringsval, ikkje eit codec-tal

Ei codec-tabell gir nyttelastfarten og ingenting anna: G.729 sender 8 kbit/s, som er 30 byte lyd kvar 30 ms. Ho seier ingenting om headarar, vern eller innramming, og dei tre dominerer resultatet. Intervallet er eit politisk val som begge endar må bli samde om, så vel det først og oppgi det, fordi kvart seinare tal heng av den eine avgjerda.

Dette dømet brukar 30 ms, så pakkefarten er 33.3 per sekund. Det føreset ein RTP-header på 12 byte, ein UDP-header på 8 byte og ein indre IPv4-header på 20 byte utan opsjonar, og ingen SRTP, headerkomprimering eller utfylling for konfidensialitet i trafikkstraumen; kvar endring flyttar budsjettet med seg, derfor høyrer føresetnadene heime ved sida av svaret.

Legg til dei indre headarane, deretter ESP-konvolutten

Applikasjonen sender nyttelast pluss RTP pluss UDP pluss IP, som er 70 byte ved denne paketeringa. Den indre straumen blir 18.7 kbit/s, allereie meir enn det dobbelte av codec-farten, fordi headarar og ikkje lyd utgjer det meste av pakken. Ingen av dei byta er stemme; dei er prisen for adressering og sekvensering. Eit opptak teke over tunnelen viser nøyaktig dette talet, og det er talet folk siterer når dei seier at samtalen er liten.

Det er òg talet som aldri når kabelen. ESP-tunnelmodus legg til ein SPI og sekvensnummer på 8 byte, ein eksplisitt IV på 8 byte for AES-GCM, ein trailer på 2 byte og ein autentiseringstag på 16 byte. Nyttelasta på 70 byte pluss traileren endar på 72, som allereie oppfyller justeringa på fire byte, så det trengst inga ekstra utfylling her.RFC 4106 fastset storleikane på GCM-IV og taggen, og begge høyrer i aritmetikken, ikkje i ein fotnote:

30  payload, G.729 at 30 ms
12  RTP
 8  UDP
20  inner IPv4
--
70  inner IP packet
 8  ESP SPI and sequence
 8  explicit IV
 2  pad length and next header
16  authentication tag
--
104 ESP packet

Legg til dei ytre headarane som NAT-gjennomgang krev

Utanfor ESP-konvolutten sit ein ytre IPv4-header på 20 byte og ein UDP-header på 8 byte for NAT-gjennomgang, så pakken blir 132 byte. UDP-innkapslinga finst fordi pakken må overleve eit omsetjande apparat mellom partane, og ho endrar den ytre forma utan å røre den verna nyttelasta. Ved 33.3 pakkar per sekund er 132 byte om lag 35.2 kbit/s, eller rundt fire gonger den nominelle codec-farten.

Korkje taggen eller IV-en kan fjernast frå overslaget for å gjere det mindre, fordi begge er del av det lenkja faktisk skal bera. Eit overslag som utelèt dei, skildrar ein pakke som mottakaren ville avvise. Det same gjeld traileren, som finst for å markere grensa til nyttelasta og neste header inne i det verna området.

Namngje grensa før du siterer talet

Eit ytre IP-tal utelèt framleis Ethernet-innramming. Ei merkt eller umerkt tilgangslenkje legg til ein MAC-header på 14 byte og ein rammesjekksekvens på 4 byte, som gjer ramma 150 byte, og det er storleiken ein svitsjport tel. Ved same pakkefart er det 40 kbit/s, fem gonger codec-farten, og skilnaden er ikkje sløsing men prisen for transport.

Talet 40 kbit/s utelèt framleis preambelen, mellomrommet mellom rammer, VLAN-taggar, leverandørinnkapsling, RTCP, signalering og lyden som går den andre vegen. Det er eit overslag per retning, ikkje ein lenkjereservasjon, og å sitere det som ein overdriv kva lenkja må reservere på ein stad medan det underdriv det på ein annan. Eit opptak på verten kan òg oversjå innramming som lenkja legg til, derfor må grensa namngjevast saman med talet, og derfor er ein grensetabell meir nyttig enn eitt einskilt hovudtal. Reserver separat for retninga du ikkje talde.

Kontroller aritmetikken mot grensesnittet

Før du stolar på overslaget, samanlikn det med det grensesnittet rapporterer for eit kjent tal pakkar. Ta opptak på det fysiske grensesnittet og ikkje på tunneleininga, slik at innramminga du prøver å rekne med er med, og vent eit lite avvik i staden for eit perfekt samsvar.

sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0

Opptaket stadfestar den ytre pakkestorleiken, medan grensesnitteljarane viser farten inkludert innramming. Viss dei to avvik med om lag Ethernet-tillegget, er aritmetikken rett og berre grensa var feil namngjeven. Eit avvik langt større enn éin rammeheader peikar på noko anna på lenkja, som gjensendingar eller ein annan straum som deler grensesnittet. Skriv paketeringsintervallet, vernesuiten og grensa ved sida av talet, fordi eit overslag utan dei tre blir sitert som ei måling av neste lesar.