?

Log in

No account? Create an account

Изменяю своим привычкам


Previous Entry Share Next Entry
Сети для самых маленьких. Часть восьмая. BGP и IP SLA
eucariot
[Все выпуски]
7. Сети для самых маленьких. Часть седьмая. VPN
6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование


До сих пор мы варились в собственном соку – VLAN’ы, статические маршруты, OSPF. Плавно росли над собой из зелёных студентов в крепких инженеров.
Теперь отставим в сторону эти игрушки, пришло время BGP.

Сегодня мы

  • Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка

  • Подключаемся к провайдеру по BGP

  • Организуем резервирование и распределение нагрузки между несколькими линками

  • Рассмотрим вариант резервирования без использования BGP – IP SLA







Друзья, статья 90 000 символов не помещается в ЖЖ, поэтому прошу проследовать на сайт linkmeup.ru, где она в полном варианте.


Сначала освежим в памяти основы протоколов динамической маршрутизации.
Бывает два вида протоколов: IGP (внутренние по отношению к вашей автономной системе) и EGP (внешние).
И те и другие опираются на один из двух алгоритмов: DV (Distance Vector) и LS (Link State).
Внутренние мы уже рассматривали. К ним относятся ISIS/OSPF/RIP/EIGRP. Нужны они для того, чтобы обеспечить распространение маршрутной информации внутри вашей сети.

EGP представляет только один протокол – BGP – Border Gateway Protocol. Он призван обеспечивать передачу маршрутов между различными сетями (автономными системами).
Грубо говоря, стык между Балаган-Телекомом и его аплинковым провайдером будет точно организован через BGP.
То есть схема применения примерно такая:



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


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

Чтобы было немного понятнее, можно, например, представить, что город – это автономная система. И как два города связаны между собой магистралями, так и две АС связываются между собой BGP. При этом внутри каждого города есть своя дорожная система – IGP.

Вот как это выглядит с небольшого отдаления:



В BGP AS – это не просто какая-то абстрактная вещь для удобства. Эта штука весьма формализована, есть специальные окошки в собесе, где можно в будние дни с 9 до 6 получить номер автономной системы. Выдачей этих номеров занимаются RIR (Regional Internet Reistry) или LIR (Local Internet Registry).

Вообще глобально этим занимается IANA. Но чтобы не разорваться, она делегирует свои задачи RIR – это региональные организации, каждая из которых отвечает за определённую часть планеты (Для Европы и России – это RIPE NCC)



LIR’ом может стать почти любая желающая организация при наличии необходимых документов. Они нужны для того, чтобы RIR’у не пришлось напрягаться с запросами от таких мелких контор, как ЛинкМиАп.

Ну вот, например, Балаган-Телеком мог бы быть LIR’ом. И у него мы и взяли ASN (номер АС) – 64500, например. А у самого у него AS 64501.

До 2007 года были возможны только 16-ибитные номера AS, то есть всего было доступно 65536, номеров. 0 и 65535 – зарезервированы.
Номера 64512 до 65534 предназначены для приватных AS, которые не маршрутизируются глобально – что-то вроде приватных IP-адресов.
Номера 64496-64511 – для использования в примерах и документации, чем мы и воспользуемся.

Сейчас возможно использование 32битных номеров AS. Этот переход значительно легче, чем IPv4->IPv6.


Опять же нельзя говорить об автономных системах без привязки к блокам IP-адресов. На практике с каждой AS должен быть связан какой-то блок адресов.

PI и PA адреса


В пору своей профессиональной юности, читая договор с нашим LIR я посмеивался над менеджерами, которые не могли правильно написать IP-адрес: то и дело в тексте встречалось слово “PI-адрес”.
Слава богу хватило тогда ума загуглить этот вопрос

На самом деле PI – это Provider Independent.

В обычной ситуации, когда вы подключаетесь к провайдеру, он выдаёт вам диапазон публичных адресов – так называемые PA-адреса (Provider Aggregatable).
Получить их – раз плюнуть, но если вы не являетесь LIR’ом, то при смене провайдера придётся возвращать и PA-адреса. Тем более фактически допускается подключение только к одному провайдеру.
И если вы решите сменить провайдера, то старые адреса уйдут вместе с ним, а новый провайдер выдаст новые. Ну и где тут гибкость?


