Настройка bgp 2 провайдера

Обновлено: 25.01.2025

For every complex problem, there is a solution that is simple, neat, and wrong.

BGP-балансировка, резервирование

Всем привет. У меня следующая ситуация.
есть 2 магистральных провайдера, с которыми установлены сессии БГП. В данный момент трафик балансирую между ними вручную, с помощью ната (фейковые сети распихиваю по анонсированным в того или иного провайдера реальным пулам). Данная схема досталась мне в наследство от предыдущих админов и не дает мне спокойно спать.

Я хочу сделать балансировку нагрузки между этими провайдерами и резервирование.
задачи:
1 Использоваться каналы обоих провайдеров должны более менее равномерно
2 Нат будет не статический, а cg на специализированной железке
3 Надо обеспечить отказоустойчивость. При падении провайдера1 чтобы весь трафик начинал ходить через провадера2 и наоборот.

Сейчас часть пулов анонсирована в провайдера1 и другая часть в провайдера2 и в случае падения одного из них связь пропадает у всех абонентов, кто в него натится и анонсится (абоненты с реальными адресами)

Что хочу сделать - анонсировать все имеющиеся реальные пулы обоим провайдерам. Но пулы, через которые ходят в провайдер1 во второй провайдер анонсировать с BGP Prepend повыше, дабы удлинить путь и чтобы в этот путь пакеты шли только при падении провайдера 1. И наоборот пулы, которые ходят через второго провайдера анонсировать первому провайдеру с удлиненным препендом.

А гибкости нет в следующем, как мне кажется - что делать если в одном из провайдеров сильно ухудшилось качество канала? (потери, ддос и тд) Он по сути поднят. но по факту инет в нем толком не работает у абонентов и наш БГП микрот об этом ничего не знает. Да, существуют скрипты, которые будут проверять состояние канала и при его ухудшении либо его отключать либо менять настройки фильтров бгп или маршрутов и тд. Но хотелось бы как то обойтись без костылей в виде скриптов и дополнительных правил и маршрутов.

Здравствуйте господа форумчане :)
Выделили нам на днях сетку в RIPE'е, должны через пару дней и номер AS дать.
Теперь самое интересное - настройка цискаря.
К нам заходит 2 канала от ISP. Из финансовых соображений один канал пожирнее, второй поуже (планируется использовать когда первый падает).
У нас на том объекте стоит Cisco 2801. Full-View на неё пихать опасно, люди говорят не выдержит кошка и повесится :)
Теории про BGP начитался, на практике дел не имел, а юзеров живых предстоит сажать сразу на новую схему.
Есть у кого-нибудь пример конфига в самом простом исполнении, когда мы анонсируем свою сеть двум провайдерам, они в свою очередь отдают не full-view, а мы гоним всё в одного, а если он "лежит", то во второго.

> А в случае, если ширина каналов обоих провайдеров будет одинакова, как будет
> выглядеть конфиг ?
> "route-map ispB-out permit 100" я так понимаю ненужен будет, т.к. искусственно увеличивает
> цепочку 'к нам'. "ip prefix-list my_net" тоже уйдёт
условие "бэкапный канал" никто не отменил.

>> А в случае, если ширина каналов обоих провайдеров будет одинакова, как будет
>> выглядеть конфиг ?
>> "route-map ispB-out permit 100" я так понимаю ненужен будет, т.к. искусственно увеличивает
>> цепочку 'к нам'. "ip prefix-list my_net" тоже уйдёт
> условие "бэкапный канал" никто не отменил.
В этом случае мы их будем использовать как оба равноправных, по пропуску трафика, канала. В случае падени одного из них, связь останется на другом.

>>> А в случае, если ширина каналов обоих провайдеров будет одинакова, как будет
>>> выглядеть конфиг ?
>>> "route-map ispB-out permit 100" я так понимаю ненужен будет, т.к. искусственно увеличивает
>>> цепочку 'к нам'. "ip prefix-list my_net" тоже уйдёт
>> условие "бэкапный канал" никто не отменил.
> В этом случае мы их будем использовать как оба равноправных, по пропуску
> трафика, канала. В случае падени одного из них, связь останется на
> другом.
Выставляя одинаковый препенд обоим аплинкам вы вряд ли добьетесь одинакового входа.

