медленная вывод команды show в 9800 CLI/SSH wireless

[jasonm002]

Есть 1000 точек доступа на 66 тегах сайта, они настроены так, что тег сайта используется для набора точек доступа, принадлежащих каждому зданию. У меня также есть 9800-80, на который мы сейчас переходим, с 8 тегами сайта, 132 точками доступа и 302 клиентами (на данный момент). Если я выполняю команду «term len 0» на этом устройстве и «show wireless client summary», то для вывода списка из 302 клиентов требуется около 4 секунд. На AireOS это заняло бы около 100 мс. Это скорее раздражает, чем мешает, поэтому я и написал об этом здесь. Я не против просто подождать, пока в следующих версиях IOS XE это исправят.

[Mark Elsen]

• Не забудьте использовать WirelessAnalyzer (как я указал в своем первоначальном ответе) ,
  он
  очень
  информативен М. -- Пусть все происходит с вами
  Красота и ужас
  Просто продолжайте идти
  Ни одно чувство не является окончательным
  Райнер Мария Рильке
  (1899)

[Scott Fella]

Если это проблема, а другие ее не видят, вам следует открыть заявку в службу технической поддержки. Я не думаю, что в будущих версиях ваша проблема будет устранена, если она не будет зарегистрирована как проблема/ошибка. Возможно, причиной этого является что-то другое. -Скотт***
Пожалуйста, оцените полезные сообщения ***

[Rich R]

9800-80 с 861 точкой доступа и 1573 клиентами — только что протестировано:
точки доступа около 9-10 секунд,
клиенты около 6 секунд.
Согласен, что это может быть немного медленнее, чем AireOS, но для нас это не проблема
. Стоит проверить, правильно ли настроен TCP в IOS? Что будет работать лучше всего, зависит от вашей среды, но посмотрите ip tcp mss <> — размер, чтобы гарантировать, что фрагментация не потребуется, ip tcp selective-ack, ip tcp window-size 65535 и ip ssh window-size 65535. Обратите внимание, что, похоже, есть ошибка при загрузке больших файлов с помощью scp с устройства, которая зависает на 99%, когда окно составляет 65535 — в этом случае помогает уменьшение до 32768. Я так и не успел протестировать точку останова или открыть заявку в TAC по этому поводу. Однако это не влияет на загрузку файлов на устройство. ------------------------------
Пожалуйста, нажмите
«Полезно»,
если этот пост был вам полезен, и
«Принять как решение»
(выпадающее меню в правом верхнем углу этого ответа), если он ответил на ваш вопрос.

Коды,
рекомендованные TAC для AireOS WLC
и
Коды, рекомендованные TAC для 9800 WLC
Лучшие практики для AireOS WLC
,
Рекомендуемые методы для 9800 WLC
и
Матрица совместимости Cisco
Wireless
Проверьте конфигурацию 9800 WLC с помощью
Wireless Config Analyzer,
используя вывод «show tech
wireless
» или «config paging disable», а затем вывод «show run-config» на AireOS, и используйте
Wireless Debug Analyzer
для анализа отладки клиента WLC
.
Уведомление: FN63942 Точки доступа и WLC не могут создать соединения CAPWAP из-за истечения срока
действия сертификата
. Уведомление: FN72424 Поздние версии точек доступа WiFi 6 не могут подключиться к WLC — требуется обновление
программного обеспечения
. Уведомление: FN72524 Точки доступа IOS застревают в состоянии загрузки после 4 декабря 2022 г. из-за истечения
срока
https://www.cisco.com/c/en/us/support/docs/field-notices/725/fn72524.html
действия
сертификата
— исправлено в 8.10.196.0, последних версиях 9800,
8.5.182.12
(8.5.182.13 для 3504) и
8.5.182.109
(IRCM, 8.5.182.111 для 3504)
Уведомление: FN70479 Точка доступа не подключается или подключается с одним радиомодулем из-за несовместимости стран, требуется RMA
Как избежать цикла перезагрузки из-за поврежденного образа на точках доступа Wave 2 и Catalyst 11ax (CSCvx32806)
Уведомление: FN74035 - Точки доступа Wave2 DFS могут не обнаруживать Radar после проверки доступности канала
Список
[ошибок]
[Leo]
,
[влияющих на точки доступа]
[2800/3800/4800/1560]
Стандартная скорость передачи данных консоли точки доступа с версии 17.12.x составляет 115200
— введено
CSCwe88390