У LIR вы можете приобрести повайдеро-независимый блок адресов (PI) и обязательно ASN. В нашем случае пусть это будет блок 100.0.0.0/23, который мы будем анонсировать по BGP своим соседям. И эти адреса уже чисто наши и никакие провайдеры нам не страшны: не понравился один – ушли к другому с сохранением своих адресов.

Получить PI-адреса всегда было не очень просто. Вам нужно подготовить массу документов, обосновать необходимость такого блока итд.
Сейчас с исчерпанием IPv4 получить большие блоки становится всё сложнее. RIR их уже не выдаёт, а LIR раздают последнее.


Таким образом и номера AS и PI-адреса можно получить в одних их тех же конторах.

После получения всего этого хозяйства вам нужно будет ещё внести изменения в базу данных RIPE. Дело это хлопотное, непростое и разбираться придётся долго.
Вот краткая инструкция по объектам БД RIPE.

Предположим, что в нашем случае компания ЛинкМиАп получила блок адресов 100.0.0.0/23 и AS 64500. Возвращаясь к нашей аналогии, мы дали городу имя и снабдили его диапазоном индексов.

Ещё одна статья на эту тему.
Краткий FAQ

BGP


Так вот для того, чтобы нам из своей AS передать информацию об этих публичных адресах в другую AS (читай в Интернет) и используется BGP. И если вы думаете, что яндекс или майкрософт использует какие-то небесные технологии для подключения своих ЦОДов к Интернету, то вы ошибаетесь – всё тот же BGP.

Теперь главный вопрос, который интересует всегда новичков: а зачем BGP, почему не взять пресловутый OSPF или вообще статику?

Наверное, большие дяди могут очень подробно и обстоятельно объяснить это, мы же постараемся дать поверхностное понимание.

– Если говорить о OSPF/IS-IS, то это Link-State алгоритмы, которые подразумевают (внимание!), что каждый маршрутизатор знает топологию всей сети. Представляем себе миллионы маршрутизаторов в Интернете и отказываемся от идеи использовать Link State для этих целей вообще.

Вообще OSPF при маршрутизации между area'ми является фактически distance vector протоколом. Гипотетически, можно было бы заменить «AS» на «Area» в плане глобальной маршрутизации, но OSPF просто не предназначен для переваривания таких объемов маршрутной информации, да и нельзя выделить в интернете Area 0.


RIP, EIGRP... Кхе-кхе. Ну, тут всё понятно.

– IGP – это нечто интимное и каждому встречному ISP показывать его не стоит. Даже без AS ситуация, когда клиент поднимает IGP с провайдером, крайне редкая (за исключением L3VPN). Дело в том, что IGP не имеют достаточно гибкой системы управления маршрутами – для LS-протоколов это вообще знать всё или ничего (опять же можно фильтровать на границе зоны, но гибкости никакой).
В итоге оказывается, что придётся открывать кому-то чужому потаённые части своей приватной сети или настраивать хитрые политики импорта между различными IGP-процессами.
– В данный момент в интернете более 450 000 маршрутов. Если бы даже OSPF/ISIS могли хранить всю топологию Интернета, представьте сколько времени заняла бы работа алгоритма SPF.
Вот наглядный пример, чем может быть опасно использование IGP там, где напрашивается нечто глобальное.

Поэтому нужен свой специальный протокол для взаимодействия между AS.
Во-первых, он должен быть дистанционно-векторным – это однозначно. Маршрутизатор не должен делать расчёт маршрута до каждой сети в Интернете, он лишь должен выбрать один из нескольких предложенных.
Во-вторых, он должен иметь очень гибкую систему фильтрации маршрутов. Мы должны легко определять, что светить соседям, а что не нужно выносить из избы.
В-третьих, он должен быть легко масштабируемым, иметь защиту от образования петель и систему управления приоритетами маршрутов.
В-четвёртых, он должен обладать высокой стабильностью. Поскольку данные о маршрутах будут передаваться через среду, которая не всегда может обладать гарантированным качеством (за стык отвечают по крайней мере две организации), необходимо исключить возможные потери маршрутной информации.
Ну и логичное, в-пятых, он должен понимать, что такое AS, отличать свою AS от чужих.

Встречайте: BGP.

Вообще описание работы этого поистине грандиозного протокола мы разобьём на две части. И сегодня рассмотрим принципиальные моменты.

BGP делится на IBGP и EBGP.

IBGP необходим для передачи BGP-маршрутов внутри одной автономной системы. Да, BGP часто запускается и внутри AS, но об этом мы плотненько поговорим в другой раз.
EBGP – это обычный BGP между автономными системами. На нём и остановимся.



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


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



Устройства, между которыми устанавливается BGP-сессия называются BGP-пирами или BGP-соседями.

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

I) Изначальное состояние BGP-соседства – IDLE. Ничего не происходит.



BGP находится в соcтоянии IDLE, если нет маршрута к BGP-соседу.

II) Для обеспечения надёжности BGP использует TCP.
Это означает, что теоретически BGP-пиры могут быть подключены не напрямую, а, например, так.

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

BGP-маршрутизатор (их также называют BGP-спикерами/speaker или BGP-ораторами) слушает и посылает пакеты на 179-й TCP порт.
Когда слушает – это состояние CONNECT. В таком состоянии BGP находится очень недолго.

Когда отправил и ожидает ответа от соседа – это состояние ACTIVE.



R1 отправляет TCP SYN на порт 179 соседа, инициируя TCP-сессию.





R2 возвращает TCP ACK, мол, всё получил, согласен и свой TCP SYN.





R1 тоже отчитывается, что получил SYN от R2.



После этого TCP-сессия установлена.


В состоянии ACTIVE BGP может подвиснуть, если

  • нет IP-связности с R2

  • BGP не запущен на R2

  • порт 179 закрыт ACL


Вот пример неуспешного установления TCP-сессии. BGP будет в состоянии ACTIVE, иногда переключаясь на IDLE и снова обратно.
TCP SYN отправлен с R1 на R2.




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



Периодически R1 будет пытаться снова установить TCP-сессию.

В свою бытность зелёным юнцом, я, впервые настраивая BGP-пиринг с провайдером, потратил полдня на поиск проблемы. Я реально не знал, как настраивается BGP и искал ошибку в конфигурации, думал, что есть какие-то тонкости для моей ситуации, уже начал читать про community. Но наконец в голову пришла светлая мысль – проверить ACL на входе в сеть. Да, TCP-запросы провайдера попадали в deny и сессия не устанавливалась.
Будьте аккуратны. Рядовая практика для провайдера вешать на все свои внешние интерфейсы, торчащие в "мир" ACL.


III) После того, как TCP-сессия установлена, BGP-ораторы начинают обмен сообщениями OPEN.

OPEN – первый тип сообщений BGP. Они отсылаются только в самом начале BGP-сессии для согласования параметров.




В нём передаются версия протокола, номер AS, Hold Timer и Router ID. Чтобы BGP-сессия поднялась, должны соблюдаться следующие условия:

  • Версии протокола должна быть одинаковой. Маловероятно, что это будет иначе

  • Номера AS в сообщении OPEN должны совпадать с настройками на удалённой стороне

  • Router ID должны различаться


Также внизу вы можете увидеть поддерживает ли маршрутизатор дополнительные возможности протокола.

Получив OPEN от R1, R2 отправляет свой OPEN, а также KEEPALIVE, говорящий о том, что OPEN от R1 получен – это для сигнал для R1 переходить к следующему состоянию – Established.



Вот примеры неконсистентности параметров:

а) некорректная AS (На R2 настроена AS 300, тогда, как на R1 считается, что данный сосед находится в AS 200):

R2 отправляет обычный OPEN



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



При этом в консоли R1 появляются следующие сообщения:





б) одинаковый Router ID
R2 отправляет в OPEN Router ID, который совпадает с ID R1:



R1 возвращает NOTIFICATION, мол, опух?!



При этом в консоли будут следующего плана сообщения:





После таких ошибок BGP переходит сначала в IDLE, а потом в ACTIVE, пытаясь заново установить TCP-сессию и затем снова обменяться сообщениями OPEN, вдруг, что-то изменилось?
Когда сообщение Open отправлено – это состояние OPEN SENT.
Когда оно получено – это сотояние OPEN CONFIRM.


Если Hold Timer различается, то выбран будет наименьший. Поскольку Keepalive Timer не передаётся в сообщении OPEN, он будет рассчитан автоматически (Hold Timer/3). То есть Keepalive может различаться на соседях
Вот пример: на R2 настроены таймеры так: Keepalive 30, Hold 170.



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



Это означает, что R2 свои Keepalive’ы будет рассылать каждые 30 секунд, а R1 – 56. Но главное, что Hold Timer у них одинаковый, и никто из них раньше времени не разорвёт сессию.


Увидеть состояние OPENSENT или OPENCONFIRM практически невозможно – BGP на них не задерживается.

IV) После всех этих шагов они переходят в стабильное состояние ESTABLISHED.
Это означает, что запущена правильная версия BGP и все настройки консистентны.

Для каждого соседа можно посмотреть Uptime – как долго он находится в состоянии ESTABLISHED.



V) В первые мгновения после установки BGP-сессии в таблице BGP только информация о локальных маршрутах.



Можно переходить к обмену маршрутной информацией.
Для это используются сообщения UPDATE

Каждое сообщение UPDATE может нести информацию об одном новом маршруте или о удалении группы старых. Причём одновременно.




Разберём их поподробнее.
R1 передаёт маршрутную информацию на R2.
Первый плюсик в сообщении UPDATE – это атрибуты пути. Мы их подробно рассмотрим позже, но вам уже должны быть поняты два из них. AS_PATH означает, что маршрут пришёл из AS с номером 100.
NEXT_HOP – что логично, информация для R2, что указывать в качестве шлюза для данного маршрута. Теоретически здесь может быть не обязательно адрес R1.

Атрибут ORIGIN сообщает о происхождении маршрута:

  • IGP – задан вручную командой network или получен по BGP

  • EGP – этот код вы никогда не встретите, означает, что маршрут получен из устаревшего протокола, который так и назывался – “EGP”, и был полностью повсеместно заменен BGP

  • Incomplete – чаще всего означает, что маршрут получен через редистрибьюцию



Второй плюсик – это собственно информация о маршрутах – NLRI – Network Layer Reachability Information. Собственно, наша сеть 100.0.0.0/23 тут и указана.

Ну и UPDATE от R2 к R1.


Нижеидущие KEEPALIVIE – это своеобразные подтверждения, что информация получена.

Информация о сетях появилась теперь в таблице BGP:



И в таблице маршрутизации:




UPDATE передаются при каждом изменении в сети до тех пор пока длится BGP-сессия. Заметьте, никаких синхронизаций таблиц маршрутизации нет, в отличии от какого-нибудь OSPF. Это было бы технически глупо – полная таблица маршрутов BGP весит несколько десятков мегабайтов на каждом соседе.

VI) Теперь, когда всё хорошо, каждый BGP-маршрутизатор регулярно будет рассылать сообщения KEEPALIVE. Как и в любом другом протоколе это означает: "Я всё ещё жив". Это происходит с истечением таймера Keepalive – по умолчанию 60 секунд.

Если BGP-сессия устанавливается нормально, но потом рвётся и это повторяется с некой периодичностью – верный знак, что не проходят keepalive. Скорее всего, период цикла – 3 минуты (таймер HOLD по умолчанию). Искать проблему надо на L2. Например, это может быть плохое качество связи, перегрузки на интерфейсе или ошибки CRC.


Ещё один тип сообщений BGP – ROUTE REFRESH – позволяет запросить у своих соседей все маршруты заново без рестарта BGP процесса.

Подробнее обо всех типах сообщений BGP.

Полная FSM (конечный автомат) для BGP выглядит так:





Нашёл в сети подробное описание каждого шага.





Вопрос на засыпку: Предположим, что Uptime BGP-сессии 24 часа. Какие сообщения гарантировано не передавались между соседями последние 12 часов?



Теперь расширим наш кругозор до вот такой сети:
Картинки без подсетей


И посмотрим, что из себя представляет таблица маршрутов BGP на маршрутизаторе R1:



Как видите, маршрут представляет из себя вовсе не только NextHop или просто список устройств до нужной подсети. Это список AS. Иначе он называется AS-Path.
То есть, чтобы попасть в сеть 123.0.0.0/24 мы должны отправить пакет наружу, преодолеть AS 200 и AS 300.

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


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



И так далее. При передаче маршрута внешнему соседу номер AS всегда добавляется в начало списка AS-path. То есть фактически это стек.

AS-path нужен не просто для того, чтобы маршрутизатор R1 знал путь до конечной сети – ведь по сути Next Hop достаточно – каждый маршрутизатор решение по-прежнему принимает на основе таблицы маршрутизации. На самом деле тут преследуются две более важные цели:
1) Предотвращение петель маршрутизации. В AS-Path не должно быть повторяющихся номеров (кроме случая AS-Path Prepend)
2) Выбор наилучшего маршрута. Чем короче AS-Path, тем предпочтительнее маршрут, но об этом позже.

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


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


Внизу наш главный маршрутизатор msk-arbat-gw1. Для упрощения настройки и понимания, мы отрешимся от всех старых настроек и освободим интерфейсы.

Выше два наших старых провайдера – Балаган Телеком и Филькин Сертификат.

Разумеется, у каждого провайдера здесь своя AS. Мы добавили ещё одну тупиковую AS – до неё и будем проверять, пусть, это например, ЦОД в Интернете.

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

Мы поднимаем BGP-сессию с обоими провайдерами.
Нам важна следующая информация:
1) Номер нашей AS и блок IP-адресов. Их мы уже получили: AS64500 и блок: 100.0.0.0/23.
2) Номер AS "Балаган Телеком" и линковая подсеть с ним. AS64501 и линковая сеть: 101.0.0.0/30.
3) Номер AS "Филькин Сертификат" и линковая подсеть с ним. AS64502 и линковая сеть: 102.0.0.0/30.

При подключении по BGP в качестве линковых адресов используются обычно публичные с маской подсети /30 и выдаёт их нам вышестоящий провайдер.
Делается это по той простой причине, чтобы ваш трафик везде следовал по публичным адресам и в трассировке посередине не появлялись всякие 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. Именно тот номер, который выдал LIR. Это вам не OSPF – вольности недопустимы.

Теперь поднимаем пиринг.


R1(config-router)#neighbor 101.0.0.1 remote-as 64501


Командой neighbor мы указываем, с кем устанавливать сессию. Именно на адрес 101.0.0.1 маршрутизатор будет отсылать сначала TCP-SYN, а потом OPEN. Также мы обязаны указать номер удалённой Автономной Системы – 64501.

Конфигурация с обратной стороны симметрична:

R2(config)#router bgp 64501
R2(config-router)#neighbor 101.0.0.2 remote-as 64500


Уже по одному сообщению *Mar 1 00:11:12.203: %BGP-5-ADJCHANGE: neighbor 101.0.0.2 Up

можно судить, что BGP поднялся, но давайте проверим его состояние:



Вот они пробежали по всем состояниям и сейчас их статус Established.
Получал и отправлял наш маршрутизатор по одному OPEN и успел за это время отослать и принять уже 2 KEEPALIVE.

Командой sh ip bgp можно посмотреть какие сети известны BGP:



Пусто. Надо указать, что есть у нас вот эта сеточка 100.0.0.0/23 и передать её провайдерам?

Для этого существует три варианта:
– определить сети командой network
– импортировать из другого источника (direct, static, IGP)
– создать аггрегированный маршрут командой aggregate-address

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


R1(config)#router bgp 64500
R1(config-router)#network 100.0.0.0 mask 255.255.254.0


Смотрим появилась ли наша сеть в таблице:



Странно, но нет, ничего не появилось. На 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 по 2 маршрута к некоторым сетям, а в таблице маршрутизации только один. Маршрутизатор выбирает лучший из всех и только его переносит в таблицу маршрутизации. Об этом поговорим позже.
Это необходимый минимум, после которого уже будет маленькое счастье.

=====================
Задача №1

Схема:



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




Подробности задачи тут
=====================



Full View и Default Route


Говоря о BGP и подключении к провайдерам, нельзя не затронуть эту тему. Когда ЛинкМиАп, имея уже AS и PI-адреса, будет делать стык с Балаган-Телекомом, одним из первых вопросов от них будет: “Фул вью или Дефолт?”. Тут главное не растеряться и не сморозить чепуху.

То, что вы видели до сих пор – это так называемый Full View – маршрутизатор изучает абсолютно все маршруты Интернета, пусть даже в нашем случае это пять-шесть штук. В реальности их сейчас больше 400 000. Соответственно от одного провайдера вы получите 400k маршрутов, от второго столько же. Подчас бывает и третий резервный – плюс ещё 400k. Итого больше миллиона.
Ну не покупать же теперь маленькому недоинтерпрайзу циску старших серий только для этого?


