<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[17.12.3 9130AXI Cleanair Bug]]></title><description><![CDATA[<p dir="auto">Это скорее общественное объявление о 9130AXI на 17.12.3. Я открыл заявку в TAC по этому поводу, но, похоже, что<br />
<a href="https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwh49406" rel="nofollow ugc">https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwh49406</a><br />
является симптомом какой-то другой ошибки, связанной с cleanair на 2,4 ГГц с 9130AXI. В версии 17.12.3 точки доступа 9130AXI (в моем случае, конкретно 9130AXI-B) могут в определенных условиях выдавать сообщение syslog о чрезмерных ошибках cleanair в слоте 0 и отображаться на WLC с включенными, но неработающими датчиками cleanair 2,4 и 5 ГГц (похоже, это также влияет на датчик 5 ГГц, но я вижу только сообщение syslog о слоте 0 на AP). Попытка вручную повторно включить cleanair в диапазоне 5 ГГц в моем случае не сработала, в выводе «show ap &lt;name&gt; config slot 1» я вижу только сообщение о возникшей неустранимой ошибке датчика cleanair, и в этом выводе фактически рекомендуется перезагрузить AP. AP в этом состоянии также, по-видимому, случайным образом отсоединяются от WLC и снова подключаются к нему. Моя гипотеза заключается в том, что<br />
<a href="https://quickview.cloudapps.cisco.com/quickview/bug/CSCwh49406" rel="nofollow ugc">CSCwh49406</a><br />
был результатом того, что разработчик ввел некоторую отладку, которая обходила фильтры syslog и была непреднамеренно оставлена в 17.12.2.<br />
<a href="https://quickview.cloudapps.cisco.com/quickview/bug/CSCwh49406" rel="nofollow ugc">CSCwh49406</a><br />
исправлен в 17.12.3, но проблема с датчиком cleanair, которую они, по-видимому, пытались решить, все еще остается. По-видимому, это также повлияло на версию 17.12.2, но я отключил Cleanair на 2,4 ГГц, когда работал с версией 17.12.2, чтобы обойти<br />
<a href="https://quickview.cloudapps.cisco.com/quickview/bug/CSCwh49406" rel="nofollow ugc">CSCwh49406</a><br />
. Мое обходное решение для этой проблемы в версии 17.12.3 такое же, как и для<br />
<a href="https://quickview.cloudapps.cisco.com/quickview/bug/CSCwh49406" rel="nofollow ugc">CSCwh49406</a><br />
: отключить Cleanair на диапазоне 2,4 ГГц глобально («no ap dot11 24ghz cleanair») и перезагрузить/перезапустить затронутые точки доступа. В моем случае я использую версию 17.12.3, чтобы получить возможность использовать WLAN с переходом WPA2+3 на радиочастоте 6 ГГц.</p>
]]></description><link>https://sla247.ru/forum/topic/2849/17123-9130axi-cleanair-bug</link><generator>RSS for Node</generator><lastBuildDate>Thu, 14 May 2026 22:27:25 GMT</lastBuildDate><atom:link href="https://sla247.ru/forum/topic/2849.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 06 Mar 2026 20:42:23 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 17.12.3 9130AXI Cleanair Bug on Fri, 06 Mar 2026 20:42:26 GMT]]></title><description><![CDATA[<p dir="auto">Если у вас есть 9130s, я бы оставил cleanair отключенным на 2,4 ГГц в 17.12.3, они исправили проблему со спамом в системном журнале, но, по-видимому, не исправили основную проблему с датчиком cleanair, если вы выполните show ap dot11 5ghz cleanair summary | i Down show ap dot11 24ghz cleanair summary | i Down вы можете увидеть 9130s с отключенной функцией Cleanair на любом из диапазонов, и эти точки доступа через некоторое время станут нестабильными. Проблема, по-видимому, возникает в диапазоне 2,4 ГГц, но я заметил, что функция Cleanair отключена и на 5 ГГц на многих точках доступа. Если вы возьмете пакет поддержки с затронутых точек доступа и посмотрите файл сообщений, вы увидите следующее: kernel: [*03/25/2024 16:05:16.1518] CLEANAIR: Чрезмерное количество ошибок на слоте 0. CleanAir отключен до тех пор, пока не будет отключен/включен заново Обходной путь — отключить его глобально на 2,4 ГГц и перезагрузить все затронутые 9130.</p>
]]></description><link>https://sla247.ru/forum/post/20910</link><guid isPermaLink="true">https://sla247.ru/forum/post/20910</guid><dc:creator><![CDATA[jasonm002]]></dc:creator><pubDate>Fri, 06 Mar 2026 20:42:26 GMT</pubDate></item><item><title><![CDATA[Reply to 17.12.3 9130AXI Cleanair Bug on Fri, 06 Mar 2026 20:42:25 GMT]]></title><description><![CDATA[<p dir="auto">Мы тоже столкнулись с этой ошибкой. К счастью, это было здание с 75 точками доступа, и только одна из них создавала проблемы. Эта ошибка открыла целую кучу проблем. Во-первых, одна точка доступа использовала 100 % порта коммутатора (Tx). Затем две камеры видеонаблюдения Avigilon решили присоединиться к этому процессу и «воспроизвели» трансляцию CleanAir, в результате чего мы получили полномасштабную DDoS-атаку. В конце концов, обходной путь не помог, поэтому мы решили рискнуть и обновили наш контроллер до версии 17.12.3. Как только точки доступа загрузились в версии 17.12.3, использование канала связи для всего здания снизилось и нормализовалось. В настоящее время мы оцениваем версию 17.12.3, поскольку эта ошибка появилась только через 36 часов после обновления до версии 17.12.2. Использование канала от проблемной точки доступа сначала выросло до 15 % через 36 часов, затем до 45 % через еще 36 часов (или 72 часа работы), а затем резко выросло до 100 % через еще 36 часов.</p>
]]></description><link>https://sla247.ru/forum/post/20909</link><guid isPermaLink="true">https://sla247.ru/forum/post/20909</guid><dc:creator><![CDATA[Leo Laohoo]]></dc:creator><pubDate>Fri, 06 Mar 2026 20:42:25 GMT</pubDate></item><item><title><![CDATA[Reply to 17.12.3 9130AXI Cleanair Bug on Fri, 06 Mar 2026 20:42:24 GMT]]></title><description><![CDATA[<p dir="auto">Должно быть исправлено в версии 17.9.5 или более поздней, 17.12.5 или более поздней, 17.15.4 или более поздней. Обновитесь до последней версии в рекомендуемом MR-трене, и все должно быть в порядке.</p>
]]></description><link>https://sla247.ru/forum/post/20908</link><guid isPermaLink="true">https://sla247.ru/forum/post/20908</guid><dc:creator><![CDATA[jasonm002]]></dc:creator><pubDate>Fri, 06 Mar 2026 20:42:24 GMT</pubDate></item></channel></rss>