Test delle prestazioni del firewall con Xena VulcanBay

In questo caso di test concreto abbiamo utilizzato un Xena VulcanBay con 2 interfacce QSFP+ da 40 Gbps per testare le prestazioni di alcuni firewall di nuova generazione. Nello specifico, eravamo interessati ai seguenti scenari di test:

• Pura produttività
• Elevato numero di connessioni (carico di sessione)
• Utilizzo di NAT
• Traffico realistico
• Periodi di test più lunghi durante i quali abbiamo “spinto” nuove regole del firewall per rilevare potenziali violazioni della capacità di trasmissione

In questo articolo vogliamo mostrarvi come abbiamo utilizzato Xena VulcanBay, inclusi i suoi sistemi di gestione, VulcanManager e uno switch Cisco Nexus per connettere i cluster di firewall. Elenchiamo i nostri scenari di test e forniamo alcuni suggerimenti su possibili ostacoli.

Per i nostri test abbiamo utilizzato una Xena VulcanBay Vul-28PE-40G con firmware versione 3.6.0, licenze per entrambe le interfacce 40G e per tutti i 28 Packet Engine disponibili. Il VulcanManager era in esecuzione sulla versione 2.1.23.0. Poiché utilizzavamo una sola VulcanBay (e non diverse in sedi distribuite), l'unico utente amministratore era in grado di distribuire tutti i 28 Packet Engine equamente su queste due porte.

 

Per test con throughput fino a 80 G sono stati sufficienti due moduli QSFP+ (a sinistra) e la distribuzione dei motori di pacchetto su queste porte (a destra).Cablaggio

Abbiamo utilizzato un singolo switch Cisco Nexus con un numero sufficiente di moduli QSFP+ e la relativa velocità di trasmissione per collegare VulcanBay ai rispettivi cluster di firewall. Poiché avevamo collegato contemporaneamente tutti i cluster di firewall e VulcanBay a questo switch e avevamo sempre utilizzato gli stessi intervalli di indirizzi IPv4/IPv6 per i test, siamo stati in grado di decidere quale produttore di firewall testare semplicemente con la funzionalità "shutdown / no shutdown" delle singole interfacce. In questo modo, l'intero laboratorio era controllabile a distanza. Una soluzione molto pratica per il caso tipico di un dipendente che lavora da casa. Inoltre, è stato semplicissimo collegare VulcanBay "a se stesso" per ottenere valori di riferimento significativi per tutti i test. A tale scopo, entrambe le interfacce 40 Gb verso VulcanBay sono state temporaneamente configurate nella stessa VLAN.

 

Con due linee ciascuna per client e server, tutti i cluster firewall erano collegati a uno switch centrale. Anche il VulcanBay di Neox Networks.

Esistono switch con moduli QSFP+, che però sono progettati come 4x 10 G e *non* come 1x 40 G. Per il collegamento del VulcanBay con le sue interfacce 40 G, quest'ultima è inevitabile.

 

Grazie ai moderni slot QSFP+ con interfacce da 40 G, è possibile raggiungere una velocità di trasmissione duplex di 80 Gbit/s con sole due connessioni.Subnet IP

Nel nostro caso, volevamo testare diversi firewall in modalità Layer 3. Per integrare questo routing "Device Under Test" (DUT), abbiamo creato subnet appropriate, sia per il protocollo IPv4 obsoleto che per IPv6. Le subnet IP simulate da VulcanBay vengono quindi collegate direttamente al firewall. Nel caso di un protocollo IPv4 /16 network, esattamente questo /16 network Deve essere configurato anche sul firewall. Particolarmente importante è il gateway predefinito, ad esempio 10.0.0..1 per il client IPv4 networkSe si utilizza anche l'opzione "Usa ARP" (a destra), non è necessario preoccuparsi degli indirizzi MAC visualizzati. VulcanBay li risolve autonomamente.

 

L'intervallo di indirizzi deve essere regolato in modo che i test eseguiti non equivalgano al flooding MAC.

Lo stesso vale per IPv6. Qui il network non viene immesso con la consueta notazione slash, ma vengono semplicemente determinati il ​​gateway e l'intervallo di indirizzi. Tramite "Usa NDP", VulcanBay risolve automaticamente l'indirizzo MAC di Livello 2 nell'indirizzo IPv6 di Livello 3.

 

L'opzione "Usa gateway" indica a VulcanBay che per i test deve essere utilizzato un router/firewall intermedio.

Flooding MAC! A seconda degli scenari di test utilizzati, VulcanBay può simulare milioni di indirizzi IPv4/IPv6 nel segmento client o server. Si tratta di un vero e proprio flood di indirizzi MAC per ogni switch o firewall intermedio. I sistemi di fascia alta più comuni possono contenere un massimo di 128 indirizzi MAC nella loro tabella degli indirizzi MAC. Se si lascia l'intervallo predefinito di 16 milioni (!) di indirizzi IPv4, o 1.8 x 10^19 indirizzi IPv6 impostato di default da Xena Networks, qualsiasi risultato del test non è significativo. Pertanto, consigliamo vivamente di ridurre gli intervalli di indirizzi iniziali a valori realistici, come si può vedere nello screenshot qui sopra (in giallo: 65 indirizzi).

Come valori di riferimento, VulcanBay era anche "connesso a se stesso" per tutti i test. Mentre IPv4 consentiva di utilizzare le stesse "subnet" networkcon intervalli di indirizzi diversi, IPv6 richiedeva subnet all'interno dello *stesso* prefisso /64.Casi di test

1) Throughput puro: nel primo scenario di test, eravamo interessati esclusivamente al throughput dei firewall. Per questo abbiamo scelto lo scenario "Pattern", una volta per IPv4 e una volta per IPv6, che imposta automaticamente il rapporto a 50-50. Nelle impostazioni abbiamo inoltre selezionato "Bidirezionale" per inoltrare i dati in entrambe le direzioni, ovvero duplex, in entrambi i casi. In questo modo abbiamo potuto raggiungere il throughput massimo di 80 Gbps con le 2 interfacce da 40 Gbps. Per distribuire la larghezza di banda su più sessioni (che nella realtà è il caso di test più realistico), abbiamo selezionato 1000 utenti, che avrebbero dovuto stabilire connessioni da 100 porte sorgente a 10 server ciascuno. Ciò significa 1 milione di sessioni per IPv4 e IPv6. Con un tempo di ramp-up di 5 secondi, ovvero un aumento graduale delle connessioni anziché l'immediato pieno carico, il test puro è durato 120 secondi, prima di subire un tempo di ramp-down di 5 secondi.

 

Scenario di test "Pattern" con una distribuzione 50-50 di IPv4 e IPv6. Il "Load Profile" (a destra) mostra gli utenti da simulare utilizzando l'asse temporale.

Durante il test, VulcanManager visualizza già alcuni dati utili, come le connessioni TCP o il throughput di Livello 1. Grazie ai grafici nell'area superiore, si ottiene una buona impressione a colpo d'occhio. Nello screenshot seguente si può notare che il numero di connessioni attive è inferiore alla metà di quello pianificato (negativo), mentre il Goodput di Livello 5-7 presenta una brutta flessione all'inizio del test. Entrambi i problemi si sono rivelati errori nell'implementazione IPv6 del dispositivo testato.

 

Mentre teoricamente 2 milioni di sessioni con una velocità di trasmissione di 80 G avrebbero dovuto superare il firewall, meno della metà di esse sono riuscite a passare senza problemi.

Il grafico "Sessioni attive" non mostra le sessioni attive effettive, ma il numero di utenti simulati nella visualizzazione live durante il test e nel report PDF successivo. Sebbene il grafico sia corretto per i 2000 utenti, in realtà durante il test si sono verificate 2 milioni di sessioni.

2) Elevato numero di connessioni (carico di sessione): anche per IPv4 e IPv6, durante questo test sono state stabilite e mantenute 20 milioni di sessioni TCP parallele. Non solo la somma delle sessioni è stata rilevante, ma anche il breve tempo di avvio di soli 30 secondi, corrispondente a una velocità di configurazione di 667,000 connessioni al secondo! Le sessioni sono state lasciate in sospeso per 60 secondi, ma senza trasferire dati. Per altri 30 secondi sono state nuovamente terminate, come avviene tipicamente per TCP tramite FIN-ACK. L'obiettivo era che i firewall da testare, in primo luogo, consentissero il passaggio delle connessioni senza problemi e, in secondo luogo, potessero anche smantellarle senza problemi (liberando così la loro memoria).

Prima di ogni test abbiamo cancellato la tabella degli indirizzi MAC sullo switch e le cache di sessione, ARP e NDP sui firewall. Quindi ogni test è stato eseguito da zero a zero.

3) Scenari NAT: è stato utilizzato lo stesso test del punto 1), con l'unica differenza che le connessioni IPv4 dal client network al server network è stato fornito un NAT sorgente sui firewall. L'obiettivo era scoprire se ciò avrebbe causato un degrado delle prestazioni dei firewall.

4) Traffico realistico: con un "Datacenter Mix" predefinito, siamo stati in grado di simulare il flusso di due connessioni HTTPS, SMB2, LDAP e AFS (tramite UDP e TCP) per diverse migliaia di utenti con pochi clic. Non si trattava di un test a pieno carico dei firewall, ma di velocità di installazione e disinstallazione, nonché di rilevamento delle applicazioni. A seconda che gli ID applicazione dei firewall fossero attivati ​​o disattivati, si sono riscontrate differenze significative.

5) 10 minuti di fuoco continuo con commit: questo test, un po' più specifico, consisteva negli scenari 1 e 4, ovvero a pieno carico (1) con configurazione e spegnimento della sessione costanti (4) contemporaneamente. Il test è stato eseguito ininterrottamente per 10 minuti, mentre installavamo altre 500 regole su ciascun firewall. In questo caso, volevamo verificare se questo processo creasse un calo misurabile della velocità di trasmissione sui firewall, cosa che in parte si è verificata.Risultati del test

Al termine di ogni test, VulcanManager visualizza la pagina Statistiche e Report con tutti i dettagli possibili. Con "Crea Report" è possibile creare un PDF contenente, oltre a tutti i dettagli, anche informazioni sullo scenario di test selezionato e sul dispositivo testato. La sfida consiste nel distinguere i numeri rilevanti da quelli meno rilevanti e inserirli nel contesto corretto per ottenere risultati significativi. Durante i nostri confronti tra diversi firewall di nuova generazione, ci siamo limitati al "throughput costante di Livello 1 (bps)" per il test di throughput, o alle "Connessioni TCP riuscite" per il test di connessione. Rispetto ai valori di riferimento con cui VulcanBay era connesso a se stesso, questo ha già prodotto risultati significativi e confrontabili, facilmente visualizzabili sia in forma tabellare che grafica.

 

La pagina Statistiche e report fornisce una panoramica generale (al centro) e la possibilità di leggere i valori dei test da tutti i livelli OSI e dagli scenari di test selezionati (collegamenti, schede pieghevoli).

 

Dettaglio del report PDF con tutti i dettagli.

I vari scenari “Application Mix” esistenti di Xena Networks non servono al confronto diretto dei valori delle prestazioni del firewall, ma alla generazione mirata di network traffico. In questo modo, è possibile verificare i rilevamenti delle applicazioni o "stressare" un po' di più altri scenari eseguiti in parallelo.Ulteriori caratteristiche

Si noti che VulcanManager offre altre funzionalità interessanti che non abbiamo utilizzato in questo caso di studio, come TLS Traffic (per testare l'intercettazione TLS) e Packet Replay (per testare scenari personalizzati e più specifici estratti dai PCAP caricati). Inoltre, non abbiamo utilizzato molti scenari di test orientati ad applicazioni o protocolli come Dropbox, eBay, LinkedIn o HTTPS, IMAP e NFS. Questo è dovuto alle nostre finalità di test, che erano fortemente incentrate sulla produttività e sul numero di sessioni.Conclusione

VulcanBay di XENA Networks è il dispositivo di test ideale per confrontare diversi firewall di nuova generazione. In brevissimo tempo abbiamo configurato e testato diversi scenari di test. Inizialmente, solo la quantità di risultati dei test ci ha sopraffatto. Il segreto è stato concentrarsi sulle informazioni rilevanti.