синхронизация состояния ISE Posture — отзывы из реального мира

[Ivaylo Georgiev]

Привет всем, Я работаю над развертыванием ISE и рассматриваю возможность включения синхронизации состояния позора в конце развертывания. Из того, что я прочитал об этой функции, она кажется полезной, но у меня есть некоторые опасения по поводу ее использования. Моя главная обеспокоенность связана с нагрузкой, которую это может создать для WLC, когда весь трафик рабочих станций начнет попадать в ACL «posture-compliant» на WLC. Несмотря на простоту этого ACL, каждый пакет будет начинать сопоставляться с строкой «permit ip any any», что заставляет меня задуматься, не перегрузит ли это WLC. Я также обеспокоен тем, что это может усложнить эксплуатацию и, возможно, вызвать путаницу у инженеров, которые будут поддерживать развертывание. Кто-нибудь использовал эту функцию и приносит ли она достаточно преимуществ, чтобы оправдать усилия по ее настройке и управлению?

[Cristian Matei]

Привет, Сначала спросите себя, нужна ли вам эта функция для исправления чего-то или это скорее приятное дополнение? Если вы действительно что-то исправляете, стоит подумать о риске, если нет, я бы пропустил это, так как эта функция была добавлена для исправления определенных сценариев. https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-software/222483-configure-and-troubleshoot-posture-state.html Что касается влияния на инженерную команду, то это не что-то чрезвычайно сложное, а лишь небольшая доработка существующей функциональности, поэтому, как только вы с ней ознакомитесь, это не должно вызвать больших проблем. Что касается влияния на производительность/масштабируемость, здесь в игру вступают аппаратные возможности и программные ошибки. С текущими моделями WLC и Catalyst switch я использую ACL, скажем, в среднем масштабе (15 000+ устройств) без каких-либо проблем, при условии, что для работы выбрано хорошее программное обеспечение. Удачи, Кристиан.

[Leo Laohoo]

@Ivaylo Georgiev
написал:
У вас включена функция «исключение клиентов» в настройках SSID? Думаю, это решит вашу проблему с постоянными сбоями аутентификации. Да и нет. Да, «исключение клиента» настроено, однако оно не является надежным. По истечении времени таймера беспроводной клиент, не прошедший аутентификацию, будет по-прежнему предпринимать попытки. Эти попытки повлияют не только на WLC, но и на ISE. Единственный способ обойти это — вручную настроить исключение беспроводной сети для проблемного MAC-адреса. Подумайте о сфере здравоохранения, где есть сотни IoT (Internet of Trash), вручную настроенных с использованием неверных учетных данных. Еще один момент, который следует серьезно учитывать, — это проводной dot1x. Опять же, проводные клиенты обращаются к коммутатору (для запуска процесса dot1x), который отправляет запрос на сервер ISE (и возвращает ответ). Этот процесс, даже если аутентификация завершается неудачей, имеет «стоимость» и приводит к утечке памяти контрольной плоскости коммутатора, как ничто другое. Вот несколько примеров: ![9800-80: IOS v17.12.3, 3080 APs, <10k daily client count, inter-controller roaming, 12 weeks uptime]
9800-80: IOS v17.12.3, 3080 точек доступа, <10 тыс. клиентов в день, роуминг между контроллерами, время
![9800-80, 17.12.3, 3050 x APs, Uptime: 6 weeks]
работы 12 недель
9800-80, 17.12.3, 3050 точек доступа, время работы: 6
![3850: IOS-XE 16.6.5, uptime 3y39w22h, graph "last 800 days", non-Dot1x, 1 client connected only, 88% memory utilization]
недель3850: IOS-XE 16.6.5, время работы 3 года 39 недель 22 часа, график «последние 800 дней», без Dot1x, подключен только 1 клиент, использова
ние
памяти
![6 x 9300]
88 %
6 x
![6 x 9300, IOS-XE 17.6.4]
9300
6 x 9300, IOS-XE 17.6.4
![LeoLaohoo_0-1678855479738.png]
![Runaway Switch: Data-Plane memory leak, 6 x 9300, IOS-XE 16.6.3, Uptime: 102 days]
Безудержный коммутатор: Утечка памяти в плоскости данных, 6 x 9300, IOS-XE 16.6.3, время работы: 102
дня
![3850 (4 x switches), Firmware version: 16.12.4, Uptime: 1y43w4d]
3850 (4 коммутатора), версия прошивки: 16.12.4, время работы: 1 год 43 недели 4 дня А вот хороший пример: ![12.png] Желтый квадрат означает, что 9800-80 не имел НИ ОДНОГО точки доступа. В марте 2022 года (красный квадрат) мы добавили около 4000 точек доступа к контроллеру. Я оставлю вам возможность сделать собственные выводы.