[jasonm002]

Я думаю, что вы действительно воспроизвели проблему, если тестировали с помощью команд «show ap summary» и «show wireless client summary». Наши результаты почти совпадают, если смотреть на соотношение времени вывода/точка доступа или времени вывода/клиент при использовании этих команд. Я только что проверил еще раз, и вывод команды «show ap summary» составляет ~14 секунд для 999 точек доступа, а вывод команды «show wireless client summary» составляет ~18 секунд для 4086 клиентов. Время ~40 секунд, которое я указал выше, было для команды «show wireless client summary detail», и действительно, если я запускаю эту команду на моем WLC с текущим количеством клиентов ~4086, она занимает ~65 секунд. «show ap dot11 5ghz summary» для 999 точек доступа занимает у меня ~27 секунд. Все выводы SSH, не связанные с беспроводной связью, с WLC не затронуты. Проблема, по-видимому, заключается в производительности WLC, особенно с учетом того, что команды wireless show, которые возвращают больше данных, занимают гораздо больше времени для того же количества точек доступа и клиентов.

[jasonm002]

Эта проблема по-прежнему актуальна в версии 17.9.3, и чем больше клиентов и точек доступа на WLC, тем она усугубляется. Точки доступа довольно хорошо распределяют нагрузку между wncds. Использование ЦП на wncds низкое — около 12 % на самом высоком wncd за 1 минуту. Отображение сводки по беспроводным клиентам занимает около 1 минуты 22 секунд для 5824 клиентов, а отображение сводки по точкам доступа занимает около 31 секунды для 1439 точек доступа. Сам вывод SSH работает нормально, я могу, например, засыпать команды show config, и это не вызывает задержки вывода — похоже, что это какая-то проблема с медленным запросом к базе данных или медленным IPC, возможно, на SSH, но я не уверен. В любом случае, команды, которые извлекают больше данных из бэкэнда (бэкэндов), работают медленнее, поэтому замедление, по-видимому, связано с объемом данных, которые вы запрашиваете. К сожалению, TAC в последнее время для меня практически бесполезен. Раньше (примерно в 2016-2018 годах) они действительно расследовали проблемы и подавали отчеты об ошибках, но те дни, похоже, прошли, за исключением, возможно, высокопоставленных/очень важных клиентов. Я не отношусь к их числу, поэтому для меня TAC — не более чем престижный механизм RMA.

[Mark Elsen]