* вывод таблицы маршрутизации с одного из публичных серверов (дуступен по telnet route-server.ip.att.net)

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

Позвольте привести небольшие аргументы в пользу того и другого.

  • Full View. Вы обладаетe полным чистейшим знанием о структуре Интернета. До любого адреса в Интернете вы можете просмотреть путь от себя:



    Вы знаете, какие к нему ведут AS. Через сайт RIPE можно посмотреть какие провайдеры обеспечивают транзит. Вы следите за всеми изменениями. Если вдруг у кого-то что-то упадёт через первый линк (даже не у вас или у провайдера, а где-то там, дальше), BGP это отследит и перестроит свою таблицу маршрутизации для передачи данных через второго провайдера.
    При этом вы очень гибко можете управлять маршрутами, вмешиваясь в стандартную процедуру выбора наилучшего пути.
    Например, весь трафик на яндекс вы будете пускать через Балаган Телеком, а на гугл через Филькин Сертификат. Это называется распределением нагрузки.
    Достигается это путём настройки, например, приоритетов маршрутов для определённых префиксов.

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

  • Default Route
    Ну, во-первых, это, конечно, сильно экономит ресурсы вашего оборудования.
    Во-вторых, проще в обслуживании, можно сказать. Не нужно по всей своей AS гонять сотни тысяч маршрутов.
    В-третьих, никакого представления о состоянии интернета и реальной доступности получателей нет – вы просто слепо доверяетесь дефолту, полученному от апстрима. То есть в случае проблемы выше, вы о ней не узнаете и часть сервисов может упасть. Но тут мы надеемся, что у вышестоящих провайдеров надёжность сети на порядки выше и нам не о чем беспокоиться.

    Балансировка и распределение входящего трафика при получении маршрута по умолчанию никак не затрагивается – проблемы те же. А вот с исходящим, конечно, всё, немного иначе, былой гибкости тут уже не будет.



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

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

При этом от всех провайдеров вы можете брать Default плюс определённые префиксы (например, именно этого провайдера). Таким образом до нужных ресурсов у вас будут специфические маршруты без Full View.

Вот пример настройки передачи Default Route нижестоящему маршрутизатору:

balagan-router(config-router)#neighbor 101.0.0.2 default-originate

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



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


Сейчас вы уже должны начинать догадываться, что Default Route – это не противопоставление Full View. Не обязательно здесь стоит "или то или другое" (надо бы ввести понятие хили или ксили, как английское XOR), вы вполне можете использовать Default Route в дополнение к Full View или Default Route и часть каких-то других маршрутов.



=====================
Задача №2

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


Подробности задачи тут
=====================


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



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


Одним из очень мощных инструментов работы с BGP – Looking Glass. Это сервера, расположенные в Интернете, которые позволяют взглянуть на сеть извне: проверить доступность, просмотреть через какие AS лежит путь в вашу автономную систему, запустить трассировку до своих внутренних адресов.





Это как если бы вы попросили кого-то: “слушай, а посмотри, как там мои анонсы видятся?”, только просить никого не нужно.

Не стоит недооценивать силу внешних инструментов. Однажды у меня была проблема с очень низкой скоростью отдачи вовне. Она едва переваливала за несколько мегабит. После довольно продолжительного траблшутинга, решил взглянуть в Looking Glass. Какого же было моё удивление, когда я обнаружил, что трафик идёт ко мне, через VPN канал до филиала в другом городе, с которым установлен IBGP. Естественно, ширина канала была небольшой и утилизировалась практически полностью.


Существуют также специальные организации, которые отслеживают анонсы BGP в Интернете и, если вдруг происходит что-то неожиданное, может уведомить владельца сети – BGPMon, Renesys, RouterViews.
Благодаря им было предотвращено несколько глобальных аварий.

С помощью сервиса 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) – собственно передача полезных данных клиентов.

Часто случается так, что данные двух уровней ходят в разных направлениях, “навстречу друг другу”. Так в BGP маршруты передаются из AS100 в AS200 для того, чтобы AS200 могла передать данные в AS100.



Более того, на разных уровнях могут быть разные парадигмы работы. Например, в MPLS Data Plane ориентирован на создание соединения, то есть данные там передаются по заранее определённому пути – LSP.
А вот сам этот путь подготавливается по стандартным законам IP – от хоста к хосту.

Важно понять назначение уровней и в чём разница.

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