Räkna ett G.729-paket genom en IPsec-tunnel

Tal över IPsec anges som codec-bitrate, och den siffran är fel vid varje gräns utom codec:ens egen. Ljudet är 8 kbit/s, paketet som bär det är större, ESP-höljet är ännu större, och Ethernet-ramen lägger till inramning som en inspelning på tunneln aldrig visar. Att räkna ett paket från ett angivet format är det enda sättet att ta reda på vad den fysiska länken faktiskt måste bära. Genomgången nedan gör det bara för en riktning, och varje tal här är aritmetik, inte mätning.

Börja med ett paketeringsval, inte ett codec-tal

En codec-tabell ger nyttolastens hastighet och ingenting annat: G.729 avger 8 kbit/s, vilket är 30 byte ljud var 30 ms. Den säger ingenting om huvuden, skydd eller inramning, och de tre dominerar resultatet. Intervallet är ett policyval som båda ändar måste enas om, så välj det först och ange det, eftersom varje senare tal beror på det enda beslutet.

Det här exemplet använder 30 ms, så paketfrekvensen är 33.3 per sekund. Det förutsätter ett RTP-huvud på 12 byte, ett UDP-huvud på 8 byte och ett inre IPv4-huvud på 20 byte utan optioner, och ingen SRTP, huvudkomprimering eller utfyllnad för trafikflödets konfidentialitet; varje ändring flyttar budgeten med sig, därför hör antagandena hemma bredvid svaret.

Lägg till de inre huvudena, sedan ESP-höljet

Applikationen skickar nyttolast plus RTP plus UDP plus IP, vilket är 70 byte vid denna paketering. Den inre strömmen landar på 18.7 kbit/s, redan mer än dubbelt codec-hastigheten, eftersom huvuden och inte ljud utgör större delen av paketet. Ingen av de byten är röst; de är priset för adressering och sekvensering. En inspelning ovanför tunneln visar exakt detta tal, och det är det folk citerar när de säger att samtalet är litet.

Det är också talet som aldrig når kabeln. ESP-tunnelmodus lägger till en SPI och sekvensnummer på 8 byte, en explicit IV på 8 byte för AES-GCM, en trailer på 2 byte och en autentiseringstagg på 16 byte. Nyttolasten på 70 byte plus trailern landar på 72, vilket redan uppfyller justeringen på fyra byte, så ingen extra utfyllnad behövs här.RFC 4106 fastställer storlekarna på GCM-IV:n och taggen, och båda hör i aritmetiken, inte i en fotnot:

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

Lägg till de yttre huvuden som NAT-passage kräver

Utanför ESP-höljet sitter ett yttre IPv4-huvud på 20 byte och ett UDP-huvud på 8 byte för NAT-passage, så paketet blir 132 byte. UDP-inkapslingen finns eftersom paketet måste överleva en översättande enhet mellan parterna, och den ändrar den yttre formen utan att röra den skyddade nyttolasten. Vid 33.3 paket per sekund är 132 byte ungefär 35.2 kbit/s, eller runt fyra gånger codec:ens nominella hastighet.

Varken taggen eller IV:n kan tas bort från uppskattningen för att göra den mindre, eftersom båda är en del av det länken faktiskt kommer att bära. En uppskattning som utelämnar dem beskriver ett paket som mottagaren skulle avvisa. Detsamma gäller trailern, som finns för att markera nyttolastens gräns och nästa huvud inne i det skyddade området.

Namnge gränsen innan du citerar talet

Ett yttre IP-tal utesluter fortfarande Ethernet-inramning. En taggad eller otaggad åtkomstlänk lägger till ett MAC-huvud på 14 byte och en ramkontrollsekvens på 4 byte, vilket gör ramen 150 byte, och det är storleken en switchport räknar. Vid samma paketfrekvens är det 40 kbit/s, fem gånger codec-hastigheten, och skillnaden är inte slöseri utan priset för transport.

Talet 40 kbit/s utesluter fortfarande preambeln, mellanrummet mellan ramar, VLAN-taggar, leverantörens inkapsling, RTCP, signalering och ljudet som går åt andra hållet. Det är en uppskattning per riktning, inte en länkreservation, och att citera den som en överdriver vad länken måste reservera på ett ställe medan den underskattar det på ett annat. En inspelning på värden kan också missa inramning som länken lägger till, därför måste gränsen namnges tillsammans med talet, och därför är en gränstabell mer användbar än ett enda huvudtal. Reservera separat för den riktning du inte räknade.

Kontrollera aritmetiken mot gränssnittet

Innan du litar på uppskattningen, jämför den med vad gränssnittet rapporterar för ett känt antal paket. Gör inspelningen på det fysiska gränssnittet och inte på tunnelenheten, så att inramningen du försöker räkna med ingår, och förvänta dig en liten avvikelse i stället för en perfekt träff.

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

Inspelningen bekräftar den yttre paketstorleken, medan gränssnittets räknare visar hastigheten inklusive inramning. Om de två avviker med ungefär Ethernet-tillägget är aritmetiken rätt och bara gränsen var felaktigt namngiven. En avvikelse långt större än ett ramhuvud pekar på något annat på länken, som omsändningar eller en annan ström som delar gränssnittet. Skriv paketeringsintervallet, skyddssviten och gränsen bredvid talet, eftersom en uppskattning utan de tre citeras som en mätning av nästa läsare.