ISE 3.4 на SNS3615

[tachyon05]

Кто-нибудь имеет опыт работы с ISE 3.4 на SNS3615? У меня ISE 3.2 работает в средней конфигурации с 2 административными узлами и 4 PSN на SNS3615. Могу ли я перейти на ISE 3.4? Будут ли проблемы с производительностью на SNS3615?

[Arne Bier]

Привет
[, @tachyon05] Краткий ответ — нет. Но
SNS-36x5 поддерживает ISE 3.4
, а также поддерживается путь обновления с 3.2 до 3.4. По моему опыту, устройства SNS работают очень медленно, потому что в старых поколениях используются вращающиеся диски. Ситуация изменилась с появлением серии SNS-38x5, в которой используются SSD. Я думаю, что самая большая проблема с меньшими серверами SNS заключается в том, что у них только один диск, и ввод-вывод всегда является узким местом. В любом случае, производительность — это очень субъективная вещь. Вы можете сделать несколько вещей, чтобы попытаться уменьшить нагрузку на ваши узлы в целом: Отключите все ненужные службы
Если профилирование включено, включите только те зонды, которые вам нужны
Если профилирование включено, удалите ненужные логические профили (предоставленные Cisco).
Сделайте набор политик максимально эффективным, думая как программист — не повторяйте бесполезные тесты, не просматривайте все хранилища идентификационных данных, если знаете, что идентификационные данные можно найти только в определенных местах (например, AD). Упорядочите наборы политик и правила AuthN и AuthZ по количеству обращений, чтобы быстрее запускать сопоставление (не нарушая логику набора политик... Логика всегда на первом месте, а затем идет настройка производительности)
Настройте сеть так, чтобы отправлять промежуточные обновления учета только при необходимости — например, максимум раз в 48 часов.
В беспроводных сетях используйте оптимизацию роуминга, чтобы по возможности избежать повторяющихся 802.1X, а затем другие приемы, такие как возобновление сеанса, чтобы сократить количество TLS-транзакций.
Распределите нагрузку ваших запросов RADIUS, чтобы обеспечить равномерную загрузку всех PSN — всегда можно использовать ручное распределение нагрузки (назначение PSN по определенным вами правилам) или распределение нагрузки IOS (или использовать соответствующий балансировщик нагрузки) — распределение нагрузки имеет смысл для приложений с высокой нагрузкой, где дисбаланс приведет к простоям одного PSN, в то время как другой будет перегружен и будет медленно отвечать NAD — руководствуйтесь своим суждением. Балансировка нагрузки IOS RADIUS — отличный вариант для Catalyst, но убедитесь, что PSN, которые вы указываете, имеют одинаковое RTT от NAD (не указывайте PSN, доступные через более медленную WAN). Настройка узла ISE может быть очень полезной. Но если вы можете создать ISE в виде виртуальной машины на месте, вы с большей вероятностью получите лучшую производительность, поскольку в настоящее время большинство ферм виртуальных машин работают на SSD и имеют лучший процессор. Не забудьте также проверить обновления CIMC/BIOS для вашей модели оборудования — используйте только прошивку, найденную в загрузке программного обеспечения ISE — никогда не используйте общую прошивку UCS!

[uRLKuzE]

Недавно я без проблем обновил небольшую установку из двух SNS3615 с версии 3.1 до 3.4 P3, но это небольшая установка с разумным количеством аутентификаций. Поэтому я не могу говорить о производительности в средней установке, такой как ваша.