O tráfego UDP através do ASA falha depois que o link primário do ISP volta a ficar on-line em uma configuração de ISP duplo

Introdução

Se um Adaptive Security Appliance (ASA) tiver duas interfaces de saída por sub-rede de destino e a rota preferencial para um destino for removida da tabela de roteamento por algum tempo, as conexões do User Datagram Protocol (UDP) poderão falhar quando a rota preferencial for adicionada novamente à tabela de roteamento. As conexões TCP também podem ser afetadas pelo problema, mas como o TCP detecta a perda de pacotes, essas conexões são interrompidas automaticamente pelos endpoints e recriadas usando as rotas mais ideais após a alteração das rotas.

Esse problema também pode ser visto se um protocolo de roteamento for usado e uma alteração de topologia acionar uma alteração na tabela de roteamento no ASA.

Antes de Começar

Requisitos

Para encontrar esse problema, a tabela de roteamento do ASA deve ser alterada. Isso é comum com links ISP duplos de forma redundante ou quando o ASA está aprendendo rotas via IGP (OSPF, EIGRP, RIP).

Esse problema ocorre quando o enlace principal do ISP volta a ficar on-line ou o IGP em questão vê uma reconvergência devido à qual uma rota menos preferencial que estava sendo usada pelo ASA é substituída pela rota de métrica mais baixa preferencial. Você verá conexões de longa duração, como registros SIP UDP, GRE, etc., falharem depois que a rota primária ou preferencial for reinstalada na tabela de roteamento do ASA.

Componentes Utilizados

As informações neste documento são baseadas nas seguintes versões de hardware e software:

• Qualquer dispositivo de segurança adaptável Cisco ASA 5500 Series

• ASA versões 8.2(5), 8.3(2)12, 8.4(1)1, 8.5(1) e posteriores

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Problema

Se uma entrada da tabela de roteamento for removida da tabela de roteamento do ASA e não houver rotas fora de uma interface para acessar um destino, as conexões criadas através do firewall com esse destino externo serão excluídas pelo ASA. Isso ocorre para que as conexões possam ser criadas novamente usando uma interface diferente com entradas de roteamento presentes para o destino.

No entanto, se rotas mais específicas forem adicionadas de volta à tabela, as conexões não serão atualizadas para usar as novas rotas mais específicas e continuarão a usar a interface menos ideal.

Por exemplo, considere que o firewall tem duas interfaces que enfrentam a Internet - "externa" e "de backup" - e essas duas rotas existem na configuração do 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

Se as interfaces externa e de backup estiverem "ativadas", as conexões criadas fora do firewall usarão a interface externa, pois ela tem a métrica preferencial de 1. Se a interface externa estiver desativada (ou a função de monitoramento de SLA que está rastreando a rota encontrar uma perda de conectividade com o IP rastreado), as conexões que usam a interface externa serão desativadas e recriadas usando a interface de backup, pois a interface de backup é a única interface com uma rota até o destino.

O problema ocorre quando a interface externa é ativada novamente ou a rota rastreada se torna a rota favorecida novamente. A tabela de roteamento é atualizada para preferir a rota original, mas as conexões existentes continuam a existir no ASA e atravessam a interface de backup e NÃO são excluídas e recriadas na interface externa com a métrica mais preferida. Isso ocorre porque a rota padrão de backup ainda existe na tabela de roteamento específica da interface do ASA. A conexão continua a usar a interface com a rota menos preferida até que a conexão seja excluída; no caso do UDP, isso pode ser indefinido.

Essa situação pode causar problemas com conexões de longa duração, como registros SIP externos ou outras conexões UDP.

Solução

Para resolver esse problema específico, um novo recurso foi adicionado ao ASA que fará com que as conexões sejam desativadas e reconstruídas em uma nova interface se uma rota preferencial para o destino for adicionada à tabela de roteamento. Para ativar o recurso (desativado por padrão), defina um timeout diferente de zero para o comando timeout floating-conn. Esse tempo limite (especificado em HH:MM:SS) especifica o tempo que o ASA aguarda antes de interromper a conexão depois que uma rota preferencial é adicionada de volta à tabela de roteamento:

Este é um exemplo de CLI de ativação do recurso. Com esta CLI, se um pacote for recebido em uma conexão existente para a qual agora existe uma rota diferente e mais preferencial para o destino, a conexão será desfeita 1 minuto depois (e reconstruída usando a nova rota, mais preferencial):

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#

Esse recurso é adicionado à plataforma ASA nas versões 8.2(5), 8.3(2)12, 8.4(1)1 e 8.5(1), incluindo versões posteriores do software ASA.

Se você executar uma versão do código ASA que não implementa esse recurso, uma solução alternativa para o problema seria descarregar manualmente as conexões UDP que continuam a tomar a rota menos preferida, apesar de uma rota melhor ser disponibilizada através de um clear local-host <IP> ou clear-conn <IP> .

A referência de comando lista esse novo recurso na seção timeout.

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems