- PVSM.RU - https://www.pvsm.ru -
Основная страница мониторинга.
SD-Access — это реализация нового подхода к строительству локальных сетей от Cisco. Сетевые устройства объединяются в фабрику, поверх неё строится оверлей, и всем этим управляет центральный компонент — DNA Center. Выросло всё это из систем мониторинга сети, только теперь мутировавшая система мониторинга не просто мониторит, но собирает подробную телеметрию, конфигурирует всю сеть как единое устройство, находит в ней проблемы, предлагает их решения и вдобавок энфорсит политики безопасности.
Забегая вперёд, скажу, что решение довольно громоздкое и на данный момент нетривиальное в плане освоения, но чем больше сеть и чем важнее безопасность, тем выгоднее на него переходить: серьёзно упрощает управление и траблшутинг.
Заказчик переезжал в новый свежекупленный офис из арендуемого. Локальную сеть планировали сделать по традиционной схеме: коммутаторы ядра, коммутаторы доступа плюс какой-нибудь привычный мониторинг. В это время мы как раз развернули стенд с SD-Access в нашей лаборатории и успели немного пощупать решение и пройти обучение с очень кстати посетившим Москву экспертом из французского офиса Cisco.
Пообщавшись с вендором, и мы, и заказчик решились-таки строить сеть по-новому. Увидели вот такие преимущества:
Недостатки мы увидели уже потом.
Прикинули верхнеуровневый дизайн. Планируемая архитектура стала выглядеть так:
Внизу под этим — underlay, построенный на привычных протоколах (основа — IS-IS), но идея решения такова, что тонкости его работы нас интересовать не должны. Overlay выполнен на LISP и VXLAN. Логикой решения предполагается предпочтительное использование 802.1x-авторизации на портах доступа. Впрочем, заказчик предполагал использовать её в обязательном порядке для всех изначально. Можно обойтись и без 802.1x и настраивать сеть почти «по старинке», тогда нужно настраивать пулы IP-адресов вручную, а потом опять же руками на каждом порту прописывать, к какому IP-пулу он принадлежит, причём сделать Copy-Paste, как раньше в командной строке, не получится, всё только через веб. При таком подходе плюсы решения превращаются в жирный минус. Такую схему можно применять только там, где это неизбежно, но не на всей сети. Применение прав доступа обеспечивается за счёт SGT-меток.
Заказали оборудование и софт, а пока всё ехало, стали «приземлять» дизайн, чтобы понять, что будем настраивать. Тут и столкнулись с первой сложностью: если раньше с заказчиком нужно было согласовать IP-подсети и набор номеров VLAN так, чтобы это встраивалось в принятые у него схемы, то теперь всё это нас не интересовало: нужно было понять, какие группы пользователей и устройств пользуются сетью, как взаимодействуют между собой и какими сетевыми сервисами пользуются. Непривычно и для нас, и для заказчика. Получить подобную информацию оказалось сложнее. На первый взгляд, именно от таких данных нужно было отталкиваться при проектировании сетей всегда, но на практике почти всегда закладывался стандартный набор VLAN, а потом реальность впихивалась в него в ходе эксплуатации мозолистыми руками админов. В парадигме SD-Access выбора нет: сеть строится «под бизнес».
Сроки сжимались, подъехало оборудование. Нужно было настраивать.
Процесс внедрения сети отличается от старых схем ещё больше, чем процесс планирования. Раньше инженер соединял устройства между собой, настраивал их одно за другим и получал один за другим работающие сегменты сети. С SD-Access процесс внедрения выглядит следующим образом:
Это в первый раз. Причём DNA Center для первичного развёртывания требует DNS, NTP и доступ в облако Cisco для скачивания обновлений (со Smart Account). На нашем внедрении выяснилось, что обновляться при первичной установке DNA Center очень любит: доведение всех его компонентов до актуальных версий заняло около двух дней, хоть и происходило в основном без нашего участия.
Пример собранной фабрики.
Когда же DNA Center уже работает, чтобы поднять новый офис, достаточно повторить пункты 1, 4, 5 и 8. Новые коммутаторы благодаря Plug-and-Play Agent получают адреса DNA Center по DHCP (опцией), берут оттуда предварительные конфиги и становятся видны в интерфейсе управления DNA Center. Остаётся расписать их роли (Egde/Control/Border), и новая фабрика готова. Группы устройств и политики на ней можно использовать старые.
Конечно, когда сталкиваешься с таким процессом впервые, сложно понять, с какой стороны к нему подойти. Вдобавок вместе с парадигмой SD-Access и соответствующими продуктами Cisco породила такое количество новых терминов и определений, что даст возможность даже бывалому CCIE снова почувствовать себя юным. Вот основные:
Вообще как следует обучиться концептам стоит и тем, кто внедряет, и тем, кто будет это эксплуатировать. От незнания внедренцы затянут сроки, а у админов потом упадут KPI. Так можно и без премий остаться. Ну а недоверие руководства заказчика к выбранному решению — проблемы вообще для всех.
С внедрением из-за того, что заказчику нужно было уже заезжать в новый офис, мы пошли по следующей схеме:
Далее пункты с 3-го по 7-й необходимо было повторять для новых групп до тех пор, пока все пользователи и устройства, подключаемые к сети, не окажутся в своих группах. При работе в режиме OpenAuth клиентское устройство делает попытку авторизации. При удачном исходе на порт, к которому оно подключено, применяются настройки, соответствующие группе, к которой это устройство принадлежит, а при неудачном оно попадает в IP Pool, заранее настроенный на порту коммутатора, — своего рода откат к традиционному режиму работы локальной сети.
Конечно, как и на любом новом продукте, немало часов мы провели, обновляя софты и выявляя баги. К счастью, Cisco TAC помогал в этом оперативно. Однажды с утра, зайдя в веб-интерфейс DNA Center, обнаружили, что вся сеть лежит. При этом ни одной жалобы от пользователей: офис работает, попивая утренний кофе. Покопались в логах, и выяснилось, что возникла проблема с SNMP, по которому DNA Center получает информацию о состоянии фабрики. Сети не видно, а она есть. Помогло исключение части OID из поллинга.
Страничка с версиями компонентов.
DNA Center собирает с фабрики кучу полезных данных по SNMP, Netflow и Syslog и умеет их представлять в понятном виде. Это особенно полезно при решении плавающих проблем вроде «что-то вчера у многих телефония отваливалась, хотя сейчас вроде нормально». Можно полазать в данных Application Experience и попытаться понять, что происходило. Так есть шанс устранить проблему до того, как «прилетит» в следующий раз. Или доказать, что сеть была ни при чём.
Данные о качестве работы приложения.
Для многих проблем, которые DNA Center показывает как Alarm, он подсказывает, «куда копать».
Пример сообщения о падении OSFP Adjacency с подсказкой, что делать.
Легче стало проводить рутинный анализ. Например, при необходимости можно быстро отследить путь трафика по сети, не лазая на устройства одно за одним. С авторизацией через ISE DNA Center подхватывает и показывает имена клиентов, в том числе и на проводной сети: не нужно лазать в поисках IP-адреса.
Пример отслеживания пути трафика через сеть. Красная метка на одном из устройств говорит, что трафик заблокирован на нём списком контроля доступа.
Можно быстро увидеть, какой сегмент сети охвачен проблемой (коммутаторы в DNA Center разбиваются по локациям, площадкам и этажам).
«Геймифицированный» показатель качества жизни приложений в сети в процентах позволяет поверхностно оценить состояние сети и видеть, не становится ли ей хуже со временем.
Показатель качества жизни приложений.
Как и раньше в Prime Infrastructure, предусмотрено также управление версиями ПО на сетевых устройствах. DNA Center держит свой репозиторий, куда образы можно заливать как вручную, так и автоматически подкачивать с Cisco.com, а потом деплоить на устройства. При этом можно программировать и запускать скрипты для проверки корректности работы сети до и после обновления. Стандартный пречек-скрипт, к примеру, включает в себя проверку доступности свободного места на флеше, состояние confi-register, сохранён ли конфиг. Поддерживается и патчинг ПО для тех устройств, которые это умеют.
Репозиторий ПО на DNA Center.
Ну и, конечно, доступ к командной строке сетевых железок по-прежнему есть.
Продукт новый, подходы новые внедрять можно, правда, осторожно. Из-за новизны кода встречаются баги в работе, но техподдержка Cisco реагирует оперативно, а девелоперы выпускают обновления регулярно. Из-за новизны подхода к управлению сетью вероятность ошибок на ранних этапах эксплуатации довольно высока, но постепенно админы привыкают, и ошибок становится меньше, чем при поддержке традиционной ЛВС. Стоит заранее подумать о том, как оттестировать и обкатать всё на части пользователей, а потом распространить на всех (хотя с опытом понимаешь, что это полезно при внедрении любых ИТ-решений, даже самых понятных и проверенных).
Автор: Максим Казаков
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/322131
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/457738/?utm_source=habrahabr&utm_medium=rss&utm_campaign=457738
Нажмите здесь для печати.