Die Konfiguration bietet acht Transforms, jemand liest die stärkste davon, und der Durchsatzwert wird ihr dann zugeschrieben. Der Tunnel hat diese Transform wahrscheinlich gar nicht gewählt, und er hat auch nicht die Arbeitslast ausgeführt, die sich irgendjemand vorgestellt hat. Was ausgehandelt wurde, ist ein einziger Eintrag aus dieser Liste, mit einer Paketgröße, in einer Richtung, auf einem Build. Messen Sie das, und die Diskussion über Algorithmen endet meist, bevor sie begonnen hat.

Das Symptom: eine Zahl unter dem, was die Konfiguration verspricht

Eine lange Transform-Liste beschreibt Möglichkeiten, und jede Möglichkeit wird auf dem Papier bewertet statt auf dieser Hardware. Das ausgehandelte Ergebnis ist eine einzige Kombination, die beide Peers akzeptiert haben, und es kann die schwächste sein, die eine der Seiten aus Kompatibilitätsgründen noch zulässt. Was diese Kombination leistet, hängt von Offload-Status, Paketgröße und Queue-Verhalten ab, sodass zwei Geräte mit identischer Policy-Datei weit auseinanderliegen können. Die Liste ist eine Speisekarte; die Assoziation ist die Bestellung, die zurückkam.

Das Lesen der Liste sagt Ihnen, was hätte gewählt werden können. Das Lesen der Assoziation sagt Ihnen, was den Transfer tatsächlich trägt, und nur das beschreibt ein Durchsatzwert. Jeder Tuning-Schritt, der bei der Liste beginnt, ist eine Vermutung mit zusätzlichem Papierkram.

Erfassen Sie die Assoziation, die diesen Transfer trägt

Auf einer ASA show crypto ipsec sa listet die aktiven Assoziationen mit ihren Transforms und Zählern je Richtung auf, und die Befehlsreferenz von Cisco dokumentiert diese Ausgabe. Wählen Sie den Peer und die Richtung, die zählen, und beachten Sie, dass ein Rekey die Assoziation ersetzt und ihre Zähler zurücksetzt, was eine Baseline, auf die Sie sich noch verlassen haben, still ungültig macht. Speichern Sie die Ausgabe neben den Testnotizen, damit der nächste Lauf etwas zum Vergleichen hat. Eine Assoziationskennung, die zwischen Läufen driftet, macht jeden späteren Vergleich bedeutungslos.

What to recordWhere to read itWhat it rules out
Negotiated transform and SA identifiersshow crypto ipsec sa for that peer and direction"the configuration picked the wrong algorithm"
Offload or accelerator state for that buildplatform show commands and interface statistics"the crypto engine is the ceiling"
Payload size and offered ratethe test tool's own settings and summary"packets per second versus bytes per second"
Delivered rate and loss at the receiverthe receiving endpoint, not the sender's counters"the sender transmitted, so it arrived"
Access-link load and dropsunderlay interface counters along the path"the bottleneck lives inside the tunnel"

Fünf Zeilen genügen, um eine Messung reproduzierbar zu machen, und jede einzelne schließt eine bestimmte Erklärung aus, wenn sie fehlt. Keine davon ist ein Eintrag aus der Vorschlagsliste, denn die Liste kann nicht sagen, was Ihre Bytes gerade jetzt schützt. Füllen Sie die Tabelle einmal aus, und der nächste Vorfall beginnt mit Daten statt mit einer neuen Diskussion über Algorithmen.

Die Access-Link-Zeile ist die, die man überspringt, und sie ist diejenige, die am häufigsten eine Lücke erklärt, die kryptografisch aussieht. Ein gesättigtes Underlay oder ein Policer entlang des Pfads erzeugt dieselbe Symptomform wie eine langsame Engine.

Messen Sie eine Richtung mit kontrollierter Last

Fahren Sie den Test von einem LAN-Endpunkt aus, der die Anwendung repräsentiert, statt vom Gateway selbst, denn eine vom Gateway erzeugte Probe kann einer anderen lokalen Policy folgen. Messen Sie eine Richtung, bevor Sie einen zweiten Stream hinzufügen, und erfassen Sie sowohl die angebotene Rate als auch das, was der Empfänger tatsächlich erhalten hat. Ein ratenbegrenzter UDP-Lauf trennt die angebotene Last von der Stauantwort von TCP, während ein unbegrenzter UDP-Sender keine neutrale Diagnose ist. Protokollieren Sie auch die Nutzlastlänge, denn ein größeres Datagramm ändert sowohl die Paketrate als auch den Kapselungs-Overhead.

show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30

Führen Sie denselben Test zweimal mit derselben Nutzlastlänge und Dauer aus, denn ein einzelner Lauf kann eine Obergrenze nicht von einer schlechten Minute trennen. Wenn der Empfänger weniger Pakete meldet, als der Sender ausgegeben hat, ist der Verlust Ihr Befund, und die Crypto-Engine ist nur einer von mehreren Kandidaten dafür.

Erklären Sie die Lücke, bevor Sie irgendetwas tunen

Prüfen Sie Weiterleitungs-Policy, Queue-Drops, Interface-Fehler und Ressourcengrenzen zusammen mit dem Verschlüsselungspfad, denn ein Raten-Defizit allein identifiziert nie eine CPU. Halten Sie auch die Abrechnungsschichten explizit: Äußere Tunnel-Bytes enthalten die Kapselung, und Retransmissionen verschieben das Verhältnis zwischen inneren und äußeren Zählern. Der Byte-für-Byte-Vergleich nicht zusammengehöriger Zähler erzeugt eine Diskrepanz, die es nie gab.

Die Paketgröße verdient einen eigenen kontrollierten Vergleich statt einer aus einem alten Beispiel kopierten Zahl. TCP MSS passt TCP an und hat keine Wirkung auf beliebige UDP-Datagramme, sodass ein fester Wert von 1350 aus einem Alt-Dokument überhaupt nichts misst. Ändern Sie die Nutzlastlänge absichtlich und beobachten Sie, was der Empfänger meldet.

Ändern Sie eine Variable und behalten Sie die Arbeitslast

Sobald sich die Baseline in einem engen Band wiederholt, ändern Sie eine unterstützte Variable und führen Sie die ursprüngliche Anwendungsaufgabe erneut aus. Dieser Schritt macht aus einer Zahl eine Ursache, und nur er rechtfertigt einen Eingriff in die Konfiguration. Wiederholen Sie dieselbe Arbeitslast statt einer freundlicheren.

Legen Sie keine Vorschläge still, schwächen Sie die Authentifizierung nicht ab und schalten Sie den Schutz nicht ab, um eine synthetische Zahl größer zu machen. Diese Manöver verändern die Sicherheitslage und messen dann das Ergebnis dieser Veränderung, nicht die Kapazität des Tunnels.

Ähnliche Artikel