Протокол 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

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