La voce su IPsec viene citata come bitrate del codec, e quella cifra è sbagliata a ogni confine tranne quello del codec stesso. L'audio è 8 kbit/s, il pacchetto che lo trasporta è più grande, l'involucro ESP lo è ancora di più, e la trama Ethernet aggiunge un incapsulamento che nessuna cattura sul tunnel mostra. Contare un pacchetto a partire da un formato dichiarato è l'unico modo per sapere cosa il collegamento fisico deve davvero trasportare. Il percorso qui sotto lo fa solo per una direzione, e ogni numero è aritmetica, non misura.

Parti da una scelta di impacchettamento, non da una cifra di codec

Una tabella di codec dà il bitrate del carico utile e nulla più: G.729 emette 8 kbit/s, cioè 30 byte di audio ogni 30 ms. Non dice nulla su intestazioni, protezione o incapsulamento, e sono proprio queste tre a dominare il risultato. L'intervallo è una scelta di politica su cui entrambe le estremità devono concordare, quindi scegliilo per primo e dichiaralo, perché ogni numero successivo dipende da quella sola decisione.

Questo esempio usa 30 ms, quindi la frequenza dei pacchetti è 33.3 al secondo. Assume un'intestazione RTP di 12 byte, un'intestazione UDP di 8 byte e un'intestazione IPv4 interna di 20 byte senza opzioni, e nessun SRTP, compressione delle intestazioni o riempimento di riservatezza del flusso di traffico; qualsiasi modifica sposta anche il budget, per questo le ipotesi stanno accanto alla risposta.

Aggiungi le intestazioni interne, poi l'involucro ESP

L'applicazione invia carico utile più RTP più UDP più IP, che con questo impacchettamento sono 70 byte. Quel flusso interno arriva a 18.7 kbit/s, già più del doppio del bitrate del codec, perché sono le intestazioni, non l'audio, a occupare la maggior parte del pacchetto. Nessuno di quei byte è voce; sono il prezzo dell'indirizzamento e della sequenziazione. Una cattura presa sopra il tunnel mostra esattamente questo numero, ed è quello che la gente cita quando dice che la chiamata è piccola.

È anche il numero che non arriva mai al cavo. La modalità tunnel ESP aggiunge uno SPI e un numero di sequenza di 8 byte, un IV esplicito di 8 byte per AES-GCM, una coda di 2 byte e un'etichetta di autenticazione di 16 byte. Il carico utile di 70 byte più la coda arriva a 72, che soddisfa già l'allineamento su quattro byte, quindi qui non serve riempimento aggiuntivo.RFC 4106 fissa le dimensioni dell'IV e dell'etichetta GCM, ed entrambe appartengono all'aritmetica, non a una nota a piè di pagina:

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

Aggiungi le intestazioni esterne richieste dal passaggio NAT

Fuori dall'involucro ESP ci sono un'intestazione IPv4 esterna di 20 byte e un'intestazione UDP di 8 byte per il passaggio NAT, così il pacchetto diventa 132 byte. L'incapsulamento UDP esiste perché il pacchetto deve sopravvivere a un dispositivo di traduzione tra i pari, e cambia la forma esterna senza toccare il carico protetto. A 33.3 pacchetti al secondo, 132 byte sono circa 35.2 kbit/s, cioè all'incirca quattro volte il bitrate nominale del codec.

Né l'etichetta né l'IV possono essere tolti dalla stima per renderla più piccola, perché entrambi fanno parte di ciò che il collegamento trasporterà davvero. Una stima che li omette descrive un pacchetto che il ricevente rifiuterebbe. Lo stesso vale per la coda, che esiste per marcare il confine del carico e l'intestazione successiva dentro la regione protetta.

Nomina il confine prima di citare il numero

Una cifra di IP esterno esclude ancora l'incapsulamento Ethernet. Un collegamento di accesso con o senza tag aggiunge un'intestazione MAC di 14 byte e una sequenza di controllo trama di 4 byte, portando la trama a 150 byte, che è la dimensione contata da una porta di switch. Allo stesso ritmo di pacchetti sono 40 kbit/s, cinque volte il bitrate del codec, e la differenza non è spreco ma il costo del trasporto.

BoundaryPacket sizeRate at 33.3 packets/sWhat it counts
Codec payload30 bytes8.0 kbit/sThe audio alone
Inner IP packet70 bytes18.7 kbit/sApplication headers included
Outer IP packet132 bytes35.2 kbit/sESP and NAT-T included
Ethernet frame150 bytes40.0 kbit/sLink framing included

La cifra di 40 kbit/s esclude ancora il preambolo, lo spazio tra trame, i tag VLAN, l'incapsulamento del fornitore, RTCP, la segnalazione e l'audio che viaggia nell'altra direzione. È una stima per direzione, non una prenotazione di collegamento, e citarla come tale esagera ciò che il collegamento deve riservare in un punto mentre lo sottostima in un altro. Una cattura sull'host può anche mancare l'incapsulamento che il collegamento aggiunge, per questo il confine va nominato accanto al numero, e per questo una tabella dei confini è più utile di un solo numero di titolo. Riserva separatamente per la direzione che non hai contato.

Verifica l'aritmetica contro l'interfaccia

Prima di fidarti della stima, confrontala con ciò che l'interfaccia riporta per un numero noto di pacchetti. Cattura sull'interfaccia fisica e non sul dispositivo del tunnel, così che l'incapsulamento che stai cercando di contabilizzare sia incluso, e aspettati un piccolo scarto invece di una corrispondenza perfetta.

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

La cattura conferma la dimensione del pacchetto esterno, mentre i contatori dell'interfaccia mostrano il tasso incapsulamento compreso. Se i due differiscono di circa la tolleranza Ethernet, l'aritmetica è corretta e solo il confine era etichettato male. Una differenza molto maggiore di un'intestazione di trama indica qualcos'altro sul collegamento, come ritrasmissioni o un altro flusso che condivide l'interfaccia. Scrivi l'intervallo di impacchettamento, la suite di protezione e il confine accanto al numero, perché una stima senza quei tre viene citata come misura dalla persona successiva che la legge.

Articoli correlati