BGP протокол: проблемы и пути решения

BGP (Border Gateway Protocol) — единственный протокол глобальной маршрутизации в интернете, так что если вы зарегистрировали в RIPE или ином RIR автономную систему, то неизбежно с ним столкнетесь. Ни один другой протокол не предоставляет столько возможностей фильтрации и модификации маршрутов. Но у гибкости есть и обратная сторона — в опциях легко запутаться. В этой статье мы рассмотрим некоторые распространенные проблемы и пути их решения.

Для примеров настроек мы будем использовать свободную реализацию стека протоколов FreeRangeRouting, которая работает на операционных системах на базе Unix и используется в специализированных сетевых дистрибутивах Linux, например Cumulus Linux и VyOS.

Автономная система с несвязанными частями

Считается, что все части автономной системы напрямую связаны между собой. Но в некоторых случаях приходится отступать от этого правила. При поэтапной миграции в другой датацентр это неизбежно. Точки присутствия в разных датацентрах с одним номером AS — нежелательная, но допустимая ситуация.

Казалось бы, достаточно разбить сеть на части — к примеру, 192.0.2.0/24 на 192.0.2.0/25 и 192.0.2.128/25, — настроить новый маршрутизатор на дополнительной точке присутствия и начать анонсировать оттуда 192.0.2.128/25. Но не все так просто: с параметрами по умолчанию все в интернете будут видеть обе части AS, но ваши собственные маршрутизаторы потеряют связь друг с другом.

Почему это происходит? Предположим, вы используете номер автономной системы 64500. Пусть между ее частями находится провайдер с номером 64501. Тогда AS path будет выглядеть так: 64500 64501 64500.

РЕКОМЕНДУЕМ:
Возможности NAT в netfilter iptables

AS path в BGP — не только критерий выбора путей, но и механизм предотвращения петель. Если вспомнить про заложенное в протокол предположение, что все части AS связаны напрямую, наш путь выглядит именно как петля.

Реализации BGP считают закольцованным и отбрасывают любой маршрут, где один и тот же номер AS встречается в пути более одного раза. Но также они часто предоставляют возможность отказаться от заданного по умолчанию заведомо безопасного поведения. Этот случай — один из них. Опция обычно называется allowas-in. В качестве параметра она принимает максимально допустимое число дублированных номеров AS. Настроим ее, чтобы две одинаковые AS в пути не считались петлей:

Конечно, с такими настройками ваш маршрутизатор может начать пропускать и настоящие закольцованные маршруты. К счастью, на практике они в большом интернете не встречаются: транзитные провайдеры подобные опции не включают и правильно делают. Во внутренней же сети вам ничто не мешает присвоить каждой независимой части отдельный номер AS из частного диапазона (64512–65534).

AS path prepend и контроль над входящим трафиком

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

У любой автономной системы, однако, есть контроль над длиной AS path в исходящих анонсах, и это можно использовать как косвенный механизм контроля.

Как мы уже видели, один и тот же номер AS не может появляться в пути дважды в разных местах (то есть когда между экземплярами одного номера есть третий), иначе такой путь считается закольцованным. Однако несколько экземпляров одного номера подряд петлей не считаются. Путь вроде 64500 64500 64555 64501 не вызовет у реализаций BGP никаких возражений. При этом две одинаковые AS не считаются за одну, так что этот путь будет длиннее, чем 64500 64555 64501.

Искусственное удлинение пути называется AS path prepend и часто используется для влияния на выбор пути другими сетями. Если у вас два провайдера и одному вы анонсируете с путем 64500, а второму с 64500 64500, маршрут через первого будет выглядеть для других сетей более привлекательным. По крайней мере, в теории.

Вот так в FRR можно сделать путь на три номера AS длиннее, чем он есть:

Теперь в show ip bgp мы увидим на выходе путь из трех копий нашей AS вместо обычного для локальных анонсов пустого пути:

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

Так что более разумно использовать т. н. community strings, если ваш транзитный провайдер их поддерживает.

Community strings

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрим на себя извне

Многие наверняка видели инструменты типа looking glass. Провайдеры нередко предоставляют интерфейс, с которого можно запустить ping и traceroute к указанному адресу из их сети. Обычно ничего другого и не нужно, но для отладки политик маршрутизации бывает полезно увидеть AS path. К счастью, транзитные провайдеры обычно дают и такую возможность. К примеру: Level3, Telia, Hurricane Electric.

Hurricane Electric поныне предоставляет доступ к своему looking glass еще и через telnet. Когда-то это был стандартный способ, реализации вроде Cisco IOS и Quagga или FRR предоставляют достаточно гибкое управление правами на выполнение команд, чтобы сделать такую конфигурацию безопасной и разрешить только просмотр данных. Глянем, через кого трафик из их сети пойдет в сеть Qrator (AS197068), за которой находится наш сайт. Отрезолвим tech-geek.ru (178.248.232.29) и выполним команду:

Узнать, кому принадлежит номер автономной системы, можно через whois: whois AS3491 скажет нам, что на момент написания статьи этот провайдер — PCCW Global. Маршрутизация в интернете нередко меняется, так что не удивляйтесь, если повторите и увидите другой результат.

Заключение

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

РЕКОМЕНДУЕМ:
Советы по настройке сети в Linux

Если вы не работаете в компании со своей AS, но вам хочется поэкспериментировать с маршрутизацией в похожих на реальные условиях, можно присоединиться к DN42 — виртуальной сети, которая моделирует интернет с BGP, DNS, whois и прочими атрибутами.