Pruebas de rendimiento del firewall con Xena VulcanBay

En este caso de prueba concreto, utilizamos un Xena VulcanBay con dos interfaces QSFP+ de 2 Gbps para evaluar el rendimiento de algunos firewalls de nueva generación. En concreto, nos interesaban los siguientes escenarios de prueba:

• Rendimiento puro
• Alto número de conexiones (carga de sesión)
• Uso de NAT
• Tráfico realista
• Períodos de prueba más largos durante los cuales “impulsamos” nuevas reglas de firewall para detectar posibles infracciones de rendimiento

En este artículo, mostramos cómo utilizamos Xena VulcanBay, incluyendo su administración, VulcanManager y un switch Cisco Nexus para conectar los clústeres de firewall. Enumeramos nuestros escenarios de prueba y ofrecemos algunas sugerencias sobre posibles obstáculos.

Para nuestras pruebas, utilizamos un Xena VulcanBay Vul-28PE-40G con firmware 3.6.0, licencias para ambas interfaces de 40 G y los 28 motores de paquetes disponibles. VulcanManager se ejecutó con la versión 2.1.23.0. Dado que solo usamos un VulcanBay (y no varios en ubicaciones distribuidas), el único usuario administrador pudo distribuir los 28 motores de paquetes equitativamente en estos dos puertos.

 

Para pruebas con un rendimiento de hasta 80 G fueron suficientes dos módulos QSFP+ (izquierda), así como la distribución de los motores de paquetes en estos puertos (derecha).Alambrado

Utilizamos un único switch Cisco Nexus con suficientes módulos QSFP+ y el rendimiento correspondiente para conectar VulcanBay a los respectivos clústeres de firewalls. Dado que habíamos conectado todos los clústeres de firewalls, así como VulcanBay, a este switch simultáneamente, y siempre habíamos utilizado los mismos rangos de direcciones IPv4/IPv6 para las pruebas, pudimos decidir qué fabricante de firewall queríamos probar simplemente con el apagado/no apagado de las interfaces individuales. De este modo, todo el laboratorio era controlable a distancia. Muy práctico para el caso típico de un empleado que trabaja desde casa. Además, fue muy fácil conectar VulcanBay consigo mismo para obtener valores de referencia significativos para todas las pruebas. Para ello, ambas interfaces de 40 G de VulcanBay se configuraron temporalmente en la misma VLAN.

 

Con dos líneas para el cliente y el servidor, todos los clústeres de firewall se conectaron a un conmutador central. También el VulcanBay de Neox Networks.

Existen conmutadores con módulos QSFP+ que, sin embargo, están diseñados como 4 x 10 G y *no* como 1 x 40 G. Para la conexión del VulcanBay con sus interfaces de 40 G, esto último es inevitable.

 

Gracias a las modernas ranuras QSFP+ con interfaces de 40 G, se puede lograr un rendimiento dúplex de 80 Gbit/s con solo dos conexiones.Subredes IP

En nuestro caso, queríamos probar diferentes firewalls en modo de Capa 3. Para integrar este enrutamiento de "Dispositivo Bajo Prueba" (DUT), creamos subredes adecuadas, tanto para el protocolo IPv4 obsoleto como para IPv6. Las subredes IP simuladas por VulcanBay se conectan directamente al firewall. En el caso de un IPv4 /16 network, exactamente esto /16 network También debe configurarse en el firewall. Es especialmente importante la puerta de enlace predeterminada, por ejemplo, 10.0.0..1 para el cliente IPv4. networkSi además usa la opción "Usar ARP" (lado derecho), no tendrá que preocuparse por las direcciones MAC mostradas. VulcanBay las resuelve automáticamente.

 

El rango de direcciones debe ajustarse para que las pruebas realizadas no sean equivalentes a una inundación de MAC.

Lo mismo se aplica a IPv6. Aquí el network No se introduce con la notación de barra diagonal habitual, sino que simplemente se determinan la puerta de enlace y el rango de direcciones. Mediante "Usar NDP", VulcanBay resuelve automáticamente la dirección MAC de capa 2 a la dirección IPv6 de capa 3.

 

