Балансировка двух провайдеров на основе bgp и eem

AS-PATH Prepend

Попробуем применить этот метод в нашей сети. Для этого создадим на CSR два route-map и используем их:

Теперь в сторону ISP#1 префикс 172.16.9.0/24 будет анонсироваться с AS-PATH, удлиненным на три номера AS65000, а в сторону ISP#2 тоже самое будет делаться для префиксов 172.16.7.0/24 и 172.16.8.0/24.

Теперь, в идеале, трафик для каждой группы префиксов должен поступать через своего провайдера, а в случае падения одного из uplink, начнет работать анонс с prepend. Например, при падении ISP#2 трафик для 172.16.9.0/24 не прервется, так как весь мир все равно «видит» этот префикс через ISP#1, хоть с удлиненным AS-PATH.

Этот способ сработал бы, но тут в игру вмешиваются различные local preferences, которые провайдеры используют для клиентов и пиринга. Так как, при выборе маршрута атрибут LOCAL PREFERENCE имеет больший приоритет, чем AS-PATH, внутри каждого провайдера наш prepend не будет играть роли и трафик всегда будет направляться через клиентский канал. В нашей сети этот метод сработает только для AS65050, так как она присоединена в обоим провайдерам.

Посмотрим подробней.

Действительно, на R5 все хорошо:

На основе атрибута AS-PATH для каждой группы префиксов выбран оптимальный маршрут через своего провайдера, что подтверждает трассировка.

Но вот на R11 (AS65110) все не так радужно.

Трафик до обоих хостов идет к нам через один и тот же пятисотмегабитный стык.

Причина как раз в local preference. Смотрим на R13 провайдера ISP#2:

На маршрутизаторе все BGP-анонсы наших сетей в двух экземплярах:

• полученные через клиентское присоединение (next-hop 192.168.103.100);
• полученные через пиринг (next-hop 192.168.200.12).

Но, несмотря на длинный AS-PATH, для префиксов 172.16.7.0/24 и 172.16.8.0/24 best-маршрут – маршрут с local preference 120 через клиента, т.е. через нас, а не через пиринг. Получается, что ISP#2 направит весь трафик наших абонентов через канал 500Mbps. И, если за этим провайдером окажется дата-центр какого-нибудь крупного контент-провайдера (например VK.com), то это приведет к перегрузке на канале и проблемам с сервисом.

Получается, что стандартный AS-PATH prepend нам не поможет.

Стандартные ограничения и пути их обхода

В динамической маршрутизации есть множество способов наделать ошибок, поэтому реализации протоколов включают стандартные ограничения для предотвращения типичных проблем. В то же время граница между ошибкой и необычной, но осмысленной настройкой бывает тонкой.

В качестве примера рассмотрим опцию . По умолчанию BGP откажется устанавливать соединение с соседом, если он не находится в одном сегменте канального уровня (то есть между соседями есть промежуточные маршрутизаторы). Обычно это вполне логичная политика: маршрутизировать трафик через кого-то, кто с вами не в одной сети, очевидно невозможно.

Однако BGP достаточно абстрактный протокол по сравнению со всеми остальными и позволяет установить для маршрутов свой шлюз. Из-за этого BGP нередко используют как метод автоматической передачи списков сетей, а что с этими сетями делать, каждый уже решает сам.

Компания Team Cymru таким способом предоставляет всем желающим актуальные списки сетей, которые еще не выделены ни одной компании и поэтому не должны появляться в интернете, — если к вам приходит трафик из них, это явный признак IP spoofing.

Поскольку их сервер маршрутов находится где-то далеко в интернете и маршрутизировать трафик через него самого не предполагается, ограничение на нахождение соседей в одной сети к нему неприменимо. В этом случае нам и поможет опция , которая устанавливает максимально допустимое число промежуточных маршрутизаторов:

Loopback Interfaces

Loopback interfaces часто используются IBGP peer’ами. Приемущество использования loopback interfaces заключается в том, что настройка маршрутизации перестает быть связана с IP адресом физического интерфейса. При этом, даже если физический интерфейс будет down, это никоим образом не повлияет на маршрутизацию между автономными системами, т.к. он будет использовать некий псевдо-ip адрес интерфейса loopback, как идентифицирующий данный роутер.

Использование Loopback Interfaces

На приведенном выше рисунке роутеры A и B обмениваются таблицами маршрутизации по IBGP в пределах AS 100. Если при конфигурировании роутера A в качестве IP адреса neighbor’а мы укажем IP адрес одного из его eth iface’ов, то все, конечно же, будет работать. До тех пор, пока этот eth iface по каким-то причинам не упадет. Если это случится, то обмен таблицами маршрутизации, равно как и траффиком, прекратится в результате того, что станет невозможным установить TCP connection между раутерами A и B.

