SD-WAN BI.ZONE часть 3 — поговорим о дизайне сети и о том, что меняется в дизайне при внедрении SD-WAN, а что остаётся как и было.
Пока ожидаем CPEs и есть время, можно как раз проговорить появляющиеся особенности дизайна. Кроме этого рассмотрим моменты связанные с дизайном, которые по разным причинам постоянно упускал из виду до этого.
Централизация дизайна
До SD-WAN у нас был распределённый дизайн. То есть отдельные площадки, соединённые какими-то (не суть важно какими) линиями связи. Всё в разнобой. Здесь вот так сделано, там по-другому. Даже с учётом DMVPN, потому что DMVPN, если уж честно, не совсем централизованное решение. При таком подходе основной элемент дизайна — это сама площадка.
С приходом SD-WAN появляется централизация и унификация. Сам SD-WAN — сердце нашей системы. Теперь он основной элемент дизайна, а площадки вторичны. Все площадки подчиняются одной и той же политике прохождения трафика. Все каналы связи, вне зависимости что это за каналы, агрегируются в SD-WAN.
При этом FW/NGFW больше не занимаются связностью площадок посредством VPN туннелей (за исключением отдельных туннелей, в основном с арендованными облаками). Сейчас их место будет сразу за оборудованием SD-WAN. И выполняют они свою прямую обязанность. А именно фильтрацию трафика между площадками. В этом слое дизайна тоже желательно добавить средство централизации. Например для Check Point, как уже обозначал, таким средством является MDS. Тогда у нас вдобавок появляется централизованная политика фильтрации трафика.
Раз уже заговорили про дизайн, продолжим.
Кампусная сеть
Что тут? Не упоминал такие вещи, не было необходимости, время пришло. 🙂 Надо понимать что не берусь обозначить все многообразие топологий. Мне это не под силу.
Уровень ядра
На самом деле дизайн сети, как его рассказывает CISCO, больше умозрительная структура. На практике не так.
- Во-первых, уровень ядра. На бумаге он есть, фактически его нет.
Даже в больших компаниях, вы этот уровень встретите крайне редко. Почему? Потому что уровень ядра рассчитан на группу зданий (Уровень ядра комплекса зданий, см. картинку). И ядро тут быстрый транспорт для уровня распределения каждого из зданий. А где у нас компании чтобы владели прям большой группой, прям больших зданий, стоящих рядом? Ну как рядом, максимум несколько десятков километров. Возможно у них в америках, в силиконовых долинах, такое повсеместно. У нас нет. В итоге используется свёрнутое ядро Two-Tier Design (Collapsed Core).
Из экономических соображений тоже. Никто не будет ставить пару довольно дорогих коммутатора без всяких сервисов, чтобы они просто гоняли через себя трафик. Тут есть толстое исключение, о нём далее.
Уровень распределения
- Во-вторых, "пара коммутаторов" свёрнутого ядра переродилась в стек. Simplified Campus Design.
Стек и только стек.
Перерождение уже случилось и никакие "пары" нигде не используются. Всё ещё кипятите? Тогда мы идём к вам! Если у вас используется именно пара, стекируйте. Нельзя стекировать, вопрос о замене.
В зависимости от размера офиса лучшее решение на момент (по моему мнению) — это стек из коммутаторов CISCO 9300 (с network-advantage лицензией) или в идеале 9500 (тьфу тыж ё, опять циска). Поддержка BGP, VRF. Туда подключается всё и все настройки там. Этот стек может быть более чем из двух коммутаторов, но тогда скорее всего такое решение приведёт к снижению отказоустойчивости. Так как лучшая практика соединять остальное оборудование парой линков в два коммутатора свёрнутого ядра.
Оба эти линка собираются в Port Channel через LACP. Почему через LACP? Этот протокол "умный" и производит мониторинг линков. Он открытый, не завязан на оборудование конкретного вендора (CISCO). Топология при этом звезда, но это так скажем "хорошая звезда". 🙂 Сбалансированная, отказоустойчивая и STP не блокирует линки между свёрнутым ядром и подключенным в него оборудованием.
А на доступ 9200. Понятно что 9500/9300/9200 — это линейки коммутаторов. Так среди 9200 есть высокопроизводительная модель C9200L-48P-4X с четырьмя 10-гигабитными портами, а есть совсем простая и дешёвая C9200L-48T-4G-E. Дешманские C9200L-48T-4G-E собираем в стек и используем в модуле Server Farm под iLO. Для коммутаторов уровня доступа "правило двух" не работает. Там в стек пихается столько коммутаторов, сколько нужно для достижения необходимой плотности портов.
Высокопроизводительные порты позволят обеспечить достаточную скорость передачи к другим модулям Enterprise Architecture Model. Опять же по моему мнению 10Gbps — это на сегодняшний день стандарт для связи сетевого оборудования. И стремиться надо к нему.
Full Mesh
- В-третьих, при отсутствии уровня ядра все "пары коммутаторов" свёрнутого ядра группы зданий в теории подсоединяются по схеме Full Mesh.
В гайдах CCNA/CCNP (далее — учебник/книжка) так. На практике ничего такого нету. Конечно полносвязное соединение хорошо. Кто спорит? Но в реалиях офисы одного города разнесены. Зачем делать два офиса близко друг к другу? А тогда соединение их напрямую оптикой (предпочтительный вариант) стоит денег. Не каждая компания себе может позволить прям всё на всё завязать оптикой. Допустим два основных офиса и РЦОД полносвязно, а третий офис подцеплен только к одному из основных. Partial Mesh. Надеюсь понятно, обозначил.
Связанный момент на примере, по прямой между зданиями двух офисов 18км, длина оптической трассы 45 (!). Не придумано, из реалий. Поэтому в некоторых случаях даже когда здания относительно рядом, соединить оптикой их не получится. Или будет оч дорого. Так относительно дешёвые одноглазые модули на 10Gbps фирмы SNR до 20км (SNR-SFP+W37-20/SNR-SFP+W73-20) стоят три тысячи, до 60км (SNR-SFP+W37-60/SNR-SFP+W73-60) десятку. До 80 (SNR-SFP+W45-80/SNR-SFP+W54-80) уже полтинник (!) за модуль (по ценам на июнь 23). А ведь сама линия (прокладка, абонентская плата) тоже стоит в зависимости от дистанции.
Ещё момент, оптика не прокладывается единой линией. Есть сварка, соединительные муфты. Они ухудшают уровень сигнала. Поэтому не ошибусь, если скажу что больное место всех дальнобойных линий — слабый уровень сигнала. В районе нижнего варнинга.
# show interface Twe1/0/2 transiver detail
Optical High Alarm High Warn Low Warn Low Alarm
Receive Power Threshold Threshold Threshold Threshold
Port Lane (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ---- --------------- ---------- --------- --------- ---------
Twe1/0/2 N/A -22.4 -7.0 -8.0 -23.0 -24.0
Чуть ещё сигнал упал и.. посыпались CRC-шки как из ведра изобилия.
Уровень доступа
- В-четвёртых, собрать уровень доступа как говорит циска опять не всегда возможно.
Пример, допустим вам протянули с одного этажа бизнес-центра на другой две линии оптики. Без вариантов. И есть несколько серверных с десятком коммутаторов для подключения. Даже если это стеки, как вы их подключите двумя линками? А ведь ещё отказоустойчиво надо.
Поэтому уровень доступа часто разваливается на два уровня. Первый непосредственно доступа для пользовательских устройств. Второй недо/полу уровень распределения. Стек двух коммутаторов, который агрегирует на себя коммутаторы доступа. И вот уже этот стек подключается парой оптики к свёрнутому ядру.
Может не хватить десяточных портов на стеке полу-агрегации. Их недостаточно для этих целей на младших моделях. Но таковы реалии российского бизнеса.
Обобщая:
Картинки в книжке циско.. это просто картинки. Не более.
ЦОД/РЦОД
В книжке отказоустойчивость кампусной сети обеспечивалась модульностью. К модулю ядра подключались модули WAN Edge и Interner Edge. Но там нет ни слова что для крупных/головных офисов эти модули требуют обязательного резервирования. Представьте что у ключевого офиса отвалилась связность с другими площадками. Такого быть не должно. Поэтому модули находится в ЦОД, а дублирующие (в идеале полностью аналогичные по железу) в резервном ЦОД (РЦОД).
Если компания готова тратить деньги, то это буду прям два отдельных дата-центра (ДЦ). Связь с офисом (куда прикручены эти модули) по оптике. Если хочется чуть сэкономить, то ЦОД будет располагаться в серверной самого офиса, а РЦОД уже в ДЦ. При этом дизайн может быть весьма сложный.
Может сложиться превратное впечатление, что РЦОД нужен только для каких-то аварий и большую часть времени простаивает. Нет, это было бы слишком неэкономно. Часть сервисов работает по умолчанию через ЦОД, часть через РЦОД. Поэтому переключение только на РЦОД (или только на ЦОД) не такая уж простая задача. И естественно должна быть расписана по шагам заранее.
Что с SD-WAN? Понятное дело CPEs должны стоять и там, и там.
Пора про исключение. Если компания серьёзная, ЦОД в одном ДЦ, РЦОД в другом, то уровень ядра таки может быть. И он вынесен в ЦОД/РЦОД. В ЦОД стек ядра №1, в РЦОД №2. Не пара коммутаторов конечно, но оч похоже. Да, и такое бывает.
Диаметр STP
Когда у нас такая сложная структура из коммутаторов, транки через оптику на другие площадки, не стоит забывать про STP. Свёрнутое ядро на одной из площадок корневой коммутатор (root primary), на другой резервный корневой (root secondary). Таймеры STP по умолчанию рассчитаны так, чтобы от корневого коммутатора было в любую сторону, по любой цепочке, не более 7 коммутаторов. Если больше, то вот те коммутаторы, которые зашкаливают за диаметр STP, на них STP будет работать неправильно. Возможно ничего страшного (зависит от топологии), но момент этот не надо упускать из виду. И поднастроить если что.
В жизни встречал топологии, где от рута было 13 коммутаторов в одну сторону. Парились люди, что у них STP неправильно работает? Нет, они вообще про это не знали.
DMZ
Казалось бы уже и так достаточно сложно, но это ещё не всё. Есть DMZ. В учебнике DMZ обозначается как область серверов компании, доступных из интернета. В жизни не так. Обычно есть два уровня DMZ. Как обычно? У действительно большой компании, это имелось в виду.
White DMZ
Сервера обеспечивающие доступ к сервисам только из интернета. Через локальную сеть пользователи туда не ходят (за исключением админов в целях исключительно администрирования). У серверов White DMZ есть ограниченная связь с некоторыми внутренними серверами в Server Farm. Сервера White DMZ отгорожены как от интернета, так и от внутренней сети с помощью FW. На самом деле физически это может быть один и тот же FW.
Слой White DMZ находится максимально близко к интернету. Обычно достаточно расположить сеть White DMZ прям на отдельном интерфейсе FW, стоящего в сторону внутренней сети сразу за роутером CE (Customer Edge). Место FW в корпоративной сети рассказывал тут. Большого смысла использовать NAT нету. Сеть прям из белых адресов (поэтому White) и каждый сервер имеет сразу белый адрес на интерфейсе.
Кроме этого некоторые сервисы White DMZ используют сразу два сервера. Front End расположен непосредственно в White DMZ и обычно несёт на себе веб-сервер. Защищаемый Back End с базой данных уже в Server Farm. В FW нарезаны дырки для корректной связи.
Grey DMZ
Или App DMZ несёт сервисы доступные как из интернета, так и из внутренней сети. Для доменных пользователей. В правильной сети App DMZ отделён от White DMZ. Серверам App DMZ нужен доступ к DC для аутентификации пользователей. Оптимально когда App DMZ расположен за ещё одним FW. То есть слой App DMZ он глубже в сети и дальше от интернета. Сеть из приватных адресов. Здесь уже все сервера за NAT. Основной адрес сервера при этом приватный, а белый организуется как раз за счёт статического NAT.
Очень примерно рассказал для общего понимания и упрощения. Потому что дополнительно есть WAF, PAM, сервера Remote Access (к примеру MS Always On VPN), решения по кибербезопасности связанные с почтой. Они не вписываются в рассказанную структуру DMZ. Если и их сюда притянуть, получится совсем длинно и путано.
Что в итоге?
Наверное понятно что White DMZ и Grey DMZ находятся в ЦОД/РЦОД. Причём размазаны между ними. Часть серверов в ЦОД, часть в РЦОД. И только некоторые сервера кластеризованы. Поскольку при проблемах доступа из интернета к ЦОД (или РЦОД) соответствующая часть серверов DMZ окажется недоступна, то между ЦОД/РЦОД обязательно должны быть прямые линки. А ещё лучше не просто прямые линки, а группы прямых линков. Ну то есть для стека коммутаторов White DMZ свои линки, для стека App DMZ свои.
Дефолтный маршрут
Связанный момент: как разобраться в таком сложном дизайне? Самое простое тут посмотреть куда указывает дефолтный маршрут офиса/площадки. Когда смотрите на топологию сети, особенно разветвлённую, задайтесь первым делом этим вопросом. Поможет разобраться.
Самое простое когда на площадке выделенное устройство или кластер устройств, обеспечивающих выход в интернет. Оно логически не привязано к ЦОД, если он в офисе (хотя может физически находиться в той же серверной). Сложнее когда это устройство завязано на ЦОД. И значит в РЦОД есть дублирующее устройство.
Да, забыл тут момент. Дефолт площадки, то есть выход для пользователей и серверов Server Farm (для которых такой выход разрешён) обычно упирается в конечном итоге в NGFW или прокси корпоративного класса (типа Blue Coat ProxySG). Точка выхода занимает определённое место в дизайне. А точка выхода для серверов DMZ может быть совсем другим элементом дизайна. В другом слое, через другое решение, с другим блоком белых адресов.
Ещё припомнил. Доступ из внутренней сети к части сервисов в интернете может работать очень криво или вообще не работать через NGFW (крайне редкое явление). Самое популярное тут капризные UDP-сервисы, FTP, частные Mail-сервисы и некоторые ресурсы, подгружающие данные с CDN. Возможно эти ресурсы в интернете сами криво настроены, возможно не хватает сил разобраться. Тогда в дело идут PBR. Они выборочно разворачивают трафик на какое-нибудь более простое устройство для выхода в интернет (типа ASA). Рассказал для того, чтобы обратить внимание, что и такие костыли могут иметь место в дизайне реальной сети.
Думаете всё это напридумывал? 🙂 Ничего такого. Пересказал своими словами архитектуру сети инвестиционного подразделения одного весьма крупного банка. Поскольку маршрутизация и корректная работа всех устройств в такой сети совсем не детское дело, то даже пару раз в год планируют, так скажем, учения по переключению ЦОД/РЦОД на разных площадках (проводились они в выходные разумеется).
Заключение
Итак, основной посыл этой статьи:
Хотя SD-WAN крайне полезная вещь, многое решает, многое упрощает, но конечно же только SD-WAN не решит вам всех проблем по организации отказоустойчивой связи.
Приглашаю поделиться мнением в Tелеграм канал