IPsec-genomströmning lägre än väntat? Kontrollera den aktiva SA först
En lång transformlista är inte den session som skyddar din överföring. Registrera den förhandlade SA:n, nyttolaststorleken och den levererade hastigheten innan du skyller på krypteringen.
Konfigurationen erbjuder åtta transforms, någon läser den starkaste, och genomströmningstalet knyts till den. Tunneln valde förmodligen inte den transformen, och den körde inte heller den arbetsbelastning som någon föreställde sig. Det som förhandlades fram är en post från listan, med en paketstorlek, i en riktning, på en build. Mät det, och diskussionen om algoritmer tar oftast slut innan den börjat.
Symtomet: en siffra under det som konfigurationen lovar
En lång transformlista beskriver möjligheter, och varje möjlighet bedöms på papperet i stället för på den här hårdvaran. Det förhandlade resultatet är en enda kombination som båda parterna accepterade, och den kan vara den svagaste som endera sidan fortfarande tillåter av kompatibilitetsskäl. Vad den kombinationen presterar beror på offload-tillstånd, paketstorlek och köbeteende, så två enheter med en identisk policyfil kan hamna mycket långt ifrån varandra. Listan är en meny; associationen är den beställning som kom tillbaka.
Att läsa listan säger vad som kunde ha valts. Att läsa associationen säger vad som faktiskt bär överföringen, och det är det enda ett genomströmningstal beskriver. Varje justeringssteg som börjar vid listan är en gissning med extra pappersarbete.
Registrera associationen som bär den här överföringen
På en ASA show crypto ipsec sa listar de aktiva associationerna med sina transforms och räknare per riktning, och kommandoreferensen från Cisco dokumenterar den utdata. Välj den peer och den riktning som spelar roll, och notera att en rekey ersätter associationen och nollställer dess räknare, vilket tyst ogiltiggör en baslinje du fortfarande litade på. Spara utdata bredvid testanteckningarna så att nästa körning har något att jämföra. Ett associations-id som driver mellan körningar gör varje senare jämförelse meningslös.
| 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" |
Fem rader räcker för att göra en mätning reproducerbar, och varje rad utesluter en specifik förklaring när den saknas. Ingen av dem är en post från förslagslistan, eftersom listan inte kan säga vad som skyddar dina byte just nu. Fyll i tabellen en gång, och nästa incident börjar med data i stället för med en ny diskussion om algoritmer.
Raden om access-länken är den folk hoppar över, och den är den som oftast förklarar en klyfta som ser kryptografisk ut. En mättad underlay eller en policer längs vägen ger samma symtomform som en långsam motor.
Mät en riktning med en kontrollerad belastning
Kör testet från en LAN-endpunkt som representerar applikationen i stället för från gatewayen själv, eftersom en gateway-genererad probe kan följa en annan lokal policy. Mät en riktning innan du lägger till en andra ström, och registrera både den erbjudna hastigheten och vad mottagaren faktiskt tog emot. En hastighetsbegränsad UDP-körning skiljer den erbjudna belastningen från TCP:s trängselrespons, medan en obegränsad UDP-avsändare inte är en neutral diagnos. Logga också nyttolastlängden, eftersom ett större datagram ändrar både paketfrekvensen och inkapslingens overhead.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30Kör samma test två gånger med samma nyttolastlängd och varaktighet, eftersom en enda körning inte kan skilja ett tak från en dålig minut. Om mottagaren rapporterar färre paket än avsändaren skickade, är förlusten ditt fynd, och krypteringsmotorn är bara en av flera kandidater till den.
Förklara klyftan innan du justerar något
Kontrollera vidarebefordringspolicy, ködrops, gränssnittsfel och resursgränser tillsammans med krypteringsvägen, eftersom ett hastighetsunderskott i sig aldrig identifierar en CPU. Håll också redovisningslagren explicita: yttre tunnelbytes omfattar inkapsling, och omsändningar flyttar förhållandet mellan inre och yttre räknare. Att jämföra orelaterade räknare byte för byte skapar en avvikelse som aldrig fanns.
Paketstorleken förtjänar en egen kontrollerad jämförelse i stället för en siffra kopierad från ett gammalt exempel. TCP MSS justerar TCP och har ingen effekt på godtyckliga UDP-datagram, så ett fast 1350 hämtat från ett äldre dokument mäter ingenting alls. Ändra nyttolastlängden med avsikt och se vad mottagaren rapporterar.
Ändra en variabel och behåll arbetsbelastningen
När baslinjen upprepas inom ett smalt band ändrar du en variabel som stöds och kör om den ursprungliga applikationsuppgiften. Det steget är det som gör en siffra till en orsak, och det är det enda som motiverar att röra konfigurationen. Upprepa samma arbetsbelastning i stället för en vänligare.
Ta inte bort förslag, försvaga inte autentiseringen och stäng inte av skyddet för att göra en syntetisk siffra större. De greppen ändrar säkerhetsläget och mäter sedan resultatet av den ändringen, inte tunnelns kapacitet.