[Ivaylo Georgiev]

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

[Cristian Matei]

Привет, @Ivaylo Georgiev
Да, я использовал эту функцию, однако в меньшем масштабе, около 500 устройств. С подходящими версиями программного обеспечения на supplicant, NAD и NAS не было никаких проблем, настройка по-прежнему работает. Спасибо, Кристиан.

[Leo Laohoo]

@Ivaylo Georgiev
написал:
Моя главная обеспокоенность связана с нагрузкой, которая может возникнуть на WLC, когда весь трафик рабочих станций начнет попадать в ACL «posture-compliant» на WLC. По моему скромному мнению, я всегда считал, что WLC 9800-40, -80, -M, H1/H2 работает на ошибочной прошивке IOS-XE. Я сформировал это мнение задолго до 2018 года и, по состоянию на декабрь 2025 года, не могу изменить его. Позвольте мне задать следующий вопрос: что происходит, когда проводной или беспроводной клиент
постоянно
не проходит аутентификацию? (Особое внимание на слове «постоянно».) Как эта постоянная (то есть непрерывная) неудачная аутентификация клиента влияет на использование памяти контрольной плоскости WLC или коммутатора (в сценарии dot1x)? У меня есть несколько автономных WLC 9800-80 с менее чем 10 тысячами клиентов в день и нагрузкой AP менее 50 % (на каждый контроллер), и постоянная неудачная аутентификация клиентов может вывести WLC или коммутатор (сценарий dot1x) из строя. Мне приходится перезагружать наши контроллеры каждые 4–6 месяцев (каждые 3–4 месяца для коммутаторов). В настоящее время у меня есть случай TAC под названием «Призрачные порты», и сценарий выглядит следующим образом: Стек 9300 (2 коммутатора в стеке), прошивка с портом, постоянно/непрерывно сообщающим об ошибке TStart: %ILPOWER-5-IEEE_DISCONNECT: Интерфейс <PORT>: PD
удален%ILPOWER-3-CONTROLLER_PORT_ERR: Ошибка порта контроллера, интерфейс
<PORT>
: Контроллер питания сообщает об обнаружении ошибки Tstart питания Прошивка 17.9.3, время работы коммутатора — 2 года и 14 недель. И вот что самое интересное: к указанному порту ничего не подключено. Под «ничего» я имею в виду, что к порту не подключен ни один кабель. Порт не используется более 2 лет и 9 недель. И это не первый раз, когда я сталкиваюсь с такой ситуацией. Помимо этого случая, в ноябре 2025 года мне лично пришлось перезагрузить два стека 9300, потому что они делали точно то же самое (вместо ошибки Tstart порты постоянно отключались/включались). Я наблюдал такое поведение много раз, особенно с версии 16.3.X, и никогда не видел ничего подобного с классической версией IOS и IOS-XE версии 3.X.X.

[Ivaylo Georgiev]

У вас включена функция «исключение клиента» в настройках SSID? Думаю, это решит вашу проблему с постоянными сбоями аутентификации.

[Ivaylo Georgiev]

Я думаю, что он готовится к взлету. Спасибо, что поделились всеми этими подробностями — очень полезная дополнительная информация.

[Leo Laohoo]

С 2018 года я внимательно слежу за использованием памяти контрольной плоскости. Перезагружая маршрутизаторы IOS-XE, стеки коммутаторов (автономные коммутаторы не затронуты в такой степени) и WLC всякий раз, когда использование памяти контрольной плоскости достигает определенного порога в 85%, я сумел предотвратить сбой, который нанес бы ущерб и стал бы причиной позора для нашей организации. Я также продемонстрировал нашим внутренним критикам, когда они отказались позволить мне вмешаться: это было не самое приятное зрелище, когда коммутатор, маршрутизатор или WLC выходили из строя, а затем приходилось проводить процесс восстановления и анализ первопричин инцидента (RCA). За последние 6 месяцев появилось много идентификаторов ошибок, в которых сбои маршрутизаторов, стеков коммутаторов и/или WLC объясняются утечками памяти в плоскости управления, которые не контролируются должным образом ни одной системой управления сетью (включая DNAC). Утечка памяти в плоскости управления — это реальность. Это единственная вещь, которая не дает мне спать по ночам, заставляя кричать и плакать.