Протокол BGP в Windows Server 2012 R2 и 2016

Встроенная реализация BGP в Windows Server 2012 R2 и 2016 - изучаем и настраиваем

Привет.

Когда в Windows Server 2008 убрали OSPF, это было печально. Остался только RIP (видимо, для того, чтобы честно написать, что в продукте присутствует поддержка динамической маршрутизации). Это прискорбие, в общем-то, имело под собой логические обоснования – очень мало людей обладают настолько сложными патологиями, чтобы купить Windows Server ради роли OSPF-роутера. Но время идёт, и сценарий вида “мы подключены к двум разным провайдерам, хотим и отказоустойчивости, и балансировки, и управляемости” уже не экзотичен, да и цены на подключение ко второму провайдеру и свой номер AS всё ниже. А в данной ситуации выход один – BGPv4. Поэтому очень здорово, что сетевая подсистема Windows Server 2012 R2 обогатилась его поддержкой.

Давайте разбираться, что к чему. Нам будет интересно – ведь этого материала нет в курсах, и – !!!! – самое страшное для тренеров Microsoft – у BGP в Windows Server 2012 R2 отсутствует GUI. Но нам это фиолетово.

Я предполагаю, что вы знаете маршрутизацию и BGP хотя бы на уровне Cisco ROUTE 2.0, больше – лучше. Поэтому тут не будет рассказа про все атрибуты BGP, про логику выбора лучшего пути, и прочего. Статья про конкретную реализацию, а не про достаточно объёмный и сложный протокол.

Приступим.

BGP в Windows Server

  • Подготавливаем Windows Server 2012 R2 к работе с BGP
  • Включаем BGP на Windows Server 2012 R2
  • Устанавливаем связь с BGP-пирами
  • Работаем с маршрутами BGP на Windows Server 2012 R2
  • Настраиваем политики BGP-пиринга на Windows Server 2012 R2
  • Настраиваем политики BGP-префиксов на Windows Server 2012 R2

Начнём.

Подготавливаем Windows Server 2012 R2 к работе с BGP

Первым делом – установим компонент маршрутизации. Визуально это тот самый, классический RRaS, но внутри там скрывается BGP :)

Install-WindowsFeature Routing

ОК, компонент установлен. Но не инициализирован в плане стоящих перед ним задач. Откройте оснастку RRaS, нажмите правой кнопкой на имени сервера, выберите Configure and Enable Routing and Remote Access, там Custom Configuration и в ней LAN. Можно выбрать ещё что-нибудь дополнительно, не суть – нам нужна поддержка LAN Routing. RRaS предложит запустить сервис после конфигурирования – согласитесь, а после зайдите в services.msc и переключите службу Routing and Remote Access из Automatic (Delayed Start) в Automatic.

Движок установили – обновим help и проверим наличие командлетов:

Update-Help Get-Command *BGP*

Включаем BGP на Windows Server 2012 R2

На данный момент наш BGP-роутер не инициализирован. Для его старта, если помните, нам нужен минимальный комплект информации – номер нашей AS и Router ID.

Тут нас ждёт первое знакомство с серьёзными сетевиками из Microsoft – с их точки зрения Router ID в BGP – это “Internet IPv4 address of a local BGP router”. Не обращаем внимания – мы ж знаем, что такое ID, а что такое IP. Включаем. Для теста выберем частный номер AS – 65000 и установим идентификатор 1.1.1.1.

Add-BGPRouter -LocalASN 65000 -BGPIdentifier “1.1.1.1”

Посмотрим результат:

Get-BGPRouter

Судя по всему, включилось. Если что, можно выключить опять – применив командлет Remove-BGPRouter без параметров.

Что мы сможем поправить в глобальных настройках роутера, до того, как добавим eBGP-пира?

Настройка обработки MED

Мы можем включить или выключить сравнение Multi-Exit Discriminator’ов, полученных для одного префикса от разных пиров из разных AS. Это включается командой   Set-BGPRouter -CompareMEDAcrossASN $True   Пока не будем.

Включение поддержки IPv6