Поэтому, вместо того чтобы указывать IP адрес eth iface’а раутера B, мы сделаем следующее:

а) сконфигурим раутер B таким образом, чтобы он получил некоторый дополнительный IP адрес — адрес его loopback iface’а.

б) настроим обмен таблицами маршрутизации между роутерами A и B таким образом, что на роутере A в качестве IP адреса команде neighbor будет указан IP адрес loopback iface’а роутера B.

в) Роутер B сконфигурим таким образом, чтобы IP адрес выходящих с него пакетов — был IP адрес интерфейса loopback.

Конфигурация роутера «A»:

!Router A
router bgp 100
neighbor 150.212.1.1 remote-as 100

Конфигурация роутера «B»:

!Router B
loopback interface 0
ip address 150.212.1.1 255.255.0.0
!
router bgp 100
neighbor 190.225.11.1 remote-as 100
neighbor 190.225.11.1 update-source loopback 0

Таким образом, в конфигурации роутера A мы можем указать IP адрес loopback iface’а роутера B (150.212.1.1) в команде neighbor.

Loopback ifaces редко используются на роутерах, которые работают по EBGP, поскольку эти роутеры и так зависят от непосредственного физического соединения друг с другом — то есть при падении одного из iface’ов на одном из роутеров связь так или иначе будет прервана, будь то eth или serail iface’ы.

Community strings

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

Community strings — это произвольные значения вида (вроде 64500:111), которые можно присвоить анонсам на выходе и использовать в качестве критерия в политике на входе. В общем случае смысл конкретных значений определяется настройками, хотя и существует несколько стандартных значений, к примеру , которое говорит маршрутизатору не распространять анонс остальным.

Транзитные провайдеры часто предоставляют клиентам такую возможность. В разделе BGP Services/Features в Cogent User Guide (двадцатая страница) можно увидеть целый набор опций для установки и контроля над тем, кому Cogent будет анонсировать ваш маршрут (никому, всем, отдельным регионам мира). У других провайдеров тоже обычно есть подобные документы — вот, к примеру, для российского RETN.

Предположим, вы хотите дать своим соседям возможность выставить на вашей стороне для их анонсов. Пусть ваша автономная система — 64500, а у клиента — 64496.

Сначала рассмотрим, как со стороны клиента отправить провайдеру строку. Отправим условному провайдеру анонс с . Вот как это можно сделать в FRR:

Теперь рассмотрим, как ее использовать для определения политик на стороне провайдера. Установим для анонсов с такой строкой в 50 (меньше значения по умолчанию):

Убедиться, что на провайдерской стороне все работает, можно все той же командой :

Bogon-префиксы

Одна из первых вещей, которую изучает человек, решивший побольше узнать о сетях, это что такое IP-адрес, какие диапазоны адресов бывают и что есть, например, частный диапазон адресов (описан в RFС 1918). О котором говорится, что эти сети не будут маршрутизироваться в Интернет. Но, к сожалению, бывает так, что адреса частного диапазона попадают в анонсы BGP.

Можно посмотреть статистику по анонсам префиксов, которые не должны встречаться в Интернет (не только частный диапазон), но всё же анонсируются и какая автономная система их анонсирует. Такие префиксы называются bogon (иногда термин bogon используется для описания адресов, которые не выделены официально какой-либо организации или зарезервированы, а частный диапазон адресов описывается отдельно).

В отчете встречается сеть 192.168.1.0/24 из частного диапазона. Можно воспользоваться статистикой RIPE NCC для того чтобы проверить когда этот адрес анонсировался в последний раз (информация о времени нужна для утилиты BGPlay).
Суммарная статистика по сети 192.168.1.0/24: https://stat.ripe.net/192.168.1.0/24#tabId=at-a-glance

Первое, что отображает информация RIPE NCC, это то что это сеть частного диапазона адресов:

У регистратора RIPE NCC есть проект RIS , который предназначен для сбора, хранения и обработки информации о маршрутизации в Интернет, и предоставления результатов всему сообществу Интернет. Информацию собирают коллекторы RIS, которые распределены по миру. Автономные системы других компаний устанавливают связь с коллекторами RIS и отправляют им всю информацию, которая им известна. За счет этого RIS предоставляет много интересной и удобной информации в виде различных утилит.

И о том, когда сеть 192.168.1.0/24 была видна на маршрутизаторах RIS:

Зная информацию о времени, когда эта сеть была видна, можно воспользоваться утилитой BGPlay и посмотреть как распространялась информация об этой сети.

На схеме видно, что в это время эта сеть анонсировалась двумя автономными системами (отмечены красным цветом). Подробнее об интерфейсе утилиты написано в последней части статьи.

Вы можете запустить утилиту BGPlay самостоятельно и посмотреть как эти анонсы добавлялись и удалялись в сети:

Рисунок 9. Анонс сети 192.168.1.0/24 в BGPlay