к какому типу относится протокол bpg

OSPF, RIP и BGP простым языком. Часть 1. Протокол RIP

Введение

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

Маршрутизация

Этапы маршрутизации:

1. Изучение сети

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

RIP (Routing Information Protocol — протокол машрутной информации) является внутренним протоколом маршрутизации дистанционно-векторного типа (что это значит я опишу уже в следующей статье). Будучи простым в реализации он в основном использовался в небольших сетях, хотя сейчас он уже сильно устарел и редко используется в более менее современных компаниях. Его работу я опишу вкратце, дабы не забивать вам голову устаревшей информацией.
Этап 1 — создание минимальной таблицы. В исходном состоянии на каждом маршрутизаторе программным обеспечением стека TCP/IP автоматически создается минимальная таблица маршрутизации, в которой учитываются только непосредственно подсоединенные сети.
Пример таблицы маршрутизатора с 3 подсоединенными портами.

Этап 2 — рассылка минимальной таблицы соседям. После создания своих минимальных таблиц, маршрутизатор начинает рассылать своим соседям сообщения протокола RIP. Сообщения, которые передаются в дейтаграммах UDP, включают в себя информацию о каждой сети: её IP-адрес и расстояние до неё от передающего маршрутизатора.

Этап 3 — получение RIP-сообщений от соседей и обработка полученной информации. Наш маршрутизатор, после получения сообщений от соседних маршрутизаторов, увеличивает каждое поле метрики на 1 и запоминает, через какой порт и от какого маршрутизатора получена информация, после сравнивает значения со своей таблицей.

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

Этап 5 — получение таблиц и обработка полученной информации. Тут все, как на 3 этапе — маршрутизатор получает таблицу и сравнивает со своей, внося изменения.

2. Продвижение пакетов на маршрутизаторе

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

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

Для адаптации к изменениям в сети протокол RIP использует ряд механизмов.

Адаптация маршрутизаторов RIP к изменениям состояние сети.

К новым маршрутам маршрутизаторы RIP приспосабливается безболезненно — они передают новую информацию в очередном сообщении своим соседям и постепенно эта информация становится известна всем маршрутизаторам сети. А вот с потерей какого-либо маршрута протокол справляется достаточно проблематично. Это связано с тем, что в формате сообщений протокола RIP нет поля, которое бы указывало на то, что путь к данной сети больше не существует.

Для уведомления о том, что данный маршрут недействителен, используются механизм истечения времени жизни маршрута.

Механизм основан на том, что обмен таблицами маршрутизации в протоколе RIP происходит раз в 30 секунд, время тайм-аута — в 6 раз больше, то есть 180 секунд, и маршрутизатор, получивший сообщение с подтверждением записи маршрута, ставит таймер в исходное состояние и если в течении времени тайм-аута (180 секунд) подтверждение не приходит еще раз, то маршрут становится недействительным.

Шестикратное время тайм-аута нужно для того, чтобы была точная уверенность, что маршрут недействителен, а не пакеты потерялись (ведь протокол использует транспортный протокол UDP).

В принципе я старался максимально просто объяснить протокола и надеюсь у меня это получилось:)

Источник

Принципы работы протокола BGP

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

Итак, что такое BGP? BGP — это протокол динамической маршрутизации, являющийся единственным EGP( External Gateway Protocol) протоколом. Данный протокол используется для построения маршрутизации в интернете. Рассмотрим как строится соседство между двумя маршрутизаторами BGP.

Рассмотрим соседство между Router1 и Router3. Настроим их при помощи следующих команд:

Соседство внутри одной автономной системы — AS 10. После ввода данных на маршрутизаторе, например на Router1, данный маршрутизатор пытается настроить отношения соседства с маршрутизатором Router3. Начальное состояние, когда ничего не происходит называется Idle. Как только будет настроен bgp на Router1, он начнет слушать TCP порт 179 — перейдет в состояние Connect, а когда пытается открыть сессию с Router3, то перейдет в состояние Active.

