IPsec-gjennomstrømning lavere enn forventet? Sjekk den aktive SA-en først
En lang transformliste er ikke sesjonen som beskytter overføringen din. Registrer den forhandlede SA-en, nyttelaststørrelsen og hastigheten som faktisk leveres, før du gir krypteringen skylden.
Konfigurasjonen tilbyr åtte transforms, noen leser den sterkeste, og gjennomstrømningstallet blir festet til den. Tunnelen valgte trolig ikke den transformen, og den kjørte heller ikke arbeidsmengden noen hadde sett for seg. Det som ble forhandlet, er én oppføring fra den listen, med én pakkestørrelse, i én retning, på én build. Mål det, og diskusjonen om algoritmer slutter som regel før den begynner.
Symptomet: et tall under det konfigurasjonen lover
En lang transformliste beskriver muligheter, og hver mulighet vurderes på papiret i stedet for på denne maskinvaren. Det forhandlede resultatet er én kombinasjon som begge partene godtok, og den kan være den svakeste som en av sidene fortsatt tillater av kompatibilitetshensyn. Hva den kombinasjonen presterer, avhenger av offload-tilstand, pakkestørrelse og køoppførsel, så to enheter med en identisk policyfil kan havne svært langt fra hverandre. Listen er en meny; assosiasjonen er bestillingen som kom tilbake.
Å lese listen forteller hva som kunne ha blitt valgt. Å lese assosiasjonen forteller hva som faktisk bærer overføringen, og det er det eneste et gjennomstrømningstall beskriver. Hvert tuningsteg som starter ved listen, er en gjetning med ekstra papirarbeid.
Registrer assosiasjonen som bærer denne overføringen
På en ASA show crypto ipsec sa listes de aktive assosiasjonene med sine transforms og tellere per retning, og kommandoreferansen fra Cisco dokumenterer denne utdataen. Velg peeren og retningen som betyr noe, og merk at en rekey erstatter assosiasjonen og nullstiller tellerne, noe som stille ugyldiggjør en baseline du fortsatt stolte på. Lagre utdataen ved siden av testnotatene, slik at neste kjøring har noe å sammenligne. En assosiasjons-ID som driver mellom kjøringer, gjør enhver senere sammenligning 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 er nok til å gjøre en måling reproduserbar, og hver av dem utelukker en bestemt forklaring når den mangler. Ingen av dem er en oppføring fra forslagslisten, for listen kan ikke si hva som beskytter bytene dine akkurat nå. Fyll ut tabellen én gang, og neste hendelse starter med data i stedet for en ny diskusjon om algoritmer.
Raden om access-link er den folk hopper over, og den er den som oftest forklarer et gap som ser kryptografisk ut. En mettet underlay eller en policer langs stien gir samme symptomform som en treg motor.
Mål én retning med en kontrollert last
Kjør testen fra et LAN-endepunkt som representerer applikasjonen i stedet for fra gatewayen selv, fordi en gateway-generert probe kan følge en annen lokal policy. Mål én retning før du legger til en andre strøm, og registrer både hastigheten som tilbys, og det mottakeren faktisk mottok. En hastighetsbegrenset UDP-kjøring skiller den tilbudte lasten fra TCPs overbelastningsrespons, mens en ubegrenset UDP-avsender ikke er en nøytral diagnose. Logg også nyttelastlengden, fordi et større datagram endrer både pakkehastigheten og innkapslingens overhead.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30Kjør den samme testen to ganger med samme nyttelastlengde og varighet, fordi én kjøring ikke kan skille et tak fra et dårlig minutt. Hvis mottakeren rapporterer færre pakker enn avsenderen sendte, er tapet ditt funn, og krypteringsmotoren er bare én av flere kandidater til det.
Forklar gapet før du justerer noe
Kontroller videresendingspolicy, kødropp, grensesnittfeil og ressursgrenser sammen med krypteringsbanen, fordi et hastighetsunderskudd alene aldri identifiserer en CPU. Hold også regnskapslagene eksplisitte: ytre tunnelbytes omfatter innkapsling, og retransmisjoner flytter forholdet mellom indre og ytre tellere. Å sammenligne urelaterte tellere byte for byte lager en avvikelse som aldri fantes.
Pakkestørrelsen fortjener en egen kontrollert sammenligning i stedet for et tall kopiert fra et gammelt eksempel. TCP MSS justerer TCP og har ingen effekt på vilkårlige UDP-datagrammer, så en fast 1350 hentet fra et eldre dokument måler absolutt ingenting. Endre nyttelastlengden med vilje og se hva mottakeren rapporterer.
Endre én variabel og behold arbeidsmengden
Når baselinen gjentar seg innenfor et smalt bånd, endrer du én støttet variabel og kjører den opprinnelige applikasjonsoppgaven på nytt. Det steget er det som gjør et tall til en årsak, og det er det eneste som rettferdiggjør å røre konfigurasjonen. Gjenta den samme arbeidsmengden i stedet for en vennligere.
Ikke fjern forslag, svekk autentiseringen eller slå av beskyttelsen for å gjøre et syntetisk tall større. De grepene endrer sikkerhetsstillingen og måler deretter resultatet av den endringen, ikke tunnelens kapasitet.