17.12.3 9130AXI Cleanair Bug

[jasonm002]

Это скорее общественное объявление о 9130AXI на 17.12.3. Я открыл заявку в TAC по этому поводу, но, похоже, что
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwh49406
является симптомом какой-то другой ошибки, связанной с 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 <name> config slot 1» я вижу только сообщение о возникшей неустранимой ошибке датчика cleanair, и в этом выводе фактически рекомендуется перезагрузить AP. AP в этом состоянии также, по-видимому, случайным образом отсоединяются от WLC и снова подключаются к нему. Моя гипотеза заключается в том, что
CSCwh49406
был результатом того, что разработчик ввел некоторую отладку, которая обходила фильтры syslog и была непреднамеренно оставлена в 17.12.2.
CSCwh49406
исправлен в 17.12.3, но проблема с датчиком cleanair, которую они, по-видимому, пытались решить, все еще остается. По-видимому, это также повлияло на версию 17.12.2, но я отключил Cleanair на 2,4 ГГц, когда работал с версией 17.12.2, чтобы обойти
CSCwh49406
. Мое обходное решение для этой проблемы в версии 17.12.3 такое же, как и для
CSCwh49406
: отключить Cleanair на диапазоне 2,4 ГГц глобально («no ap dot11 24ghz cleanair») и перезагрузить/перезапустить затронутые точки доступа. В моем случае я использую версию 17.12.3, чтобы получить возможность использовать WLAN с переходом WPA2+3 на радиочастоте 6 ГГц.

[jasonm002]

Должно быть исправлено в версии 17.9.5 или более поздней, 17.12.5 или более поздней, 17.15.4 или более поздней. Обновитесь до последней версии в рекомендуемом MR-трене, и все должно быть в порядке.

[Leo Laohoo]

Мы тоже столкнулись с этой ошибкой. К счастью, это было здание с 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 часов.

[jasonm002]

Если у вас есть 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.