Привет.
Когда в 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’ами
Для тестовых задач мы нарисуем такую вот схему:
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, результат будет примерно такой:
Это нормально – наш роутер пытается законнектиться по TCP 179 на указанные адреса (кстати, не забудьте проверить, разрешает ли ему это Windows Advanced Firewall). Настроим по схеме остальных участников и получим другой результат:
Для R1:
Для маршрутизатора 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 объявил сеть:
Всё хорошо – читаем строчку: выбран лучший путь до сети 192.168.1.0/24, он валидный, next-hop достижим и его IPv4-адрес 172.20.101.1, метрика не назначена, local pref тоже, веса нет, трасса – до автономной системы 65000, а там этот префикс и родился естественным путём.
Теперь со стороны ISP2:
Тут тоже всё нормально – префикс 192.168.1.0/24 получен от пира с именем Customer (под этим именем я добавлял R1 на R3), next-hop 172.20.102.1, никакие атрибуты не заданы. В таблице маршрутизации данный префикс также добавился и на R2:
И на R3:
Правда, стандартный вывод route print убогий, например, в нём не видно, от какого источника в route table пришёл какой маршрут, поэтому я пользуюсь своим костылём под названием ATcmd (кстати, надо будет его модернизировать).
Тут лучше заметен единственный BGP-маршрут.
Итак, декларацией о сетях (наличествующих или нет) обменялись. Теперь надо подумать, как обрабатывать информацию от peer’ов. Ведь пиры могут отправлять некорректную информацию, лишнюю или откровенно вредоносную – это всё ж EGP-маршрутизация, а не IGP.
Настраиваем политики BGP-пиринга на Windows Server 2012 R2
Логика этой части работы будет следующей. Есть дваНастраиваем политики 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? Интересная ситуация. Ну а дальше, думаю, будет ещё интереснее.
Удачных проектов!
