1. Настройка Underlay сети
Топология и IP-план
В качестве самого первого шага придумаем IP-план, которого будем придерживаться :).
Выделим IP-адреса для Loopback'ов и номера автономных систем для наших коммутаторов:
Spine-1
10.1.0.1
65100
Spine-2
10.1.0.2
65100
Leaf-1
10.1.1.1
65001
Leaf-2
10.1.1.2
65002
Leaf-3
10.1.1.3
65003
Спайны будут иметь общий номер AS. Каждому лифу, наоборот, будет назначен уникальный номер автономной системы (то есть для связности будет использоваться eBGP, что является хорошей практикой при построении топологии Clos в условиях ЦОД).
Интересной особенностью нашей настройки underlay будет использование метода передачи префиксов, описанного в RFC 5549: Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop, или анонсирование маршрутизационной информации для IPv4-префиксов с использованием IPv6-некстхопа. Что здесь имеется в виду?
Смысл такой схемы состоит в том, чтобы уйти в underlay-сети от необходимости адресации BGP-соседей с использованием статически заданных стыковочных сетей. То есть по сути мы можем просто указать процессу BGP на конкретный интерфейс и сказать - пирься! :) На стыковочных интерфейсах маршрутизаторов активируется IPv6, после чего они периодически начинают отправлять в стыковочный линк сообщения IPv6 RA (Router Advertisment). Потенциальные пиры на другом конце линка получают эти RA-пакеты, и информация из этих пакетов дает им достаточно информации для установления BGP-соседства по link-local адресу соседа.

