Протокол bgp принцип работы. Преимущества использования BGP

Базовая настройка:

Router(config)# router bgp

remote-as

ID маршрутизатора в BGP берется из следующих источников, в порядке предпочтения:

Команда bgp router-id
Наибольший IP петлевого (loopback) интерфейса
Наибольший IP физического интерфейса

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

Маршруты, объявляемые вручную, указываются следующей командой:

Включение редистрибуции:

Router(config-router)# redistribute

Маршруты, добавленные вручную (командой network ) помечаются как маршруты, происходящие из IGP ("i"), а маршруты, полученные при редистрибуции, помечаются как маршруты с неизвестным происхождением ("?").

BGP-маршрутизатор может отдавать своим соседям маршрут по-умолчанию:

Router(config-router)# neighbor
default-originate

Требование синхронизации маршрутов можно отключить, позволив тем самым BGP импортировать в свою таблицу внутренние маршруты, не известные IGP:

Router(config-router)# no synchronization

Атрибут "next hop" в маршрутах, рассылаемых iBGP-пирам, можно подменять на адрес объявляющего эти маршруты роутера:

Router(config-router)# neighbor
next-hop-self

Регулировка таймеров (в секундах):

Router(config-router)# bgp timers

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

Router(config-router)# neighbor
update-source

Для увеличения TTL в eBGP, которое по-умолчанию равно 1, используется "eBGP multihop":

Router(config-router)# neighbor
ebgp-multihop

"eBGP multihop" обязателен, если используются петлевые интерфейсы.

Агрегация маршрутов

Статические маршруты:

Router(config)# ip route 192.168.0.0 255.255.0.0 Null0
...
Router(config-router)# network 192.168.0.0 mask 255.255.0.0

Команда "aggregate-address":

Router(config-router)# aggregate-address 192.168.0.0 255.255.0.0

Если используется ключевое слово summary-only , объявляется только агрегированный маршрут. Если же это ключевое слово не используется, то наряду с агрегированным маршрутом рассылаются и more-specific (морспецифики, более конкретные маршруты).

С другой стороны, отдельные морспецифики можно фильтровать при помощи "подавления" (suppress map) :

Router(config-router)# aggregate-address 192.168.0.0 255.255.0.0 suppress-map

С целью изменения атрибутов агрегированному адресу можно назначить attribute map (например, для установки origin - происхождения маршрута):

Router(config-router)# aggregate-address 192.168.0.0 255.255.0.0 attribute-map

По-умолчанию в агрегированный маршрут не включается "AS Set". Для включения этого атрибута:

Router(config-router)# aggregate-address 192.168.0.0 255.255.0.0 as-set

При включении "AS Set" агрегированный маршрут наследует все атрибуты включенных в него маршрутов. Для наследования атрибутов только от избранных маршрутов используется "advertise map ":

Router(config-router)# aggregate-address 192.168.0.0 255.255.0.0 as-set advertise-map

Управление BGP-соединениями

Для удобства каждому соседу можно назначить описание:

Router(config-router)# neighbor 192.168.123.45 description R7 in Moscow

Соединение с отдельным соседом можно спрятать под пароль (хэш MD5 включается в BGP-пакеты):

Router(config-router)# neighbor 192.168.123.45 password FooBar

Для каждого соседа можно настроить интервал рассылки (advertisement interval) , регулируя тем самым время ожидания перед отправкой объявлений (0-600 секунд):

Router(config-router)# neighbor 192.168.123.45 advertisement-interval

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

Router(config-router)# neighbor 192.168.123.45 version

Можно настроить маршрутизатор таким образом, чтобы в процессе выбора наилучшего маршрута не учитывалась длина "AS Path":

Router(config-router)# bgp bestpath as-path ignore

Количество префиксов, получаемых от соседа, можно ограничить:

Router(config-router)# neighbor 192.168.123.45 maximum-prefix []

Здесь порог предупреждения (warning threshold) определяет процент от максимального количества префиксов, при превышении которого генерируется предупреждение. Ключевое слово warning-only позволяет соединению продолжать работу, даже если пир превысил максимальный порог префиксов.

Для временного отключения соседа без удаления его конфигурации используется команда neighbor shutdown .

Правила маршрутизации

Для фильтрации принимаемых или рассылаемых маршрутов применяются списки дистрибуции (distribute list):

Router(config-router)# neighbor distribute-list {in | out}

