Коротко о настройке BGP и его диагностировании

31.05.2019

Как работает интернет?

Если на пальцах, то практически у каждого, кто подключен больше, чем к одному провайдеру (а тем более, у самих провайдеров) есть магическая сущность, которая называется автономной системой (AS) или по русски - АСка.

Всем своим соседям (не по дому, разумеется, а тем, с кем есть прямые соединения), владелец AS сообщает: "Чуваки! У меня есть AS номер XXX!" Это называется BGP-Анонсом.

Соседи принимают это во внимание и передают дальше. Вот владелец AS YYY всех оповещает: "чуваки! Через меня доступна ASXXX! Путь до нее: XXX YYY". Постепенно, у каждого участника этой вакханалии складывается маршрутная таблица, в которой всегда видно, что от своей ASZZZ до ASXXX можно дойти по маршруту "ZZZ YYY YYY1 XXX".

Всё это развлекательное мероприятие и называется "протокол BGP".

Радость от него была бы неполной, не будь в BGP возможности выбрать маршрут. От двух свои провайдеров можно получить разные маршруты до ZZZ. Если XXX подключен не только к YYY1, но и напрямую к YYY, то у него будет более выгодный маршрут всего из трех хопов, вместо четырех.

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

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

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

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

Как? А элементарно. Надо соседу, который сидит по ту сторону резервного канала, отдавать не просто свой номер AS, а целый маршрут до нее. Вот так: "XXX XXX XXX XXX XXX". Да-да, просто несколько раз указать свою же AS. Это называется "добавить препенды".

Возвращаясь к нашей картинке, AS XXX подключена к двум провайдерам: YYY1 - кривой, но с безнлимитным трафиком. YYY - устойчивый, но трафик за большое бабло. Владелец XXX предпочитает, чтобы пока работает YYY1, весь трафик гонялся через него. Поэтому специально для YYY сообщаем, что через нас видно "XXX XXX XXX". Поскольку маршрут от XXX до ZZZ напрямую через YYY теперь получается длиннее, то связь будет через YYY.

Главное, чтобы ни из одной точки интернета этот маршрут никогда не стал кратчайшим. Сколько препендов добавить обычно выбирается на глазок - ну 5-10. Более длинные маршруты в интернете встречаются редко.

http://to-the-future.livejournal.com/450700.html

Тема чертовски глобальная, в эти игры уже играют провайдеры.
В рамках этой статьи мы обсудим следующие моменты:
- Непосредственно протокол BGP, принципы его работы и настройку;
- Поднимем линк с провайдером через BGP;
- Вслед за этим настроим резервирование и балансировку линков;
- Также попробуем в резервирование без BGP, посредством IP SLA.
Прежде чем кидаться на амбразуры, давайте ка вспомним теорию. Поговорим о протоколах динамической маршрутизации в целом. Глобально они делятся на две категории по отношению к автономным системам - AS :
> IGP , Internal Gateway Protocol - внутренние нашей автономки.
> EGP , External Gateway Protocol - соответственно, внешние.
Далее обе эти категории делятся по принципу своей работы - DV (Distance Vector ) и LS (Link State ).
Как вы помните, внутренние мы уже рассматривали в общей статье о динамической маршрутизации. Речь об ISIS/OSPF/RIP/EIGRP. Таким образом, как следует из названия, эти протоколы занимаются распространением маршрутов внутри нашей сети. С этим всё понятно и прозрачно.
Теперь перейдем к EGP. В мире он представлен лишь одним-единственным протоколом - BGP , Border Gateway Protocol . Этот товарищ организует передачу маршрутов уже между целыми сетями (читай, автономными системами , AS ).
То есть какой-либо местный провайдер будет слинкован с вышестоящим поставщиком услуг именно посредством протокола BGP.
В общем применяется всё это примерно так:

AS. Автономные системы.

Понятия 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 и PA адреса

Нет-нет, это отнюдь не неграмотность. 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-адреса вы получаете в одной и той же организации.

Цитата: Еще запара...

Наш пример подразумевает получение блока 100.0.0.0/23 и AS 64500 . Если продолжить сравнение с городом, то мы его наконец-то назвали и получили охапку почтовых индексов.
Полезные статьи:
Инфраструктура сети: AS, PI, LIR etc .
.

BGP

BGP служит для передачи информации о наших публичных IP-адресах из своей AS в интернет, т.е. другим AS. И нет никаких исключений. Дата-центры таких гигантов как Google, Яндекс и прочих Майкрософтов подключаются к Интернету отнюдь не благодаря магии, а с помощью всё того же BGP.
Будучи человеком новым в этой сфере, можно подумать: "А на кой черт нужен этот стрёмный BGP, если существует няшный OSPF и вообще можно статических маршрутов накидать?"
Попробуем вкратце это объяснить. Если говорить начистоту, то OSPF при работе между зонами (т.н. area ) работает как заправский distance vector протокол. И вообще чисто в теории можно было бы заменить эти самые AS на православные Area и пилить на этой основе глобальную маршрутизацию. Проблема в том, что OSPF просто склеит ласты от гигантских объемов динамически изменяющейся маршрутной информации. Это раз. А два - во взрослых интернетах нельзя просто так взять и выделить некую Area 0 .
Что там у нас еще? RIP? EIGRP? Ой нет, спасибо.
IGP - вещь сугубо для внутреннего использования, не нужно, чтобы передаваемая этими протоколами маршрутная информация попадала к нашему аплинковому ISP . Даже если отбросить автономки, клиент очень редко поднимает с провом IGP в чистом виде (разве что при L3VPN ). Основная причина в том, что все без исключения IGP лишены возможности максимально гибко работать с маршрутами, те же LS-протоколы хотят знать всё или ничего (окей, можно настроить фильтрацию на границах Area, но это всё костыли).
Что мы имеем? С IGP нам придется вываливать информацию о приватной части сети третьим лицам. Окей, можно городить политики импорта между IGP-процессами, но и это такое себе.
В данный момент глобальная сеть имеет больше 450000 маршрутов. Если даже представить, что уютные OSPF/ISIS могли бы хранить всю эту гигантскую топологию Глобальной Сети, то время расчета алгоритмов SPF затянулось бы на неопределенный срок. А вот и живой пример Яндекса , иллюстрирующий опасность использования IGP вместо глобальных решений.
Именно для этого взаимодействие между AS идет с помощью специального протокола. Какие к нему применяются критерии?
1. Обязательно он должен быть дистанционно-векторным (distance vector ). Маршрутизатору не нужно рассчитывать маршрут до каждой сети в интернете. Всё, что ему нужно - выбрать один из предложенных.
2. Требуется гибкая система фильтрации маршрутов . Нужно всегда знать, что следует анонсировать соседям, а что нет.
3. Нужна легкость масштабирования , конечно, защиту от образования петель , а также систему управления приоритетами маршрутов .
4. Высокая стабильность . Это невозможно переоценить. В случае с BGP за качество стыка отвечают как минимум две организации, а значит повышается вероятность потерь/повреждения маршрутной информации при её путешествии во враждебной среде.
5. Система свой-чужой . Протокол должен знать, где его AS, а где чужие.
В горниле этих жестких критериев и родился BGP . Пока рассмотрим основные моменты функционирования этого протокола, а нырнем совсем глубоко позже.
Следует знать, что BGP делится на IBGP и EBGP.
IBGP - передает маршрутную информацию в рамках одной AS. Да, вы не ослышались, BGP умеет и внутри AS, но об этом не сегодня.
EBGP - то, о чем мы и будем говорить, основная среда обитания BGP - между автономными системами.
О нем и пойдет разговор.

Установление BGP-сессии и процедура обмена маршрутами

Будем оперировать самой стандартной ситуацией, когда мы имеем прямой стык с провайдерским шлюзом.

Железки между которыми поднимается BGP-сессия зовутся BGP-пирами или же BGP-соседями (peer or neighbor )
Протокол BGP не ищет соседей в полностью автоматическом режиме, нужна предварительная настройка.
Разберем процесс установления соседства.
1. Сначала состояние соседства у нас IDLE , тишина.

Состояние IDLE означает отсутствие маршрута к BGP-соседу.
2. Для успешной передачи данных BGP юзает TCP. Так что по факту пиры могут быть соединены не напрямую, а как-то так, например:

Но подключение к провайдеру в большинстве случаев будет прямым, тогда маршрут до соседа всегда будет подключенным непосредственно, т.е. directly connected .
BGP-маршрутизатор (aka BGP-speaker) слушает и шлет пакеты на порт TCP/179 . Состояние прослушивания называется CONNECT, длится оно недолго.
После отправки пакета и ожидания ответа от соседа маршрутизатор войдет в состояние ACTIVE .

R1 отправляет TCP SYN на все тот же TCP/179 соседа, тем самым поднимая TCP-сессию.

R2 возвращает TCP ACK с подтверждением, а также свой TCP SYN .

R1 подтверждает получение SYN от R2 .

Отлично, TCP-сессия установлена.
В каком случае BGP может зависнуть ACTIVE ?
- отсутствует IP-связность с R2;
- не запущен процесс BGP на R2;
- TCP/179 закрыт ACL.
Перед нами пример провала в установлении TCP-сессии. BGP будет останется в состоянии ACTIVE , иногда сваливаясь в IDLE , и снова обратно.
TCP SYN оправлен с R1 на R2 :

На R2 банально не запущен BGP, и R2 просто возвращает ACK , мол SYN от R1 получен. И вдогонку RST, означающий необходимость сбросить соединение.

Время от времени R1 будет повторять попытки установления TCP-сессии.
Будьте внимательны! Всегда проверяйте настройки ACL.
3. После установки TCP-сессии участники BGP начинают обмен пакетами с меткой OPEN .
OPEN - это самый первый тип сообщений в контексте BGP. Они отсылаются первоначально для согласования параметров.

Сообщение несет в себе такие данные как версия протокола, AS Number, Hold Timer, Router ID.
Условия успешной BGP-сессии:
- Одинаковые версии протокола. Несовпадение вряд ли возможно, но все же;
- Конечно, должны совпадать AS Number в OPEN-сообщении и в настройках на удаленной стороне;
- Должны различаться Router ID.
Чуть ниже увидим наличие поддержки дополнительных возможностей протокола.
Итак, R2 получает OPEN от R1 , и отправляет ответный OPEN и вдобавок KEEPALIVE , означающий успешное получение OPEN-пакета от R1 . Всё это становится отмашкой для R1 , и тот переходит в состояние Established .

Какие тут могут быть косяки?
а) Неверный AS Number . На R2 у нас настроена AS 300, а вот R1 уверен, что его сосед находится в AS 200.
Вот R2 отправляет OPEN:

R1 видит, что ASN в сообщении не совпадает с настроенным и дропает сессию с сообщением NOTIFICATION . Данные сообщения отправляются как раз в случае возникновения каких-либо проблем для разрыва сессии.

При этом в CLI на R1 можно увидеть это:

б) одинаковый Router ID
R2 отправляет в своем OPEN-сообщении Router ID , совпадающий с этим значением ID у R1 .

R1 отвечает на это NOTIFICATION-сообщением , дескать что-то тут не так:

Сообщения в CLI роутера будут примерно такого вида:

После данной ошибки процесс BGP уходит в IDLE , а потом снова в ACTIVE , в попытке снова поднять TCP-сессию и отправить OPEN-сообщение . Мало ли, вдруг ситуация поменялась.
OPEN SENT - состояние по факту отправки OPEN-сообщения.
OPEN CONFIRM - состояние при получении OPEN-сообщения.

Цитата: Замечание

Если в конфигах различается Hold Timer , то будет выбран наименьший из них. А Keepalive Timer при этом будет рассчитан по формуле Hold Timer/3 , т.к. его значение в OPEN-сообщении не передается. Это значит, что у пиров может быть разный Keepalive.
Давайте разбираться на кошках. Вот на R2 настроено, что Keepalive 30, а Hold 170:

R2 шлет это в своем OPEN-сообщении . R1 его получает и начинает сравнивать: полученное значение 170, а у самого 180. Понятное дело, будет выбрано то, что меньше - 170, а после считаем Keepalive-таймер :

R2 будет слать свои Keepalive-сообщения каждые 30 секунд, а вот R1 - каждые 56. И ничего, что эти значения разные, главное Hold Timer у роутеров одинаковый и раньше времени сессию никто не дропнет.

Состояния OPENSENT и OPENCONFIRM очень кратковременные, и вы вряд ли успеете их зафиксировать.
4. И вот роутеры входя в состояние стабильное BGP-состояние ESTABLISHED . Значит сконфигурировано всё с обеих сторон верно, дзен достигнут.
У каждого маршрутизатора можно проверить Uptime , сколько процесс BGP пребывает в состоянии ESTABLISHED.

5. Сначала в таблице BGP в самом начале установки сессии имеется информация только о локальных маршрутах:

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

Давайте разбираться. Вот R1 передает для R2 свою маршрутную информацию, как это видно в дампе вайршарка. Path attributes - это атрибуты пути, такие как AS_PATH , который прямо говорит, что это маршрут из AS за номером 100. Далее идет NEXT_HOP , который информирует R2 , что ему выставлять в качестве шлюза для этого маршрута. Чисто в теории это может быть и не адрес R1 .
А вот атрибут ORIGIN расскажет нам об "истоках" этого маршрута, откуда он взялся.
IGP - прописан статически с помощью команды network или же получен по BGP.
EGP - маршрут получен с помощью одноименного протокола, но его вы уже не увидите, т.к. он вымер как мамонты.
Incomplete - в большинстве случаев означает, что раут пришел через редистрибуцию маршрутов .
Дальше мы видим NLRI – Network Layer Reachability Information , саму информацию о маршрутах. Тут мы и видим искомую сеть 100.0.0.0/23 .
Теперь поглядим на UPDATE от R2 к R1 .

Сообщения KEEPALIVIE подтверждают, что всё ок, информация получена.
Проверим информацию о сетях в таблице BGP:

А также в таблице маршрутизации:

При любых изменениях в сети передаются UPDATE-сообщения на протяжении всей BGP-сессии. И да, вы не увидите здесь синхронизации маршрутной информации как в том же OSPF. Оно и понятно, эти таблички слишком тяжеловесны, по несколько десятков мегабайт, гонять их туда-сюда нецелесообразно.
6. Идиллия наступила, и теперь с настроенной периодичностью маршрутизаторы будут слать KEEPALIVE-сообщения . Тем самым пиры говорят, что у них всё в порядке. По дефолту таймер отправки KEEPALIVE равен 60 секундам.

Цитата: Уточнение

Если с завидной периодичностью BGP-сессия поднимается, а потом также отваливается, то в большинстве случаев это верный признак того, что не проходят keepalive . Порочный цикл обычно имеет величину 60x3=180 секунд или 3 минут (так настроен HOLD-таймер по-умолчанию. Если такое происходит, то искать источник проблемы следует на L2-уровне. Это может быть, например, плохое качество связи, забитый канал, перегрузка на интерфейсе или банальные CRC Errors на нем же.

Процесс BGP шлет еще один тип сообщений - ROUTE REFRESH , эта волшебная просьба запрашивает у соседей заново все маршруты, но при этом не требуется перезапуск всего BGP-процесса.
Подробнее о типах сообщений можно почитать .
Finite-state machine в контексте BGP будет таким:

Тоже, но в виде анимации:

Вот теоретический вопрос. Пусть наша успешная BGP-сессия разменяла 24-часовой аптайм. Каких сообщений точно за это время не было?
Идем дальше.
Представим теперь сеть поинтереснее:

Взглянем на маршрутную таблицу BGP роутера R1 :

Интересно, тут не просто таблица NextHop"ов или устройств до нужной подсети. Здесь мы видим список AS, он же - AS-Path .
Таким образом для попадания в сетку 123.0.0.0/24 мы должны пройти AS 200 и AS 300 .
Разберемся с принципом образования AS-path:
1) Пока маршрут находится в пределах AS список пуст, т.к. роутеры прекрасно понимают, что полученный маршрут из этой же AS.
2) Но при анонсе маршрута соседу, BGP-peer"у, он добавляет в список AS-path номер своей AS.

3) При этом на соседской AS список остается прежним, т.е. только с номером изначальной AS.
4) При передаче маршрута от соседской AS дальше в начало списка добавляется номер текущей AS.

Ну и дальше по такой схеме при дальнейшей передаче маршрута внешнему соседу номер AS всегда будет добавляться в начало списка AS-path , т.е. они стекируются.
AS-path нужен маршрутизатору R1 не просто ради того, чтобы он знал путь до конечной сети, обычного Next-hop"a тут достаточно - маршрутизаторы все равно принимают решение на основе своей таблицы маршрутизации. Причин тут две.
> Избежание маршрутных петель, поэтому в AS-Path номера не должны повторяться.
Ну, точнее как... Они могут и должны повторяться если мы юзаем инструмент AS-Path Prepend или же в случае соединения частей одной AS, которые напрямую друг с другом не связаны.
> Благодаря AS-Path выбирается наилучший маршрут - по дефолту чем AS-Path короче, тем лучше.

Настройка BGP и практика

Будем оперировать и теорией и практикой, так будет проще понять происходящее. Снова в качестве подопытного кролика будет использована сеть ЛинкМиАп , при этом оставим на схеме только нужное:

Внизу у нас основной маршрутизатор msk-arbat-gw1 . Выпилим пока все старые настройки и будем конфигурировать с чистого листа. Чуть выше видим наших драгоценных ISP - Балаган Телеком и Филькин Сертификат. Каждый пров, конечно, имеет свою AS, наша сеть тоже. Но мы добавим еще одну конечную автономку, некий ЦОД в сети Интернет.
Производить настройку мы будем в идеальных условиях: каждая AS представлена одним-единственным маршрутизатором, не настроено никаких ACL, и всё соединено напрямую без промежуточных устройств.
Нужно поднять BGP-сессию с обоими провайдерами. Давайте разбираться, что нам потребуется для этого.
1. Наш AS Number и соответствующий блок IP-адресов. Это AS64500 и блок 100.0.0.0/23 ;
2. AS Number прова «Балаган Телеком» и его подсеть, с которой мы будем линковаться. AS64501 и линковая подсеть 101.0.0.0/30 ;
3. То же для провайдера «Филькин Сертификат». AS64502 и линковая подсеть 102.0.0.0/30 .

Цитата: Немного матчасти

Вообще-то при подключении по BGP линковыми адресами обычно становятся IP с маской /30 , которые выдает вышестоящий провайдер. Зачем это делается? Чтобы трафик шел публичными адресами, без всяких приватных IP посреди трассировки, типа 10.Х.Х.Х какого-нибудь. В этом нет ничего криминального, но всё таки этого правила придерживаются.

Ну-с, приступим? Для начала простое - настройка интерфейсов.
msk-arbat-gw1 R1(config)#int fa0/0 R1(config-if)#ip address 101.0.0.2 255.255.255.252 R1(config-if)#no shutdown R1(config)#int fa0/1 R1(config-if)#ip address 102.0.0.2 255.255.255.252 R1(config-if)#no shutdown

Назначим и Loopback-интерфейсу какой-нибудь адрес, чтобы далее проверить связность:
R1(config)#int loopback 0 R1(config-if)#ip address 100.0.0.1 255.255.255.255
А теперь самое вкусное - настройка BGP. Будем разбирать каждую строчку.
R1(config)#router bgp 64500
Сначала поднимаем процесс BGP и назначаем AS Number , именно тот, что выдал нам LIR !
Далее настраиваем пиринг, задаем информацию о соседе:
R1(config-router)#neighbor 101.0.0.1 remote-as 64501
Командой neighbor мы указываем того, с кем будем поднимать сессию. На указанный адрес 101.0.0.1 наш маршрутизатор последовательно отправит сначала TCP-SYN , а затем OPEN-сообщение . Здесь же указываем номер автономки, с которой у нас намечается пиринг - AS64501 .
Абсолютно симметричная конфигурация на противоположной стороне:
R2(config)#router bgp 64501 R2(config-router)#neighbor 101.0.0.2 remote-as 64500
В CLI появится сообщение:
*Mar 1 00:11:12.203: %BGP-5-ADJCHANGE: neighbor 101.0.0.2 Up
Ура? Ура, но проверим состояние процесса.

Одно состояние сменяет другое и вот достигнут Established . Маршрутизатор за это время отправил одно OPEN-сообщение и аналогичное получил, а также получил и принял по два KEEPALIVE .
Проверим о каких сетях знает BGP.
sh ip bgp

Ни-че-го. Смотрим на R2 .

И тут тоже самое.
А всё тут просто. До прописанной командой network сети должен быть точный маршрут, в противном случае она не окажется в таблице BGP. А муршрута нет:

