> >

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

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

//cdn.atraining.ru/i/at300x300.jpg300300

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

BGP в Windows Server 2012 R2

  • Подготавливаем 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? Интересная ситуация. Ну а дальше, думаю, будет ещё интереснее.
 
Удачных проектов!

Автор

@
info@atraining.ruAdvanced Training
//cdn.atraining.ru/i/at300x300.jpg300300

Полезные статьи

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

  • mike

    AD нужен?

  • Для BGP? Зачем? :)

  • Anonymous
  • Вы этот вывод сделали по маркетинговой статье сотрудников Microsoft, которым заказали написать про “рассказать хоть примерно зачем это может пригодиться” для тех, кто с BGP “крайне много” работал? Из факта оного маркетингового материала однозначно следует, что существует только написаный сценарий, и он единственен? :). Прямо MVP-подход какой-то – “Я Буду Делать Добуквенно И Только Так Как Указано На Сайте Господина”.

  • Юрий
  • Забавная статья. Вообще, крики вида “Давайте выберем самый огромный протоколище, Это Круто, и будем везде пихать”, обычно характеризуют начально-среднюю степень понимания сетевых технологий. Вида “Раз большие это юзают, это круто”. Линуксшколота типовая такая, “Я читал что линух на суперкомпах, поставлю на домашнюю тачку”. Буду ездить на работу на экскаваторе, он большой, Это Круто :)

    В роли IGP BGP проигрывает всем троим основным – OSPF / EIGRP / IS-IS. Учитывая, что EIGRP теперь стандартный, и что IS-IS активно продвигается, у BGP шансов тут выиграть, проигрывая по всем техническим параметрам – от времени сходимости до функционала – просто нет.

    “Аргументация” в оной статье тоже конечно шедевр: типа настраивать проще. И всё. А мол что у BGP сходимость от нескольких секунд – это ерунда. Зашибись ерунда, конечно. Заново L3-distribution перепридумать, который уже несколько лет как стандартный, и выдать это за фичу перехода на BGP – ещё круче. И на добивку – “Только при нашем подходе частные номера AS кончатся, но не беда – мы их предлагаем повторно юзать”. Шизофазия.

    И финал – бубнение мантры “Надо перейти на BGP, потому что надо”, без каких-либо аргументов как таковых. Не доклад, а сайентология.

  • Юрий

    кстати, EIGRP уже кто-то имплементировал?

  • У Huawei есть драфт рабочий, ждут пока RFC устаканится. Хотя пирится ОК.

  • Volodimir Tihonov

    Авторизацию на сессии поднять :)

  • Некислый бы вброс получился, если добавить что “А под доменным админом работает ощутимо быстрее”. Поверило бы процентов 98 винадминов. :)

  • Alexander Shapoval

    Можно эту статью на TechNet-е опубликовать?

  • Можно конечно.

  • Konstantin Goncharenko

    Простите, а между чем и чем пирили? какие именно девайсы со стороны Хуавей (версия VR тоже интерисует весьма)

  • Дмитрий

    Однако на дворе 2014 года, а МС не включил поддержку 32-битных ASN. Или нужно хитрым способом ее опционально включать?

    Также решил сделать воркэраунд и выкрутиться не через родную АС, а взять из диапазона “приватных”. На линуксе все прилетает как надо, а на виндовс – нет, хотя и пишет, что connecting.

  • Дмитрий

    2014 год, а BGP От MS не поддерживает 32-битные ASN. Или нужно в реестре включать “расширенные” функции?:)
    Сделал воркэраунд через приватные ASN 64xxx, но маршруты не прилетели, при этом коннекция с пиром устанавливается. Линукс нормально подхватил данную конфигурацию.

  • Дмитрий

    connecting – это bad, нужно – connectED, те Estableshed