Еще раз замечу - никакой IPv4-адресации на стыковочных интерфейсах у нас не будет вообще. IPv4-сети (в данном случае /32 IPvLoopback-адреса) будут анонсироваться с IPv6-некстхопами.
Конечно, мы настроим аутентификацию для BGP. Использовать будем самый обычный MD5-алгоритм. Аутентификация нам нужна не для того, чтобы помешать какому-либо злоумышленнику порушить нашу сеть, а скорее для защиты от некоего BGP speaker'а, могущего внезапно и случайно оказаться в стыковочном широковещательном домене между коммутаторами, и могущего попытаться запириться с нашими устройствами. Что там может прилететь от него и как поведет себя сеть - совершенно неясно, поэтому лучше перестраховаться от таких ситуаций и настроить хотя бы минимальную аутентификацию.
⚠️ Важное замечание! Достижимости между Loopback'ами спайнов у нас не будет, так как они не установят маршруты до Loopback'ов друг друга из-за того, что в AS-PATH будет присутствовать собственная AS (помним, что она одинаковая на Spine'ах). Это механизм предотвращения образования петель в eBGP: видишь свою AS в AS-PATH - отказывайся от приема такого маршрута. Данное ограничение можно обойти через использование команды "allowas-in" в настройках пир-группы, но это всё же костыль, который не стоит использовать без явной необходимости, а такой необходимости в общении между спайнами я не просматриваю. :)
Переходим к настройке. Помним, что конечная наша цель - обеспечить связность между IPv4-лупбэками на каждом устройстве (за исключением пары Spine-Spine).
Настройка
Настройка Spine-1
Базовые настройки
В первую очередь, перед тем, как начинать что-либо настраивать, мы переключимся на новый маршрутизационный движок ArBGP или, как его еще называют, режим "multi-agent".
Без этого режима схему BGP Unnumbered построить на удастся. Точнее, BGP настроить получится, и мы даже установим нужные нам маршруты в FIB, но фактически трафик с использованием IPv6-некстхопа ходить не будет.
Активировать ArBGP можно с помощью команды service routing protocols model multi-agent, отданной в режиме глобальной конфигурации:
Команда фактически применится после перезагрузки, но перезагрузиться можно уже после окончания настройки. Идем дальше.
Установим hostname:
Включим IPv4- и IPv6-маршрутизацию. IPv6-маршрутизация нам необходима для реализации схемы BGP Unnumbered. Также включаем маршрутизацию IPv4 через IPv6-интерфейсы (что так же необходимо для работы по RFC 5549):
Настроим Loopback-интерфейс. Пропишем на нем IP-адрес.
Настроим интерфейсы, смотрящие в сторону Leaf'ов. Здесь мы переводим их в L3-режим, пишем осмысленное описание и включаем IPv6 на интерфейсе (нужно для генерации Link-local адресов):
Остальные доступные интерфейсы отключим от греха подальше:
На этом основную настройку можно считать завершенной. Переходим к конфигурации протокола BGP.
Настройка BGP
Первым шагом, еще до создания роутингового процесса, давайте создадим маршрутную карту и фильтрационный список AS.
Маршрутная карта, которую мы здесь создадим, позволит нам "отобрать" интерфейсы, сети которых мы будем редистрибьютить в BGP. Ведь нам необходимо анонсировать в BGP только адрес Loopback, а всему остальному там присутствовать не нужно. Данной маршрутной картой мы отловим только интерфейс Loopback0, все остальное попадет в implicit deny (неявный запрет).
Теперь фильтрационный список. Он позволит нам задать диапазон AS. Его мы будем использовать при настройке BGP-соседей для того, чтобы не указывать AS для каждого пира вручную. Более того, мы здесь оставим запас из трех AS для будущих Leaf'ов, которых у нас сейчас нет (ну так, на всякий случай). Таким образом при подключении новых коммутаторов не придется для них настраивать пиринг BGP отдельно. Данный список разрешает диапазон AS 65001-65006, все остальное в него не попадает.
Теперь перейдем к настройке непосредственно BGP. Создадим процесс для автономной системы 65100 (AS наших Spine'ов):
Включим ECMP для BGP. Возьмем некоторое число с запасом. Ну, пусть будет 64.
Создадим пир-группу CLOS. Она будет содержать все BGP-настройки, которые одинаковы для наших соседей. Таким образом, не придется набивать одно и то же для каждого соседа по отдельности.
Отключим задержку перед уведомлением BGP-соседа об изменениях в нашей таблице маршрутизации. В нашей маленькой закрытой ЦОД-сети она не так актуальна, как в Большом Интернете:
Активируем для соседа BFD:
Подкрутим Keepalive- и Hold-таймеры в сторону уменьшения. Это позволит уменьшить время сходимости.
Включим аутентификацию с помощью MD5-алгоритма. Это позволит защититься от теоретически внезапно могущих появиться "левых" BGP-спикеров на наших стыковочных каналах. Пароль установим "OTUS".
Включим редистрибьюцию IPv4-маршрутов в наш BGP. Тут мы применяем ту самую маршрутную карту, которую мы создали ранее. Это позволит нам анонсировать в BGP исключительно подсети интерфейса Loopback0.
Объявляем наших "нейборов". А точнее, указываем интерфейсы, на которых мы хотим пириться с соседями. В нашем случае это Ethernet1-3, на которых расположены наши Leaf'ы, а также интерфейсы Ethernet 3-6, на которых в будущем могут разместиться новые Leaf-коммутаторы. :) Также применяем наш фильтрационный список AS, согласно которому пириться мы будем только с теми BGP speaker'ами, чьи AS совпадают с нашим списком (65001-65006). Соседство будет установлено с помощью IPv6 Link-Local адресов.
Активируем семейство адресов IPv4 Unicast для нашей группы CLOS и указываем, что в качестве next-hop'а для наших анонсов будут использоваться link-local адреса IPv6:
На этом настройку нашего Spine-1 можно считать законченной. Приведем полную распечатку команд, которые мы вводили, для наглядности (и для более удобного копипастинга в Spine-2) :)
Теперь перезагрузим устройство:
Настройка Spine-2
Здесь всё так же, как и для Spine-1. Меняется только адрес loopback и hostname.
Закопипастим всё это хозяйство в Spine-2, сделаем write и reload now.
Настройка Leaf-1
Здесь у нас будут небольшие различия в плане настройки по сравнению со Spine'ами.
Во-первых, так как AS Spine'ов у нас одна, то и фильтрационный список мы указывать не будем, а явно зададим "remote-as 65100". Во-вторых, локальная AS для каждого Leaf у нас уникальна. В остальном все то же самое, если не считать мелочей, вроде описаний интерфейсов и количества аплинков.
Приведу готовую простыню для копипастинга, без пояснения по каждой команде отдельно, так как нового здесь ничего нет.
Делаем write и reload now.
Настройка Leaf-2
Всё то же самое, что и для Leaf-1. Другой IP на Loopback, другая локальная AS (65002).
Делаем write и reload now.
Настройка Leaf-3
Всё то же самое, что и для Leaf-1 и Leaf-2. Другой IP на Loopback, другая локальная AS (65003).
Делаем write и reload now.
Проверки
Проверка Spine-1
Во-первых, проверим IPv4- и IPv6-адресации:
Все выглядит в порядке. Link-local адреса на месте, IPv4-loopback присутствует.
Проверим, что список ASN и маршрутная карта созданы корректно:
Проверим состояние наших сессий и самую общую информацию о BGP:
Видим BGP-соседства в состоянии Up на все трех downlink-интерфейсах (т.е. интерфейсах в сторону лифов), AFI IPv4 включена, Router-ID корректный, локальный номер автономки - тоже.
Проверим BGP RIB:
Здесь мы видим маршруты до каждого Loopback'а, кроме Spine-2. Маршруты к Loopback'ам лифов имеют Link-local некст-хопы на соответствующих интерфейсах. Маршрут Loopback для Spine-2 мы отвергли из-за того, что наша AS (65100) присутствует в его AS-PATH, поэтому его мы здесь не видим.
Посмотрим в таблицу маршрутизации:
Маршруты до Leaf'ов в FIB установлены.
В последнюю очередь проверим состояние наших BFD-сессий:
Все выглядит в порядке.
Проверка Spine-2
Быстренько пробежимся по Spine-2. Интерфейсы:
Проверим BGP RIB:
Посмотрим в таблицу маршрутизации:
BFD:
Все выглядит в порядке. Перейдем к лифам.
Проверка Leaf-1
Интерфейсы:
Общий статус BGP:
BGP-сессии установлены только со Spine-ами.
Проверим BGP RIB:
Посмотрим в таблицу маршрутизации:
BFD:
Все выглядит в порядке.
Проверка Leaf-2
Интерфейсы:
BGP:
Таблица маршрутизации:
BFD:
Все выглядит в порядке.
Проверка Leaf-3
Интерфейсы:
BGP:
BFD:
Все выглядит в порядке.
Проверка связанности между Loopback'ами
Теперь underlay полностью настроен и пинги между Loopback'ами должны проходить на каждом устройстве. Проверим!
Spine-1
ping Leaf-1
ping Leaf-2
ping Leaf-3
Spine-2
ping Leaf-1
ping Leaf-2
ping Leaf-3
На лифах проверим только связность между лифами, так как связность в парах Leaf-Spine мы уже проверили.
Leaf-1
ping Leaf-2
ping Leaf-3
Leaf-2
ping Leaf-1
ping Leaf-3
Leaf-3
ping Leaf-1
ping Leaf-2
Заключение
Связность между Loopback'ами достигнута. Underlay у нас работает и теперь мы можем переходить к следующей части - настройке L2-VXLAN.
Last updated