Так как поддерживается протокол MP-BGPv4, то можно включить и обработку префиксов, у которых next hop будет ipv6. Это делается так:   Set-BGPRouter -IPv6Routing Enable   Тоже пока не нужно.   Пора установить связь с роутерами провайдеров, связь сама не установится – это же не IGP, а EGP.

Устанавливаем связь с BGP-peer’ами

Для тестовых задач мы нарисуем такую вот схему:   Windows Server 2012 R2 BGP - схема сети   R1 – это наш роутер на базе Windows Server 2012 R2. R2 – это роутер Cisco на IOS 15.1. R3 – ещё один роутер на базе Windows Server 2012 R2. На схеме помечены IPv4-сети – все IPv4-адреса образуются по логике “последний октет равен номеру устройства”, которая хорошо знакома тем, кто обучался у нас на курсах Cisco. Наш номер автономной системы будет 65000, а Router ID будут простыми – у R1 будет 1.1.1.1, у R2 – 2.2.2.2, у R3 – 3.3.3.3.   Сделаем нужные базовые настройки на системах (IPv4-адреса, включим протокол BGP с нужным Router ID и нужным номером AS) и перейдём к настройке пиринга.   Пиринг будет настраиваться командлетом Add-BGPPeer. Какие параметры мы должны ему задать?  

Обязательные параметры BGP-пира в Windows Server 2012 R2

Этих параметров будет 4.

Параметр -LocalIPAddress

Данный параметр укажет, из-под какого нашего адреса мы будем устанавливать сессию до данного пира. Это может быть как адрес с интерфейса, “смотрящего” на пира, так и loopback для сценариев с ebgp-multihop.

Параметр -PeerIPAddress

Данный параметр укажет, на какой из адресов пира мы будем подключаться.

Параметр -PeerASN

Это – номер AS, к которой относится пир.

Параметр -PeerName

Это удобное для нас имя пира. Произвольное, исключительно для идентификации.   По результатам, на R1 мы выполним такие командлеты:   Add-BGPPeer -PeerName “ISP1” -LocalIPAddress 172.20.101.1 -PeerIPAddress 172.20.101.2 -PeerASN 65101   Add-BGPPeer -PeerName “ISP2” -LocalIPAddress 172.20.102.1 -PeerIPAddress 172.20.102.3 -PeerASN 65102   Если задали пира неправильно, можно удалить его командлетом Remove-BGPPeer, указав обязательный параметр -PeerName.   На данный момент состояние подключения к соседям можно посмотреть Get-BGPPeer, результат будет примерно такой:   Настройка BGP-пиров в Windows Server 2012 R2   Это нормально – наш роутер пытается законнектиться по TCP 179 на указанные адреса (кстати, не забудьте проверить, разрешает ли ему это Windows Advanced Firewall). Настроим по схеме остальных участников и получим другой результат:   Для R1:   Работающие BGP-пиры в Windows Server 2012 R2   Для маршрутизатора Cisco:   Работающий BGP-пир на базе Windows Server 2012 R2 с точки зрения маршрутизатора Cisco   Отлично. Теперь надо посмотреть, что мы можем дополнительно настроить в базовых взаимоотношениях с другим BGP-роутером.

Настройка тайм-аутов и holdtime для BGP на Windows Server 2012 R2

Вы можете настроить два значения для каждого пира – это HoldTimeSec и IdleHoldTimeSec.   Первый параметр, -HoldTimeSec, укажет время в секундах, через которое, если пир ничего не присылает, он будет считаться погибшим и будет предпринята попытка переподключения.   Второй параметр, -IdleHoldTimeSec, укажет время в секундах, через которое будет предпринята попытка повторного подключения, если на стартовой фазе возникли ошибки. Допустим, Вы неправильно настроили номер AS у пира – Ваш роутер пытается начать подключаться, переходит в Connecting, после обнаруживает несоответствие критических параметров BGP-сессии и уходит в Idle. Как раз на это время, после чего опять пробует переподключиться – вдруг Вы или пир поправили параметры и теперь всё получится.

Настройка логики установки сессии с пиром для BGP на Windows Server 2012 R2

