<?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 Re: Channel bonding : strange behavior in Wireless</title>
    <link>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478573#M294494</link>
    <description>&lt;P&gt;You definitely shouldn’t be bonding over channel 64/100… &lt;/P&gt;&lt;P&gt;I’m conflicted over primary/secondary - I can see an argument for both ways. My personal view has been that if you get enough traffic for it to become an issue you should be using 20 MHz wide channels any way. &lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;In 6 GHz they better not mix the primary channels up… that will irk me!&lt;/P&gt;</description>
    <pubDate>Mon, 18 Dec 2023 21:04:46 GMT</pubDate>
    <dc:creator>danjns</dc:creator>
    <dc:date>2023-12-18T21:04:46Z</dc:date>
    <item>
      <title>Channel bonding : strange behavior</title>
      <link>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478570#M294491</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;when I was playing with the new AP Neighbor option I saw that AutoRF makes strange choices when it comes to channel planning:&lt;/P&gt;&lt;P&gt;We're mostly using 40Mhz channels on 5Ghz and what I see is:&lt;/P&gt;&lt;P&gt;- Some channels have the lower channel as primary channel, others have the upper channel as primary&lt;/P&gt;&lt;P&gt;- AutoRF does not avoid overlap : I see often secondary channels overlapping due to this&lt;/P&gt;&lt;P&gt;- AutoRF thinks that Channel 64/100 is also a perfect pair (have never seen this before with other vendors).&lt;/P&gt;&lt;P&gt;Although this might technically all work fine (have had no complaints) but I'd like to see a bit more predictability (&lt;/P&gt;&lt;P&gt;In critical environments I opt for a static channel plan) : so no overlap and being able what to use as primary channel.&lt;/P&gt;&lt;P&gt;&lt;SPAN class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="MarcelTempelman_0-1702889933563.png" style="width: 400px;"&gt;&lt;span class="lia-inline-image-display-wrapper" image-alt="image.png"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/272948i3DF24910BB3BF77C/image-size/large?v=v2&amp;amp;px=999" role="button" title="image.png" alt="image.png" /&gt;&lt;/span&gt;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 18 Dec 2023 08:56:44 GMT</pubDate>
      <guid>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478570#M294491</guid>
      <dc:creator>Marcel Tempelman</dc:creator>
      <dc:date>2023-12-18T08:56:44Z</dc:date>
    </item>
    <item>
      <title>Re: Channel bonding : strange behavior</title>
      <link>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478571#M294492</link>
      <description>&lt;P&gt;I have a similar odd choice for an 80MHz channel:&lt;/P&gt;&lt;P&gt;&lt;SPAN class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="cmr_0-1702915988518.png" style="width: 400px;"&gt;&lt;span class="lia-inline-image-display-wrapper" image-alt="image.png"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/272950i83A1DD439476C039/image-size/large?v=v2&amp;amp;px=999" role="button" title="image.png" alt="image.png" /&gt;&lt;/span&gt;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 18 Dec 2023 16:13:20 GMT</pubDate>
      <guid>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478571#M294492</guid>
      <dc:creator>CMR</dc:creator>
      <dc:date>2023-12-18T16:13:20Z</dc:date>
    </item>
    <item>
      <title>Re: Channel bonding : strange behavior</title>
      <link>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478572#M294493</link>
      <description>&lt;P&gt;Ouch that does not seem to be a good behavior for the algorithm ;).&lt;BR /&gt;It is imperative that you don't mix your primary channels since that will cause alot of collisions.  Usually I keep the primary channel as the lowest one.&lt;/P&gt;</description>
      <pubDate>Mon, 18 Dec 2023 19:51:03 GMT</pubDate>
      <guid>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478572#M294493</guid>
      <dc:creator>joey.debra</dc:creator>
      <dc:date>2023-12-18T19:51:03Z</dc:date>
    </item>
    <item>
      <title>Re: Channel bonding : strange behavior</title>
      <link>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478573#M294494</link>
      <description>&lt;P&gt;You definitely shouldn’t be bonding over channel 64/100… &lt;/P&gt;&lt;P&gt;I’m conflicted over primary/secondary - I can see an argument for both ways. My personal view has been that if you get enough traffic for it to become an issue you should be using 20 MHz wide channels any way. &lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;In 6 GHz they better not mix the primary channels up… that will irk me!&lt;/P&gt;</description>
      <pubDate>Mon, 18 Dec 2023 21:04:46 GMT</pubDate>
      <guid>https://community.cisco.com/t5/wireless/channel-bonding-strange-behavior/m-p/5478573#M294494</guid>
      <dc:creator>danjns</dc:creator>
      <dc:date>2023-12-18T21:04:46Z</dc:date>
    </item>
  </channel>
</rss>