“Use Gateway” le dice a VulcanBay que se debe utilizar un enrutador/firewall intermedio para las pruebas.

Inundación de direcciones MAC. Dependiendo de los escenarios de prueba utilizados, VulcanBay puede simular millones de direcciones IPv4/IPv6 en el segmento cliente o servidor. Esto supone una inundación de direcciones MAC para cada conmutador o cortafuegos intermedio. Los pesos de gama alta comunes pueden contener un máximo de 128 16 direcciones MAC en su tabla de direcciones MAC. Si se deja el rango predeterminado de 4 millones (!) de direcciones IPv1.8, o 10 x 19 6 direcciones IPv65, establecido por Xena Networks, los resultados de las pruebas carecen de valor. Por lo tanto, recomendamos encarecidamente reducir los rangos de direcciones desde el principio a valores realistas, como se puede ver en la captura de pantalla anterior (marcado en amarillo: XNUMX XNUMX direcciones).

Para los valores de referencia, VulcanBay también se conectó consigo mismo en todas las pruebas. Si bien IPv4 permitía usar las mismas subredes, networks con diferentes rangos de direcciones, IPv6 requiere subredes dentro del *mismo* prefijo /64.Casos de prueba

1) Rendimiento puro: En el primer escenario de prueba, nos centramos exclusivamente en el rendimiento de los firewalls. Para ello, elegimos el escenario "Patrón", uno para IPv4 y otro para IPv6, que establece automáticamente la proporción al 50/50. En la configuración, seleccionamos además "Bidireccional" para enviar datos en ambas direcciones, es decir, dúplex, en ambos casos. De esta forma, pudimos alcanzar el rendimiento máximo de 80 G con las dos interfaces de 2 G. Para distribuir el ancho de banda en varias sesiones (que en la práctica es el caso de prueba más realista), seleccionamos 40 usuarios, que debían establecer conexiones desde 1000 puertos de origen a 100 servidores cada uno. Esto da un total de 10 millón de sesiones para IPv1 e IPv4. Con un tiempo de aceleración de 6 segundos (es decir, un aumento gradual de las conexiones en lugar de la carga completa inmediata), la prueba pura se ejecutó durante 5 segundos después, antes de tener también un tiempo de desaceleración de 120 segundos.

 

Escenario de prueba "Patrón" con una distribución 50/50 de IPv4 e IPv6. El "Perfil de Carga" (derecha) muestra los usuarios que se simularán utilizando el eje temporal.

Durante la prueba, VulcanManager ya muestra datos útiles, como las conexiones TCP o el rendimiento de capa 1. Los gráficos de la parte superior ofrecen una buena impresión a simple vista. En la siguiente captura de pantalla se puede observar que el número de conexiones activas es inferior a la mitad del planificado (incorrecto), mientras que el rendimiento de capa 5-7 presenta una falla poco atractiva al inicio de la prueba. Ambos problemas resultaron ser errores en la implementación de IPv6 del dispositivo probado.

 

Si bien en teoría 2 millones de sesiones con un rendimiento de 80 G deberían haber pasado el firewall, menos de la mitad de ellas lo hicieron sin problemas.

El gráfico "Sesiones activas" no muestra las sesiones activas reales, sino el número de usuarios simulados en la Vista en vivo durante la prueba, así como en el informe PDF posterior. Si bien el gráfico es correcto para los 2000 usuarios, en realidad hubo 2 millones de sesiones durante la prueba.

2) Alto número de conexiones (carga de sesión): También para IPv4 e IPv6, se establecieron y mantuvieron 20 millones de sesiones TCP paralelas durante esta prueba. No solo la suma de las sesiones fue relevante, sino también el corto tiempo de arranque de tan solo 30 segundos, lo que correspondió a una tasa de configuración de 667,000 60 conexiones por segundo. Las sesiones se mantuvieron en espera durante 30 segundos, pero sin transferir datos. Transcurridos otros XNUMX segundos, se terminaron de nuevo, como es habitual en TCP mediante FIN-ACK. El objetivo era que los cortafuegos probados, en primer lugar, permitieran el paso limpio de las conexiones y, en segundo lugar, también pudieran desmantelarlas limpiamente (y así liberar memoria).

