Si un dispositivo de seguridad adaptable (ASA) tiene dos interfaces de salida por subred de destino y la ruta preferida a un destino se elimina de la tabla de enrutamiento durante algún tiempo, las conexiones del protocolo de datagramas de usuario (UDP) pueden fallar cuando la ruta preferida se vuelve a agregar a la tabla de enrutamiento. Las conexiones TCP también pueden verse afectadas por el problema, pero dado que TCP detecta la pérdida de paquetes, los terminales interrumpen automáticamente estas conexiones y las vuelven a crear utilizando las rutas más óptimas después de que cambian las rutas.
Este problema también puede observarse si se utiliza un protocolo de ruteo y un cambio de topología desencadena un cambio en la tabla de ruteo en el ASA.
Para encontrar este problema, la tabla de ruteo del ASA debe cambiar. Esto es común con los links ISP duales de una manera redundante o cuando el ASA está aprendiendo rutas a través de un IGP (OSPF, EIGRP, RIP).
Este problema ocurre cuando el link ISP primario vuelve a estar en línea o el IGP mencionado ve una reconvergencia debido a la cual una ruta menos preferida que estaba siendo utilizada por el ASA es reemplazada por la ruta de métrica inferior preferida. Verá entonces que las conexiones de larga duración, como los registros UDP SIP, GRE, etc., fallan una vez que la ruta principal o preferida se reinstala en la tabla de ruteo de ASA.
La información que contiene este documento se basa en estas versiones de software y hardware.
Cualquier dispositivo de seguridad adaptable Cisco ASA serie 5500
ASA versiones 8.2(5), 8.3(2)12, 8.4(1)1, 8.5(1) y posteriores
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
Si se elimina una entrada de la tabla de ruteo del ASA y no hay rutas fuera de una interfaz para alcanzar un destino, las conexiones construidas a través del firewall con ese destino externo serán eliminadas por el ASA. Esto ocurre para que las conexiones se puedan construir nuevamente usando una interfaz diferente con entradas de ruteo para el destino presente.
Sin embargo, si se agregan rutas más específicas de nuevo a la tabla, las conexiones no se actualizarán para utilizar las rutas nuevas y más específicas, y continuarán utilizando la interfaz menos óptima.
Por ejemplo, considere que el firewall tiene dos interfaces que se enfrentan a Internet - "afuera" y "respaldo" - y que estas dos rutas existen en la configuración del ASA:
route outside 0.0.0.0 0.0.0.0 10.1.1.1 1 track 1 route backup 0.0.0.0 0.0.0.0 172.16.1.1 254
Si las interfaces externa y de respaldo están "activas", las conexiones generadas de manera saliente a través del firewall utilizarán la interfaz externa, ya que tiene la métrica preferida de 1. Si la interfaz externa se apaga (o la función de monitoreo de SLA que está rastreando la ruta encuentra una pérdida de conectividad con la IP rastreada), las conexiones que utilizan la interfaz externa se desactivarán y se reconstruirán usando la interfaz de respaldo, ya que la interfaz de respaldo es la única interfaz con una ruta al destino.
El problema ocurre cuando la interfaz externa se vuelve a activar o la ruta rastreada se convierte nuevamente en la ruta favorita. La tabla de ruteo se actualiza para preferir la ruta original, pero las conexiones existentes continúan existiendo en el ASA y atraviesan la interfaz de respaldo y NO se eliminan y se vuelven a crear en la interfaz externa con la métrica más preferida. Esto se debe a que la ruta predeterminada de respaldo todavía existe en la tabla de ruteo específica de la interfaz de ASA. La conexión continúa utilizando la interfaz con la ruta menos preferida hasta que se elimina la conexión; en el caso de UDP, puede ser indefinido.
Esta situación puede causar problemas con conexiones de larga duración, como registros SIP externos u otras conexiones UDP.
Para resolver este problema específico, se agregó una nueva función al ASA que hará que las conexiones se desconecten y se reconstruyan en una nueva interfaz si se agrega una ruta preferida al destino a la tabla de ruteo. Para activar la función (está inhabilitada de forma predeterminada), establezca un tiempo de espera distinto de cero en el comando timeout flotante-conn. Este tiempo de espera (especificado en HH:MM:SS) especifica el tiempo que el ASA espera antes de interrumpir la conexión una vez que se agrega una ruta preferida a la tabla de ruteo:
Este es un ejemplo de CLI de activación de la función. Con esta CLI, si se recibe un paquete en una conexión existente para la que ahora hay una ruta diferente y más preferida al destino, la conexión se interrumpirá 1 minuto después (y se reconstruirá usando la nueva ruta más preferida):
ASA# config terminal ASA(config)# timeout floating-conn 0:01:00 ASA(config)# end ASA# show run timeout timeout conn 1:00:00 half-closed 0:10:00 udp 0:50:00 icmp 0:00:02 timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00 timeout sip-provisional-media 0:02:00 uauth 0:01:00 absolute timeout tcp-proxy-reassembly 0:01:00 timeout xlate 0:01:00 timeout pat-xlate 0:00:30 timeout floating-conn 0:01:00 ASA#
Esta función se añade a la plataforma ASA en las versiones 8.2(5), 8.3(2)12, 8.4(1)1 y 8.5(1), incluidas las versiones posteriores del software ASA.
Si ejecuta una versión de código ASA que no implementa esta función, una solución alternativa al problema sería vaciar manualmente las conexiones UDP que continúan tomando la ruta menos preferida a pesar de que se haya puesto a disposición una mejor ruta a través de un clear local-host <IP> o clear-conn <IP> .
La referencia de comandos enumera esta nueva función en la sección timeout.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
21-Jun-2012
|
Versión inicial |