Для фильтрации маршрутов, основываясь на их "AS Path", применяются списки фильтрации (filter list):

Router(config)# ip as-path access-list 1 permit
...
Router(config-router)# neighbor filter-list {in | out}

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

Router(config-router)# neighbor route-map {in | out}

Административный вес влияет на предпочтения среди маршрутов, полученных от BGP-пиров. Маршрутам от отдельного соседа этот вес (0-65535) можно назначить локально:

Router(config-router)# neighbor weight

По-умолчанию маршрутам, имеющим локальное происхождение, назначается вес 32768, в то время как вес всех остальных равен 0. Вес можно назначать и избранным маршрутам, применяя роутмапы или используя ключевое слово weight после параметра filter-list :

Router(config-router)# neighbor filter-list weight

Административная дистанция отличается от веса тем, что влияет на предпочтения среди маршрутов, полученных от разных протоколов маршрутизации. Чем меньше дистанция, тем предпочтительней. Административная дистанция внешних BGP-маршрутов равна 20. Дистанция внутренних и локальных (генерируемых данным роутером при помощи команды network ) BGP-маршрутов равна 200.

Бэкдор (backdoor link, черный ход) - приватное соединение между AS, которому должно отдаваться предпочтение перед eBGP-маршрутами. Для чего административная дистанция внешнего маршрута должна быть искусственно завышена включением в BGP-процесс необходимой сети с ключевым словом backdoor :

Router(config-router)# network backdoor

Маршрут к указанной сети будет считаться локальным с административной дистанцией 200, из-за чего предпочтение будет отдаваться маршрутам, полученным из IGP, который работает в этом приватном линке, и трафик вместо внешнего маршрута потечет по бэкдору.

Кроме того, iBGP-пиры обмениваются друг с другом локальными предпочтениями (local preference, 32-битная величина, по-умолчанию равная 100). Это значение можно установить командой ip default local-preference , либо set local-preference в роутмапе. В отличие от административного веса, действие локалпрефов распространяется за пределы локального роутера.

Влияние на путь, которым трафик будет заходить в вашу AS из соседней, при наличии нескольких точек входа, оказывает MED (или "метрика"). Для установки MED BGP-маршрута равным значению метрики такого же маршрута из IGP, в роутмапе можно воспользоваться командой set metric-type internal . Для принудительного сравнения MED нескольких маршрутов к одному адресату, даже если они происходят из разных AS, в BGP-процессе применяется команда bgp always-compare-med .

MED влияет только на поведение соседней AS. Повлиять аналогичным образом на поведение удаленных AS можно при помощи искусственного увеличения "AS Path" маршрутов. Для этого в роутмапе используется команда set as-path prepend . Обычно локальная AS "препендится" один или несколько раз. Например, для маршрутов AS 123:

route-map PREPEND_AS permit 10
match ip address
set as-path prepend 123 123 123

Для сохранения BGP-информации в процессе редистрибуции в/из IGP используется тегирование маршрутов (route tagging). По-умолчанию маршруты, передаваемые из BGP в IGP, тегируются собственным "AS Path". В тег можно добавить ещё происхождение маршрута командой set automatic-tag в роутмапе. Для автоматической установки атрибута "AS Path" из тега при редистрибуции маршрута из IGP обратно в BGP применяется команда set as-path tag в роутмапе. Также теги маршрутов могут применяться для хранения BGP-коммьюнити.

Включение подавления маршрутов:

Router(config-router)# bgp dampening [ ]

Посмотреть подавленные маршруты можно командой show ip bgp dampened-paths . Команда show ip bgp flap-statistics позволяет просмотреть все текущие подавленные маршруты вместе с маршрутами, которые вообще когда-либо подавлялись. Команда clear ip bgp dampening возвращает подавленные маршруты обратно в обслуживание. Командой clear ip bgp flap-statistics стирается вся история "мигания" маршрутов.

BGP в больших сетях

Пример организации пиринговой группы:

Router(config-router)# neighbor BRANCHES peer-group
Router(config-router)# neighbor BRANCHES ebgp-multihop 2
Router(config-router)# neighbor BRANCHES update-source Loopback 0
Router(config-router)# neighbor 10.1.0.84 peer-group BRANCHES
Router(config-router)# neighbor 10.1.0.84 remote-as 123

Router(config)# ip community-list 101 {permit | deny}