Antes de cada prueba, borramos la tabla de direcciones MAC del switch, así como las cachés de sesión, ARP y NDP de los firewalls. Por lo tanto, cada prueba se realizó desde cero.

3) Escenarios NAT: Se utilizó la misma prueba que en el punto 1), con la única diferencia de que las conexiones IPv4 del cliente network al servidor network Se les proporcionó un NAT de origen en los firewalls. El objetivo era determinar si esto causaría una degradación del rendimiento de los firewalls.

4) Tráfico realista: Con una "Combinación de centros de datos" predefinida, pudimos simular el flujo de dos conexiones HTTPS, SMB2, LDAP y AFS (vía UDP y TCP) para miles de usuarios con tan solo unos clics. No se trataba de una prueba de carga completa de los firewalls, sino de la velocidad de configuración y desmontaje, así como de la detección de aplicaciones. Se observaron diferencias significativas según si los ID de las aplicaciones de los firewalls estaban activados o desactivados.

5) 10 minutos de ejecución continua con confirmaciones: Esta prueba, algo más específica, consistió en los escenarios 1 y 4, es decir, carga completa (1) con configuración y apagado de sesión constantes (4) al mismo tiempo. Esto se ejecutó de forma continua durante 10 minutos, mientras instalábamos otras 500 reglas en cada firewall. Queríamos determinar si este proceso generaba una limitación medible en el rendimiento de los firewalls, lo cual fue parcialmente cierto.Resultados de la prueba

Al final de cada prueba, VulcanManager muestra la página de Estadísticas e Informes con todos los detalles posibles. Con "Crear Informe", puede crear un PDF que, además de todos los detalles, también contiene información sobre el escenario de prueba seleccionado y el dispositivo probado. El reto reside en distinguir las cifras relevantes de las menos relevantes y contextualizarlas adecuadamente para obtener resultados significativos. Durante nuestras comparaciones de diferentes firewalls de última generación, nos limitamos al "Rendimiento estable de capa 1 (bps)" para la prueba de rendimiento, o a las "Conexiones TCP exitosas" para la prueba de conexión. Comparado con los valores de referencia con los que VulcanBay se conectó consigo mismo, esto ya arrojó resultados comparables significativos que se pueden mostrar fácilmente tanto en forma de tabla como gráficamente.

 

La página de Estadísticas e informes proporciona una descripción general aproximada (centro) y la posibilidad de leer valores de prueba de todas las capas OSI y los escenarios de prueba seleccionados (enlaces, pestañas desplegables).

 

Detalle de un informe en PDF con todos los detalles.

Los diversos escenarios de “mezcla de aplicaciones” existentes de Xena Networks no sirven para la comparación directa de los valores de rendimiento del firewall, sino para la generación específica de network Tráfico. De esta forma, se pueden comprobar las detecciones de las aplicaciones o se pueden "estresar" un poco más otros escenarios ejecutados en paralelo.Otras caracteristicas

Tenga en cuenta que VulcanManager cuenta con otras funciones interesantes que no utilizamos en este caso práctico, como Tráfico TLS (para probar la interceptación TLS) y Reproducción de Paquetes (para probar escenarios personalizados y más específicos extraídos de los PCAP cargados). Además, no utilizamos muchos escenarios de prueba orientados a aplicaciones o protocolos, como Dropbox, eBay, LinkedIn o HTTPS, IMAP y NFS. Esto se debe a que nuestros objetivos de prueba se centraron principalmente en el rendimiento y el número de sesiones.Conclusión

VulcanBay de XENA Networks es el dispositivo de prueba ideal para comparar varios firewalls de nueva generación. En muy poco tiempo, configuramos y probamos diversos escenarios. Al principio, la abundancia de resultados fue abrumadora. La clave estaba en concentrarse en la información relevante.