10-05-2022 04:04 AM
Hi,
we reconfigure our L2L VPN from crypto map to VTI with iBGP. We use DHCP server which is at a remote location. During the failover, BGP flapped and after some time some devices didnt get the IP address. I checked sh conn for the IP address of the DHCP server and found this one:
UDP WAN DHCP_SERVER:67 INSIDE DHCP_RELAY_CLIENT:67, idle 0:00:01, bytes 410645626, flags X
UDP WAN DHCP_SERVER:67 INSIDE DHCP_RELAY_CLIENT:67, idle 0:00:00, bytes 410647268, flags X
So ASA was sending traffic to physical interface, not VTI. When I did clea conn address DHCP_RELAY_CLIENT, WAN changed to VTI and everything started to work.
I suspect that when the BGP was down, client requested for the IP, ASA established it via default route (WAN) and the connection remained there even after BGP was up. The question is how to refresh it. My idea is to route the RFC1918 to Null0 so these connections won't be even established.
Is there any clear solution to this one?
thank you
Solved! Go to Solution.
10-05-2022 04:15 AM
@peter.matuska1 refer to this link https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113592-udp-traffic-fails-00.html
"This situation can cause problems with long-lived connections, such as external SIP registrations or other UDP connections.
In order to address this specific problem, a new feature was added to the ASA that will cause connections to be torn down and rebuilt on a new interface if a more preferred route to the destination is added to the routing table. In order to activate the feature (it is disabled by default), set a non-zero timeout to the timeout floating-conn command."
...not the exact same scenario, but I think the same logic applies.
10-05-2022 04:15 AM
@peter.matuska1 refer to this link https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113592-udp-traffic-fails-00.html
"This situation can cause problems with long-lived connections, such as external SIP registrations or other UDP connections.
In order to address this specific problem, a new feature was added to the ASA that will cause connections to be torn down and rebuilt on a new interface if a more preferred route to the destination is added to the routing table. In order to activate the feature (it is disabled by default), set a non-zero timeout to the timeout floating-conn command."
...not the exact same scenario, but I think the same logic applies.
10-05-2022 04:25 AM
Hi
yes, it looks like it solves the problem I have. I will try it. thank you
10-05-2022 07:40 AM
please can you confirm you test this command and work ?
10-05-2022 09:31 PM
Before that command came out I used to add a backup route to null0 and it always did the trick, it's still my preferred way since it completely prevents connections to wrong interfaces to be formed and doesn't add timeouts, as soon as vti interface come up again the new connection get created and start working,
10-22-2022 08:11 AM - edited 10-22-2022 08:13 AM
I configured another VTI with BGP and found another issue. It is ASA<->FTD with 2 uplinks on both sites. There are 2 VTI tunnels. The first is bind to primary link on both ends and the second one to the backup link on both ends. I noticed when primary VTI goes down and then up after few minutes the sh conn shows me that most of the traffic goes still via backup VTI tunnel (everything works but on different tunnel). It works but via VTI 2, not VTI 1. I had to manually clear the connections. timeout floating-conn 0:01:00 is on both ends and routing table is correct - via VTI 1.thank you
10-23-2022 02:39 AM
that Why I ask you before does floating work for you,
anyway check
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide