UDP-verkeer via ASA mislukt nadat primaire ISP-link online terugkomt in een dubbele ISP-instelling

Inleiding

Als een adaptieve security applicatie (ASA) twee uitgangsinterfaces per doelsubnetverbinding heeft en de voorkeursroute naar een bestemming voor enige tijd uit de routertabel wordt verwijderd, kunnen UDP-verbindingen (User Datagram Protocol) falen wanneer de voorkeursroute opnieuw aan de routeringstabel wordt toegevoegd. TCP-verbindingen kunnen ook worden beïnvloed door het probleem, maar aangezien TCP pakketverlies detecteert, worden deze verbindingen automatisch door de eindpunten afgebroken en opnieuw opgebouwd met behulp van de meest optimale routes nadat de routes zijn gewijzigd.

Dit probleem kan ook worden gezien als een routeringsprotocol wordt gebruikt en een topologieverandering een verandering in de routeringstabel op ASA teweegbrengt.

Voordat u begint

Vereisten

Om dit probleem aan te pakken, moet de routeringstabel van de ASA veranderen. Dit is gebruikelijk bij dubbele ISP-links op een redundante manier of wanneer de ASA routes leert via een IGP (OSPF, EIGRP, RIP).

Deze kwestie komt voor wanneer de primaire ISP-verbinding online terugkomt of de genoemde IGP een reconvergentie ziet toe te schrijven aan welke een minder wenselijke route die door ASA werd gebruikt met de aangewezen laag-metrische-route wordt vervangen. U zou dan langdurige verbindingen zien, zoals UDP SIP-registraties, GRE, enzovoort, die mislukken zodra de primaire of voorkeursroute opnieuw is geïnstalleerd in de routeringstabel van de ASA.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende hardware- en softwareversies:

• Any Cisco ASA 5500 Series adaptieve security applicatie

• ASA versies 8.2(5), 8.3(2)12, 8.4(1)1, 8.5(1) en hoger

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Probleem

Als een routeringstabel wordt verwijderd uit de routeringstabel van de ASA en er geen routes zijn vanuit een interface om een bestemming te bereiken, worden verbindingen die door de firewall zijn gebouwd met die buitenlandse bestemming door de ASA verwijderd. Dit gebeurt zodat de verbindingen opnieuw kunnen worden gebouwd met behulp van een andere interface met routingvermeldingen voor de aanwezige bestemming.

Als echter meer specifieke routes aan de tabel worden toegevoegd, zullen de verbindingen niet worden bijgewerkt om de nieuwe, specifiekere routes te gebruiken en zal de minder optimale interface blijven gebruiken.

Houd er bijvoorbeeld rekening mee dat de firewall twee interfaces heeft die op het internet gericht zijn - "buiten" en "back-up" - en dat deze twee routes in de configuratie van de ASA bestaan:

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

Als zowel de buiten- als de reserveinterfaces "omhoog" zijn, dan zullen de verbindingen die door de firewall worden uitgebouwd de buiteninterface gebruiken, aangezien het de aangewezen metriek van 1 heeft. Als de buiteninterface is gesloten (of de SLA controlefunctie die de route volgt ontmoet een verlies van connectiviteit aan gevolgde IP), zouden de verbindingen die de buiteninterface gebruiken worden afgebroken en worden herbouwd die de reserveinterface gebruiken, aangezien de reserveinterface de enige interface met een route aan de bestemming is.

Het probleem doet zich voor wanneer de buiteninterface wordt teruggebracht of de gevolgde route de geprefereerde route opnieuw wordt. De routeringstabel wordt bijgewerkt om de oorspronkelijke route te verkiezen, maar de bestaande verbindingen blijven op ASA bestaan en de reserveinterface oversteken en NIET geschrapt en op de buiteninterface met de meer-voorkeursmetriek opnieuw gecreëerd. Dit komt doordat de standaardroute voor back-ups nog steeds bestaat in de interfacespecifieke routeringstabel van de ASA. De verbinding blijft de interface met de minder wenselijke route gebruiken tot de verbinding wordt verwijderd; in het geval van UDP zou dit voor onbepaalde tijd kunnen zijn.

Deze situatie kan problemen met langdurige verbindingen veroorzaken, zoals externe SIP-registraties of andere UDP-verbindingen.

Oplossing

Om dit specifieke probleem aan te pakken werd een nieuwe eigenschap toegevoegd aan ASA die zal veroorzaken dat de verbindingen worden afgebroken en op een nieuwe interface worden herbouwd als een meer aangewezen route aan de bestemming aan de routeringstabel wordt toegevoegd. Om de functie te activeren (deze is standaard uitgeschakeld) stelt u een non-zero timeout in op de opdracht floating-console van de timeout. Deze onderbreking (die in HH wordt gespecificeerd:MM:SS) specificeert de tijd ASA wacht alvorens het onderaan de verbinding zodra een meer aangewezen route terug naar de routeringstabel wordt toegevoegd:

Dit is een CLI-voorbeeld van het inschakelen van de functie. Met deze CLI, als een pakket wordt ontvangen op een bestaande verbinding waarvoor nu een andere, meer geprefereerde route naar de bestemming is, wordt de verbinding 1 minuut later afgebroken (en opnieuw opgebouwd via de nieuwe, meer geprefereerde route):

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#

Deze functie wordt toegevoegd aan het ASA-platform in de versies 8.2(5), 8.3(2)12, 8.4(1)1 en 8.5(1), inclusief latere versies van ASA-software.

Als u een versie van ASA-code uitvoert die deze functie niet implementeert, is het een oplossing voor het probleem om de UDP-verbindingen die de minder wenselijke route blijven volgen, handmatig door te spoelen, ondanks het feit dat een betere route via een duidelijke lokale host <IP> of clear-conn <IP> beschikbaar wordt gesteld.

De opdrachtreferentie beschrijft deze nieuwe functie onder de tijdelijke sectie.

Gerelateerde informatie

• Technische ondersteuning en documentatie – Cisco Systems