Ein G.729-Paket durch einen IPsec-Tunnel zählen

Sprache über IPsec wird als Codec-Bitrate angegeben, und diese Zahl ist an jeder Grenze falsch außer an der des Codecs selbst. Das Audio sind 8 kbit/s, das Paket, das es trägt, ist größer, der ESP-Mantel noch größer, und der Ethernet-Rahmen fügt eine Rahmung hinzu, die ein Mitschnitt am Tunnel nie zeigt. Ein Paket aus einem angegebenen Format zu zählen ist der einzige Weg zu erfahren, was die physische Strecke tatsächlich tragen muss. Die folgende Rechnung tut das nur für eine Richtung, und jede Zahl hier ist Arithmetik, keine Messung.

Beginne mit einer Paketierungsentscheidung, nicht mit einer Codec-Zahl

Eine Codec-Tabelle nennt die Nutzlastrate und sonst nichts: G.729 liefert 8 kbit/s, also 30 Byte Audio alle 30 ms. Sie sagt nichts über Header, Schutz oder Rahmung, und diese drei bestimmen das Ergebnis. Das Intervall ist eine Richtlinienentscheidung, auf die sich beide Seiten einigen müssen, also wähle es zuerst und nenne es, denn jede spätere Zahl hängt von dieser einen Entscheidung ab.

Dieses Beispiel verwendet 30 ms, also beträgt die Paketrate 33.3 pro Sekunde. Es nimmt einen 12-Byte-RTP-Header, einen 8-Byte-UDP-Header und einen inneren IPv4-Header von 20 Byte ohne Optionen an, dazu kein SRTP, keine Header-Kompression und keine Auffüllung für Verkehrsfluss-Vertraulichkeit; jede Änderung verschiebt das Budget mit, deshalb gehören die Annahmen neben die Antwort.

Füge die inneren Header hinzu, dann den ESP-Mantel

Die Anwendung sendet Nutzlast plus RTP plus UDP plus IP, was bei dieser Paketierung 70 Byte sind. Dieser innere Strom ergibt 18.7 kbit/s, schon mehr als das Doppelte der Codec-Rate, weil Header und nicht Audio den größten Teil des Pakets ausmachen. Keines dieser Bytes ist Stimme; sie sind der Preis für Adressierung und Sequenzierung. Ein Mitschnitt oberhalb des Tunnels zeigt genau diese Zahl, und sie ist es, die Leute zitieren, wenn sie sagen, der Anruf sei klein.

Es ist auch die Zahl, die nie auf die Leitung gelangt. Der ESP-Tunnelmodus fügt einen 8-Byte-SPI samt Sequenznummer, einen 8-Byte-expliziten IV für AES-GCM, einen 2-Byte-Trailer und ein 16-Byte-Authentifizierungs-Tag hinzu. Die 70 Byte Nutzlast plus Trailer ergeben 72, was die Ausrichtung auf vier Byte bereits erfüllt, also ist hier keine zusätzliche Auffüllung nötig.RFC 4106 legt die Größen von GCM-IV und Tag fest, und beide gehören in die Arithmetik statt in eine Fußnote:

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

Füge die äußeren Header hinzu, die NAT-Traversal verlangt

Außerhalb des ESP-Mantels sitzen ein äußerer IPv4-Header von 20 Byte und ein UDP-Header von 8 Byte für NAT-Traversal, sodass das Paket 132 Byte wird. Die UDP-Kapselung existiert, weil das Paket ein übersetzendes Gerät zwischen den Partnern überstehen muss, und sie ändert die äußere Form, ohne die geschützte Nutzlast zu berühren. Bei 33.3 Paketen pro Sekunde sind 132 Byte etwa 35.2 kbit/s, also rund das Vierfache der nominellen Codec-Rate.

Weder Tag noch IV können aus der Schätzung gestrichen werden, um sie kleiner zu machen, denn beide gehören zu dem, was die Strecke tatsächlich trägt. Eine Schätzung, die sie auslässt, beschreibt ein Paket, das der Empfänger verwerfen würde. Dasselbe gilt für den Trailer, der die Nutzlastgrenze und den nächsten Header innerhalb des geschützten Bereichs markiert.

Benenne die Grenze, bevor du die Zahl zitierst

Eine äußere IP-Zahl schließt die Ethernet-Rahmung noch aus. Eine getaggte oder ungetaggte Zugangsstrecke fügt einen 14-Byte-MAC-Header und eine 4-Byte-Rahmenprüfsequenz hinzu, wodurch der Rahmen 150 Byte groß wird, die Größe, die ein Switch-Port zählt. Bei gleicher Paketrate sind das 40 kbit/s, das Fünffache der Codec-Rate, und der Unterschied ist kein Verschwenden, sondern der Preis des Transports.

Die Zahl 40 kbit/s schließt weiterhin die Präambel, die Zwischenrahmenlücke, VLAN-Tags, Provider-Kapselung, RTCP, Signalisierung und das Audio in der Gegenrichtung aus. Es ist eine Schätzung pro Richtung, keine Streckenreservierung, und sie als solche zu zitieren überzeichnet, was die Strecke an einer Stelle reservieren muss, und untertreibt es an einer anderen. Ein Mitschnitt auf dem Host kann auch Rahmung verpassen, die die Strecke hinzufügt, deshalb muss die Grenze zusammen mit der Zahl genannt werden, und deshalb ist eine Grenztabelle nützlicher als eine einzelne Schlagzeile. Reserviere getrennt für die Richtung, die du nicht gezählt hast.

Prüfe die Arithmetik gegen das Interface

Bevor du der Schätzung traust, vergleiche sie damit, was das Interface für eine bekannte Paketanzahl meldet. Schneide am physischen Interface mit, nicht am Tunnelgerät, damit die Rahmung enthalten ist, die du abrechnen willst, und erwarte eine kleine Abweichung statt einer perfekten Übereinstimmung.

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

Der Mitschnitt bestätigt die äußere Paketgröße, während die Interface-Zähler die Rate einschließlich Rahmung zeigen. Weichen beide um etwa den Ethernet-Zuschlag ab, stimmt die Arithmetik und nur die Grenze war falsch benannt. Eine Abweichung weit größer als ein Rahmen-Header deutet auf etwas anderes auf der Strecke hin, etwa auf Wiederholungen oder einen anderen Fluss, der sich das Interface teilt. Schreibe das Paketierungsintervall, die Schutzsuite und die Grenze neben die Zahl, denn eine Schätzung ohne diese drei wird vom nächsten Leser als Messung zitiert.