• Возможно, это связано с более общей проблемой, касающейся доступных ресурсов , для изучения которой может быть полезна следующая группа команд:
  show platform resources
  show processes cpu platform sorted | ex 0% 0% 0%
  show processes memory platform sorted
  show processes memory platform accounting
  show int po1 | i line protocol|put rate|drops|broadcast (Проверьте объем трафика, полученного и переданного WLC, например)
  показать статистику активных пакетов qfp аппаратного шасси платформы (проверить на наличие пропущенных пакетов)
  показать статистику функции беспроводной передачи активных пакетов qfp аппаратного шасси платформы (Проверьте наличие пакетов, отправленных на CPU)
  show buffers | i buffers|failures (Проверьте наличие сбоев буфера)
  show platform hardware chassis active qfp datapath utilization | i Load
  ((Проверьте нагрузку на процессор (pct) ниже, чтобы увидеть загрузку, которая не должна превышать 92 %)

....
TAC — это не что иное, как усовершенствованный механизм RMA
.
Вот почему мы здесь (ЛОЛ!) М. -- Пусть все происходит с вами
Красота и ужас
Просто продолжайте идти
Ни одно чувство не является окончательным
Райнер Мария Рильке
(1899)

[jasonm002]

Это 9800-80, все показатели значительно ниже предельных значений, включая загрузку процессора wncd и общую загрузку процессора. Загрузка QFP составляет 2% в течение 1 минуты и 60 минут. На уровне портов передней панели/PHY не наблюдается никаких падений. 17 сентября 2022 года Рич Р. отметил выше «9800-80 с 861 точкой доступа и 1573 клиентами — только что протестировано:
точки доступа около 9-10 секунд,
клиенты около 6 секунд». Предполагая, что это было только для «show ap summary» и «show wireless client summary» (что, как я полагаю, требует извлечения меньшего количества данных из wncds), для него это заняло 0,011 секунды на точку доступа для «show ap summary» и 0,003 секунды на клиента. Если я повторю тест со своими значениями, то получу 20,00 сек/1439 точек доступа = 0,013 сек на точку доступа и 29,72 сек/7477 клиентов = 0,003 сек на клиента. Значения очень близки, поэтому, похоже, у нас обоих происходит одна и та же проблема, но она больше влияет на меня, потому что у меня больше точек доступа и больше клиентов. Кроме того, вывод команд, которые возвращают больше данных из базовых баз данных, таких как «show ap dot11 5ghz summary» и «show wireless client summary detail», занимает гораздо больше времени на вывод каждой строки, чем более простые команды. Мне кажется, что это проблема производительности базы данных/IPC.

[Scott Fella]

Буду честен, у меня вообще нет особых проблем с TAC. Если я не могу продвинуться в деле, которое у меня есть, потому что оно не очевидно, я обычно эскалирую его, чтобы BE помогло. Судя по тому, что вы видите, TAC необходимо собрать данные, чтобы эскалировать/получить поддержку от BE. -Скотт***
Пожалуйста, оцените полезные сообщения ***

[jasonm002]

Раньше TAC мог внутренне проверять, соответствует ли поведение ожидаемому, и в случае несоответствия подавать отчеты об ошибках, но, насколько я могу судить, теперь эта функция утрачена. Например, у меня был еще один случай, когда клиентский RA-трасс показывал, что клиент был удален за кражу IP-адреса, хотя мы отключили кражу IP-адресов как причину исключения на WLC. Насколько я могу судить, это довольно очевидная ошибка, но TAC оказался совершенно неэффективным, даже после того, как ему был показан RA-трасс, на котором это происходило, и конфигурация WLC с отключенной кражей IP-адресов как условием исключения. Что произошло: телефон Android, пользователь отключил рандомизацию MAC, повторно подключился и был исключен за кражу IP, потому что телефон сохранил тот же IPv6-адрес локальной сети. У меня настроено «no wireless wps client-exclusion ip-theft», но WLC все равно удаляет IPv6-воров, несмотря на это. Я бы предпочел просто использовать dhcp-required и IPSG для решения этой проблемы, вместо того чтобы исключать клиентов, потому что даже с коротким таймером некоторые клиенты плохо справляются с деавторизацией и переключаются на мобильные данные. Дело все еще открыто, потому что технически это все еще проблема, но она настолько редка, что и TAC, и я уже отказались от ее решения. Вероятно, эта проблема гораздо чаще встречается в средах, которые заставляют пользователей отключать рандомизированный MAC — мы этого не делаем, но один пользователь случайно это сделал и заявил, что это не работает, и так я обнаружил эту проблему. Предполагаю, что многие службы поддержки просто посоветовали бы людям перезагрузить компьютер и надеяться, что к тому времени таймер исключения истечет.
![:winking_face:]

[Mark Elsen]

• Возможно, это имеет отношение к данному вопросу:
  https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwc31406 М. -- Пусть все происходит с тобой
  Красота и ужас
  Просто продолжай идти
  Ни одно чувство не является окончательным
  Райнер Мария Рильке
  (1899)

[jasonm002]

Я видел это, но эта ошибка, скорее всего, связана с ситуацией, когда у вас включено исключение кражи IP-адресов, но оно не работает так, как должно. В моем случае я отключил эту функцию, но, по-видимому, она отключена только для IPv4, а устройства IPv6 по-прежнему приводят к удалению клиентов. В любом случае, я, по-видимому, отклонился от темы этой ветки, извините.