IPsec-doorvoer lager dan verwacht? Controleer eerst de actieve SA
Een lange transformatielijst is niet de sessie die uw overdracht beschermt. Leg de onderhandelde SA, de payloadgrootte en de werkelijk geleverde snelheid vast voordat u de versleuteling de schuld geeft.
De configuratie biedt acht transforms, iemand leest de sterkste, en het doorvoercijfer wordt daaraan toegeschreven. De tunnel heeft die transform waarschijnlijk niet gekozen, en hij heeft ook niet de werkbelasting gedraaid die iemand zich voorstelde. Wat is onderhandeld, is één vermelding uit die lijst, met één pakketgrootte, in één richting, op één build. Meet dat en de discussie over algoritmen eindigt meestal voordat zij begint.
Het symptoom: een cijfer onder wat de configuratie belooft
Een lange transformatielijst beschrijft mogelijkheden, en elke mogelijkheid wordt op papier beoordeeld in plaats van op deze hardware. Het onderhandelde resultaat is één combinatie die beide peers hebben geaccepteerd, en het kan de zwakste zijn die een van beide partijen nog toestaat voor compatibiliteit. Wat die combinatie presteert, hangt af van offload-status, pakketgrootte en wachtrijgedrag, zodat twee apparaten met een identiek policybestand ver uit elkaar kunnen liggen. De lijst is een menukaart; de associatie is de bestelling die terugkwam.
De lijst lezen vertelt u wat er gekozen had kunnen zijn. De associatie lezen vertelt u wat de overdracht werkelijk draagt, en dat is het enige wat een doorvoercijfer beschrijft. Elke afstelstap die bij de lijst begint, is een gok met extra papierwerk.
Leg de associatie vast die deze overdracht draagt
Op een ASA show crypto ipsec sa worden de actieve associaties opgesomd met hun transforms en tellers per richting, en de commandoreferentie van Cisco documenteert die uitvoer. Kies de peer en de richting die ertoe doen, en bedenk dat een rekey de associatie vervangt en de tellers reset, wat stilletjes een basislijn ongeldig maakt waarop u nog vertrouwde. Bewaar de uitvoer naast de testnotities zodat de volgende run iets heeft om te vergelijken. Een associatie-identificatie die tussen runs verschuift, maakt elke latere vergelijking zinloos.
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
Vijf rijen zijn genoeg om een meting reproduceerbaar te maken, en elke rij sluit een specifieke verklaring uit wanneer zij ontbreekt. Geen enkele is een vermelding uit de voorstellenlijst, want de lijst kan niet zeggen wat uw bytes op dit moment beschermt. Vul de tabel één keer in en het volgende incident begint met gegevens in plaats van met een nieuw debat over algoritmen.
De rij van de access-link is degene die mensen overslaan, en zij is degene die het vaakst een kloof verklaart die cryptografisch lijkt. Een verzadigde underlay of een policer langs het pad levert dezelfde symptoomvorm op als een trage engine.
Meet één richting met een gecontroleerde belasting
Voer de test uit vanaf een LAN-eindpunt dat de toepassing vertegenwoordigt in plaats van vanaf de gateway zelf, omdat een door de gateway gegenereerde probe een ander lokaal beleid kan volgen. Meet één richting voordat u een tweede stream toevoegt, en leg zowel de aangeboden snelheid vast als wat de ontvanger werkelijk heeft ontvangen. Een snelheidsbegrensde UDP-run scheidt de aangeboden belasting van de congestierespons van TCP, terwijl een onbeperkte UDP-verzender geen neutrale diagnose is. Noteer ook de payloadlengte, want een groter datagram verandert zowel de pakketsnelheid als de encapsulatie-overhead.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30Draai dezelfde test twee keer met dezelfde payloadlengte en duur, want één run kan een plafond niet scheiden van een slechte minuut. Als de ontvanger minder pakketten meldt dan de verzender heeft uitgezonden, is het verlies uw bevinding, en de crypto-engine is slechts één van meerdere kandidaten daarvoor.
Verklaar de kloof voordat u iets afstelt
Controleer het doorstuurbeleid, wachtrijdrops, interfacefouten en resource-limieten samen met het versleutelingspad, want een snelheidstekort alleen identificeert nooit een CPU. Houd ook de boekhoudlagen expliciet: bytes van de buitenste tunnel bevatten encapsulatie, en hertransmissies verschuiven de verhouding tussen binnenste en buitenste tellers. Het byte voor byte vergelijken van ongerelateerde tellers produceert een discrepantie die er nooit was.
De pakketgrootte verdient een eigen gecontroleerde vergelijking in plaats van een getal dat uit een oud voorbeeld is gekopieerd. TCP MSS past TCP aan en heeft geen effect op willekeurige UDP-datagrammen, dus een vaste 1350 uit een verouderd document meet helemaal niets. Wijzig de payloadlengte met opzet en kijk wat de ontvanger meldt.
Wijzig één variabele en behoud de werkbelasting
Zodra de basislijn zich binnen een smalle band herhaalt, wijzigt u één ondersteunde variabele en voert u de oorspronkelijke toepassingstaak opnieuw uit. Die stap maakt van een cijfer een oorzaak, en is de enige die het aanpassen van de configuratie rechtvaardigt. Herhaal dezelfde werkbelasting in plaats van een vriendelijkere.
Trek geen voorstellen in, verzwak de authenticatie niet en schakel de bescherming niet uit om een synthetisch cijfer groter te maken. Die ingrepen veranderen de beveiligingshouding en meten vervolgens het resultaat van die verandering, niet de capaciteit van de tunnel.