<?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 Access point abnormal behaviours  during a fallback in Wireless</title>
    <link>https://community.cisco.com/t5/wireless/access-point-abnormal-behaviours-during-a-fallback/m-p/3674608#M207536</link>
    <description>&lt;P&gt;Hi All,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I have access points in 2 sites&amp;nbsp; that are joining a regional primary controller and each ap is a member of a certain ap group&amp;nbsp;&lt;/P&gt;
&lt;P&gt;we configured a secondary controller to those APs that is located in another physical location "not in HA pair"&amp;nbsp; and we tried to simulate the failover scenario where the APs will fall over and fall back normally&amp;nbsp;&lt;/P&gt;
&lt;P&gt;when we disable the primary controller, all the APs were switched to the backup one but unfortunately the SSIDs was mapped to different VLAN numbers so it didn't work&amp;nbsp; so directly we roll back so all APs could join the primary WLC&amp;nbsp; again till fixing the configuration on the secondary WLC&lt;/P&gt;
&lt;P&gt;but was weird&amp;nbsp;that even when they&amp;nbsp;were back to their primary controller&amp;nbsp; ALL APs joined normally&amp;nbsp; but some abnormal behaviors happen&amp;nbsp;as&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Site-1: users can't obtain IP add and after a lot of troubleshooting&amp;nbsp; we rebooted the APs and it works fine&amp;nbsp;&lt;/P&gt;
&lt;P&gt;site-2: APs joined the primary WLC&amp;nbsp; but in&amp;nbsp;undesired AP groups, so moving them to their desired AP groups makes the APs reboot as well and the problem was solved&amp;nbsp;&lt;/P&gt;
&lt;P&gt;so it was clear that AP reboot in all cases solves the problem&lt;/P&gt;
&lt;P&gt;Is there any justification for these behaviors when APs reverted back to their original controller?&amp;nbsp; when the AP joined another controller with different configuration parameters like the VLAN number than the initial one, it should get the new configuration or it keeps caching the old one?&lt;/P&gt;
&lt;P&gt;Are there any additional actions I could take care of?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Note: both WLC are with the same software version and no flex connect groups are created&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Mon, 05 Jul 2021 15:53:45 GMT</pubDate>
    <dc:creator>mina_raouf</dc:creator>
    <dc:date>2021-07-05T15:53:45Z</dc:date>
    <item>
      <title>Access point abnormal behaviours  during a fallback</title>
      <link>https://community.cisco.com/t5/wireless/access-point-abnormal-behaviours-during-a-fallback/m-p/3674608#M207536</link>
      <description>&lt;P&gt;Hi All,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I have access points in 2 sites&amp;nbsp; that are joining a regional primary controller and each ap is a member of a certain ap group&amp;nbsp;&lt;/P&gt;
&lt;P&gt;we configured a secondary controller to those APs that is located in another physical location "not in HA pair"&amp;nbsp; and we tried to simulate the failover scenario where the APs will fall over and fall back normally&amp;nbsp;&lt;/P&gt;
&lt;P&gt;when we disable the primary controller, all the APs were switched to the backup one but unfortunately the SSIDs was mapped to different VLAN numbers so it didn't work&amp;nbsp; so directly we roll back so all APs could join the primary WLC&amp;nbsp; again till fixing the configuration on the secondary WLC&lt;/P&gt;
&lt;P&gt;but was weird&amp;nbsp;that even when they&amp;nbsp;were back to their primary controller&amp;nbsp; ALL APs joined normally&amp;nbsp; but some abnormal behaviors happen&amp;nbsp;as&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Site-1: users can't obtain IP add and after a lot of troubleshooting&amp;nbsp; we rebooted the APs and it works fine&amp;nbsp;&lt;/P&gt;
&lt;P&gt;site-2: APs joined the primary WLC&amp;nbsp; but in&amp;nbsp;undesired AP groups, so moving them to their desired AP groups makes the APs reboot as well and the problem was solved&amp;nbsp;&lt;/P&gt;
&lt;P&gt;so it was clear that AP reboot in all cases solves the problem&lt;/P&gt;
&lt;P&gt;Is there any justification for these behaviors when APs reverted back to their original controller?&amp;nbsp; when the AP joined another controller with different configuration parameters like the VLAN number than the initial one, it should get the new configuration or it keeps caching the old one?&lt;/P&gt;
&lt;P&gt;Are there any additional actions I could take care of?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Note: both WLC are with the same software version and no flex connect groups are created&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 05 Jul 2021 15:53:45 GMT</pubDate>
      <guid>https://community.cisco.com/t5/wireless/access-point-abnormal-behaviours-during-a-fallback/m-p/3674608#M207536</guid>
      <dc:creator>mina_raouf</dc:creator>
      <dc:date>2021-07-05T15:53:45Z</dc:date>
    </item>
    <item>
      <title>Re: Access point abnormal behaviours  during a fallback</title>
      <link>https://community.cisco.com/t5/wireless/access-point-abnormal-behaviours-during-a-fallback/m-p/3674739#M207537</link>
      <description>&lt;P&gt;Hi&lt;/P&gt;
&lt;P&gt;&amp;nbsp;I had a similar issue in the past. There was a bug on the WLC version but it was 7.x , probably newer version does not have anymore.&lt;/P&gt;
&lt;P&gt;&amp;nbsp; What you should do is configure the vlan mapping per group and not per AP. Check the option "Override VLAN on AP".&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;-If I helped you somehow, please, rate it as useful.-&lt;/P&gt;</description>
      <pubDate>Wed, 25 Jul 2018 19:53:31 GMT</pubDate>
      <guid>https://community.cisco.com/t5/wireless/access-point-abnormal-behaviours-during-a-fallback/m-p/3674739#M207537</guid>
      <dc:creator>Flavio Miranda</dc:creator>
      <dc:date>2018-07-25T19:53:31Z</dc:date>
    </item>
  </channel>
</rss>