После того, как сессия установится между Router1 и Router3, то происходит обмен Open сообщениями. Когда данное сообщение отправит Router1, то данное состояние будет называться Open Sent. А когда получит Open сообщение от Router3, то перейдет в состояние Open Confirm. Рассмотрим более подробно сообщение Open:

В данном сообщение передается информация о самом протоколе BGP, который использует маршрутизатор. Обмениваясь Open сообщениями, Router1 и Router3 сообщают друг другу информацию о своих настройках. Передаются следующие параметры:

Для установления соседства необходимо выполнения следующих условий:

Здесь указывают сети, о которых сообщает Router1 и Path attributes, которые являются аналогом метрик. О Path attributes мы поговорим более подробно. Также внутри TCP сессии передаются Keepalive сообщения. Они передаются, по умолчанию, каждые 60 секунд. Это Keepalive Timer. Если в течении Hold Timer-а не будет получено Keepalive сообщение, то это будет означать потерю связи с соседом. По умолчанию, он равен — 180 секундам.

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

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

Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if the IP route exists, put the equivalent NLRI into the local BGP table.

Теперь поднимем BGP на всех оставшихся и посмотрим как происходит выбор маршрута внутри одной AS. После того, как BGP маршрутизатор получит маршруты от соседа, то начинается выбор оптимального маршрута. Здесь надо понять какого вида соседи могут быть — внутренние и внешние. Маршрутизатор по конфигурации понимает является ли сконфигурированный сосед внутренним или внешним. Если в команде:

в качестве параметра remote-as указан AS, который сконфигурирован на самом маршрутизаторе в команде router bgp 10. Маршруты, пришедшие из внутренней AS считаются внутренними, а маршруты из внешней соответственно внешними. И по отношению к каждому работает разная логика получения и отправки. Рассмотрим такую топологию:

На каждом маршрутизаторы настроен loopback интрефейс с ip: x.x.x.x 255.255.255.0 — где x номер маршрутизатора. На Router9 у нас есть loopback интерфейс с адресом — 9.9.9.9 255.255.255.0. Его мы будем анонсировать по BGP и посмотрим как он распространяется. Данный маршрут будет передан на Router8 и Router12. С Router8 данный маршрут попадет на Router6, но на Router5 в таблице маршрутизации его не будет. Также и на Router12 данный маршрут попадет в таблицу, но на Router11 его также не будет. Попытаемся разобраться с этим. Рассмотрим какие данные и параметры передается Router9 своим соседям, сообщая об этом маршруте. Пакет внизу будет отправлен с Router9 на Router8.

Информация о маршруте состоит из аттрибутов пути (Path attributes).

Атрибуты пути разделены на 4 категории:

Атрибут Origin — указывает на то, каким образом был получен маршрут в обновлении. Возможные значения атрибута:

Далее, Next-hop. Атрибут Next-hop

Теперь Router6 передал маршрут Router5 и первому правилу Next-hop не изменил. То есть, Router5 должен добавить 9.9.9.0 [20/0] via 192.168.68.8, но у него нет маршрута до 192.168.68.8 и поэтому данный маршрут добавлен не будет, хотя информация о данном маршруте будет храниться в таблице BGP:

Та же самая ситуация произойдет и между Router11-Router12. Чтоб избежать такой ситуации необходимо настроить, чтоб Router6 или Router12, передавая маршрут своим внутренним соседям, подставляли в качестве Next-hop свой ip адрес. Делается при помощи команды:

После данной команды, Router6 отправит Update сообщение, где для маршрутов в качества Next-hop будет указан ip интерфейса Gi0/0 Router6 — 192.168.56.6, после чего данный маршрут уже попадет в таблицу маршрутизации.

Пойдем дальше и посмотрим появиться ли этот маршрут на Router7 и Router10. В таблице маршрутизации его не окажется и мы могли бы подумать, что проблема как в первом с параметром Next-hop, но если мы посмотрим вывод команды show ip bgp, то увидим, что там маршрут не был получен даже с неправильным Next-hop, что означает, что маршрут даже не передавался. И это нас приведет к существованию еще одного правила:

Маршруты, полученные от внутренних соседей не передаются другим внутренним соседям.

Так как, Router5 получил маршрут от Router6, то другому своему внутреннему соседу он передаваться не будет. Для того, чтобы передача произошла необходимо настроить функцию Route Reflector, либо настроить полносвязные отношения соседства ( Full Mesh), то есть Router5-7 каждый будет соседом с каждым. Мы будем в данном случае использовать Route Reflector. На Router5 необходимо использовать данную команду:

Route-Reflector меняет поведение BGP при передаче маршрута внутреннему соседу. Если внутренний сосед указан как route-reflector-client, то данным клиентам будут анонсироваться внутренние маршруты.

Маршрут не появился на Router7? Не забываем также и про Next-hop. После данных манипуляций маршрут должен и на Router7, но этого не происходит. Это нас подводит к еще одному правилу:

Правило next-hop работает только для External маршрутов. Для внутренних маршрутов замена атрибута next-hop не происходит.

И мы получаем ситуацию, в которой необходимо создать среду при помощи статичной маршрутизации или протоколов IGP сообщить маршрутизаторам о всех маршрутах внутри AS. Пропишем статические маршруты на Router6 и Router7 и после этого получим нужный маршрут в таблице маршрутизаторе. В AS 678 же мы поступим немного иначе — пропишем статические маршруты для 192.168.112.0/24 на Router10 и 192.168.110.0/24 на Router12. Далее, установим отношения соседства между Router10 и Router12. Также настроим на Router12 отправку своего next-hop для Router10:

Итогом будет то, что Router10 будет получать маршрут 9.9.9.0/24, он будет получен и от Router7 и от Router12. Посмотрим какой выбор сделает Router10:

Как мы видим, два маршрута и стрелка ( > ) означает, что выбран маршрут через 192.168.112.12.
Посмотрим как происходит процесс выбора маршрута:

Теперь все маршруты от данного соседа будут иметь такой вес. Посмотрим как изменится выбор маршрута после данной манипуляции:

Но как видим один маршрут через Router6. А где же маршрут через Router7? Может и на Router7 его нет? Смотрим:

Странно, вроде все в порядке. Почему же он не передается на Router5? Все дело в том, что у BGP есть правило:

Маршрутизатор передает только те маршруты, которые использует сам.

Router7 используется маршрут через Router5, поэтому маршрут через Router10 передаваться не будет. Вернемся к Local Preference. Давайте зададим Local Preference на Router7 и посмотрим как отреагирует на это Router5:

Итак, мы создали route-map, в который попадаются все маршруты и сказали Router7, чтоб при получение он менял параметр Local Preference на 250, по умолчанию равен 100. Смотрим, что произошло на Router5:

Посмотрим, что произойдет, если допустим Router6 потеряет маршрут 9.9.9.0/24 через Router9. Отключим интерфейс Gi0/1 Router6, который сразу поймет, что BGP сессия с Router8 оборвана и сосед пропал, а значит и маршрут, полученные от него не действительны. Router6 сразу отправляет Update сообщения, где указывает сеть 9.9.9.0/24 в поле Withdrawn Routes. Как только Router5 получит подобное сообщение, отправит его к Router7. Но так как у Router7 есть маршрут через Router10, то в ответ сразу отправит Update c новым маршрутом. Если детектировать падения соседа по состоянию интерфейса не получается, то придеться ждать срабатывания Hold Timer-а.

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

Здесь ссылка на данную лабу, а тут конфигурация для GNS3.

Пришлось бы настраивать Route-Reflector или полносвязые отношения соседства. Разбивая одну AS 2345 на 4 sub-AS ( 2,3,4,5) для каждого маршрутизатора, мы в итоге получаем другую логику работы. Все отлично описано здесь.

Источник

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

Статья рассматривает способ управления BPG-анонсами на маршрутизаторах Cisco, c операционной системой IOS XE, с помощью Cisco Embedded Event Manager (EEM) для балансировки входящего трафика и резервирования uplink от нескольких вышестоящих провайдеров.

Введение