Критерий сравнения по коммьюнити-листу в роутмапе можно включать командой match community . Коммьюнити можно добавлять к маршруту без изменения уже присвоенных ему коммьюнити при помощи ключевого слова additive команды set community . Определенные коммьюнити, совпадающие с коммьюнити-листом, можно удалять командой set comm-list delete .

Номера приватных AS

Частные ASN находятся в промежутке с 64512 по 65535. В настройках соседа командой remove-private-as

На роут-рефлекторе должны быть указаны внутренние пиры, которым он должен отражать маршруты:

Router(config-router)# neighbor route-reflector-client

Роут-рефлектор добавляет к маршрутам "Originator ID", указывающий на происхождение маршрута, и "Cluster List", определяющий рефлект-кластер во избежание появления маршрутных петель. По-умолчанию роут-рефлектор добавляет свой ID в список кластера. Но ID кластера можно указать вручную командой bgp cluster-id . Это необходимо, если в кластере несколько рефлекторов.

Если клиенты рефлектора полносвязны между собой, для отключения отражения маршрутов между клиентами используется команда no bgp client-to-client reflection . Маршруты извне кластера будут продолжать отражаться обычным образом.

Пограничный (внешний) шлюзовой протокол (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 используется сегодня не только для обмена маршрутной информацией между автономными системами, но и внутри них.

Тема чертовски глобальная, в эти игры уже играют провайдеры.
В рамках этой статьи мы обсудим следующие моменты:
- Непосредственно протокол 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 .

1. Использование BGP для п одключения к провайдеру

Интернет - это набор автономных систем, которые соединены между собой для коммуникации. BGP обеспечивает маршрутизацию между этими автономными системами.
Предприятие, кjторое хочет подключиться к интернету, делает это через одного из провайдеров. Если предприятие имеет только одно подключение к интернету, возможно, ему не понадобится использовать BGP, вместо него можно использовать маршруты по умолчанию. Однако, если имеется несколько подключений к одному или нескольким провайдерам, BGP будет предпочтительным для использования, т.к. он позволяет манипулировать атрибутами маршрутов, чтобы был выбран оптимальный путь.
Чтобы понять BGP, надо понять, чем он отличается от других протоколов маршрутизации. Один путь, это разделить протоколы на внешние и внутренние протоколы маршрутизации, такие как:
- IGP (Interior gateway protocol), внутренний протокол маршрутизации - это протокол, который обменивается маршрутной информацией внутри автономной системы Примеры таких протоколов - RIP, OSPF, EIGRP.

EGP (Exterior gateway protocol), внешний протокол маршрутизации - протокол, который обменивается маршрутной информацией между разными автономными системами. BGP - пример внешнего протокола. BGP является внутридоменным протоколом маршрутизации (IDRP), также известным как EGP. Последней версией протокола является BGP версии 4, который описан в RFC 4271. Как сказано в RFC, классическое описание автономной системы - набор маршрутов под одним техническим администрированием, который маршрутизирует пакеты внутри автономной системы с помощью внутренних протоколов маршрутизации, а также с помощью внешних протоколов маршрутизации определяет, как маршрутизируются пакеты к другим автономным системам.

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

Когда BGP работает между маршрутизаторами в разных автономных системах, он называется внешним BGP (EBGP). Когда BGP работает между маршрутизаторами внутри одной автономной системы, он называется внутренним BGP (IBGP). BGP определяет путь для пакетов между автономными системами. Важно понимать, как работает BGP для избежания создания проблем для автономной системы в результате работы BGP.

2. Варианты использования BGP для нескольких подключений к провайдеру

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

Резервирование несколькими подключениями

Нет привязки к политике маршрутизации одного провайдера

Наличие многих путей к одним и тем же сетям для улучшения политики управления маршрутами

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

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

Каждый провайдер пропускает только один маршрут по умолчанию к автономной системе. Этот маршрут указывает на внутренние маршрутизаторы

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

Каждый провайдер пропускает все маршруты в автономную систему. На всех внутренних маршрутизаторах по пути транзита работает BGP и пропускает маршруты между маршрутизаторами.

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

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

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

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

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

Управление пропускной способностью очень сложное и может быть применено только манипулированием метрики маршрута по умолчанию внутреннего протокола маршрутизации

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

Как видно на рисунке, автономные системы AS 65020 и AS 65030 отправляют маршруты по умолчанию в AS 65010, сеть абонента А. Из-за метрики внутреннего протокола маршрутизации сети абонента А, а также из-за настройки маршрутизаторов R1 и R2, граничный маршрутизатор провайдера PE1 выбран как маршрут по умолчанию для достижения любой внешней сети за пределами автономной системы абонента А.

Эта процедура может привести к неоптимальной маршрутизации. Например, при задаче отправить пакет в сеть 172.17.0.0, пакет будет сначала отправлен провайдеру ISP1 на маршрутизатор РЕ1, так как маршрутизатор РЕ1 является предпочтительным путем для абонента А. А затем уже провайдер ISP1 отправит пакет в сеть назначения провайдеру ISP2.

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

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

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

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

На рисунке провайдеры в AS 65020 и AS 65030 отправляют маршруты по умолчанию и маршруты к своим абонентам абоненту А (AS 65010).

Путем использования внутреннего BGP между внутренними маршрутизаторами R1 и R2 внутри AS 65010, AS 65010 может выбрать оптимальный путь к сетям провайдеров ISP1 и ISP2. Если сеть абонента А отправляет трафик к неизвестной сети, будет использоваться один из двух маршрутов по умолчанию. Снова таки это может привести к неоптимальной маршрутизации, как показано на рисунке. Неизвестный маршрут к другой автономной системе не показан на рисунке, так как эти маршруты не были проанонсированы в AS 65010 провайдерами ISP1 и ISP2. Метрика внутреннего протокола маршрутизации будет использована для выбора маршрута по умолчанию за пределы автономной системы абонента А.

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

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

Автономная система отправляет все свои маршруты провайдерам, которые обрабатывают маршруты и отправляют эти маршруты другим автономным системам.

На рисунке AS 65020 и AS 65030 отправляют все маршруты в AS 65010. Провайдер, имеющий маршрут к специфической внешней сети из AS 65010, определяется с помощью BGP.

Маршрутизаторы в AS 65010 могут быть настроены для влияния на маршруты к определенным сетям. Например, R1 и R2 могут влиять на выбор маршрута для исходящего трафика из AS 65010.

3. BGP маршрутизация между автономными системами

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

IANA - организация, ответственная за присвоение номеров автономным системам. Конкретно, ARIN (Американский регистратор номеров интерната) отвечает за присвоение номеров для Америки, Карибов и Африки. RIPENIC (Европейский исследовательский сетевой информационный центр IP) присваивает номера автономным системам в Европе. А APNIC (Азиатско-Тихоокеанский сетевой информационный центр) - за присвоение номеров автономным системам в Азиатско-Тихоокеанском регионе.

Номера автономных систем - это 16-битный номер от 1 до 65535. RFC 1930 предоставляет руководство по использованию номеров автономных систем. Диапазон номеров автономных систем от 64512 до 65535 зарезервирован для частного использования, наподобие частных IP адресов.

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

BGP - то преемник EGP, который был разработан для изоляции сетей одна от другой при росте интернета.

Есть много RFC, относящихся к BGP4, текущей версии BGP. Эти RFC включают 1772, 1773, 1774, 1930, 1966, 1997, 1998, 2042, 2385, 2439, 2545, 2547, 2796, 2858, 2918, 3065, 3107, 3392, 4223 и 4271.

BGP4 имеет много улучшений по сравнению с более ранними протоколами. Интернет широко использует BGP для соединения провайдеров и подключения предприятий к провайдерам.

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

Когда используется бесклассовая маршрутизация на маршрутизаторе ядра основного провайдера, построенная таблица маршрутизации состоит в основном из BGP маршрутов и имеет более 175000 блоков бесклассовых сетей. Если не использовать бесклассовую маршрутизацию, таблица маршрутизации может содержать более 2 000 000 записей. Использование BGP4 предотвращает таблицу маршрутизации интернета становиться слишком большой для соединения миллионов пользователей.

3. Сравнение BGP с внутренними протоколами маршрутизации

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

4. Функциональность вектора пути

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

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

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

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

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

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

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

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

Примеры BGP политик:

На рисунке выше у автономной системы AS 65010 есть следующие возможные пути для достижения AS 65060 через AS 65020:

65020 - 65030 - 65060

65020 - 65050 - 65060

65020 - 65030 - 65050 - 65070 - 65060

65020 - 65050 - 65030 - 65060

65020 - 65050 - 65070 - 65060

Но AS 65010 не видит все эти возможности.

AS 65020 передает AS 65010 только информацию о лучшем пути 65020 - 65030 - 65060, так же как протокол внутренней маршрутизации анонсирует только лучший путь с наименьшей стоимостью. Это единственный путь через AS 65020, который AS 65010 увидит. Все пакеты с сетью назначения, принадлежащей AS 65010, будут идти через AS 65020 только по этому маршруту.

Даже если существуют другие пути, AS 65010 может использовать лишь тот путь к AS 65060, который был анонсирован AS 65020. Путь к автономной системе, который был анонсирован, 65020 - 65030 - 65060, это путь «шаг за шагом», который AS 65020 использует, чтобы достигнуть AS 65060. AS 65020 не будет анонсировать другой путь, например, 65020 - 65050 - 65030 - 65060, тка как он не будет выбран лучшим путем политикой маршрутизации AS 65020.

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

Даже если AS 65010 узнает о каком-то пути через AS 65020, он не сможет его использовать, т.к. AS 65020 не отправит трафик по другому пути, у него есть лучший путь 65020 - 65030 - 65060, поэтому именно его он и будет использовать, согласно политики маршрутизации BGP. BGP не позволяет одной автономной системе отправлять трафик через соседнюю автономную систему по маршруту, отличному от маршрута, которым пользуется трафик, генерируемый в соседней автономной системе.

AS 65010 может выбрать для отправки трафика в AS 65060 маршрут через AS 65020 или через AS 65040. AS 65010 выберет лучший путь, основываясь на собственной политике маршрутизации BGP.

5. Особенности BGP

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

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

BGP - это только IP протокол маршрутизации, который использует NCP как транспортный уровень. OSPF, IGRP и EIGRP работают именно на IP уровне, а RIP использует UDP как транспорт.

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

С другой стороны, BGP имеет в интернете более 175 000 сетей для анонсирования, и это число растет. BGP использует TCP для обеспечения функции подтверждения. NCP использует динамический размер окна, которое позволяет отправить 65 576 байт перед тем, как отправка будет остановлена для ожидания подтверждения. Например, при использовании максимального размера окна, если будут отправляться 1000-байтные пакеты, понадобится отправка 65 неподтвержденных пакетов перед тем, как BGP остановит передачу и будет ждать подтверждение.

TCP разработан для использования скользящего размера окна, где приемник отправляет подтверждение в точке приема половины размера передаваемого окна. Этот метод позволяет TCP приложениям, таким как BGP, продолжать отправку пакетов без необходимости остановки для ожидания подтверждения, как это требуется в OSPF и EIGRP.

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

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

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

BGP следует использовать в следующих случаях:

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

Если автономная система имеет несколько подключений к другим автономным системам

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

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

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

Когда недостаточно ресурсов процессора и памяти на граничном маршрутизаторе для применения BGP маршрутизации

Когда недостаточно понимания о фильтрации маршрутов и процессе выбора пути BGP

Если политика маршрутизации, применяемая в автономной системе, совместима с политикой в автономной системе провайдера, нет необходимости или нежелательно настраивать DGP в этой автономной системе

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

Для того, чтобы BGP установил соседские отношения, он должен быть явно настроен для каждого соседа. ВGP формирует TCP отношения с каждым настроенным соседом и поддерживает эти отношения путем отправки BGP/TCP сообщения поддержания отношений. BGP отправляет это сообщение каждые 60 секунд.

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

Внешние BGP маршруты, изученные от внешних автономных систем, имеют административное расстояние 20. Внутренние BGP маршруты, изученные внутри автономной системы, имеют административное расстояние 200.

Существует четыре типа сообщений BGP: open, keepalive, update, notification.

После установления TCP соединения, первое сообщение, отправляемое каждой стороной, это open сообщение. После получения open сообщения, каждая сторона отправляет keepalive сообщение, которым подтверждает получение. После получения подтверждения о получении open сообщения устанавливаются BGP отношения, BGP соседи могут обмениваться любыми update, keepalive и notification сообщениями.

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

Open сообщение - содержит следующюю информацию:

Номер версии - предлагаемый номер версии протокола. Наибольший номер версии, поддерживаемый маршрутизаторами. Большинство реализаций BGP маршрутизации сейчас используют BGP4.

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

Hold time - максимальное число секунд, которое может пройти между успешными keepalive или update сообщениями отправителя. При получении open сообщения маршрутизатор вычисляет значение hold таймера путем использования меньшего значения между настроенным на маршрутизаторе и полученным в open сообщении

BGP router-ID - 32-битное поле, показывающее BGP идентификатор отправителя. BGP ID - это IP адрес, назначенный маршрутизатору, он определяется при загрузке. BGP router-ID выбирается так же, как и OSPF router ID? Это наибольший IP адрес активного интерфейса маршрутизатора при условии, что loopback интерфейсы не настроены. А если настроены loopback интерфейсы, BGP router-ID выбирается как наибольший IP адрес одного из loopback интерфейсов. Router-ID также можно задать вручную.

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

Keepalive сообщение - обмен этими сообщениями проводится соседями чаще, чем истекает врямя hold таймера. Если согласованное значение hold таймера равно 0, периодическая отправка keepalive сообщений не производится. Keepalive сообщение состоит только из заголовка.

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

Withdrawn routes - список отображает IP адреса префиксов маршрутов, которые выведены из эксплуатации, если таковые имеются

Path attributes - эти атрибуты включают: путь к автономной системе, происхождение, локальные предпочтения и др. Каждый атрибут пути включает атрибут TLV. Тип атрибута состоит из флагов, которые следуют за кодом типа атрибута.

Network-layer reachability information - это поле содержит список префиксов IP адресов, которые доступны по этому пути.

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

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

к какой сети он должен его передать;
по какому пути.

Последнее решение основано на выборе оптимального пути. Какой доступный путь является оптимальным путем? Это обычно определяется метрикой. Метрика – это условная стоимость передачи по сети. Полное измерение конкретного маршрута равно сумме метрик сетей, которые включают в себя маршрут . Маршрутизатор выбирает маршрут с наименьшей метрикой. Метрика назначается для интерфейса сети в зависимости от типа протокола. Некоторые простые протоколы, подобно протоколу маршрутной информации ( RIP – Routing Information Protocol ), рассматривают все сети как одинаковые. Тогда стоимость прохождения через каждую сеть - одна и та же, и для определения метрики подсчитываются участки. Так, если пакет, чтобы достигнуть конечного пункта, проходит через 10 сетей, полная стоимость составляет 10 участков.

Другие протоколы, такие как "первоочередное открытие наикратчайших путей" ( OSPF - Open Shortest Path First ), позволяют администратору назначить стоимость для передачи через сеть , основанную на типе требуемого обслуживания. Маршрут через сеть может иметь различную стоимость (метрику). Например, если для типа сервиса желательна максимальная производительность , спутниковый канал имеет меньшую метрику, чем оптическая линия. С другой стороны, если типу сервера желательна минимальная задержка, оптическая линия имеет меньшую метрику, чем спутниковый канал. OSPF позволяет каждому маршрутизатору иметь таблицу последовательностей маршрутов, основанную на требуемом типе сервиса.

Другие протоколы определяют метрику различно. В протоколе пограничной маршрутизации ( BGP - Border Gateway Protocol ) критерий - это политика, которую может устанавливать администратор . Политика - это принцип, по которому определяется путь .

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

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

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

Внутренняя и внешняя маршрутизация

Сегодня Интернет - громадная сеть , так что один протокол маршрутизации не может обрабатывать задачу обновления таблиц всех маршрутизаторов. По этой причине Интернет разделяется на автономные системы. Автономная система (Autonomous System – AS) - группа сетей и маршрутизаторов под управлением одного администратора. Маршрутизация внутри автономной системы отнесена к внутренней маршрутизации . Маршрутизация между автономными системами отнесена к внешней маршрутизации . Каждая автономная система может выбрать протокол внутренней маршрутизации для того, чтобы обрабатывать маршрутизацию внутри автономной системы. Однако для обработки маршрутизации между автономными системами выбирается только один протокол маршрутизации .

Разработано несколько внутренних и внешних протоколов. В этой лекции мы коснемся только наиболее популярных из них - внутренних протоколов RIP и OSPF и одного внешнего протокола BGP . RIP и OSPF используются для обновления таблиц маршрутизации внутри автономной системы. Протокол BGP применяется в обновлении таблиц маршрутизации для маршрутизаторов, которые объединяют вместе автономные системы.

Протокол маршрутной информации (RIP)

Протокол маршрутной информации ( RIP – Routing Information Protocol ) - внутренний протокол маршрутизации , используется внутри автономной системы. Это очень простой протокол, основанный на применении дистанционного вектора маршрутизации. В этом разделе сначала рассмотрим принцип дистанционного вектора маршрутизации, так как он применяется в RIP , а затем обсудим сам протокол RIP .

Вектор расстояния маршрутизации

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

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