А его и вписывать некуда, кроме разве что Loopback-интерфейса . Ну нет нигде этой сети. Исхитримся так:
R1(config)#ip route 100.0.0.0 255.255.254.0 Null 0
Маршрут говорит нам, что пакеты идущие в эту сеть будут дропнуты. Но это по плану, так надо. Просто напросто при наличии более конкретных маршрутов (маска больше /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 только один.
Это очень простая в постановке задача с нетривиальным ответом.

Full View и Default Route

Мимо данной темы в контексте 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 для линка в нижестоящему маршрутизатору:
balagan-router(config-router)#neighbor 101.0.0.2 default-originate
Тогда на нашем бордере таблица маршрутов будет такой:

Теперь кроме обычных входящих в Full View маршрутов будет присутствовать и маршрут по-умолчанию.

Цитата: Небольшая ремарка

Default Route - это совсем не противопоставление Full View. Не обязательно жестко выбирать между тем или другим.
Никто не мешает использовать Default Route как дополнение к Full View. Или, например, Default Route и набор специфических маршрутов.

Схема: Общая схема сети
Задание: Настроить фильтрацию со стороны провайдера таким образом, чтобы он передавал нам только маршрут по умолчанию и ничего лишнего.
То есть, чтобы таблица BGP выглядела так:

hostname balagan-router ! router bgp 64501 no synchronization bgp log-neighbor-changes network 101.0.0.0 mask 255.255.240.0 neighbor 101.0.0.2 remote-as 64500 neighbor 101.0.0.2 default-originate neighbor 101.0.0.2 prefix-list DEFAULT out neighbor 101.0.0.6 remote-as 64502 neighbor 101.0.0.10 remote-as 64503 no auto-summary ! ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0 hostname PhCert-router ! router bgp 64502 no synchronization bgp log-neighbor-changes network 102.0.0.0 mask 255.255.248.0 neighbor 101.0.0.5 remote-as 64501 neighbor 102.0.0.2 remote-as 64500 neighbor 102.0.0.2 default-originate neighbor 102.0.0.2 prefix-list DEFAULT out neighbor 102.0.0.10 remote-as 64503 no auto-summary ! ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0

Интересно почитать: О пользе и вреде полной таблицы BGP

Looking Glass и другие инструменты

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

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

Control Plane и Data Plane

И еще маленькое отступление перед погружением в пучины маршрутизации. Есть на эту тему годное мозговыносящее чтиво 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-адресом .
Сложно? Сложно. Критериев и различных атрибутов много, и опять таки они сложные - сходу тяжело понять. Остановимся чуть позже на принципах выбора маршрутов.

Схема: Текущая схема сети
Условие: Full View на всех маршрутизаторах
Если вы сейчас посмотрите таблицу BGP на маршрутизаторе провайдера Балаган Телеком , то увидите 3 маршрута в сеть 102.0.0.0/21 - сеть Филькина Сертификата . И один из маршрутов ведёт через нашу сети ЛинкМиАп .

Это говорит о том, что наш бордер анонсирует чужие маршруты дальше, иными словами наша AS является транзитной.
Задание: Настроить фильтрацию таким образом, чтобы наша AS64500 перестала быть транзитной.

Вуаля
router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 prefix-list LAN out neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list LAN out no auto-summary ! ip route 100.0.0.0 255.255.254.0 Null0 ! ip prefix-list LAN permit 100.0.0.0/23

Управление маршрутами

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

AS-Path ACL
Prefix-list
Weight
Local Preference

Много? Но только два первых могут фильтровать анонсируемые и передаваемые маршруты. Остальное - выставление приоритетов.

AS-Path ACL

Механизм этот очень мощный, но не пользуется особой популярностью. При помощи AS-Path ACL вы можете наглухо запретить прием анонсов от AS200, к примеру. Ну, вот не нужны нам от этой автономки анонсы, пускай будем получать их от другой.
Самое сложное - это запомнить все использующиеся при этом подходе выражения:

Давайте накидаем примеров, чтобы проще было понять.
_200_ Маршруты проходящие через AS 200
До и после номера AS идут знаки “_”, означающие, что в AS-path номер 200 может стоять в начале, середине или конце, главное, чтобы он был.
^200$ Маршруты из соседней AS 200
“^” означает начало списка, а “$” – конец. То есть в AS-path всего лишь один номер AS – это означает, что маршрут был зарождён в AS 200 и оттуда сразу был передан нам.
_200$ Маршруты отправленные из AS 200
“$” означает конец списка, то есть это самая первая AS, из неё маршрут и зародился, знак “_” говорит о том, что неважно, что находится дальше, хоть ничего, хоть 7 других AS.
^200_ Сети находящиеся за AS 200
Знак “^” означает, что ASN 200 была добавлена последней, то есть маршрут к нам пришёл из AS 200, но это не значит, что родился он в ней же – знак “_” говорит о том, что это может быть конец списка, а может пробел перед следующей AS.
^$ Маршруты локальной AS
Список AS-path пуст, значит маршрут локальный, сгенерированный внутри нашей AS.
Пример
Отфильтруем в нашей сети маршруты, появившиеся в AS64501 . То есть мы будем получать от этой автономки все "глобальные интернетовские" маршруты, но ни одного её локального.
ip as-path access-list 100 deny ^64501$ ip as-path access-list 100 permit .* router bgp 64500 neighbor 101.0.0.1 filter-list 100 in

hostname msk-arbat-gw1 ! interface Loopback0 ip address 100.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 speed 100 full-duplex ! ! router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 filter-list 100 in neighbor 102.0.0.1 remote-as 64502 no auto-summary ! ip route 100.0.0.0 255.255.254.0 Null0 ! ip as-path access-list 100 deny ^64501$ ip as-path access-list 100 permit .*

Hostname msk-arbat-gw1 interface Loopback0 ip address 100.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 speed 100 full-duplex ! ! router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 102.0.0.1 remote-as 64502 no auto-summary ! ip route 100.0.0.0 255.255.254.0 Null0 !

hostname PhCert-router ! interface FastEthernet0/0 description Balagan_Telecom_BGP ip address 101.0.0.6 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description LinkMeUp_BGP ip address 102.0.0.1 255.255.255.252 speed 100 full-duplex ! interface FastEthernet1/0 description Cloud_Internet ip address 102.0.0.9 255.255.255.252 duplex auto speed auto ! ! router bgp 64502 no synchronization bgp log-neighbor-changes network 102.0.0.0 mask 255.255.248.0 neighbor 101.0.0.5 remote-as 64501 neighbor 102.0.0.2 remote-as 64500 neighbor 102.0.0.10 remote-as 64503 no auto-summary ! ip route 102.0.0.0 255.255.248.0 Null0

hostname cloud-router ! interface Loopback0 ip address 103.0.0.1 255.255.255.255 ! interface Loopback1 ip address 120.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_BGP ip address 101.0.0.10 255.255.255.252 speed 100 full-duplex ! interface FastEthernet0/1 description Philkin_Certificate_BGP ip address 102.0.0.10 255.255.255.252 speed 100 full-duplex ! ! router bgp 64503 no synchronization bgp log-neighbor-changes network 103.0.0.0 mask 255.255.252.0 network 120.0.0.0 mask 255.255.255.0 neighbor 101.0.0.9 remote-as 64501 neighbor 102.0.0.9 remote-as 64502 no auto-summary ! ip route 103.0.0.0 255.255.252.0 Null0 ip route 120.0.0.0 255.255.255.0 Null0

Инструкция по использованию регулярных выражений

Prefix-list

По сравнению с предыдущим пунктом тут можно сказать всё просто.
Префикс-листы - это уже привычные нам сеть/маска, а мы просто указываем разрешить указанные маршруты или нет.
Синтаксис будет такой:
ip prefix-list {list-name} {deny|permit} {network/length}
list-name - собственно название списка. Оказывается обычно в виде name_in или name_out . Это как бы должно намекать нам на какие маршруты (входящие или исходящие) оно будет действовать.
seq - порядковый номер правила, по аналогии с ACL.
deny/permit - этот параметр определяет, запрещающее или разрешающее будет правило.
network/length - определяем сеть и маску, например, 192.168.14.0/24 .
Возможны еще два параметра - ge и le . Как и при настройке NAT, это логика "g reater or e qual " и "l ess or e qual ".
То есть можно задать и диапазон, а не конкретный префикс. Будет это, например, так:
ip prefix-list NetDay permit 10.0.0.0/8 ge 10 le 16
При это выбраны тогда будут следующие маршруты:
10.0.0.0/10, 10.0.0.0/11, 10.0.0.0/12, 10.0.0.0/13, 10.0.0.0/14, 10.0.0.0/15, 10.0.0.0/16
Пример
Давайте запретим принимать анонс сети 120.0.0.0/24 через конкретного провайдера (в нашем случае это будет "Филькин Сертификат"), а прием остальных разрешим. Запись вида 0.0.0.0/0 le 32 будет означать любые подсети с любой длиной маски, которая меньше или равна 32, т.е. 0-32.
ip prefix-list TEST_PL_IN seq 5 deny 120.0.0.0/24 ip prefix-list TEST_PL_IN seq 10 permit 0.0.0.0/0 le 32 router bgp 64500 neighbor 102.0.0.1 prefix-list TEST_PL_IN in

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

msk-arbat-gw1
hostname msk-arbat-gw1 ! interface Loopback0 ip address 100.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 speed 100 full-duplex ! ! router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list TEST_PL_IN in no auto-summary ! ip route 100.0.0.0 255.255.254.0 Null0 ! ! ip prefix-list TEST_PL_IN seq 5 deny 120.0.0.0/24 ip prefix-list TEST_PL_IN seq 10 permit 0.0.0.0/0 le 32

Route Map

Правила у нас до этого момента применяли без всяких условий, абсолютно на все анонсы - от пира и к пиру. И вот при помощи этих самых карт маршрутов (прочие вендоры зовут их политиками маршрутизации ) мы сможем очень гибко настраивать правила, ловко отсеивая анонсы.
Команда имеет вот такой синтаксис:
route-map {map_name} {permit|deny} {seq}
Что мы тут имеем?
map_name – имя карты, как ни странно;
permit/deny – говорим, что разрешаем или нет прохождение данных, подпадающих под условия нашей route-map ;
seq – номер правила в route-map ;
match – условие подпадания трафика под данное правило.
expression:

set – выбираем, что сделать с отфильтрованными маршрутами;
expression:

Пример:
Давайте укажем, что в подсеть 120.0.0.0/24 приоритетнее ходить через прова "Балаган Телеком", а вот в 103.0.0.0/22 уже через "Филькин Сертификат". Для этих действий нам потребуется атрибут Local Preference . Выше значение данного параметра - выше приоритет маршрута.
ip prefix-list TEST1_IN seq 5 permit 120.0.0.0/24 ip prefix-list TEST2_IN seq 5 permit 103.0.0.0/22 route-map BGP1_IN permit 10 match ip address prefix-list TEST1_IN set local-preference 50 route-map BGP1_IN permit 20 set local-preference 100 route-map BGP2_IN permit 10 match ip address prefix-list TEST2_IN set local-preference 50 route-map BGP2_IN permit 20 set local-preference 100 router bgp 64500 neighbor 101.0.0.1 route-map BGP2_IN in neighbor 102.0.0.1 route-map BGP1_IN in
Вот мы создали самых обычным образом prefix-list , которым выделяем подсеть 120.0.0.0/24 . При этом атрибут permit будет означать, что на данный префикс будут впоследствии применяться политики route-map . Дальше, прямо как в обычных ACL, идет неявное правило deny на всё остальное. В данном конкретном случае оно будет означать, что под действие созданной route-map попадет только 120.0.0.0/24 и больше ничего другого.
В созданной раут-мапе BGP1_IN разрешено прохождение маршрутной инфомации (permit же), попадающий под указанный prefix-list . Об этом говорит данная строчка:
match ip address prefix-list TEST1_IN
Этим анонсам мы зададим local preference величиной в 50, взамен стандартных 100:
set local-preferеnce 50
Теперь эти анонсы станут менее приоритетными.
Остается привязать карту к определенному BGP-нейбору:
neighbor 102.0.0.1 route-map BGP1_IN in
Итог такой:

Базовый конфиг других устройств.
msk-arbat-gw1
hostname msk-arbat-gw1 ! interface Loopback0 ip address 100.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 speed 100 full-duplex ! ! router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 route-map BGP2_IN in neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 route-map BGP1_IN in no auto-summary ! ip route 100.0.0.0 255.255.254.0 Null0 ! ip prefix-list TEST1_IN seq 5 permit 120.0.0.0/24 ! ip prefix-list TEST2_IN seq 5 permit 103.0.0.0/22 ! route-map BGP1_IN permit 10 match ip address prefix-list TEST1_IN set local-preference 50 ! route-map BGP1_IN permit 20 set local-preference 100 ! route-map BGP2_IN permit 10 match ip address prefix-list TEST2_IN set local-preference 50 ! route-map BGP2_IN permit 20 set local-preference 100 !

Прочие примеры мы рассмотрим далее.

Схема: Общая схема сети
Условие: ЛинкМиАп получает Full View от обоих провайдеров.
Тема: Поиск неисправностей.
От провайдеров: полная таблица маршрутов BGP
На маршрутизаторе msk-arbat-gw1 настроено распределение исходящего трафика между провайдерами Балаган Телеком и Филькин Сертификат. Трафик идущий в сети провайдера Филькин Сертификат, должен идти через него, если он доступен. Остальной исходящий трафик, должен передаваться через провайдера Балаган Телеком, когда он доступен.
При проверке исходящего трафика, оказалось, что при отключении Балаган Телеком, исходящий трафик к ЦОД (103.0.0.1) не идет через Филькин Сертификат.
Конфигурация:
neighbor 102.0.0.1 route-map OUTBOUND in no auto-summary ! route-map OUTBOUND permit 10 match as-path 10 set weight 1000 ! ip prefix-list LAN permit 100.0.0.0/23 ! ip as-path access-list 10 permit ^64502$ ! ip route 100.0.0.0 255.255.254.0 Null0
В остальном конфигурация стандартная.
Задание: Исправить настройки так, чтобы исходящий трафик в сети провайдера ISP2, к его клиенту и в сеть удаленного офиса компании, шел через провайдера ISP2.

Проблема в route-map OUTBOUND .
В ней не хватает правила, которое разрешает остальные обновления.
При текущих настройках, от провайдера Филькин Сертификат приходят только его сети.
В route-map надо добавить правило разрешающее остальные обновления:
route-map OUTBOUND permit 10 match as-path 10 set weight 1000 route-map OUTBOUND permit 20
Кроме того, для того чтобы, при доступности двух провайдеров, через провайдера Филькин Сертификат передавался только трафик в его сети, надо добавить route-map, которая повысит приоритет маршрутов полученных через Балаган Телеком:
neighbor 101.0.0.1 route-map WEIGHT in ! route-map WEIGHT permit 10 set weight 500
Итоговая конфигурация:
router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 prefix-list LAN out neighbor 101.0.0.1 route-map WEIGHT in neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list LAN out neighbor 102.0.0.1 route-map OUTBOUND in no auto-summary ! route-map OUTBOUND permit 10 match as-path 10 set weight 1000 route-map OUTBOUND permit 20 ! route-map WEIGHT permit 10 set weight 500 ! ip prefix-list LAN permit 100.0.0.0/23 ! ip as-path access-list 10 permit ^64502$ ! ip route 100.0.0.0 255.255.254.0 Null0

Балансировка и распределение нагрузки

На собеседовании вас однозначно спросят, какие вы знаете способы балансировки трафика в BGP.
Уточню. В контексте BGP балансировка и распределение - это два абсолютно разных понятия.

Балансировка нагрузки

Балансировка - это в большинстве случаев распределение нагрузки между несколькими линками трафика, направленного в одну сеть.

Балансировка включается вот так:
Включается она просто router bgp 100 maximum-paths 2
Должны будут выполняться следующие условия:

Не менее двух маршрутов в таблице BGP для этой сети.
Оба маршрута идут через одного провайдера
Параметры Weight , Local Preference , AS-Path , Origin , MED , метрика IGP совпадают.
Параметр Next Hop должен быть разным для двух маршрутов.

Цитата: Лайфхак

Условие с некст-хопом обходится вот такой командой:
router bgp 64500 bgp bestpath as-path multipath-relax
При этом и условие полного совпадения AS-path также умаляется. Но длина всё равно должна быть одинаковой.

Как всё это проверить на практике? Нужно ведь быть уверенными, что балансировка работает.
Балансировка обычно осуществляется на базе потоков (source address/port, destination address/port) для получения пакетов в правильном порядке. Так что потока нужно создать два. Поехали.

ping непосредственно с msk-arbat-gw1 на 103.0.0.1 ;
подключаемся телнетом на msk-arbat-gw1 (не забыв настроить параметры) с любого другого маршрутизатора и запускаем пинг с указанием источника (чтобы потоки чем-то отличались друг от друга)

После один ICMP-пакет улетит с одного линка, а второй - с другого.
По дефолту пропускная способность внешних каналов никак не учитывается. Но возможность такая есть, и запускается следующим образом:
router bgp 64500 bgp dmzlink-bw neighbor 101.0.0.1 dmzlink-bw neighbor 102.0.0.1 dmzlink-bw
Конфиг устройств .

Схема: Текущая схема сети
Условие: ЛинкМиАп получает от обоих провайдеров маршрут по умолчанию.
Задание: Настроить балансировку исходящего трафика между маршрутами по умолчанию от провайдеров Балаган Телеком и Филькин Сертификат в пропорции 3 к 1.

interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 bandwidth 9000 ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 bandwidth 3000 ! ! router bgp 64500 no synchronization bgp log-neighbor-changes bgp bestpath as-path multipath-relax maximum-paths 2 bgp dmzlink-bw network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 prefix-list LAN out neighbor 101.0.0.1 dmzlink-bw neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list LAN out neighbor 102.0.0.1 dmzlink-bw no auto-summary ! ip prefix-list LAN permit 100.0.0.0/23 ! ip route 100.0.0.0 255.255.254.0 Null0

Распределение нагрузки

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

Для решения наших задач есть несколько способов.
1. Настройка параметра Weight . Это сугубо внутренний цисковский параметр и он никуда не транслируется, т.е. работает исключительно в рамках конкретного маршрутизатора. У прочих вендоров также встречаются аналоги данной установки, тот же PreVal у Huawei , к примеру. Специфического здесь ничего нет, даже зацикливаться на этом не будет. По-умолчанию параметр равен нулю - 0.
Так он применяется ко всем полученным от соседа маршрутам:
neighbor 192.168.1.1 weight 500
А таким образом применяем его через route-map :
route-map SET_WEIGHT permit 10 set weight 500 ! router bgp 64500 neighbor 102.0.0.1 route-map SET_WEIGHT in

2. Ах да, у нас же есть Local Preference ! Параметр стандартный и по дефолту выставлен на 100 для всех маршрутов. Если перед нами стоит задача направлять трафик предназначенный в определенные подсети через определенные линки, то Local Preference - это наш выбор. Да, выше мы уже разбирались с его использованием, поэтому также не будем сильно углубляться.
3. Ну, и балансировка посредством команды maximum-paths .

Схема: Общая схема сети
Условие: ЛинкМиАп получает Full View от обоих провайдеров.
Задание: Не используя атрибуты weight , local preference или фильтрацию, настроить маршрутизатор msk-arbat-gw1 так, чтобы для исходящего трафика Балаган Телеком был основным, а Филькин Сертификат резервным.

В задаче просто показано то, что часть механизмов для управления BGP, могут быть использованы в разных направлениях.
Так, например, AS prepend обычно используется для управления входящим трафиком.
Но, при необходимости, он может использоваться и для управления исходящим трафиком.
router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 prefix-list LAN out neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list LAN out neighbor 102.0.0.1 route-map PREPEND in no auto-summary ! route-map PREPEND permit 10 set as-path prepend 64502 64502 64502 64502 ! ip prefix-list LAN permit 100.0.0.0/23 ! ! ip route 100.0.0.0 255.255.254.0 Null0

Входящий
А здесь всё куда сложнее. Даже у очень крупных провайдеров исходящий трафик незначителен в сравнении со входящим. И неровное распределение нагрузки особенно и не замечается. Зато если речь касается Центров Обработки Данных, тех самых ЦОД , или о хостинг провайдерах... То вот здесь уже вопрос балансировки стоит очень остро.
Только в средствах мы стеснены.
1. AS-Path Prepend
Это один из самых часто используемых приемов, искусственное "ухудшение" пути. Случается так, что через одного провайдера ваши маршруты будут переданы с длиной AS-path большей, нежели через другого. Само собой, BGP без вариантов выберет при таких раскладах первого, и трафик будет гонять именно через него. Для того, чтобы выровнять ситуацию добавим лишний "хоп" в AS-Path при анонсировании маршрутов.
А бывает так, что один пров предоставляет нам более широкий канал за меньшие деньги, но путь через него получается длиннее, поэтому трафик уйдет через узкий и более дорогой канал. Дело ясное, что нас такое не устраивает, узкий канал надо сделать резервным.
Вот такую ситуацию и разберем. Итак, рассмотрим доступ из сети Балаган Телекома в сеть ЛинкМиАп. Так выглядит таблица BGP и маршрутизации со стороны Балаган Телеком:

Для ухудшения основного пути между ними (прямой линк, между прочим) нам нужно добавить AS в список AS-Path .
router bgp 64500 neighbor 101.0.0.1 route-map AS_PATH_PREP out route-map AS_PATH_PREP permit 10 set as-path prepend 64500 64500
Смотрим результат:

Само собой, будет выбран путь с меньше AS-Path и трафик пойдет через Филькин Сертификат (AS6502 ).

Этот маршрут добавится в таблицу маршрутизации. И да, обычно в AS-Path добавляют именно свой номер AS. Можно и чужую накинуть, но вас могут не так понять. В итоге мы завернули трафик так как нам надо. Конечно, при падении одного из каналов связи трафик пойдет через резервный, независимо от того каких Prepend’ов вы накидали в AS-Path .

Hostname msk-arbat-gw1 ! interface Loopback0 ip address 100.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 speed 100 full-duplex ! ! router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 route-map AS_PATH_PREP out neighbor 102.0.0.1 remote-as 64502 no auto-summary ! ip route 100.0.0.0 255.255.254.0 Null0 ! ! ip http server no ip http secure-server ! ! route-map AS_PATH_PREP permit 10 set as-path prepend 64500 64500

2. MED
Или же Multiexit Discriminator . Для устройств Cisco он называется метрикой (Inter-AS метрика). MED является довольно слабеньким атрибутом. Почему? Просто его значение проверяется только на шестом шаге при выборе маршрута.
Если параметр Local Preference влияет на выбор пути выхода трафика из Автономной системы, то MED передается BGP-соседям, т.е. другим AS и влияет уже на пути входа трафика.
Новички в BGP часто путают два этих параметра, поэтому давайте разберемся с разницей между ними:

Используется этот параметр редко, поэтому не будем на нем останавливаться. Плюс к тому наша сеть не подходит в качестве примера, т.к. для реализации нужно более одного соединения между AS, а у нас их по одному.
3. Анонс разных префиксов через разных ISP
Это еще один способ распределения нагрузки. Можно раздавать разные сети разным провайдерам. В данный момент для сети ЦОД наши анонсы выглядят так:

Мы видим, что наша сеть 100.0.0.0/23 известна через два пути, но в таблицу маршрутизации попадет только один. Назад весь трафик тоже пойдет только одним путем - самым лучшим.
Но тут есть нюанс. Мы можем разбить сеть на две подсети /24, отдавая при этом одну в Балаган Телеком, а другую - в Филькин Сертификат. ЦОД при этом будет знать про эти подсети через разные пути:

Настраиваться это будет следующим образом:
Первое, что нужно сделать - прописать все подсети, и /23, и обе /24.
router bgp 64500 network 100.0.0.0 mask 255.255.254.0 network 100.0.0.0 mask 255.255.255.0 network 100.0.1.0 mask 255.255.255.0
Для успешного их анонсирования нужно создать маршруты до этих подсетей:
ip route 100.0.0.0 255.255.254.0 Null0 ip route 100.0.0.0 255.255.255.0 Null0 ip route 100.0.1.0 255.255.255.0 Null0
Дальше нужно создать префикс-листы, каждый из которых будет разрешать только одну подсеть /24 и общую /23.
ip prefix-list LIST_OUT1 seq 5 permit 100.0.0.0/24 ip prefix-list LIST_OUT1 seq 10 permit 100.0.0.0/23 ! ip prefix-list LIST_OUT2 seq 5 permit 100.0.1.0/24 ip prefix-list LIST_OUT2 seq 10 permit 100.0.0.0/23
Что теперь? Привяжем нашим нейборам префикс-листы:
router bgp 64500 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 prefix-list LIST_OUT1 out neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list LIST_OUT2 out
Как видим, привязывать их нужно на OUT , т.е. на исходящий, потому что данные маршруты будут отправляться вовне, наружу.
Что получилось? Соседу 101.0.0.1 (Балаган Телеком) будут анонсироваться сети 100.0.0.0/24 и 100.0.0.0/23 , соседу же 102.0.0.1 (Филькин Сертификат) - сети 100.0.1.0/24 и 100.0.0.0/23 .
Получится следующая картина:

Ерунда какая-то получилась? Выходит, что у нас по два маршрута в каждую из сетей /24 - через обоих провайдеров. Но обратимся к AS-Path и схеме для наглядности:

То есть в принципе-то всё правильно, более того, в таблице маршрутизации следующая картина:

Остается только один маленький вопрос. Зачем мы завернули вместе с подсетями /24 и большую сетку /23? Мы же вроде решили, что существует правило Longest prefix match , согласно которому более точные маршруты будут предпочтительнее. То есть этот наш маршрут до /23 при наличии /24 и не нужен вроде бы.
Но постойте.
А если уютная сеточка Балаган Телекома упадет? Что произойдет в этом случае?
Кстати говоря, существуют даже особые организации, которые следят за анонсами BGP в сети и в случае возникновения аварийных ситуаций могут уведомить владельца сети. Бац, и подсеть 100.0.0.0/24 перестает быть известной в сети, т.к. исходя из нашей настройки анонсировалась она только Балаган Телекому. Падает провайдер - падает часть нашей сети. Тут и приходит на помощь более глобальный маршрут 100.0.0.0/23 . О нем знает второй пров Филькин Сертификат, и анонсирует его в сеть. Теперь хоть ЦОД и не в курсе про сеть 100.0.0.0/24 , но зато 100.0.0.0/23 ему известна, поэтому трафик пойдет через Филькин Сертификат.

Как видите, мы защищены от подобной нештатной ситуации.
Важно! Помимо непосредственной настройки маршрутизатора надо завести все сетки в базу RIPE - обе /24 и /23.

msk-arbat-gw1
! hostname msk-arbat-gw1 enable secret 5 $1$L4zv$aWaMDS4SiorJO9wh7gLx/1 ! interface Loopback0 ip address 100.0.0.1 255.255.255.255 ! interface Loopback1 ip address 100.0.1.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 speed 100 full-duplex ! ! router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 network 100.0.0.0 mask 255.255.255.0 network 100.0.1.0 mask 255.255.255.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 prefix-list LIST_OUT1 out neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list LIST_OUT2 out no auto-summary ! ip route 100.0.0.0 255.255.254.0 Null0 ip route 100.0.0.0 255.255.255.0 Null0 ip route 100.0.1.0 255.255.255.0 Null0 ! ! ip http server no ip http secure-server ! ! ip prefix-list LIST_OUT1 seq 5 permit 100.0.0.0/24 ip prefix-list LIST_OUT1 seq 10 permit 100.0.0.0/23 ! ip prefix-list LIST_OUT2 seq 5 permit 100.0.1.0/24 ip prefix-list LIST_OUT2 seq 10 permit 100.0.0.0/23

hostname balagan-router ! interface FastEthernet0/0 description LinkMeUp_BGP ip address 101.0.0.1 255.255.255.252 speed auto full-duplex ! interface FastEthernet0/1 description Philkin_Certificate_BGP ip address 101.0.0.5 255.255.255.252 duplex auto speed auto ! interface FastEthernet1/0 description Cloud_BGP ip address 101.0.0.9 255.255.255.252 speed 100 full-duplex ! ! router bgp 64501 no synchronization bgp log-neighbor-changes network 101.0.0.0 mask 255.255.240.0 neighbor 101.0.0.2 remote-as 64500 neighbor 101.0.0.6 remote-as 64502 neighbor 101.0.0.10 remote-as 64503 no auto-summary ! ip route 101.0.0.0 255.255.240.0 Null0

Hostname PhCert-router ! interface FastEthernet0/0 description Balagan_Telecom_BGP ip address 101.0.0.6 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description LinkMeUp_BGP ip address 102.0.0.1 255.255.255.252 speed 100 full-duplex ! interface FastEthernet1/0 description Cloud_Internet ip address 102.0.0.9 255.255.255.252 duplex auto speed auto ! ! router bgp 64502 no synchronization bgp log-neighbor-changes network 102.0.0.0 mask 255.255.248.0 neighbor 101.0.0.5 remote-as 64501 neighbor 102.0.0.2 remote-as 64500 neighbor 102.0.0.10 remote-as 64503 no auto-summary ! ip route 102.0.0.0 255.255.248.0 Null0

Hostname cloud-router ! interface Loopback0 ip address 103.0.0.1 255.255.255.255 ! interface Loopback1 ip address 120.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_BGP ip address 101.0.0.10 255.255.255.252 speed 100 full-duplex ! interface FastEthernet0/1 description Philkin_Certificate_BGP ip address 102.0.0.10 255.255.255.252 speed 100 full-duplex ! ! router bgp 64503 no synchronization bgp log-neighbor-changes network 103.0.0.0 mask 255.255.252.0 network 120.0.0.0 mask 255.255.255.0 neighbor 101.0.0.9 remote-as 64501 neighbor 102.0.0.9 remote-as 64502 no auto-summary ! ip route 103.0.0.0 255.255.252.0 Null0 ip route 120.0.0.0 255.255.255.0 Null0

BGP Community

При помощи BGP Community можно в определенном смысле контролировать провайдера, указывая, что делать с префиксом - кому передавать, кому нет, какой local preference ставить у себя и тому подобное. Сейчас вопрос с коммьюнити поднимать не будем, всё же обширная тема.

Схема: Общая схема сети
Условие: На маршрутизаторе msk-arbat-gw1 настроено управление входящим и исходящим трафиком. Основной провайдер Балаган Телеком, резервый - Филькин Сертификат. При проверке настроек оказалось, что исходящий трафик передается правильно. При проверке входящего трафика, оказалось, что входящий трафик идет и через провайдера Балаган Телеком, но когда отключается Балаган Телеком, входящий трафик не идет через Филькин Сертификат.
Задание: Исправить настройки.

Hostname msk-arbat-gw1 ! interface Loopback0 ip address 100.0.0.1 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 speed 100 full-duplex ! router bgp 64500 no synchronization bgp log-neighbor-changes network 100.0.0.0 mask 255.255.254.0 neighbor 101.0.0.1 remote-as 64501 neighbor 101.0.0.1 prefix-list LAN out neighbor 101.0.0.1 weight 500 neighbor 102.0.0.1 remote-as 64502 neighbor 102.0.0.1 prefix-list LAN out neighbor 102.0.0.1 route-map INBOUND out no auto-summary ! route-map INBOUND permit 10 set as-path prepend 64502 64502 64502 ! ip prefix-list LAN permit 100.0.0.0/23 ! ip route 100.0.0.0 255.255.254.0 Null0

Надо исправить правило as-path prepend в route-map (в правиле используется неправильный номер автономной системы):
route-map INBOUND permit 10 set as-path prepend 64500 64500 64500

Инструкция по видам балансировки и распределения нагрузки

PBR

Всё о чем мы говорили, все технологии статической и динамической маршрутизации описанные здесь и ранее в качестве основного свойства пакета используют destination address , т.е. адрес назначения. Алгоритм их работы прост и в целом одинаков - производится проверка куда идет пакет, искали в таблице маршрутизации самый точный (с наиболее "узкой" маской) маршрут до назначенного адреса (longest match ), ну и собственно отправляли пакет на тот интерфейс, который соответствовал выбранному маршруту в route table . Вот и весь принцип маршрутизации. Чёрт, мы уложились в несколько строк, зачем все эти портянки текста? Ладно, не об этом сейчас.
Но вдруг нам такой расклад не нужен? Вот уперлось нам рутить пакеты исходя из адреса источника (source address )! А может нам вообще надо исходить из содержимого пакета, направлять HTTP в одну сторону, а SNMP в другую?
Тут и сваливается на нас аки гром среди ясного неба невиданный ранее зверь - Policy based routing или в переводе с басурманского "маршрутизация на основе политик". Данная технология позволяет рутить трафик, беря во внимание следующие свойства пакета:

Source address (или же комбинация адреса источника и адреса получателя);
Информация прикладного уровня модели OSI (application layer );
Интерфейс на который пришел искомый пакет;
QoS-метки;
В целом любая информация из extended-ACL (это и source/destination port, протокол TCP, UDP, etc. и прочее, в самых извращенных сочетаниях). То есть, если мы можем отфильтровать нужный нам трафик расширенными аксесс-листами, то сможем и смаршрутизировать.

PBR дает нам максимальную гибкость при маршрутизации трафика, но всё нужно настраивать вручную, а это зачастую долгий кропотливый труд и сопутствующие этому ошибки. Страдает и производительность, на большей части роутеров PBR куда медленнее обычной маршрутизации. Есть и исключения типа серии Catalyst 6500 с хардварной поддержкой PBR.
Политика для осуществления PBR-роутинга создается командой route map POLICY_NAME и состоит из двух частей:

Выделение нужного трафика. Может быть сделано либо при помощи ACL, либо исходя из того, на какой интерфейс свалился трафик. Заведует этим команда match в режиме конфигурирования route map .
Действие, которое будем применено к подходящему под условия трафику. Этим управляет команда set .

Ну, и немного практики.
Вот, к примеру, мы имеем топологию следующего вида:

Как видим, на текущий момент трафик от R1 к R5 и обратно идет маршрутом R1-R2-R4-R5 . Для удобства схватывания последняя цифра IP-адреса будет и порядковым номером маршрутизатора:
R1#traceroute 192.168.100.5 1 192.168.0.2 20 msec 36 msec 20 msec 2 192.168.2.4 40 msec 44 msec 16 msec 3 192.168.100.5 56 msec * 84 msec R5#traceroute 192.168.0.1 1 192.168.100.4 56 msec 40 msec 8 msec 2 192.168.2.2 20 msec 24 msec 16 msec 3 192.168.0.1 64 msec * 84 msec
Давайте какой-нибудь живой пример. Допустим, нам нужно, чтобы обратный маршрут от R5 (т.е. с его IP в качестве source address ) выглядел так: R5-R4-R3 -R1 . Обратимся к схеме. Очевидно, что решить это должен маршрутизатор R4 .
Окей, на этом роутере нам для начала нужно создать ACL , который будет отбирать нужные нам пакеты:
R4(config)#access-list 100 permit ip host 192.168.100.5 any
После создаем политику и назовем её как-нибудь очень понятно:
R4(config)#route-map BACK
Уже находясь в её конфиге указываем интересующий нас трафик:
R4(config-route-map)#match ip address 100
И действие, которое будет с ним производиться:
R4(config-route-map)#set ip next-hop 192.168.3.3
Теперь зайдем на интерфейс, смотрящий в сторону R5 (PBR работает именно со входящим трафиком ) и применим соответствующую политику:
R4(config)#int fa1/0 R4(config-if)#ip policy route-map BACK
Время проверки:
R5#traceroute 192.168.0.1 1 192.168.100.4 40 msec 40 msec 16 msec 2 192.168.3.3 52 msec 52 msec 44 msec 3 192.168.1.1 56 msec * 68 msec
Вроде бы всё хорошо и всё у нас работает. Но давайте еще раз обратимся к схеме и подумаем, может мы где-то напортачили?
Именно так. Исходя из созданного ACL весь трафик с источником в виде R5 на R3 будет тупо заворачиваться. То есть пакет желающий попасть с R5 на R2 вместо логичного маршрута R5-R4-R2 будет послан далеко и надолго вот туда - R5-R4-R3-R1-R2 . Это значит, что ACL для PBR нужно создавать очень вдумчиво и максимально точным образом.
И по поводу применяемого действия. В данном примере мы переопределяем некстхоп для пакетов, но что еще умеет PBR?

set ip next-hop
set interface
set ip default next-hop
set default interface

Логика первых двух понятна, они соответственно, переопределяют некстхоп и интерфейс из которого уйдет пакет. Само по себе действие set interface чаще всего применимо в прямых линках point-to-point . Если же применить команды set ip default next-hop или set default interface роутер попросту заглянет в таблицу маршрутизации и если найдет там маршрут для проверяемого пакета, то отправит его в соответствии с таблицей. Если маршрута там нет, то только в этом случае пакет уйдет в соответствии с указаниями политики. Снова обратимся к нашему примеру. Если бы в нем мы сказали не set ip next-hop 192.168.3.3 , а set ip default next-hop 192.168.3.3 , то ровным счетом ничего бы не поменялось, ведь у R4 есть маршрут до R1 через R2 . А вот уже в случае отсутствия этого маршрута, трафик бы ушел на R3 .
Говоря о команде SET . Она имеет широкое применение, ведь с помощью неё в целевом пакете можно менять много чего от меток QoS/MPLS до атрибутов BGP.

Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).

Маршрутизаторы провайдеров также не используют BGP!

msk-arbat-gw1
hostname msk-arbat-gw1 interface Loopback1 ip address 10.0.1.1 255.255.255.0 ip nat inside ! interface Loopback2 ip address 10.0.2.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 ip nat outside duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 ip nat outside speed 100 full-duplex ! ! ip access-list extended LAN permit ip 10.0.1.0 0.0.0.255 any permit ip 10.0.2.0 0.0.0.255 any ! route-map BALAGAN permit 10 match ip address LAN match interface FastEthernet0/0 route-map PH_CERT permit 10 match ip address LAN match interface FastEthernet0/1 ! ip nat inside source route-map BALAGAN interface Fa0/0 overload ip nat inside source route-map PH_CERT interface Fa0/1 overload

balagan-router
hostname balagan-router ! interface FastEthernet0/0 description LinkMeUp_BGP ip address 101.0.0.1 255.255.255.252 speed auto full-duplex ! interface FastEthernet0/1 description Philkin_Certificate_BGP ip address 101.0.0.5 255.255.255.252 duplex auto speed auto ! interface FastEthernet1/0 description Cloud_BGP ip address 101.0.0.9 255.255.255.252 speed 100 full-duplex ! ! router bgp 64501 no synchronization bgp log-neighbor-changes network 101.0.0.0 mask 255.255.240.0 neighbor 101.0.0.6 remote-as 64502 neighbor 101.0.0.10 remote-as 64503 no auto-summary ! ip route 101.0.0.0 255.255.240.0 Null0

PhCert-router
hostname PhCert-router ! interface FastEthernet0/0 description Balagan_Telecom_BGP ip address 101.0.0.6 255.255.255.252 duplex auto speed auto ! interface FastEthernet0/1 description LinkMeUp_BGP ip address 102.0.0.1 255.255.255.252 speed 100 full-duplex ! interface FastEthernet1/0 description Cloud_Internet ip address 102.0.0.9 255.255.255.252 duplex auto speed auto ! ! router bgp 64502 no synchronization bgp log-neighbor-changes network 102.0.0.0 mask 255.255.248.0 neighbor 101.0.0.5 remote-as 64501 neighbor 102.0.0.10 remote-as 64503 no auto-summary ! ip route 102.0.0.0 255.255.248.0 Null0

cloud-router
hostname cloud-router ! interface Loopback0 ip address 103.0.0.1 255.255.255.255 ! interface Loopback1 ip address 120.0.0.1 255.255.255.255 ! interface Loopback10 ip address 103.0.0.10 255.255.255.255 ! interface Loopback20 ip address 103.0.0.20 255.255.255.255 ! interface FastEthernet0/0 description Balagan_Telecom_BGP ip address 101.0.0.10 255.255.255.252 speed 100 full-duplex ! interface FastEthernet0/1 description Philkin_Certificate_BGP ip address 102.0.0.10 255.255.255.252 speed 100 full-duplex ! ! router bgp 64503 no synchronization bgp log-neighbor-changes network 103.0.0.0 mask 255.255.252.0 network 120.0.0.0 mask 255.255.255.0 neighbor 101.0.0.9 remote-as 64501 neighbor 102.0.0.9 remote-as 64502 no auto-summary ! ip route 103.0.0.0 255.255.252.0 Null0 ip route 120.0.0.0 255.255.255.0 Null0 ! ip http server

Задание: Настроить переключение между провайдерами.
Маршрут по умолчанию к Балаган Телеком должен использоваться до тех пор, пока приходят icmp-ответы на пинг google (103.0.0.10) ИЛИ yandex (103.0.0.20). Запросы должны отправляться через Балаган Телеком. Если ни один из указанных ресурсов не отвечает, маршрут по умолчанию должен переключиться на провайдера Филькин Сертификат. Для того чтобы переключение не происходило из-за временной потери отдельных icmp-ответов, необходимо установить задержку переключения, как минимум, 5 секунд.

Создание тестов IP SLA для проверки доступности «google» и «yandex»:
ip sla 10 icmp-echo 103.0.0.10 source-interface FastEthernet0/0 threshold 200 timeout 200 frequency 3 ip sla schedule 10 life forever start-time now ip sla 20 icmp-echo 103.0.0.20 source-interface FastEthernet0/0 threshold 200 timeout 200 frequency 3 ip sla schedule 20 life forever start-time now
Так как маршрут по умолчанию будет меняться, то надо явно прописать маршруты к тем ресурсам, доступность которых проверяется в тестах.
Маршруты должны быть через того провайдера, доступность которого будет зависеть от ответа тестов.
Статические маршруты для тестов (маршруты к «гугл» и «яндекс»):
ip route 103.0.0.10 255.255.255.255 101.0.0.1 ip route 103.0.0.20 255.255.255.255 101.0.0.1
Треки следящие за тестами:
track 110 ip sla 10 reachability track 120 ip sla 20 reachability
Комбинированный трек, который будет в состоянии UP, если хотя бы один из внутренних треков (110 или 120) будет в состоянии UP:
track 12 list boolean or object 110 object 120 delay down 5 up 5
Маршрут по умолчанию к Балаган Телеком с привязанным к нему треком:
ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 12
Маршрут по умолчанию через Филькин Сертификат будет резервным, так как у него значение AD больше:
ip route 0.0.0.0 0.0.0.0 102.0.0.1 200
При переключении между провайдерами возникает проблема с «подвисаниями» сессий. Это связано с тем, что для сессий, которые были для переключения, остаются записи в таблице трансляций. Поэтому после переключения между провайдерами, необходимо очищать таблицу трансляций.
Для того чтобы делать это автоматически используется EEM (Embeded Event Manager).
Тут приведен простой пример, когда при смене состояния трека, каждый раз очищается таблица трансляций и генерируется сообщение (можно сделать два отдельных скрипта, для состояния UP и DOWN):
event manager applet TRACK_NAT event track 12 state any action 1 cli command "enable" action 2 cli command "clear ip nat trans *" action 3 syslog msg "Vse zarabotalo!!! Ura!"

Hostname msk-arbat-gw1 ! track 110 ip sla 10 reachability ! track 120 ip sla 20 reachability ! track 12 list boolean or object 110 object 120 delay down 5 up 5 ! interface Loopback1 ip address 10.0.1.1 255.255.255.0 ip nat inside ! interface Loopback2 ip address 10.0.2.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 ip nat outside duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 ip nat outside speed 100 full-duplex ! ip nat inside source route-map BALAGAN interface Fa0/0 overload ip nat inside source route-map PH_CERT interface Fa0/1 overload ! ip access-list extended LAN permit ip 10.0.1.0 0.0.0.255 any permit ip 10.0.2.0 0.0.0.255 any ! ! route-map BALAGAN permit 10 match ip address LAN match interface FastEthernet0/0 route-map PH_CERT permit 10 match ip address LAN match interface FastEthernet0/1 ! ip sla 10 icmp-echo 103.0.0.10 source-interface FastEthernet0/0 threshold 200 timeout 200 frequency 3 ip sla schedule 10 life forever start-time now ip sla 20 icmp-echo 103.0.0.20 source-interface FastEthernet0/0 threshold 200 timeout 200 frequency 3 ip sla schedule 20 life forever start-time now ! ip route 103.0.0.10 255.255.255.255 101.0.0.1 ip route 103.0.0.20 255.255.255.255 101.0.0.1 ! ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 12 ip route 0.0.0.0 0.0.0.0 102.0.0.1 200 ! event manager applet TRACK_NAT event track 12 state any action 1 cli command "enable" action 2 cli command "clear ip nat trans *" action 3 syslog msg "Vse zarabotalo!!! Ura!" !

IP SLA

Ну и теперь еще один интересный момент. Давайте вообразим, что трассу R4-R2-R1 у нас поддерживает один провайдер, а вот запасную R4-R3-R1 - другой. И у первого провайдера часто проседает скорость из-за нагрузки, в связи с чем наша телефония (читай, голосовой трафик) начинает заикаться и лагать. А запасной маршрут в этот самый момент времени вполне себе свободен, и было бы неплохо перекинуть трафик на него. Тут как бы всё просто, рисуем route map , выделяющий голосовой трафик и заворачиваем его на нормально работающего провайдера. А потом проходит час пик, и ситуация меняется - трафик снова нужно пускать через первого прова. А если такое происходит по несколько раз в день? Кошмар!
Было бы круто, если можно было в автоматическом режиме считывать характеристики основного канала (ping/jitter, например) и исходя из них рутить трафик либо на него, либо на резерв. И это возможно с помощью IP SLA.
Это технология активного сетевого мониторинга - генерации трафика с целью оценки тех или иных характеристик сети. Но это не только мониторинг, ведь роутер на основе полученных данных может влиять на маршрутизацию, своевременно реагируя и разрешая возникшую проблему. В нашем случае, снимая часть трафика с загруженного канала и перераспределяя его на другой.
Погнали настраивать.
В первую очередь создадим объект мониторинга:
R4(config)#ip sla 1
Теперь поглядим, что мы тут можем мониторить:
R4(config-ip-sla)#? IP SLAs entry configuration commands: dhcp DHCP Operation dns DNS Query Operation exit Exit Operation Configuration frame-relay Frame-relay Operation ftp FTP Operation http HTTP Operation icmp-echo ICMP Echo Operation icmp-jitter ICMP Jitter Operation mpls MPLS Operation path-echo Path Discovered ICMP Echo Operation path-jitter Path Discovered ICMP Jitter Operation slm SLM Operation tcp-connect TCP Connect Operation udp-echo UDP Echo Operation udp-jitter UDP Jitter Operation voip Voice Over IP Operation
Кстати, синтаксис команд слегка менялся от версии к версии, так что скажите у себя (config-ip-sla)#? и посмотрите, какие команды маршрутизатор вам предложит. А за подробностями вам сюда .

Схему конфигурации см. в Задаче №8.8, маршрутизаторы провайдера всё также не используют BGP.
Задание: Настроить маршрутизацию таким образом, чтобы HTTP-трафик из локальной сети 10.0.1.0 шел через Балаган Телеком, а весь трафик из сети 10.0.2.0 через Филькин Сертификат. Если в адресе отправителя фигурирует любой другой адрес, трафик должен быть отброшен, а не маршрутизироваться по стандартной таблице маршрутизации (задание надо выполнить не используя фильтрацию с помощью ACL, примененных на интерфейсе).
Дополнительное условие: Правила PBR должны работать так только если соответствующий провайдер доступен (в данной задаче достаточно проверки доступности ближайшего устройства провайдера). Иначе должна использоваться стандартная таблица маршрутизации.