Часто в сети небольшого провайдера можно встретить ситуацию, когда uplink представляет собой BGP-присоединение к двум или более операторам. Причем, второй провайдер используется не в качестве резерва, а вместе и одновременно с первым. Кроме того, ситуация осложняется тем, что каналы эти могут быть не симметричны по скорости. Например, при общей потребности uplink в 2 Gbps покупается два канала у двух разных провайдеров: 1500 Mbps и 500 Mbps. Протокол BGP, в этом случае замечательно решает задачу резервирования. Конечно, полноценного резерва тут нет. Очевидно, что нельзя зарезервировать два гигабита пятьюстами мегабитами без деградации сервиса для абонентов, однако, полного отказа услуги не произойдет. А если отказ произойдет не в ЧНН (часы наибольшей нагрузки), то сервис может не пострадать вовсе.

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

Рассмотрим, в качестве примера, следующую схему:

«Наша» AS65000 подключена в двум провайдерам: ISP #1 (AS65001) и ISP #2 (AS65002) по каналам шириной 1,5 Gbps и 500 Mbps, соответственно. Абоненты в нашей сети находятся за тремя локальными маршрутизаторами R7, R8 и R9 и используют, соответственно, три подсети:

В качестве «ресурсов глобальной сети Интернет» выступают три маршрутизатора:

Провайдеры имеют между собой пиринговый стык (между R12 и R13).

В отличии от клиентского присоединения, загрузка которого прямо связано с выручкой провайдера, пиринговый стык может не приносить провайдеру непосредственный доход, а то и вовсе, быть расходным. Поэтому нормальной практикой является увеличение BPG Local Preference для клиентских присоединений, и его уменьшение для пиров. На нашей схеме значения local preference обозначены красными маркерами: на пиринге у обоих провайдеров стоит значение 100 (по умолчанию), а на соединениях с нами, как с клиентом, увеличенное 120. Такой вариант позволяет провайдеру, при получении одинакового BPG-маршрута от клиента и другого провайдера, явным образом отдавать предпочтение клиентскому присоединению. Одновременно, именно это и является одной из причин трудностей с балансировкой uplink стандартными средствами BGP.

Балансировка

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

Эмпирическим путем устанавливаем два диапазона IP-адресов, которые «потребляют» трафик в требуемой нам пропорции. Для простоты ситуации (принцип метода от этого не меняется) допустим, что абоненты за маршрутизаторами R7 и R8 потребляют примерно три четверти общего входящего трафика, а оставшаяся четверть приходится на абонентов маршрутизатора R9. В таком случае, использую BGP анонсы, мы должны добиться что бы трафик для сетей 172.16.7.0/24 и 172.16.8.0/24 шел через ISP#1, а для сети 172.16.9.0/24 – через ISP#2.

Сформируем два префикс-листа и рассмотрим методы, которыми мы можем разделить трафик для них по каналам:

AS-PATH Prepend

В качестве стандартного решения такой задачи протокол BGP предлагает механизм AS-PATH Prepend. Суть его в том, что при выборе лучшего маршрута из нескольких возможных, протокол BGP использует значение атрибута AS-PATH, где последовательно перечислены номера всех автономных систем, через которые прошел BGP-анонс. Маршрут с кратчайшим AS-PATH является предпочтительным. Метод AS-PATH prepend позволяет искусственно удлинить значение атрибута для некоторых маршрутов.

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

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

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

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

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

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

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

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

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

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

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

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

Исключение анонсов

Другой способ разделить трафик – просто исключить из BGP-анонсов в сторону оператора те префиксы, трафик на которые мы не хотим получать через этого провайдера.

Вместо route-map настроим для каждого соседа фильтрующий prefix-list.

Теперь в сторону каждого провайдера анонсируются только те маршруты, которые должны получать трафик через этот стык:

При таком подходе оператор выстраивает свою таблицу маршрутизации именно так, как нам надо:

Теперь трассировки с R11 идут через разных провайдеров:

Однако, тут возникает проблема с резервированием. Действительно, при падении ISP#2 абоненты из сети 172.16.9.0/24 лишаются сервиса, так как весь мир больше «не видит» маршрута к ним. Обычно, это можно решить анонсированием агрегирования префикса для резерва. Например, если бы мы располагали диапазоном адресов от 172.16.6.0 до 172.16.9.255, то мы могли бы дополнительно анонсировать обоим провайдерам укрупненные подсети 172.16.6.0/23 и 172.16.8.0/23, которые включают в себя наши префиксы. Тогда, при падении одного из провайдеров и исчезновении в Интернете «специфик» маршрутов /24, все равно оставались бы /23, и сервис работал бы у всех абонентов даже на одном uplink. Но в нашем примере такое невозможно. Наши клиентские сети нельзя агрегировать в один или два префикса. Конечно, сети в примере подобраны специально, но, именно, столкновение с такой ситуацией на практике подтолкнуло меня к написанию заметки.

Резервирование

Мы решили проблему балансировки входящего трафика. Осталось добиться резервирования. Общий путь решения поняетн: в случае падения одного из пиров менять фильтр исходящих анонсов на том, пире, что еще «жив». Это можно было бы реализовать «снаружи», меняя настройки нашего пограниченого маршрутизатора скриптом по SSH или SNMP. Однако, цель заметки – сделать все встроенными средствами Cisco.

BGP Conditional Advertisement

Один из вариантов управления BGP-анонсами в зависимости от состояния BGP-соседства — Conditional Advertisement, которое позволяет анонсировать в сторону соседа те или иные префиксы, в зависимости от наличия или отсутствия в таблице BGP «контрольных» префиксов.

Префиксы, которые нужно анонсировать или, наоборот, убрать из анонса определяются специальным route-map: advertise-map, который может быть в режиме withdraw (префиксы, соответствующие route-map исключаются из анонса) или advertise (префиксы участвуют в анонсе). «Контрольные» префиксы определяются отдельным condition-map, который может быть объявлен как exist-map или non-exist-map. В первом случае префиксы из advertise-map анонсируются, только если в таблице BGP есть префиксы, соотвествующие exist-map. В случае non-exist-map — наоброт: если non-exist-map возвращет пустой список префиксов, то префиксы advertise-map анонсируются, а если нет, то исключаются из анонса.

В нашем случае подходит вариант с non-exist-map. Конфигурация route-map тут имеет несколько особенностей:

Значить нам нужен контрольный префикс. Можно выбрать что-то из того, что нам анонсируют провайдеры (или даже сообщить им, что вы используете conditional advertisement и попросить добавить в анонс префикс, на который можно ориентироваться). Но в большинстве случаев (если среди ваших клиентов нет других провайдеров) вы, вместо full-view, получите от своего вышестоящего провайдера default-префикс 0.0.0.0/0. Его мы и будем использовать в качестве контрольного. А что бы отличить default одного провайдера от другого добавим в non-exist-map фильтр по AS-PATH.

Создадим prefix-list и два as-path ACL:

Добавим два condition-map, каждый из которых будет возвращать непустой список, только если соединение с соответствующим ISP установлено:

Создадим два route-map, который будут advertise-map для соотвествубщих пиров:

Еще один route-map будем использовать для фильтрации всех исходящих анонсов:

Теперь применим их в конфигурации BGP-соседей:

Рассмотрим подробней конфигурацию neighbor 192.168.103.3:

Посмотрим, что получилось. Изначально «контрольные» префиксы для обоих non-exist-map есть в таблице BGP и соответствующие advertise-map находятся в статусе withdraw:

Так как оба провайдера «живы», то в сторону каждого из них анонсируются только часть префиксов:

В случае отключения BGP-соседства c ISP#1 из таблицы BGP исчезают префиксы для route-map isp-1-is-alive и advertise-map isp-2-adv для ISP#2 переходит в статус advertise:

Теперь префиксы по route-map isp-2-adv не исключаются из анонса и в сторону ISP#2 анонсируется полный набор префиксов:

При восстановлении BGP-соседства статус меняется advertise-map обратно на withdraw, и префиксы вновь распределяются по провайдерам для балансировки.

