Tæl én G.729-pakke gennem en IPsec-tunnel

Tale over IPsec angives som en codec-bitrate, og det tal er forkert ved hver grænse undtagen codec'ens egen. Lyden er 8 kbit/s, pakken der bærer den er større, ESP-konvolutten er endnu større, og Ethernet-rammen tilføjer indramning, som en optagelse på tunnelen aldrig viser. At tælle én pakke ud fra et angivet format er den eneste måde at finde ud af, hvad det fysiske link faktisk skal bære. Gennemgangen nedenfor gør det kun for én retning, og hvert tal her er aritmetik, ikke måling.

Start med et paketeringsvalg, ikke et codec-tal

Et codec-skema giver nyttelastens hastighed og intet andet: G.729 udsender 8 kbit/s, hvilket er 30 byte lyd hver 30 ms. Det siger intet om headere, beskyttelse eller indramning, og de tre dominerer resultatet. Intervallet er et politikvalg, som begge ender skal blive enige om, så vælg det først og angiv det, fordi hvert senere tal afhænger af den ene beslutning.

Dette eksempel bruger 30 ms, så pakkehastigheden er 33.3 i sekundet. Det forudsætter en RTP-header på 12 byte, en UDP-header på 8 byte og en indre IPv4-header på 20 byte uden optioner samt ingen SRTP, headerkomprimering eller udfyldning til trafikstrømmens fortrolighed; enhver ændring flytter budgettet med sig, og derfor hører forudsætningerne til ved siden af svaret.

Tilføj de indre headere, derefter ESP-konvolutten

Applikationen sender nyttelast plus RTP plus UDP plus IP, hvilket er 70 byte ved denne paketering. Den indre strøm løber op i 18.7 kbit/s, allerede mere end det dobbelte af codec-hastigheden, fordi headere og ikke lyd udgør det meste af pakken. Ingen af de byte er stemme; de er prisen for adressering og sekvensering. En optagelse taget over tunnelen viser præcis dette tal, og det er det, folk citerer, når de siger, at opkaldet er lille.

Det er også det tal, der aldrig når kablet. ESP-tunnelmodus tilføjer en SPI og sekvensnummer på 8 byte, en eksplicit IV på 8 byte til AES-GCM, en trailer på 2 byte og et autentificeringstag på 16 byte. Nyttelasten på 70 byte plus traileren ender på 72, hvilket allerede opfylder justeringen på fire byte, så der er ikke brug for ekstra udfyldning her.RFC 4106 fastlægger størrelsen på GCM-IV og -tag, og begge hører i aritmetikken, ikke i en fodnote:

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

Tilføj de ydre headere, som NAT-gennemgang kræver

Uden for ESP-konvolutten sidder en ydre IPv4-header på 20 byte og en UDP-header på 8 byte til NAT-gennemgang, så pakken bliver 132 byte. UDP-indkapslingen findes, fordi pakken skal overleve en oversættende enhed mellem parterne, og den ændrer den ydre form uden at røre den beskyttede nyttelast. Ved 33.3 pakker i sekundet er 132 byte omkring 35.2 kbit/s, eller cirka fire gange codec'ens nominelle hastighed.

Hverken tagget eller IV'en kan fjernes fra skønnet for at gøre det mindre, fordi begge er en del af det, linket faktisk skal bære. Et skøn, der udelader dem, beskriver en pakke, som modtageren ville afvise. Det samme gælder traileren, som findes for at markere nyttelastens grænse og den næste header inde i det beskyttede område.

Navngiv grænsen, før du citerer tallet

Et ydre IP-tal udelukker stadig Ethernet-indramning. En tagget eller utagget adgangslinje tilføjer en MAC-header på 14 byte og en rammekontrolsekvens på 4 byte, hvilket gør rammen 150 byte, som er den størrelse, en switchport tæller. Ved samme pakkehastighed er det 40 kbit/s, fem gange codec-hastigheden, og forskellen er ikke spild men prisen for transport.

Tallet 40 kbit/s udelukker stadig præamblen, mellemrummet mellem rammer, VLAN-tags, udbyderindkapsling, RTCP, signalering og lyden, der rejser den anden vej. Det er et skøn pr. retning, ikke en linkreservation, og at citere det som en overdriver, hvad linket skal reservere ét sted, mens det underdriver det et andet. En optagelse på værten kan også overse indramning, som linket tilføjer, og derfor skal grænsen navngives sammen med tallet, og derfor er en grænsetabel mere nyttig end et enkelt hovedtal. Reserver separat for den retning, du ikke talte.

Kontrollér aritmetikken mod interface

Før du tror på skønnet, sammenlign det med, hvad interfacet rapporterer for et kendt antal pakker. Optag på det fysiske interface i stedet for tunneleenheden, så den indramning, du forsøger at regne med, er inkluderet, og forvent en lille afvigelse i stedet for et perfekt match.

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

Optagelsen bekræfter den ydre pakkestørrelse, mens interface-tællerne viser hastigheden inklusive indramning. Hvis de to afviger med omkring Ethernet-tillægget, er aritmetikken rigtig, og kun grænsen blev fejletiketteret. En forskel langt større end én rammeheader peger på noget andet på linket, såsom gensendinger eller en anden strøm, der deler interfacet. Skriv paketeringsintervallet, beskyttelsessuiten og grænsen ved siden af tallet, fordi et skøn uden de tre bliver citeret som en måling af den næste, der læser det.