Тесты IP SLA для проверки доступности провайдеров (в реальной жизни лучше делать более сложные тесты, по аналогии с задачей 8.8):
ip sla 1 icmp-echo 101.0.0.1 source-interface FastEthernet0/0 threshold 200 timeout 200 frequency 3 ip sla schedule 1 life forever start-time now ! ip sla 2 icmp-echo 102.0.0.1 source-interface FastEthernet0/1 threshold 200 timeout 200 frequency 3 ip sla schedule 2 life forever start-time now
Треки, которые отслеживают тесты:
track 101 ip sla 1 reachability ! track 102 ip sla 2 reachability
Привязка трека к статическому маршруту и создание запасного маршрута:
ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 101 ip route 0.0.0.0 0.0.0.0 102.0.0.1 200
Создание ACL, которые описывают нужный трафик.
HTTP-трафик из локальной сети 10.0.1.0:
ip access-list extended HTTP permit tcp 10.0.1.0 0.0.0.255 any eq 80
Весь трафик из сети 10.0.2.0:
ip access-list extended LAN2 permit ip 10.0.2.0 0.0.0.255 any
Весь трафик, кроме трафика из локальных сетей:
ip access-list extended EX_LAN deny ip 10.0.1.0 0.0.0.255 any deny ip 10.0.2.0 0.0.0.255 any permit ip any any
Создание route-map, которая описывает правила PBR с привязкой треков для отслеживания состояния провайдеров:
route-map PBR_RULES permit 10 match ip address HTTP set ip next-hop verify-availability 101.0.0.1 1 track 101 route-map PBR_RULES permit 20 match ip address LAN2 set ip next-hop verify-availability 102.0.0.1 1 track 102
Если в адресе отправителя будет стоять IP-адрес не принадлежащий локальным сетям, то такие пакеты будут отброшены:
route-map PBR_RULES permit 30 match ip address EX_LAN set interface null 0
Применение правил PBR к пакетам, который генерирует сам маршрутизатор (так как локальные сети представлены loopback-интерфейсами):
ip local policy route-map PBR_RULES

hostname msk-arbat-gw1 ! track 101 ip sla 1 reachability ! track 102 ip sla 2 reachability ! interface Loopback1 ip address 10.0.1.1 255.255.255.0 ip nat inside ! interface Loopback2 ip address 10.0.2.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0 description Balagan_Telecom_Internet ip address 101.0.0.2 255.255.255.252 ip nat outside duplex auto speed auto ! interface FastEthernet0/1 description Philkin_Certificate_Internet ip address 102.0.0.2 255.255.255.252 ip nat outside speed 100 full-duplex ! ip nat inside source route-map BALAGAN interface Fa0/0 overload ip nat inside source route-map PH_CERT interface Fa0/1 overload ! ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 101 ip route 0.0.0.0 0.0.0.0 102.0.0.1 200 ! ! ip access-list extended LAN permit ip 10.0.1.0 0.0.0.255 any permit ip 10.0.2.0 0.0.0.255 any ! ip access-list extended HTTP permit tcp 10.0.1.0 0.0.0.255 any eq 80 ! ip access-list extended LAN2 permit ip 10.0.2.0 0.0.0.255 any ! ip access-list extended EX_LAN deny ip 10.0.1.0 0.0.0.255 any deny ip 10.0.2.0 0.0.0.255 any permit ip any any ! ip sla 1 icmp-echo 101.0.0.1 source-interface FastEthernet0/0 threshold 200 timeout 200 frequency 3 ip sla schedule 1 life forever start-time now ip sla 2 icmp-echo 102.0.0.1 source-interface FastEthernet0/1 threshold 200 timeout 200 frequency 3 ip sla schedule 2 life forever start-time now ! route-map BALAGAN permit 10 match ip address LAN match interface FastEthernet0/0 route-map PH_CERT permit 10 match ip address LAN match interface FastEthernet0/1 ! route-map PBR_RULES permit 10 match ip address HTTP set ip next-hop verify-availability 101.0.0.1 1 track 101 route-map PBR_RULES permit 20 match ip address LAN2 set ip next-hop verify-availability 102.0.0.1 1 track 102 route-map PBR_RULES permit 30 match ip address LAN set interface null 0 ! ip local policy route-map PBR_RULES

Примечание: Эта конфигурация упрощена для задачи и, для использования в реальной сети, должна быть дополнена.
Доступность провайдеров конечно же лучше проверять не по ближайшему интерфейсу, а по аналогии с задачей 8.8.
Кроме того, так как локальная сеть представлена интерфейсами loopback, то правила PBR применены локально.
В реальной сети, скорее всего, нужны будут правила для трафика, который проходит сквозь маршрутизатор. Соответственно, правила PBR должны будут применяться в таком случае не локально, а к интерфейсу, в который входит трафик.

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

Самое очевидное рассмотрение принципа работы IP SLA можно провести на примере банального icmp-echo . То есть, если мы пингуем другой конец линии, то трафик по ней пойдет, если нет - то по другой. Но это не так интересно, мы же пойдем немного другим путем, ведь для войс-трафика важным критерием будет jitter , а если совсем конкретно, то udp-jitter .
Начнем.
R4(config-ip-sla)#udp-jitter 192.168.200.1 55555
Как видим, сначала указывается вид проверки (udp-jitter в нашем случае), а вот после идет IP-адрес, на который будут отсылаться пробы. Т.е. меряем мы линию от нас до 192.168.200.1 , loopback-интерфейса R1. Порт мы берем из головы.
После настраивается частота проверок. По умолчанию она равна 60 секундам:
R4(config-ip-sla-jitter)#frequency 10
Далее настроим значение, являющееся предельным, после регистрации которого созданный нами объект ip sla 1 сообщит о проблеме.
R4(config-ip-sla-jitter)#threshold 10
Хочется отметить, что некоторые из типов измерений в IP SLA требуют наличия на ответной стороне "ответчика" (responder ), а всякие FTP, HTTP, DHCP, DNS - нет. У нас первый случай, udp-jitter требует респондера.
Сконфигурируем R1 :
R1(config)#ip sla responder
А после запускаем сбор статистики:
R4(config)#ip sla schedule 1 start-time now life forever
Сейчас мы запустили объект мониторинга с бесконечным сроком жизни.
Важно! Параметры объекта не поддаются изменению, пока сбор статистики активен. Т.е. для банального изменения параметра frequency нужно сначала вырубить сбор информации - no ip sla schedule 1 .
Посмотрим, что у нас там собирается:
R4#sh ip sla statistics 1 Round Trip Time (RTT) for Index 1 Latest RTT: 36 milliseconds Latest operation start time: *00:39:01.531 UTC Fri Mar 1 2002 Latest operation return code: OK RTT Values: Number Of RTT: 10 RTT Min/Avg/Max: 19/36/52 milliseconds Latency one-way time: Number of Latency one-way Samples: 0 Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds Jitter Time: Number of SD Jitter Samples: 9 Number of DS Jitter Samples: 9 Source to Destination Jitter Min/Avg/Max: 0/5/20 milliseconds Destination to Source Jitter Min/Avg/Max: 0/16/28 milliseconds Packet Loss Values: Loss Source to Destination: 0 Loss Destination to Source: 0 Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0 Packet Skipped: 0 Voice Score Values: Calculated Planning Impairment Factor (ICPIF): 0 Mean Opinion Score (MOS): 0 Number of successes: 12 Number of failures: 0 Operation time to live: Forever
И наклёпанный нами конфиг:
R4#sh ip sla conf IP SLAs Infrastructure Engine-II Entry number: 1 Owner: Tag: Type of operation to perform: udp-jitter Target address/Source address: 192.168.200.1/0.0.0.0 Target port/Source port: 55555/0 Request size (ARR data portion): 32 Operation timeout (milliseconds): 5000 Packet Interval (milliseconds)/Number of packets: 20/10 Type Of Service parameters: 0x0 Verify data: No Vrf Name: Control Packets: enabled Schedule: Operation frequency (seconds): 10 (not considered if randomly scheduled) Next Scheduled Start Time: Pending trigger Group Scheduled: FALSE Randomly Scheduled: FALSE Life (seconds): 3600 Entry Ageout (seconds): never Recurring (Starting Everyday): FALSE Status of entry (SNMP RowStatus): Active Threshold (milliseconds): 10 Distribution Statistics: Number of statistic hours kept: 2 Number of statistic distribution buckets kept: 1 Statistic distribution interval (milliseconds): 4294967295 Enhanced History:
Что теперь? Теперь нужно настроить track (сейчас будет неправильный, но верный по смыслу перевод - "отслеживатель"). Исходя из его состояния впоследствии будут происходить изменения в route map . В трек можно заложить задержку между переходами из состояния в состояние, что поможет в случае, если проба с плохими параметрами сражу же сменяется пробой с параметрами хорошими, что при нулевой delay влекло бы за собой мгновенные изменения маршрутизации.
Нужно указать номер трека и номер объекта ip sla , к которому он привязывается:
R4(config)#track 1 rtr 1
Теперь настраиваем задержку:
R4(config-track)#delay up 10 down 15
Это будет означать, что если мониторящийся объект отвалился и не выходит на связь в течение 15 секунд, то track сменяет состояние на down . А если объект пребывал в состоянии down , но вдруг поднялся и оставался в этом состоянии более 10 секунд, то track перейдет в состояние up .
Что нужно сделать еще? Естественно, привязать созданный трек к роут-мапе. Еще раз - дефолтный маршрут от R5 к R1 лежит через R2 , но у нас в запасниках имеется route map BACK , которая вступит в силу, если источник R5 :
R4#sh run | sec route-map ip policy route-map BACK route-map BACK permit 10 match ip address 100 set ip next-hop 192.168.3.3
Допустим, мы привяжем наш мониторинг к этой карте маршрутов, при этом поменяв строку set ip next-hop 192.168.3.3 на set ip next-hop verify-availability 192.168.3.3 10 track 1 , тогда при падении трека эффект будет противоположный (критерием для этого будет падение jitter в sla 1 ) карта обрабатываться не будет и всё будет происходить согласно route table . А если всё в порядке и трек будет up , то карта будет применяться и трафик пойдет через R3 .
Почему так? Маршрутизатор видит, что пакет подпадает под условия match , но set делает не сразу (см. пример с PBR), а сначала проверяет каково состояние track 1 , и если тот поднят, то делает set , а если нет, то переходит к следующей строке route map .

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

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

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

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

Формат сообщения

Сообщение BGP начинается с заголовка, после которого, в зависимости от типа сообщения, могут следовать данные. Максимальная длина сообщения - 4096 октетов, минимальная - 19 октетов. Заголовок сообщения содержит следующие поля:

Маркер (16 октетов) - используется для совместимости, должен быть заполнен единицами;
Длина (2 октета) - длина сообщения в октетах, включая заголовок;
Тип (1 октет):
- 1 - Открытие;
- 2 - Обновление информации;
- 3 - Оповещение;
- 4 - Сохранение соединения.

Открытие

Первое сообщение после установки соединения должно быть «Открытие». Если сообщение успешно обработано, в ответ будет послано «Сохранение соединения». В дополнение к заголовку BGP сообщение «Открытие» содержит следующие поля:

Версия (1 октет) - версия протокола, текущее значение 4;
Моя система (2 октета) - номер автономной системы;
Интервал времени (2 октета) - максимальный интервал времени в секундах между получением сообщений «Обновление информации» или «Сохранение соединения»;
Идентификатор отправителя (4 октета) - устанавливается равным IP-адресу;
Длина дополнительных параметров (1 октет);
Дополнительные параметры:
- Тип параметра (1 октет);
- Длина параметра (1 октет);
- Значение параметра.

Обновление информации

Сообщение «Обновление информации» предназначено для передачи информации о маршрутах между АС. Сообщение может указывать новые маршруты и удалять неработающие. Структура сообщения:

Длина удаляемых маршрутов (2 октета);
Удаляемые маршруты:
- Длина (1 октет) - длина в битах префикса IP-адреса;
- Префикс IP-адреса, дополненный минимальным количеством бит до полного октета;
Длина атрибутов пути (2 октета);
Атрибуты пути:
- Тип атрибута:
  - Флаг атрибута;
  - Код атрибута;
- Длина атрибута (1 или 2 октета, в зависимости от флага);
- Данные атрибута;
Информация о достижимости - список префиксов IP-адресов:
- Длина (1 октет) - длина в битах префикса IP-адреса (нулевая длина - соответствие всем IP-адресам);
- Префикс IP-адреса, дополненный минимальным количеством бит до полного октета.

Все атрибуты пути соответствуют всем записям в поле «Информация о достижимости».

Сохранение соединения

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

