La configurazione offre otto trasformazioni, qualcuno legge la più forte e la cifra di throughput viene attribuita a quella. Probabilmente il tunnel non ha scelto quella trasformazione, e non ha nemmeno eseguito il carico di lavoro che qualcuno immaginava. Ciò che è stato negoziato è una voce di quell’elenco, con una dimensione di pacchetto, in una direzione, su una build. Misura questo e la discussione sugli algoritmi di solito finisce prima di iniziare.

Il sintomo: una cifra inferiore a quanto promette la configurazione

Un lungo elenco di trasformazioni descrive possibilità, e ogni possibilità viene valutata sulla carta invece che su questo hardware. Il risultato negoziato è una singola combinazione che entrambi i peer hanno accettato, e può essere la più debole che ciascuna parte permette ancora per compatibilità. Ciò che quella combinazione riesce a fare dipende dallo stato di offload, dalla dimensione dei pacchetti e dal comportamento delle code, quindi due dispositivi con un file di policy identico possono finire molto distanti. L’elenco è un menù; l’associazione è l’ordine che è tornato.

Leggere l’elenco ti dice cosa avrebbe potuto essere scelto. Leggere l’associazione ti dice cosa sta trasportando il trasferimento, e questa è l’unica cosa che una cifra di throughput descrive. Ogni passo di ottimizzazione che parte dall’elenco è un’ipotesi con documentazione extra.

Registra l’associazione che trasporta questo trasferimento

Su un ASA show crypto ipsec sa elenca le associazioni attive con le loro trasformazioni e i contatori per direzione, e la guida ai comandi di Cisco documenta quell’output. Scegli il peer e la direzione che contano, e nota che un rekey sostituisce l’associazione e azzera i suoi contatori, invalidando silenziosamente una baseline su cui contavi ancora. Conserva l’output accanto alle note del test, così l’esecuzione successiva ha qualcosa da confrontare. Un identificatore di associazione che cambia tra un’esecuzione e l’altra rende privo di senso ogni confronto successivo.

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"

Cinque righe bastano per rendere una misurazione riproducibile, e ciascuna esclude una spiegazione specifica quando manca. Nessuna è una voce dell’elenco delle proposte, perché l’elenco non può dire cosa sta proteggendo i tuoi byte in questo momento. Compila la tabella una volta e il prossimo incidente partirà dai dati invece che da una nuova discussione sugli algoritmi.

La riga del link di accesso è quella che tutti saltano, ed è quella che spiega più spesso un divario che sembra crittografico. Un underlay saturo o un policer lungo il percorso produce la stessa forma di sintomo di un motore lento.

Misura una sola direzione con un carico controllato

Esegui il test da un endpoint della LAN che rappresenti l’applicazione anziché dal gateway stesso, perché una sonda generata dal gateway può seguire una policy locale diversa. Misura una direzione prima di aggiungere un secondo flusso, e registra sia la velocità offerta sia ciò che il ricevitore ha effettivamente ricevuto. Un’esecuzione UDP limitata in velocità separa il carico offerto dalla risposta di congestione di TCP, mentre un mittente UDP senza limiti non è una diagnosi neutra. Registra anche la lunghezza del payload, perché un datagramma più grande cambia sia la frequenza dei pacchetti sia l’overhead di incapsulamento.

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

Esegui due volte lo stesso test con la stessa lunghezza del payload e la stessa durata, perché una sola esecuzione non separa un tetto da un minuto sfortunato. Se il ricevitore riporta meno pacchetti di quelli emessi dal mittente, la perdita è il tuo risultato, e il motore crittografico è solo uno dei vari candidati.

Spiega il divario prima di ottimizzare qualsiasi cosa

Controlla policy di inoltro, code in drop, errori di interfaccia e limiti di risorse insieme al percorso di crittografia, perché un deficit di velocità da solo non identifica mai una CPU. Mantieni espliciti anche gli strati di contabilità: i byte del tunnel esterno includono l’incapsulamento, e le ritrasmissioni spostano il rapporto tra conteggi interni ed esterni. Confrontare byte per byte contatori non correlati fabbrica una discrepanza che non è mai esistita.

La dimensione dei pacchetti merita un proprio confronto controllato invece di un numero copiato da un vecchio esempio. TCP MSS regola TCP e non ha alcun effetto su datagrammi UDP arbitrari, quindi un valore fisso di 1350 ripreso da un documento legacy non misura assolutamente nulla. Cambia di proposito la lunghezza del payload e osserva cosa riporta il ricevitore.

Cambia una variabile e mantieni il carico di lavoro

Una volta che la baseline si ripete entro una banda stretta, cambia una variabile supportata e riesegui l’attività applicativa originale. Quel passo è ciò che trasforma una cifra in una causa, ed è l’unico che giustifica toccare la configurazione. Ripeti lo stesso carico di lavoro invece di uno più accomodante.

Non ritirare proposte, indebolire l’autenticazione o disattivare la protezione per rendere più grande una cifra sintetica. Quelle mosse cambiano la postura di sicurezza e poi misurano il risultato di quel cambiamento, non la capacità del tunnel.

Articoli correlati