<?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 Policy issue with 31.7.2.28-patch1-8? in ExtremeSwitching (EXOS/Switch Engine)</title>
    <link>https://community.extremenetworks.com/t5/extremeswitching-exos-switch/policy-issue-with-31-7-2-28-patch1-8/m-p/99707#M22418</link>
    <description>&lt;P&gt;x460-G2 stack version&amp;nbsp;31.7.2.28-patch1-8&lt;/P&gt;&lt;P&gt;Tricky issue to describe:&amp;nbsp; We have two internet connections and use a policy file to route traffic (based on layer 3 VLAN) to the connections for balancing.&amp;nbsp; There are small twice daily updates to the policy file for 'bed time rules'.&amp;nbsp; Occasionally we need to make significant policy changes, like for maintenance or if one internet connection is faulty.&amp;nbsp; For the second time since this FW (applied June 2023), after a major policy file switch, the whole stack gets flakey.&amp;nbsp; It's like all traffic starts going to the default route instead of the proper local VLAN, which we can see using traceroutes.&amp;nbsp; We can't even access the stack via network and have to console in.&amp;nbsp; We have to do a soft reboot of the stack.&amp;nbsp; After the reboot everything is fine, so we know the policy file is OK.&lt;/P&gt;&lt;P&gt;Assuming the switch config is OK and the policy file is OK (since everything is good after reboot), what could be happening?&amp;nbsp; Is there something more I can check while the issue is occuring?&amp;nbsp; Are there proper commands to run while applying the policy file (we just do a check policy then refresh policy after replacing the file)?&amp;nbsp; Is there a 'flush' option?&amp;nbsp; Is there an issue with this firmware?&lt;/P&gt;&lt;P&gt;This is production so it's extremely difficult to test (pun intended) and our window for FW updates is limited unless we have good reason to believe there would be a fix.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Tue, 19 Mar 2024 17:27:36 GMT</pubDate>
    <dc:creator>NetGuy</dc:creator>
    <dc:date>2024-03-19T17:27:36Z</dc:date>
    <item>
      <title>Policy issue with 31.7.2.28-patch1-8?</title>
      <link>https://community.extremenetworks.com/t5/extremeswitching-exos-switch/policy-issue-with-31-7-2-28-patch1-8/m-p/99707#M22418</link>
      <description>&lt;P&gt;x460-G2 stack version&amp;nbsp;31.7.2.28-patch1-8&lt;/P&gt;&lt;P&gt;Tricky issue to describe:&amp;nbsp; We have two internet connections and use a policy file to route traffic (based on layer 3 VLAN) to the connections for balancing.&amp;nbsp; There are small twice daily updates to the policy file for 'bed time rules'.&amp;nbsp; Occasionally we need to make significant policy changes, like for maintenance or if one internet connection is faulty.&amp;nbsp; For the second time since this FW (applied June 2023), after a major policy file switch, the whole stack gets flakey.&amp;nbsp; It's like all traffic starts going to the default route instead of the proper local VLAN, which we can see using traceroutes.&amp;nbsp; We can't even access the stack via network and have to console in.&amp;nbsp; We have to do a soft reboot of the stack.&amp;nbsp; After the reboot everything is fine, so we know the policy file is OK.&lt;/P&gt;&lt;P&gt;Assuming the switch config is OK and the policy file is OK (since everything is good after reboot), what could be happening?&amp;nbsp; Is there something more I can check while the issue is occuring?&amp;nbsp; Are there proper commands to run while applying the policy file (we just do a check policy then refresh policy after replacing the file)?&amp;nbsp; Is there a 'flush' option?&amp;nbsp; Is there an issue with this firmware?&lt;/P&gt;&lt;P&gt;This is production so it's extremely difficult to test (pun intended) and our window for FW updates is limited unless we have good reason to believe there would be a fix.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 19 Mar 2024 17:27:36 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremeswitching-exos-switch/policy-issue-with-31-7-2-28-patch1-8/m-p/99707#M22418</guid>
      <dc:creator>NetGuy</dc:creator>
      <dc:date>2024-03-19T17:27:36Z</dc:date>
    </item>
    <item>
      <title>Re: Policy issue with 31.7.2.28-patch1-8?</title>
      <link>https://community.extremenetworks.com/t5/extremeswitching-exos-switch/policy-issue-with-31-7-2-28-patch1-8/m-p/99735#M22421</link>
      <description>&lt;P&gt;Without more information my guess is that changing the routes in the hardware tables goes wrong or takes a long time. During that time traffic is send to the CPU for forwarding instead of through hardware and is causing the CPU to become too busy.&lt;/P&gt;&lt;P&gt;Another issue could be a long install of the policy, do you use refresh policy or uninstall/install ? Refresh policy can take significantly longer time than unconfigure access-list and configure the same ACL again.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 21 Mar 2024 12:51:19 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremeswitching-exos-switch/policy-issue-with-31-7-2-28-patch1-8/m-p/99735#M22421</guid>
      <dc:creator>OscarK</dc:creator>
      <dc:date>2024-03-21T12:51:19Z</dc:date>
    </item>
  </channel>
</rss>