Оповещение

Оповещение посылается в случае обнаружения ошибки, при этом соединение закрывается. Сообщение содержит следующие поля:

Код ошибки (1 октет);
Субкод (1 октет);
Данные.

Процесс выбора

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

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

См. также

Ссылки

RFC 1105 (англ.) , A Border Gateway Protocol version 1
RFC 1163 (англ.) , A Border Gateway Protocol version 2
RFC 1164 (англ.) , Application of the Border Gateway Protocol in the Internet
RFC 1265 (англ.) , BGP Protocol Analysis
RFC 1266 (англ.) , Experience with the BGP Protocol
RFC 1403 (англ.) , BGP OSPF Interaction
RFC 4271 (англ.) , A Border Gateway Protocol 4 (BGP-4)
RFC 1772 (англ.) , Application of the Border Gateway Protocol version 4 in the Internet
RFC 1773 (англ.) , Experience with the BGP-4 Protocol
RFC 4274 (англ.) , BGP-4 Protocol Analysis
RFC 1863 (англ.) , A BGP4/IDRP Route Server alternative to a full mesh routing
RFC 1997 (англ.) , BGP Communities Attribute
RFC 1998 (англ.) , An Application of the BGP Community Attribute in Multi-home Routing
BGP протокол (рус.) , Использование BGP для междоменного роутинга (примеры настройки Cisco маршрутизаторов)

Литература

Установка и настройка BGP , используя ПО маршрутизации Quagga в Gentoo Linux
Настройка BGP на Linux (Quagga Zebra) с автоматической балансировкой нагрузки по трем каналам и резервированием
Уильям Р. Паркхерст Справочник по командам и настройке протокола BGP-4 маршрутизаторов Cisco = Cisco BGP-4 Command and Configuration. - М .: «Вильямс», 2002. - С. 384. - ISBN 1-58705-017-X
BGP протокол (перевод на русский) = CISCO UNIVER CD.

Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP)
Физический
Канальный
Сетевой
Транспортный
Сеансовый
Представления

Сегодняшняя статья будет посвящена основному протоколу динамической маршрутизации – BGP (Border Gateway Protocol) . Почему основному? – Потому что с именно с помощью BGP организована топология всего Интернета.

Итак, в данной статье разберем следующие моменты:

Основные термины протокола BGP
Принципы работы протокола BGP
Типы сообщений протокола BGP

Терминология

Когда речь идёт BGP, первое на чем необходимо остановиться - это понятие автономной системы AS(Autonomus System) . Автономная система - это совокупность точек маршрутизации и связей между ними, объединенная общей политикой взаимодействия, которая позволяет этой системе обмениваться данными с узлами, находящимися за ее пределами.

AS характеризуется (с недавних пор 32 битным) номером ASN (Autonomus System Number) и пулом IP-адресов. Выдачей и того и другого занимается организация IANA (Internet Assigned Numbers Authority), делегируя контроль за распределением ASN и других интернет ресурсов, региональным регистраторам.

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

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

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

Как известно, протоколы динамической маршрутизации классифицируются по двум основным признакам:

Тип работы протокола относительно AS

IGP (Interior Gateway Protocol) – работают внутри автономной системы. Сюда относятся: RIP, OSPF, EIGRP, IS-IS
EGP (Exterior Gateway Protocol) – работают вне автономных систем и обеспечивают их связность. Сюда относится BGP

Алгоритм работы протокола

Distance-Vector - знает маршруты только до своих ближайших соседей и обменивается с ними таблицей маршрутизации. (RIP, EIGRP)
Link State – знает всю топологию сети и обменивается таблицей топологии со своими соседями (OSPF, IS-IS)

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

Итак, BGP – это протокол внешней маршрутизации, использующийся для соединения двух AS. Схема выглядит примерно так:

Так как на BGP возложена великая задача – соединение автономных систем во всем Интернете, то он должен быть очень надежным. Для этих целей, в самом начале работы, BGP-маршрутизатор инициирует установление TCP сессии на 179 порт к своему соседу, происходит стандартных обмен SYN и ACK.

Соединения по протоколу BGP должно быть абсолютно согласовано администраторами автономных систем, желающих организовать стык. Если, скажем, администратор AS402 запустил процесс BGP на маршрутизаторе BR2 (Border Router), указав в качестве соседа BR1 и его ASN, а администратор AS401 никаких действий не произвел, то TCP-сессия не поднимется и системы так и останутся несвязными. Кроме того, должны соблюдаться следующие условия:

179 порт не блокируется ACL (Access Control List)
Маршрутизаторы пингуют друг друга
При запуске BGP процесса ASN удаленной стороны был указан верно
RouterID не совпадают

Если TCP-сессия установлена успешно, то BGP-маршрутизаторы начинают обмен

сообщениями OPEN, в котором сообщают свои ASN, RouterID и Hold timer. Hold timer это время, в течение которого будет поддерживаться TCP-сессия. Если условия, перечисленные ранее, не соблюдаются, например не совпадает информация о номере AS, то сообщением NOTIFICATION маршрутизатор, получивший неверный ASN уведомит об этом своего соседа и сбросит TCP-сессию.

Если же все условия соблюдаются, то маршрутизаторы, с определенным интервалом, начинают высылать друг другу сообщения KEEPALIVE , означающие подтверждение параметров, принятых в OPEN и уведомление “я ещё жив”.

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

Path Attributes (Атрибуты пути). Здесь указывается из какой AS поступил маршрут, его происхождение и Next Hop для данного пути.
NRLI (Network Layer Reachability Information). Здесь указывает информация непосредственно о сетях, подлежащих добавлению в таблицу маршрутизации, т.е IP-адрес сети и ее маска.

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

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

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Пограничный (внешний) шлюзовой протокол (Border Gateway Protocol, BGP) версии 4 является сегодня основным протоколом обмена маршрутной информацией между автономными системами Интернета. Протокол BGP пришел на смену протоколу EGP1, использовавшемуся в тот начальный период, когда Интернет имел единственную магистраль. Эта магистраль являлась центральной автономной системой, к которой присоединялись в соответствии с древовидной топологией все остальные автономные системы. Так как между автономными системами при такой структуре петли исключались, протокол EGP не предпринимал никаких мер для того, чтобы исключить зацикливание маршрутов.

Поясним основные принципы работы BGP на примере (рис. 1).

Рис. 1 Поиск маршрута между автономными системами с помощью протокола BGP

В каждой из трех автономных систем (AS 1021, AS 363 и AS 520) имеется несколько маршрутизаторов, исполняющих роль внешних шлюзов. На каждом из них работает протокол BGP, с помощью которого они общаются между собой.

Маршрутизатор взаимодействует с другими маршрутизаторами по протоколу BGP только в том случае, если администратор явно указывает при конфигурировании, что эти маршрутизаторы являются его соседями. Например, маршрутизатор EG1 в рассматриваемом примере будет взаимодействовать по протоколу BGP с маршрутизатором EG2 не потому, что эти маршрутизаторы соединены двухточечным каналом, а потому, что при конфигурировании маршрутизатора EG1 в качестве соседа ему был указан маршрутизатор EG2 (с адресом 194.200.30.2). Аналогично, при конфигурировании маршрутизатора EG2 его соседом был назначен маршрутизатор EG1 (с адресом 194.200.30.1).

Такой способ взаимодействия удобен в ситуации, когда маршрутизаторы, обменивающиеся маршрутной информацией, принадлежат разным поставщикам услуг (ISP). Администратор ISP может решать, с какими автономными системами он будет обмениваться трафиком, а с какими нет, задавая список соседей для своих внешних шлюзов. Протоколы RIP и QSPF, разработанные для применения внутри автономной системы, обмениваются маршрутной информацией со всеми маршрутизаторами, находящимися в пределах их непосредственной досягаемости (по локальной сети или через двухточечный канал). Это означает, что информация обо всех сетях появляется в таблице маршрутизации каждого маршрутизатора, так что каждая сеть оказывается достижимой для каждой. В корпоративной сети это нормальная ситуация, а в сетях ISP нет, поэтому протокол BGP и исполняет здесь особую роль.

Для установления сеанса с указанными соседями BGP-маршрутизаторы используют протокол TCP (порт 179). При установлении BGP-сеанса могут применяться разнообразные способы аутентификации маршрутизаторов, повышающие безопасность работы автономных систем.

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

В одном сообщении UPDATE можно объявить об одном новом маршруте или аннулировать несколько маршрутов, переставших существовать. Под маршрутом в BGP понимается последовательность автономных систем, которую нужно пройти на пути к указанной в адресе сети. Более формально информация о маршруте (BGP Route) к сети (Network/ Maskjength) выглядит так:
BGP Route = AS_Path; NextHop; Network/Maskjength;
Здесь AS_Palh - набор номеров автономных систем, NextHop - IP-адрес маршрутизатора, через который нужно передавать пакеты в сеть Network/Maskjength. Например, если маршрутизатор EG1 хочет объявить маршрутизатору EG2 о том, что в AS 1021 появилась новая сеть 202.100.5.0/24, то он формирует такое сообщение:

AS 1021; 194.200.30.1; 202.100.5.0/24,
после чего передает его маршрутизатору EG2 автономной системы AS 363 (с которым у него, конечно, должен быть установлен BGP-сеанс).

Маршрутизатор EG2, получив сообщение UPDATE, запоминает в своей таблице маршрутизации информацию о сети 202.100.5.0/24 вместе с адресом следующего маршрутизатора 194.200.30.1 и отметкой о том, что эта информация была получена по протоколу BGP. Маршрутизатор EG2 обменивается маршрутной информацией с внутренними шлюзами системы AS 363 по какому-либо протоколу группы IGP, например OSPF. Если у EG2 установлен режим перераспределения маршрутов BGP в маршруты OSPF, то все внутренние шлюзы AS 363 узнают о существовании сети 202.100.5.0/24 с помощью объявления OSPF, которое будет внешним. В качестве адреса следующего маршрутизатора маршрутизатор EG2 начнет теперь объявлять адрес собственного внутреннего интерфейса, например 192.17.100.2.

Однако для распространения сообщения о сети 202.100.5.0/24 в другие автономные системы, например в AS 520, протокол OSPF использоваться не может. Маршрутизатор EG3, связанный с маршрутизатором EG4 автономной системы 520, должен пользоваться протоколом BGP, генерируя сообщение UPDATE нужного формата. Для решения этой задачи он не может задействовать информацию о сети 202.100.5.0/24, полученную от протокола OSPF через один из своих внутренних интерфейсов, так как она имеет другой формат и не содержит, например, сведений о номере автономной системы, в которой находится эта сеть.
Проблема решается за счет того, что маршрутизаторы EG2 и EG3 также устанавливают между собой BGP-сеанс, хотя они и принадлежат одной и той же автономной системе. Такая реализация протокола BGP называется внутренней (Interior BGP, iBGP), в отличие от основной, внешней (Exterior BGP, eBGP). В результате маршрутизатор EG3 получает нужную информацию от маршрутизатора EG2 и передает ее внешнему соседу - маршрутизатору EG4. При формировании нового сообщения UPDATE маршрутизатор EG3 трансформирует сообщение, полученное от маршрутизатора EG2, добавляя в список автономных систем собственную автономную систему AS 520, а полученный адрес следующего маршрутизатора заменяет адресом собственного интерфейса:

AS 363, AS 1021; 132.15.64.3; 202.100.5.0/24.

Номера автономных систем позволяют исключать зацикливание сообщений UPDATE. Например, когда маршрутизатор EG5 передаст сообщение о сети 202.100.5.0/24 маршрутизатору EG6, то последний не будет его использовать, так как оно будет иметь вид:
AS 520, AS 363, AS 1021; 201.14.110.3; 202.100.5.0/24.

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

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