Å telle én G.729-pakke gjennom en IPsec-tunnel

Tale over IPsec oppgis som en codec-bitrate, og tallet er feil ved hver grense unntatt codec-ens egen. Lyden er 8 kbit/s, pakken som bærer den er større, ESP-konvolutten er enda større, og Ethernet-rammen legger til innramming som et opptak på tunnelen aldri viser. Å telle én pakke fra et oppgitt format er den eneste måten å finne ut hva den fysiske lenken faktisk må bære. Gjennomgangen nedenfor gjør det bare for én retning, og hvert tall her er aritmetikk, ikke måling.

Start med et paketeringsvalg, ikke et codec-tall

En codec-tabell gir nyttelastens hastighet og ingenting annet: G.729 sender 8 kbit/s, som er 30 byte lyd hver 30 ms. Den sier ingenting om headere, beskyttelse eller innramming, og de tre dominerer resultatet. Intervallet er et policyvalg begge ender må bli enige om, så velg det først og oppgi det, fordi hvert senere tall avhenger av den ene beslutningen.

Dette eksempelet bruker 30 ms, så pakkehastigheten er 33.3 per sekund. Det forutsetter en RTP-header på 12 byte, en UDP-header på 8 byte og en indre IPv4-header på 20 byte uten opsjoner, og ingen SRTP, headerkomprimering eller utfylling for trafikkstrøms-konfidensialitet; enhver endring flytter budsjettet med seg, derfor hører forutsetningene hjemme ved siden av svaret.

Legg til de indre headerne, deretter ESP-konvolutten

Applikasjonen sender nyttelast pluss RTP pluss UDP pluss IP, som er 70 byte ved denne paketeringen. Den indre strømmen blir 18.7 kbit/s, allerede mer enn det dobbelte av codec-hastigheten, fordi headere og ikke lyd utgjør det meste av pakken. Ingen av de bytene er stemme; de er prisen for adressering og sekvensering. Et opptak tatt over tunnelen viser nøyaktig dette tallet, og det er tallet folk siterer når de sier at samtalen er liten.

Det er også tallet som aldri når kabelen. ESP-tunnelmodus legger til en SPI og sekvensnummer på 8 byte, en eksplisitt IV på 8 byte for AES-GCM, en trailer på 2 byte og en autentiseringstagg på 16 byte. Nyttelasten på 70 byte pluss traileren ender på 72, som allerede oppfyller justeringen på fire byte, så det trengs ingen ekstra utfylling her.RFC 4106 fastsetter størrelsene på GCM-IV og taggen, og begge hører i aritmetikken, ikke i en 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 de ytre headerne som NAT-gjennomgang krever

Utenfor ESP-konvolutten sitter en ytre IPv4-header på 20 byte og en UDP-header på 8 byte for NAT-gjennomgang, så pakken blir 132 byte. UDP-innkapslingen finnes fordi pakken må overleve en oversettende enhet mellom partene, og den endrer den ytre formen uten å berøre den beskyttede nyttelasten. Ved 33.3 pakker per sekund er 132 byte omtrent 35.2 kbit/s, eller rundt fire ganger codec-ens nominelle hastighet.

Verken taggen eller IV-en kan fjernes fra anslaget for å gjøre det mindre, fordi begge er del av det lenken faktisk skal bære. Et anslag som utelater dem, beskriver en pakke mottakeren ville avvise. Det samme gjelder traileren, som finnes for å markere nyttelastens grense og neste header inne i det beskyttede området.

Navngi grensen før du siterer tallet

Et ytre IP-tall utelukker fortsatt Ethernet-innramming. En tagget eller utagget tilgangslenke legger til en MAC-header på 14 byte og en rammesjekksekvens på 4 byte, som gjør rammen 150 byte, og det er størrelsen en svitsjport teller. Ved samme pakkehastighet er det 40 kbit/s, fem ganger codec-hastigheten, og forskjellen er ikke sløsing men prisen for transport.

Tallet 40 kbit/s utelukker fortsatt preambelen, mellomrommet mellom rammer, VLAN-tagger, leverandørinnkapsling, RTCP, signalering og lyden som går den andre veien. Det er et anslag per retning, ikke en lenkereservasjon, og å sitere det som en overdriver hva lenken må reservere på ett sted mens det underdriver det på et annet. Et opptak på verten kan også overse innramming som lenken legger til, derfor må grensen navngis sammen med tallet, og derfor er en grensetabell mer nyttig enn ett enkelt hovedtall. Reserver separat for retningen du ikke tellet.

Kontroller aritmetikken mot grensesnittet

Før du stoler på anslaget, sammenlign det med det grensesnittet rapporterer for et kjent antall pakker. Ta opptak på det fysiske grensesnittet og ikke på tunneleinheten, slik at innrammingen du prøver å regne med er inkludert, og forvent et lite avvik i stedet for et perfekt samsvar.

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

Opptaket bekrefter den ytre pakkestørrelsen, mens grensesnittellerne viser hastigheten inkludert innramming. Hvis de to avviker med omtrent Ethernet-tillegget, er aritmetikken riktig og bare grensen var feil navngitt. Et avvik langt større enn én rammeheader peker på noe annet på lenken, som gjensendinger eller en annen strøm som deler grensesnittet. Skriv paketeringsintervallet, beskyttelsessuiten og grensen ved siden av tallet, fordi et anslag uten de tre blir sitert som en måling av neste leser.