Здесь тоже будет два параметра.   Первый, -PeeringMode, будет иметь два значения – Automatic и Manual. В случае выбора первого (это по умолчанию) Ваш роутер будет постоянно стараться подключиться к пиру, которого Вы создали Add-BGPPeer. В случае выбора второго инициировать попытку подключения будете Вы лично, запуская командлет Start-BGPPeer.   Второй, -OperationMode, будет также иметь два значения – Mixed и Server. В первом случае (являющимся значением по умолчанию) роутер будет и пытаться подключаться и принимать подключения от тех, кого Вы задали пирами (BGP вообще от кого попало сессии не принимает, только от явно заданных партнёров), а во втором (Server) Ваш роутер будет только принимать входящие подключения – сам подключаться не будет.

Настройка weight’а префиксов от пира для BGP на Windows Server 2012 R2

Это делается параметром с предсказуемым значением -Weight, которое будет жестко задавать указанное число как атрибут weight у каждого префикса, полученного от данного пира.

Настройка лимита префиксов от пира для BGP на Windows Server 2012 R2

Это делается параметром -MaxAllowedPrefix. Логика простая – если Вы, допустим, договорились с провайдером, что он Вам присылает только default, то имеет смысл подстраховаться и задать данное значение – вдруг провайдер решит Вас порадовать full view, зачем оно, это сомнительное удовольствие. Если захочется, этот параметр можно менять на ходу или вообще убрать командлетом Set-BGPPeer с параметром -ClearPrefixLimit.   С добавлением пиров разобрались. Давайте добавлять маршруты, а то у нас BGP вхолостую пока работает – сессии установили, а толку никакого.

Работаем с маршрутами BGP на Windows Server 2012 R2

Наш BGP уже установил сессии с пирами и готов чем-нибудь поменяться. Изначально BGP, как положено, ничего не анонсирует – поэтому, судя по схеме, теперь нам надо добавить в анонсируемые BGP префиксы нашу сетку (я сейчас про R1) 192.168.1.0/24. Это делается командлетом   Add-BGPCustomRoute -Network “192.168.1.0/24”   Есть и второй вариант – можно просто указать интерфейс по его названию, и все connected-сети с этого интерфейса добавятся в анонс BGP.   Add-BGPCustomRoute -Interface “LAN”   Но этот вариант у меня не сработал – система написала, что такого интерфейса нет, хотя он есть. Я тестово переименовывал интерфейс и проверял фактическое переименование через netsh int ip sh int – никакого результата, не добавляет и всё.   Наши провайдеры, которые ISP1 и ISP2, соответственно, добавили свои 192.168/16 сети в анонс. Добавлять, замечу, как и положено в BGP, можно и не существующие фактически префиксы сетей – они тоже будут анонсироваться. Т.е. проверки на фактическое существование connected-подсети, совпадающей или подпадающей под анонсируемый префикс, не будет – что хотите, то и объявляйте. Посмотрим со стороны ISP1, что теперь поменялось, когда наш R1 объявил сеть:   Анонсируем BGP-префикс в Windows Server 2012 R2   Всё хорошо – читаем строчку: выбран лучший путь до сети 192.168.1.0/24, он валидный, next-hop достижим и его IPv4-адрес 172.20.101.1, метрика не назначена, local pref тоже, веса нет, трасса – до автономной системы 65000, а там этот префикс и родился естественным путём.   Теперь со стороны ISP2:   Анонсируем BGP-префикс в Windows Server 2012 R2   Тут тоже всё нормально – префикс 192.168.1.0/24 получен от пира с именем Customer (под этим именем я добавлял R1 на R3), next-hop 172.20.102.1, никакие атрибуты не заданы. В таблице маршрутизации данный префикс также добавился и на R2:   Таблица маршрутизации с BGP-маршрутом   И на R3:   Таблица маршрутизации с BGP-маршрутом   Правда, стандартный вывод route print убогий, например, в нём не видно, от какого источника в route table пришёл какой маршрут, поэтому я пользуюсь своим костылём под названием ATcmd (кстати, надо будет его модернизировать).   Таблица маршрутизации с BGP-маршрутом, просмотр через atcmd.exe   Тут лучше заметен единственный BGP-маршрут.   Итак, декларацией о сетях (наличествующих или нет) обменялись. Теперь надо подумать, как обрабатывать информацию от peer’ов. Ведь пиры могут отправлять некорректную информацию, лишнюю или откровенно вредоносную – это всё ж EGP-маршрутизация, а не IGP.