Еще один вариант использования Conditional Advertismement, это локализация проблемы на стороне провадйера или даже выше его зоны ответственности. В случае нашей тестовой схемы можно представить, что в AS65110 находится дацацентр крупного контент-провайдера, доступ к которому критичен для наших абонентов. В случае падения пиринговой связанности между двумя провайдерами, часть абонентов, чьи префиксы анонсируются только в сторону ISP#1 лишатся доступа в AS65110. При этом соединение с провайдером есть, префиксы и default от него есть, но сервис абонентов страдает. В этом случае мы можем использовать конфигурацию, аналогичную описанной выше, только в качестве «контрольного» префикса использовать адреса критично важных для нас ресурсов в AS65110.

Cisco Embedded Event Manager

Описанный дальше метод, учитывая возможности BGP Conditional Advertismement, выглядит немного искусственным для решения такой простой задачи. Причина этого в том, что в первоначальной версии статьи он был единственным, так как рассказ о Cisco EEM и был целью написания заметки. При этом проблема балансировки была выбрана как наиболее простой и понятный вариант иллюстрации. Однако позже, в комментариях, мне справедливо указали, что описывать проблему управления BGP-анонсами не упомянув инструмент, который именно для этого и предназначен не очень корректно. Так в статье появился параграф про BGP Conditional Advertisment, на фоне которого применение Cisco EEM кажется громоздким и избыточным. Однако это очень мощный инструмент, имеющий колоссальное поле применения, так что познакомиться с ним все же стоит.

Мы решили проблему балансировки входящего трафика. Осталось добиться резервирования. Общий путь решения понятен: в случае падения одного из пиров менять фильтр исходящих анонсов на том, пире, что еще «жив». Это можно было бы реализовать «снаружи», меняя настройки нашего пограниченого маршрутизатора скриптом по SSH или SNMP. Однако, цель заметки – сделать все встроенными средствами Cisco.

Тут нам пригодиться механизм Cisco Embedded Event Manager (EEM). Это очень гибкий механизм управления маршрутизатором и траблшутинга проблем на сети, возможности которого выходят далеко за пределы описываемой задачи. Нам от него требуется его умение отловить возникновение определённого события (падение или восстановление BGP-соседства) и выполнить заданный набор команд.

Для начала создадим префикс-лист, который включает в себя все наши префиксы.

Теперь сконфигурируем EEM-аплет, который будет запускаться при возникновении в логе записи об изменении статуса BGP-соседства (определяем регулярным выражением). Аплет:

Изначально обе BGP-сессии у нас активны и анонсы выглядят следующим образом:

На сети ISP#2 наши анонсы выглядят следующим образом:

Трассировки с R11 идут в нашу сеть так, как нам нужно:

Теперь попробуем отключить пир с ISP#1 со стороны провайдера. В результате одна из BGP-сессий на нашем бордере переходит в IDLE:

В логе мы при этом видим, что как только возникло событие %BGP-5-NBR_RESET: Neighbor 192.168.101.1 reset (Peer closed the session) сработал наш аплет и изменил префикс-лист:

Посмотрим, что теперь мы анонсируем в сторону ISP#2:

Т.е. теперь мы анонсируем через ISP#2 все наши префиксы. Вот как это теперь выглядит на R13:

А все трассировки в нашу сеть идут через одного провайдера.

При восстановлении BGP-сессии с IPS#1 аплет снова вернет префикс-лист для ISP#2 в исходное положение.

Заключение

Целью статьи было кратко рассмотреть применение Cisco EEM для управления входящим трафиком при балансировке нескольких аплинков, и, надеюсь, это удалось. Конечно, данный способ едва ли возможно назвать оптимальным. Скорее, это решение «в лоб». Однако, он работает и обеспечивает определенную степень отказоустойчивости. Для написания заметки вся схема собиралась в UNELAB на образах Cisco IOL и Cisco CSRv1000. Конфигурации всех устройств из рассматриваемго примера можно скачать по ссылке.

Источник