<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Floating connections in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/floating-connections/m-p/3078617#M147110</link>
    <description>&lt;P&gt;Hi all,&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;We have an ASA 5510 with two ISP lines, one for main use, and the other as a backup. Static routes are used where the main line is SLA tracked. When traffic failsover to the backup line, everything works fine. But when the main line becomes active again, everything apart from a UDP SIP connection goes back to the main line.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;I have seen that this is because the connections are not cleared as floating-conn is set to 00:00:00, and the route is not remapped because the connection doesn't recreate.&amp;nbsp;What is the best practice for setting this timeout? Would 1 minute be suitable?&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Many thanks&lt;/P&gt;
&lt;P&gt;Aaron&lt;/P&gt;</description>
    <pubDate>Tue, 12 Mar 2019 08:51:35 GMT</pubDate>
    <dc:creator>aaron.catt1</dc:creator>
    <dc:date>2019-03-12T08:51:35Z</dc:date>
    <item>
      <title>Floating connections</title>
      <link>https://community.cisco.com/t5/network-security/floating-connections/m-p/3078617#M147110</link>
      <description>&lt;P&gt;Hi all,&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;We have an ASA 5510 with two ISP lines, one for main use, and the other as a backup. Static routes are used where the main line is SLA tracked. When traffic failsover to the backup line, everything works fine. But when the main line becomes active again, everything apart from a UDP SIP connection goes back to the main line.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;I have seen that this is because the connections are not cleared as floating-conn is set to 00:00:00, and the route is not remapped because the connection doesn't recreate.&amp;nbsp;What is the best practice for setting this timeout? Would 1 minute be suitable?&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Many thanks&lt;/P&gt;
&lt;P&gt;Aaron&lt;/P&gt;</description>
      <pubDate>Tue, 12 Mar 2019 08:51:35 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/floating-connections/m-p/3078617#M147110</guid>
      <dc:creator>aaron.catt1</dc:creator>
      <dc:date>2019-03-12T08:51:35Z</dc:date>
    </item>
    <item>
      <title>1 minute is suitable for this</title>
      <link>https://community.cisco.com/t5/network-security/floating-connections/m-p/3078618#M147111</link>
      <description>&lt;P&gt;1 minute is suitable for this timer. This is also the value set in this Cisco document that details your exact issue:&lt;/P&gt;
&lt;P&gt;http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113592-udp-traffic-fails-00.html&lt;/P&gt;
&lt;P&gt;You can even set a 30 second timer if faster convergence is required.&lt;/P&gt;</description>
      <pubDate>Tue, 31 Jan 2017 13:02:52 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/floating-connections/m-p/3078618#M147111</guid>
      <dc:creator>Rahul Govindan</dc:creator>
      <dc:date>2017-01-31T13:02:52Z</dc:date>
    </item>
    <item>
      <title>Many thanks, I did see that</title>
      <link>https://community.cisco.com/t5/network-security/floating-connections/m-p/3078619#M147114</link>
      <description>&lt;P&gt;&lt;SPAN&gt;Many thanks, I did see that but on some other forums apparently 1 minute is too low. At least I don't have to manually enter &lt;/SPAN&gt;&lt;EM&gt;clear conn&lt;/EM&gt;&lt;SPAN&gt; now everytime it happens.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 31 Jan 2017 14:14:23 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/floating-connections/m-p/3078619#M147114</guid>
      <dc:creator>aaron.catt1</dc:creator>
      <dc:date>2017-01-31T14:14:23Z</dc:date>
    </item>
  </channel>
</rss>