Понятия BGP и AS (Autonomous System) очень тесно связаны. Всемогущая википедия говорит нам, что АС - это система IP-сетей и маршрутизаторов под управлением одного или нескольких операторов, имеющих единую политику маршрутизации с интернетом.
Давайте отбросим абстракции и представим живой пример. Пусть город у нас будет единой автономной системой и по аналогии как два города связаны магистралями, также и две АС связаны друг с другом посредством BGP. А внутри городов куча своих дорог, IGP-протоколов.
Картина примерно следующая:

В рамках протокола BGP автономная система это совсем не абстрактная вещь для удобства понимания. Это вещь вполне себе реальная, более того выдачей номеров AS занимаются специальные организации - RIR (Regional Internet Reistry) или LIR (Local Internet Registry). Глобально же всем этим рулит IANA, просто делегирует эту задачу RIR, региональным организациям, таким как RIPE NCC для Европы и стран Ближнего Востока:

А вот статус LIR может получить практически любая организация, и заниматься она будет выдачей номеров AS для относительно мелких контор, такой как в нашем примере. То есть для фирмочки ЛинкМиАп некий провайдер Балаган-Телеком мог бы стать тем самым LIR'ом. У него мы и возьмем AS Number, ASN 64500. У прова же будет номер 64501.
В качестве исторического экскурса укажу такой факт, что до 2007 года использовать можно было только 16-битные номер автономок, т.е. всего 65536 номеров, из которых 0 и 65535 зарезервированы.
Пул 64512-65534 являлся приватным и глобально не маршрутизировался, что-то вроде аналога приватных IP.
Пул 64496-64511 чисто для примеров и разного рода теоретических документаций. Из него мы номера и возьмем.
По состоянию на данный момент можно юзать уже 32-битные номера AS. Что характерно, данный переход куда как легче глобальной миграции с IPv4 на IPv6.
И да, автономки в неком смысле неразрывно связаны с блоками IP-адресов, т.е. в большинстве случаев за каждой AS закреплен какой-то блок IP.