Настраиваем политики BGP-пиринга на Windows Server 2012 R2

Логика этой части работы будет следующей. Есть два стула направления – ingress (в данном контексте “обрабатывать присылаемые префиксы”) и egress (“обрабатывать отправляемые префиксы”). С каждым пиром обрабатывается отдельно массив egress-политик и ingress-политик. Конфигурируется это относительно просто – у Вас есть три командлета – Add-BGPRoutingPolicyForPeer, Set-BGPRoutingPolicyForPeer и Remove-BGPRoutingPolicyForPeer. Первый из них добавляет политику с указанным именем и указанным направлением ingress/egress к одному или списку пиров, второй замещает существующую политику (или политики) указываемой, третий удаляет. Т.е. одним движением можно как добавить политику обработки префиксов для одного или нескольких пиров, так и сделать её единственной, заменив предыдущую.   Осталась одна малюсенькая проблемка – у нас политики не созданы.

Настраиваем политики BGP-префиксов на Windows Server 2012 R2

После того как мы включили BGP-роутер и настроили пиринг, нам надо задать политики обработки префиксов. Для этого у нас есть командлет   Add-BGPRoutingPolicy   Наша первая тестовая задача – зафильтровать отправляемые от нас префиксы. Идея простая – если мы будем отправлять каждому пиру всё, что у нас есть в BGP, возможен красивый сценарий, когда ISP1 отправит нам префикс, а мы отправим этот префикс ISP2, и наоборот. Мужики страшно обрадуются тому, что у них появился новый межпровайдерский пиринг, притом очень прибыльный – за бегающий сквозь нас трафик будем платить мы. Поэтому мы для начала скажем простую штуку – что наружу мы анонсируем только свои префиксы, больше провайдерам ничего знать не надо. Для задания политики нам потребуется:   1. Указать её имя (например, -Name “SendOnlyMyRoutes”).   2. Указать действие, которые она будет производить с префиксами, подпадающие под её критерии (параметр -PolicyType) – возможные варианты будут Deny – отфильтровывать все подпадающие префиксы, Allow – разрешать все подпадающие префиксы, ModifyAttribute – только заменять атрибуты у уже существующих префиксов, подпадающих под указанные критерии. Т.е. Вы можете сделать три отдельных политики и при помощи -PolicyType Allow указать в первой, какие префиксы надо принимать от пиров, после при помощи -PolicyType Deny во второй указать какие нужно игнорировать, а при помощи -PolicyType ModifyAttribute в третьей откорректировать нужные атрибуты у выживших после всего этого префиксов, подпавших под нужный критерий.   3. Указать критерии отбора префиксов – здесь будет достаточно большое поле для действия.  

Фильтрация по AS в BGPRoutingPolicy

Фильтрация по AS делается параметром -MatchASNRange, после которого можно через запятую указать диапазон номеров AS.

Фильтрация по префиксу в BGPRoutingPolicy

Фильтрация по префиксу делает параметром -MatchPrefix, который позволяет указать множество префиксов, а параметр -IgnorePrefix позволит указать исключаемое из этого множества подмножество.

Фильтрация по Next Hop в BGPRoutingPolicy

Фильтрация по Next Hop делается параметром -MatchNextHop, после которого указывается подмножество Next Hop’ов, префиксы с которыми будут подпадать под данную политику.   4. Указать действие, которое будет происходить с отобранными префиксами – варианты:  

Очистка MED в BGPRoutingPolicy

Это делается добавлением атрибута -ClearMED.

Назначение MED в BGPRoutingPolicy

Делается добавлением атрибута -NewMED.

Назначение Local Preference в BGPRoutingPolicy

Делается добавлением атрибута -NewLocalPref.

Замена next hop в BGPRoutingPolicy

Делается добавлением атрибута -NewNextHop.

Добавление и удаление bgp community в BGPRoutingPolicy

Делается добавлением атрибутов -AddCommunity и -RemoveCommunity. Напомню, данный атрибут специфичен – у предыдущих – MED, LocalPref, NextHop – одно значение, а community – список.   Давайте собирать нашу политику “SendOnlyMyRoutes”.   Add-BGPRoutingPolicy -Name SendOnlyMyRoutes -PolicyType Deny -IgnorePrefix “192.168.1.0/24”   Политика создана – она будет дропить все префиксы (т.к. не указан параметр -MatchPrefix, но указано действие Deny), кроме нашего 192.168.1.0/24. Посмотреть на все политики можно Get-BGPRoutingPolicy, но мы пойдём дальше – применим эту политику к нужному пиру.   Add-BGPRoutingPolicyForPeer -PeerName “ISP1” -PolicyName “SendOnlyMyRoutes” -Direction Egress   После её применения будет сброшена сессия – такой вот soft reset, но не суть. Теперь к пиру ISP1 не будут приходить никакие другие префиксы, кроме нашего.   По аналогии Вы сможете сделать много фильтрующих политик – давайте ещё один пример, только про другое. Допустим, у нас есть задача, чтобы до некоей сети X в Интернете мы всегда ходили через ISP1, а если он не работает – то через ISP2. Сеть, понятное дело, доступна через оба ISP, но нам вот надо явно выбрать, через кого ходить. И хочется нам, чтобы эта настройка работала в сценарии, когда у нас несколько eBGP-роутеров. Ну т.е. нам надо, чтобы когда из нашей сети трафик хотел идти в определённую сеть в Интернете (допустим, это сеть нашего датацентра), то он всегда шёл бы через одного провайдера, а если проблемы – то через другого.   Данный сценарий реализуем путём модификации атрибута local preference для получаемых префиксов. Т.е. наш роутер (или роутеры) будут “втягивать” информацию о нужном префиксе через разных провайдеров, и проштамповывать эти префиксы такими значениями local preference, чтобы любой роутер внутри нашей AS всегда мог выбрать – мол, есть два варианта выбрать до этой сети наружу, вот один лучше другого, пойду-ка я наружу через edge-роутер A, а не через edge-роутер B.   Тестовой сетью объявим 1.2.3.0/24. Пишем политики.   Add-BGPRoutingPolicy -Name LocalPrefHigh -PolicyType ModifyAttribute -MatchPrefix 1.2.3.0/24 -NewLocalPref 200   Add-BGPRoutingPolicy -Name LocalPrefLow -PolicyType ModifyAttribute -MatchPrefix 1.2.3.0/24 -NewLocalPref 100   После – привязываем их к нужным пирам (не забудем про направление – ingress, плюс то, что это модификатор входящих префиксов, а не фильтр):   Add-BGPRoutingPolicyForPeer -PeerName “ISP1” -PolicyName “LocalPrefHigh” -Direction Ingress   Add-BGPRoutingPolicyForPeer -PeerName “ISP2” -PolicyName “LocalPrefLow” -Direction Ingress   В общем-то всё. Теперь по нашей AS будет путешествовать два префикса 1.2.3.0/24 – с разными next-hop’ами и разными local preference.  

Итоги

Что хочу сказать, коллеги. Нововведение – крайне полезное и нужное, закрывающее собой целый класс задач. Сетевая сторона Windows Server 2012 R2 действительно ощутимо усилилась.

Тенденция вообще интересна – кто бы мог подумать лет 5 назад, что сетевые решения на базе СПО постепенно скатятся в low-end, а всё серьёзное в сетях будет работать только на качественном проприеритарном коде (Cisco IOS, JunOS) и что в Windows Server будет встроен BGP? Интересная ситуация. Ну а дальше, думаю, будет ещё интереснее.

Удачных проектов!

Возможно, вам будет также интересно почитать другие статьи про на нашей Knowledge Base

Ruslan V. Karmanov

Зайдите на сайт под своей учётной записью, чтобы видеть комментарии под техническими статьями. Если учётной записи ещё нет - зарегистрируйтесь, это бесплатно.