En muchas ubicaciones, solo tenemos un Cisco ASA 5505 cada uno y uno o más puntos de acceso WiFi, además del enrutador del proveedor. Sin servidores ni PC, solo servicio WiFi para visitantes ocasionales. Quiero verificar de forma remota si el proveedor nos da el ancho de banda contratado. Pude ver el ancho de banda usado en el monitoreo ASA, y probar una dirección enviando tráfico al ASA usando Iperf de mi lado.
¿Hay alguna forma de permitir que el ASA genere tráfico sustancial?
Respuestas:
(Acabo de notar tu comentario sobre Raspberrys, y quiero seguir)
Tenemos una gran red MPLS donde necesitamos medir el ancho de banda y la fluctuación entre sitios para asegurarnos de que nuestras aplicaciones más sensibles no estén dañadas.
Una buena forma de hacerlo es, como mencionó, implementar Raspberrys. Son lo suficientemente pequeños, por lo que puede instalarlos en casi cualquier lugar. Una gran herramienta para probar bandwith / jitter es iperf , que luego puede configurar para que se ejecute como un demonio (¡filtrado!) En cada PI. Luego, simplemente inicie las pruebas desde una estación de administración central.
En sentido descendente, es posible que pueda descargar algo nulo: en el ASA, pero en sentido ascendente, estaría limitado de cuánto puede transferir el disco flash, que generalmente no es tanto.
Su mejor opción sería conectar una PC y ejecutar las pruebas, pero eso requiere que alguien esté en el sitio, por supuesto.
Quizás el monitoreo pasivo es un mejor enfoque. Existen muchos sistemas que rastrearán el estado de la interfaz / errores / descartes / ancho de banda. ¿Un gráfico de ancho de banda se ajusta a sus necesidades?
Tuve un requisito similar hace muchas lunas con un enrutador remoto con IOS. Terminó usando el servicio chargen tcp-small-server en el enrutador - se ejecuta en tcp / 19. Generará una secuencia de caracteres aleatorios, etc. y se puede escalar usando múltiples sesiones de telnet desde el enrutador remoto a otros enrutadores que ejecutan chargen. En ninguna parte cerca del rico control / funcionalidad de las pruebas iperf basadas en host. Además, como sabemos, ASA no admite telnet localmente, por lo que esto no funcionará aquí ...
ASA tiene esa utilidad de rastreo de paquetes desde 7.0 para generar tráfico interesante para configuraciones de túnel, pero no permite el ajuste de la velocidad. Dicha funcionalidad también sería un vector de ataque interesante si se explota de forma remota y a escala ... Cualquier funcionalidad nativa en ASA probablemente vincularía el plano de control y cualquier variedad de vigilancia de plano de control inherente necesitaría restringir la tasa de tráfico generada.
Estoy de acuerdo con lo anterior que Raspberry Pi es una buena solución aquí. Acabamos de dejar algunos para conducir pantallas de estilo NOC. Son increíbles.
De hecho, la semana pasada me quedé atrapado con una solicitud similar (por supuesto, el sitio remoto estaba al otro lado del país). Lo que terminé haciendo fue usar mgen para enviar udp unidireccional y solo verificar los contadores en el dispositivo remoto. Si no se siente cómodo con mgen , puede hacer lo mismo con nping o una de las herramientas de nmap .
Como señaló, el problema con iperf , IxChariot y muchas otras herramientas es que requieren un respondedor remoto. mgen , nping y algunos otros no.
Si tiene el Kit de herramientas de ingeniería de vientos solares, puede usar "WAN Killer" entre las dos ubicaciones. Asegúrese de que sus ACL permitan que ambos extremos se comuniquen entre sí de esta manera, e inunde con el nivel apropiado de eco o descarte del Punto A al B y viceversa.
Usamos esto para probar la capacidad de las redes para manejar el tráfico a través de conexiones VPN y MPLS, ya sea que esté midiendo el rendimiento bruto de A a B y el PPS de A a B.