IPsec-gjennomstrøyming lågare enn venta? Sjekk den aktive SA-en først
Ei lang transformliste er ikkje økta som vernar overføringa di. Registrer den forhandla SA-en, nyttelaststorleiken og hastigheita som faktisk vart levert, før du gjev krypteringa skulda.
Konfigurasjonen tilbyr åtte transformar, nokon les den sterkaste, og gjennomstrøymingstalet vert knytt til han. Tunnelen valde truleg ikkje den transformen, og han køyrde heller ikkje arbeidsmengda nokon såg føre seg. Det som vart forhandla, er éin oppføring frå den lista, med éin pakkestorleik, i éi retning, på éin build. Mål det, og diskusjonen om algoritmar sluttar som regel før han byrjar.
Symptomet: eit tal under det konfigurasjonen lovar
Ei lang transformliste skildrar mogleikar, og kvar mogleik vert vurdert på papiret i staden for på denne maskinvara. Det forhandla resultatet er éin kombinasjon som begge sider godtok, og han kan vere den svakaste som kvar side framleis tillèt av omsyn til kompatibilitet. Kva den kombinasjonen presterer, kjem an på offload-tilstand, pakkestorleik og køåtfærd, så to einingar med ein identisk politikkfil kan hamne svært langt frå kvarandre. Lista er ei meny; assosiasjonen er bestillinga som kom tilbake.
Å lese lista fortel kva som kunne ha vorte valt. Å lese assosiasjonen fortel kva som faktisk ber overføringa, og det er det einaste eit gjennomstrøymingstal skildrar. Kvart tuningsteg som startar ved lista, er ei gissing med ekstra papirarbeid.
Registrer assosiasjonen som ber denne overføringa
På ein ASA show crypto ipsec sa listar dei aktive assosiasjonane med transformane sine og teljarar per retning, og kommandoreferansen frå Cisco dokumenterer denne utdata. Vel peeren og retninga som betyr noko, og merk at ein rekey erstattar assosiasjonen og nullstiller teljarane hans, noko som stilt gjer ein basislinje du framleis stolte på, ugyldig. Lagre utdata ved sida av testnotata, slik at neste køyring har noko å samanlikne. Ein assosiasjons-ID som driv mellom køyringar, gjer kvar seinare samanlikning meiningslaus.
| 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 radar er nok til å gjere ei måling reproduserbar, og kvar rad utelukkar ei bestemd forklaring når ho manglar. Ingen av dei er ei oppføring frå forslagslista, for lista kan ikkje seie kva som vernar byta dine akkurat no. Fyll ut tabellen éin gong, og neste hending startar med data i staden for ein ny diskusjon om algoritmar.
Rada om access-link er den folk hoppar over, og det er henne som oftast forklarar eit gap som ser kryptografisk ut. Ein metta underlay eller ein policer langs vegen gjev same symptomet som ein treg motor.
Mål éi retning med ein kontrollert last
Køyr testen frå eit LAN-endepunkt som representerer applikasjonen i staden for frå gatewayen sjølv, fordi ein gateway-generert probe kan fylgje ein annan lokal politikk. Mål éi retning før du legg til ein andre straum, og registrer både hastigheita som vert tilboden og det mottakaren faktisk fekk. Ei hastigheitsavgrensa UDP-køyring skil den tilbydde lasta frå TCP sin kørespons, medan ein ubegrensa UDP-sendar ikkje er ein nøytral diagnose. Logg òg nyttelastlengda, fordi eit større datagram endrar både pakkehastigheit og innkapslingskostnad.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30
Køyr den same testen to gonger med same nyttelastlengd og varigheit, fordi éi køyring ikkje kan skilje eit tak frå eit dårleg minutt. Viss mottakaren rapporterer færre pakkar enn sendaren sende, er tapet funnet ditt, og krypteringsmotoren er berre éin av fleire kandidatar.
Forklar gapet før du justerer noko
Kontroller videresendingspolitikk, kødropp, grensesnittfeil og ressursgrenser saman med krypteringsvegen, fordi eit hastigheitsunderskot åleine aldri identifiserer ein CPU. Hald òg rekneskapslaga eksplisitte: ytre tunnelbytar omfattar innkapsling, og retransmisjonar flyttar høvet mellom indre og ytre teljarar. Å samanlikne urelaterte teljarar byte for byte lagar ein skilnad som aldri fanst.
Pakkestorleiken fortener si eiga kontrollerte samanlikning i staden for eit tal kopiert frå eit gammalt døme. TCP MSS justerer TCP og har ingen verknad på vilkårlege UDP-datagram, så ein fast 1350 henta frå eit eldre dokument måler absolutt ingenting. Endre nyttelastlengda med vilje og sjå kva mottakaren rapporterer.
Endre éin variabel og hald på arbeidsmengda
Når basislinja gjentek seg innanfor eit smalt band, endrar du éin støtta variabel og køyrer den opphavlege applikasjonsoppgåva på nytt. Det steget er det som gjer eit tal til ei årsak, og det er det einaste som rettferdiggjer å røre konfigurasjonen. Gjenta den same arbeidsmengda i staden for ei venlegare.
Ikkje fjern forslag, svekk autentiseringa eller slå av vernet for å gjere eit syntetisk tal større. Dei grepa endrar tryggleikshaldninga og måler deretter resultatet av den endringa, ikkje kapasiteten til tunnelen.