Нет-нет, это отнюдь не неграмотность. PI означает Provider Independent, а не перепутанные буквы IP.
При подключении к прову вам выдается диапазон публичных адресов, которые зовутся PA или Provider Aggregatable. Получить подобный пул не составляет никакого труда, но не будучи LIR'ом, при смене провайдера эти самые PA-адреса нужно будет вернуть. Плюс ко всему допускается подключение только к одному провайдеру, если по факту. Короче говоря, меняете прова и теряете адреса, а новый пров выдаст вам новый диапазон. Но не всё так плохо!
У LIR можно купить блок адресов, который является "провайдеронезависимым" - PI, тот самый Provider Independent и вместе с ним в обязательном порядке ASN. Если брать конкретный случай, то это будет блок 100.0.0.0/23, который мы будем анонсировать посредством BGP своим соседям. Это именно наши IP-адреса, смена провайдера не будет означать их потерю.
И да, получить вожделенный блок PI задача непростая - нужно и документы собрать и подготовить обоснование вашего желание. Подробнее тут.
В мире где мы с вами живем отхватить более-менее крупный блок адресов уже невозможно. RIR уже не выдает новых блоков, разве что LIR еще делает это.
В общем номер AS и в довесок PI-адреса вы получаете в одной и той же организации.
Получив указанное выше богатство нужно отредактировать базу данных RIPE, о чем развернуто можно почитать здесь.
Наш пример подразумевает получение блока 100.0.0.0/23 и AS 64500. Если продолжить сравнение с городом, то мы его наконец-то назвали и получили охапку почтовых индексов.
Полезные статьи:
Инфраструктура сети: AS, PI, LIR etc.
Краткий FAQ на тему.
Установление BGP-сессии и процедура обмена маршрутами Если с завидной периодичностью BGP-сессия поднимается, а потом также отваливается, то в большинстве случаев это верный признак того, что не проходят keepalive. Порочный цикл обычно имеет величину 60x3=180 секунд или 3 минут (так настроен HOLD-таймер по-умолчанию. Если такое происходит, то искать источник проблемы следует на L2-уровне. Это может быть, например, плохое качество связи, забитый канал, перегрузка на интерфейсе или банальные CRC Errors на нем же.

Ну-с, приступим? Для начала простое - настройка интерфейсов.

Назначим и Loopback-интерфейсу какой-нибудь адрес, чтобы далее проверить связность:

А теперь самое вкусное - настройка BGP. Будем разбирать каждую строчку.

Сначала поднимаем процесс BGP и назначаем AS Number, именно тот, что выдал нам LIR!
Далее настраиваем пиринг, задаем информацию о соседе:

Маршрут говорит нам, что пакеты идущие в эту сеть будут дропнуты. Но это по плану, так надо. Просто напросто при наличии более конкретных маршрутов (маска больше /23, т.е. /24. /30. /32), то следуя правилу Longest Prefix Match будут выбираться именно они.
Радуемся. В BGP-таблице отобразился локальный маршрут:

Теперь если мы настроим процесс BGP и нужные маршруты на всех устройствах нашей схемы, то таблички BGP и маршрутизации на бордере (border - пограничный маршрутизатор сети) станет такой:

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

Схема будет следующая:

Условие: Настройки маршрутизаторов несущественны. Никаких фильтров маршрутов не настроено. Почему на одном из соседей отсутствует альтернативный маршрут в сеть 195.12.0.0/16 через AS400?

R3 получает два маршрута в сеть 195.12.0.0/16: один через R1, другой через R2.
Они равнозначны, но R3 должен выбрать только один из них. Делается это на основе IP-адреса, который меньше у R2.
Соответственно R3 анонсирует своим соседям только один маршрут через R2 до данной сети. R2 его не получает, разумеется, а вот R1 он этот маршрут изучит.
В итоге R1 получит два анонса об этой сети, а R2 только один.
Это очень простая в постановке задача с нетривиальным ответом.

Мимо данной темы в контексте BGP и подключения к прову попросту невозможно пройти. Вот наша уютная компания уже имеет AS Number и вооружилась ворохом PI-адресов. При организации стыка с провайдером Балаган-Телеком нас строго спросят - "будем фулл вью или ограничимся дефолтом?"
Всё, что было у нас выше - это Full View. Маршрутизатор будет изучать все без исключения маршруты Интернета. Наш теоретический случай предусматривает штук пять-шесть маршрутов, но в действительности их более 400000. В итоге нам и один провайдер анонсирует 400 тысяч маршрутов и другой столько же. А вдруг будет еще резервный пров? Получите распишитесь, в итоге больше миллиона маршрутов.
Ну, и чего теперь, отваливать сотни нефти за мощную циску?

Вот так выглядит саммари маршрутной таблицы route-server.ip.att.net, одного публичного сервера. Можно стучаться телнетом.
По факту не всем автономкам нужно курить Full View, даже более-менее крупным компаниям достаточно Default Route и погнали. Идея простая. Вместо вороха точных маршрутов нам приходит по одному маршруту по-умолчанию от каждого из провайдеров. Впрочем, это может происходить не только вместо, но и вместе.
Разберемся в плюсах и минусах обоих случаев.
При работе с Full View вся структура интернета у вас перед глазами. Вы можете посмотреть трассу от себя до любого адреса глобальной сети:

И вы знаете, какие AS ведут к сети назначения, а RIPE позволяет узнать, какие провайдеры обеспечивают передачу. И мы можем без проблем следить за всеми изменениями сети. Даже если где-то далеко на крайних хопах у кого-то что-то отвалится (т.е. не обязательно у вас или одного из ваших провайдеров), BGP обнаружит это и перестроит таблицу маршрутизации в соответствии с изменением топологии, например, пустит трафик через второго провайдера.
И мы вольны гибко рулить маршрутами, тонко настраивая алгоритм выбора наилучшего пути. Допустим, трафик до яндекса мы будем пускать через "Балаган Телеком", а вот уже до гугла - через "Филькин Сертификат". Это будет load balancing - распределение нагрузки.
Сделать это можно, например, путем настройки приоритета маршрутов для определенных префиксов.
Ваш выбор без вариантов Full View, если ваша AS транзитная, т.е. к вам по BGP будут подключены еще клиенты.
Плюсов много, но расплатой здесь будет производительность. Готовьтесь к высокой утилизации оперативки и долгому изучению маршрутной информации после подъема BGP-сессии. Например, даже при кратковременном падении линка до вышестоящего провайдера на полное восстановление уйдет несколько минут.
А теперь Default Route. В первую очередь - это огромная экономия ресурсов нашего оборудования. Обслуживать тоже проще, больше нет задачи гонять тысячи и тысячи маршрутов внутри нашей AS. С другой стороны вы понятия не имеете о состоянии интернетов и доступности конечных узлов - вы тупо шлете трафик на дефолт, прилетевший от провайдера, апстрима (upstream). И если проблема где-то дальше, вы о ней не будете иметь понятия, а как следствие падение части предоставляемых сервисов. В этом месте мы отдаем всё на откуп вышестоящему провайдеру, надеясь, что там BGP быстренько перестроится и снова всё взлетит.
Балансировка и распределение входящего трафика не пострадает, мы этим сможем рулить, а вот управление исходящим накроется.

Давайте резюмировать. Если у вас нет цели гонять через себя транзитный трафик (подключать через себя другие AS) и не требуется гибкое распределение исходящего трафика, то вам дорога к Default Route.
Но вот точно не имеет смысла принимать от одного провайдера анонсы Full View, а от другого Default Route, т.к. один линк всегда будет простаивать и не станет гонять через себя исходящий трафик, ведь выбираться будет более специфический маршрут, который точно найдется среди анонсированного вам Full View.
Но ничего не мешает брать от всех провов Default Route и в нагрузку определенные префиксы (конкретно этого провайдера, например). Тогда до нужных ресурсов у вас будут специфические маршруты, но при этом без Full View.
Взглянем на пример настройки Default Route для линка в нижестоящему маршрутизатору:

Default Route - это совсем не противопоставление Full View. Не обязательно жестко выбирать между тем или другим.
Никто не мешает использовать Default Route как дополнение к Full View. Или, например, Default Route и набор специфических маршрутов.
Looking Glass - крайне мощный инструмент при работе с BGP. Это некоторое множество серверов в глобальной сети, который позволяют взглянуть на сеть извне. Можно объективно проверить доступность узлов, посмотреть через какие AS трафик идет к нашей автономке, запустить трассировку до нашего блока IP.

Несколько простых движений, и вот мы уже видим как наши анонсы выглядят извне. Например, вы сможете узнать трассу, по которой к вам возвращаются пакеты. Обратный маршрут может отличаться от первоначального.
Существуют организации, следящие за анонсами BGP в сетях, и в случае аномалий/коллизий уведомляют владельцев этих сетей - BGPMon, Renesys, RouteViews.
Эти организации предотвратили несколько аварий глобального характера.
А, к примеру, сервис BGPlay позволяет визуализировать информацию о распространении маршрутов.
На NAG.ru есть годная статья о глобальных BGP "катастрофах" вроде "AS 7007 Incident" или "Google's May 2005 Outage".
А вот здесь замечательная статья по различным инструментам для работы с BGP.
И еще вдогонку Список Looking Glass серверов.

И еще маленькое отступление перед погружением в пучины маршрутизации. Есть на эту тему годное мозговыносящее чтиво MPLS Enabled Application. Так что там с понятиями в заголовке? Это никакие не уровни сетевой модели, среды или некие моменты передачи данных, а лишь абстрактное деление.
Control Plane - уровень управления, где работают служебные протоколы, которые обеспечивают условия для передачи данных. Вот запускается BGP, следует по всем своим агрегатным состояниям и обменивается маршрутной информацией. Или же когда в MPLS-сетях LDP распределяет метки на префиксы. Таким же макаром обсуждавшийся уже STP обменивается BPDU и строит L2-топологию.
Все эти процессы живут в рамках Control Plane.
А вот Data Plane, передающий уровень - это уже передача полезных данных клиента.
Часто случается, что данные с этих двух уровней ходят в разных направлениях как бы "навстречу друг другу". Таким вот образом маршруты передаются из AS100 в AS200, чтобы в свою очередь AS200 могла передать данные в AS100.

И на разных уровнях могу быть совершенно отличные принципы работы. В том же MPLS на Data Plane создается само соединение, а непосредственно данные передаются посредством заранее определенного пути LSP. Сам же путь определяется по обычному TCP/IP стандарту, т.е. от одного хоста к другому.
Тут нужно понять назначение этих уровней и разницу в них.
Это крайне важный вопрос для BGP. Анонсируя свои маршруты вы одновременно создаете путь для входящего трафика - маршруты исходят от вас, а вот трафик течет к вам.

Что у нас там с маршрутами?
Вот имеется таблица BGP, которая включает в себя все полученные от соседей маршруты:

Короче говоря, даже если у нас несколько маршрутов до сети 100.0.0.0/23, то они все окажутся в этой таблице, и неважно какие из них лучше, а какие хуже.

Но также есть и таблица маршрутизации, о которой мы уже столько говорили. И вот уже в ней содержатся только лучшие маршруты. Таким же образом BGP анонсирует своим соседям не все подряд маршруты, а только лучшие. Вы никогда не получите от одного и того же соседа два маршрута в одну сеть.
Какие у нас будут критерии выбора лучших маршрутов? Давайте разбираться.
1. Значение Weight должно быть максимальным (локально для маршрутизатора, актуально для Cisco);
2. Максимальное значение Local Preference (для всей AS);
3. Предпочтения для локального маршрута роутера (т.е. next hop = 0.0.0.0);
4. Самый короткий путь через автономки (смотрим у кого AS_PATH короче);
5. Миниальный Origin Code (IGP < EGP < incomplete);
6. Минимальный MED (передается между автономками);
7. При этом путь eBGP лучше, чем iBGP;
8. Выбор пути через ближайшего IGP-соседа;
При выполнении данного условия, кстати, нагрузка между равнозначными линками будет балансироваться.
А вот эти условия могут у разных вендоров отличаться.
9. Выбор самого старого маршрута для eBGP-пути;
10. Выбор пути через нейбора с самым маленьким BGP router ID;
11. Аналогично, но сосед должен быть с наименьшим IP-адресом.
Сложно? Сложно. Критериев и различных атрибутов много, и опять таки они сложные - сходу тяжело понять. Остановимся чуть позже на принципах выбора маршрутов.

AS-Path ACL
Prefix-list
Weight
Local Preference
MED

Статья 2013 года, впервые опубликована на сайте учебного центра “Сетевые Технологии”. Продублирована тут для сохранения статьи (ссылка на уц не работает).

Введение

BGP (Border Gateway Protocol) — это основной протокол динамической маршрутизации, который используется в Интернет.

BGP оперирует большими объемами данных (текущий размер таблицы для IPv4 порядка 450-500 тысяч маршрутов) и принципы его настройки и работы отличаются от внутренних протоколов динамической маршрутизации (IGP).

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

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

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

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

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

Так как в задачи статьи не входит детальное описание принципов работы BGP, остановимся на этом кратком описании.

В конце статьи все утилиты, ресурсы и сайты со статистикой, которые использовались в статье, перечислены с кратким описанием. Там же даны пояснения некоторым терминам.

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

Вся статистика, которая приведена в статье, актуальна на момент написания статьи и может отличаться при просмотре в последующие дни.

Общая статистика BGP

При изучении и настройке BGP очень полезными могут быть различные утилиты и статистические данные.

С точки зрения изучения BGP, они позволяют лучше понять как работает протокол, как выбираются маршруты, какая текущая ситуация в Интернет с точки зрения различной статистики.

Например, первое, что, как правило, встречается при описании основ BGP, это то, что BGP работает между автономными системами.

Рисунок 1. С точки зрения BGP Интернет выглядит как множество соединенных между собой автономных систем.

На рисунке 1 изображена небольшая часть сети, относительно автономной системы 60953, которая будет использоваться в примерах (эта схема сгенерирована утилитой BGPlay).

Каждая автономная система, которая обозначена на схеме, на самом деле внутри состоит из множества маршрутизаторов (цветовые обозначениях, которые используются в схеме, будут объяснены далее).

Для того чтобы немного лучше понимать масштабы работы BGP, далее приведено немного общей статистики.

Количество префиксов и автономных систем с которыми работает BGP:

На момент написания статьи, количество автономных систем было порядка 44 тысяч, а префиксов IPv4 более 500 тысяч.

В этом отчете можно также посмотреть более подробную информацию по каждой стране.

Если присмотреться к количеству соседей различных компаний, то достаточно просто понять, что первые в списке, как правило, операторы связи.

Bogon-префиксы

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

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

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

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

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

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

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

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

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

Использование утилит при настройке BGP

В этой части статьи использование различных утилит рассматривается на примере автономной системы 60953 (далее AS60953). Эта автономная система выполняет роль компании, которая недавно приобрела AS и свой блок адресов IPv4 и настроила подключение к двум провайдерам с использованием BGP.

Team Cymru предлагает свой вариант краткого вывода whois, который отличается компактным и удобным представлением информации.

Рисунок 10. Whois от Team Cymru.

Кроме whois можно воспользоваться другими ресурсами, которые предоставляют не только регистрационную информацию как whois, но и другие статистические данные и информацию о префиксе или автономной системе.

Ресурсы, на которых можно посмотреть различную дополнительную информацию и статистику об определенной AS (на примере AS60953):

Далее примеры приведены с сайта RIPE NCC.

AS60953 анонсирует один префикс 185.20.218.0/23 в Интернет и подключена к двум провайдерам (два соседа BGP). На рисунке 12 видно, что изначально AS60953 была подключена только к одному провайдеру, а через день-два подключилась ко второму. В конце статьи этот момент будет показан в динамике в утилите BGPlay.

Для настройки BGP характерно то, что управлять исходящим трафиком из локальной автономной системы клиента достаточно легко. И, что также важно, легко проверить, через какого провайдера идет исходящий трафик (особенно, если провайдеры используются в варианте основной/резервный).

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

Удобная и простая утилита для проверки политики для входящего трафика – looking glass (LG). Сервера LG позволяют проверить каким образом префикс виден в Интернет и через какого из провайдеров пойдет трафик идущий в эту сеть. Как правило, на LG доступны такие команды (или часть из них):

show ip bgp summary
show ip bgp
show ip bgp regex
traceroute
ping

Для того чтобы посмотреть как префикс 185.20.218.0/23 видится соседями коллекторов RIS, можно воспользоваться поиском, который предоставляет информацию о том, какие маршруты используют соседи коллекторов и показывает атрибуты маршрутов.

Один из способов управления входящим трафиком – использование AS path prepending (административное добавление автономных систем в путь, который анонсируется с префиксом BGP). Наименьшее количество автономных систем по пути к получателю – это один из основных критериев по которым BGP выбирает лучший маршрут. Поэтому, увеличив количество автономных систем, которые анонсируются вместе с префиксом соседям, можно повлиять на входящий трафик (этот метод не во всех случаях позволяет добиться необходимого результата, но является одним из самых простых и надежных). Для того чтобы это сделать, надо настроить политику работы с соседями так, чтобы префикс анонсировался провайдерам с добавленными нужное количество раз номерами локальной автономной системы.

Однако, при первом знакомстве с BGP может быть совершенно непонятно какое количество автономных систем добавлять для того чтобы добиться результата: 1, 2, 5 или, может быть, 20. Не понятно о каком порядке идет речь. И хотя LG-сервера позволяют проверить как повлияла политика и достаточное ли количество раз добавлена AS, информация о статистике может помочь сориентироваться в порядке значений.

Статистика о длине пути от коллекторов RIS к AS60953 представлена ниже.

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

BGPlay показывает всю информацию с точки зрения соседей коллекторов RIS. Это позволяет понять как именно входящий трафик попадает в выбранную автономную систему. Кроме того, утилита в динамике показывает как меняются пути со временем, при изменении настроек или добавлении новых подключений (который могут выполняться как с исходной AS, так и провайдерами по пути к коллекторам).

Рисунок 18. Пояснения к интерфейсу утилиты BGPlay

Для примера на рисунке выше и в следующем, используется AS60953. На схеме она обозначена красным цветом. Синим обозначены автономные системы, которые являются соседями коллекторов RIS. Коллекторы RIS собирают всё информацию от соседей, а утилита BGPlay обрабатывает её и представляет в графическом виде.

В примере выбран интервал времени, начиная с момента перед тем как AS60953 была подключена к первой автономной системе и до того момента как было настроено второе подключение. Две соседние автономные системы (AS35320 и AS61034) это провайдеры к которым подключена AS60953. Первым было настроено подключение к AS35320, а затем подключение к AS61034.

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

Рисунок 19. Пример использования утилиты BGPlay для AS60953.

Используя ссылку можно запустить утилиту BGPlay и посмотреть все эти изменения в динамике самостоятельно. Однако, расположение автономных систем будет не такое как в показанных рисунках, так как утилита сама их расставляет (вы можете самостоятельно расположить их так, как вам удобно, перемещая объекты).

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

Читайте также: