Вход в личный кабинет Bgp case studies
Looking glass и другие инструменты
Одним из очень мощных инструментов работы с BGP – Looking Glass. Это сервера, расположенные в Интернете, которые позволяют взглянуть на сеть извне: проверить доступность, просмотреть через какие AS лежит путь в вашу автономную систему, запустить трассировку до своих внутренних адресов.
Это как если бы вы попросили кого-то: “слушай, а посмотри, как там мои анонсы видятся?”, только просить никого не нужно.
Не стоит недооценивать силу внешних инструментов. Однажды у меня была проблема с очень низкой скоростью отдачи вовне. Она едва переваливала за несколько мегабит. После довольно продолжительного траблшутинга, решил взглянуть в Looking Glass. Какого же было моё удивление, когда я обнаружил, что трафик идёт ко мне, через VPN канал до филиала в другом городе, с которым установлен IBGP. Естественно, ширина канала была небольшой и утилизировалась практически полностью.
Существуют также специальные организации, которые отслеживают анонсы BGP в Интернете и, если вдруг происходит что-то неожиданное, может уведомить владельца сети – BGPMon, Renesys, RouterViews.Благодаря им было предотвращено несколько глобальных аварий.
С помощью сервиса BGPlay можно визуализировать информацию о распространении маршрутов.
Автономная система с несвязанными частями
Считается, что все части автономной системы напрямую связаны между собой. Однако в ряде случаев приходится отступать от этого правила. При поэтапной миграции в другой датацентр это неизбежно. Точки присутствия в разных датацентрах с одним номером AS — нежелательная, но допустимая ситуация.
Казалось бы, достаточно разбить сеть на части — к примеру, 192.0.2.0/24 на 192.0.2.0/25 и 192.0.2.128/25, — настроить новый маршрутизатор на дополнительной точке присутствия и начать анонсировать оттуда 192.0.2.128/25. Но не все так просто: с параметрами по умолчанию все в интернете будут видеть обе части AS, но твои собственные маршрутизаторы потеряют связь друг с другом.
Почему это происходит? Предположим, ты используешь номер автономной системы 64500. Пусть между ее частями находится провайдер с номером 64501. Тогда AS path будет выглядеть так: 64500 64501 64500.
AS path в BGP — не только критерий выбора путей, но и механизм предотвращения петель. Если вспомнить про заложенное в протокол предположение, что все части AS связаны напрямую, наш путь выглядит именно как петля.
Реализации BGP считают закольцованным и отбрасывают любой маршрут, где один и тот же номер AS встречается в пути более одного раза. Но также они часто предоставляют возможность отказаться от заданного по умолчанию заведомо безопасного поведения. Этот случай — один из них.
router bgp 64496
neighbor 192.0.2.1 remote-as 64500
!
address-family ipv4 unicast
neighbor 192.0.2.1 allowas-in 2
exit-address-family
Конечно, с такими настройками твой маршрутизатор может начать пропускать и настоящие закольцованные маршруты. К счастью, на практике они в большом интернете не встречаются: транзитные провайдеры подобные опции не включают и правильно делают. Во внутренней же сети тебе ничто не мешает присвоить каждой независимой части отдельный номер AS из частного диапазона (64512–65534).
Автономномые системы – 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 должен быть связан какой-то блок адресов.
Установление bgp-сессии и процедура обмена маршрутами – сети для самых маленьких
В свою бытность зелёным юнцом, я, впервые настраивая BGP-пиринг с провайдером, потратил полдня на поиск проблемы. Я реально не знал, как настраивается BGP и искал ошибку в конфигурации, думал, что есть какие-то тонкости для моей ситуации, уже начал читать про community. Но наконец в голову пришла светлая мысль – проверить ACL на входе в сеть. Да, TCP-запросы провайдера попадали в deny и сессия не устанавливалась.
Будьте аккуратны. Рядовая практика для провайдера вешать на все свои внешние интерфейсы, торчащие в «мир» ACL.
§
§
§
§
Default Route
Ну, во-первых, это, конечно, сильно экономит ресурсы вашего оборудования.
Во-вторых, проще в обслуживании, можно сказать. Не нужно по всей своей AS гонять сотни тысяч маршрутов.
В-третьих, никакого представления о состоянии интернета и реальной доступности получателей нет – вы просто слепо доверяетесь дефолту, полученному от апстрима. То есть в случае проблемы выше, вы о ней не узнаете и часть сервисов может упасть. Но тут мы надеемся, что у вышестоящих провайдеров надёжность сети на порядки выше и нам не о чем беспокоиться.
Балансировка и распределение входящего трафика при получении маршрута по умолчанию никак не затрагивается – проблемы те же. А вот с исходящим, конечно, всё, немного иначе, былой гибкости тут уже не будет.
§
§
§
В своё время, читая MPLS Enabled Application, я сломал свой мозг на них. Просто никак не мог сообразить, о чём авторы ведут речь.
Итак, дабы не было конфузов у вас.
Это не уровни модели, не уровни среды или моменты передачи данных – это весьма абстрактное деление.
Управляющий уровень (Control Plane) – работа служебных протоколов, обеспечивающих условия для передачи данных.
Например, когда запускается BGP, он пробегает все свои состояния, обменивается маршрутной информацией итд.
Или в MPLS-сети LDP распределяет метки на префиксы.
Или STP, обмениваясь BPDU, строит L2-топологию.
§
§
§
§
§
list-name – название списка. Ваш КО. Обычно указывается, как name_in или name_out. Это подсказывает нам на входящие или исходящие маршруты будет действовать (но, конечно, на данном этапе никак не определяет).
seq – порядковый номер правила (как в ACL), чтобы проще было оперировать с ними.
deny/permit – определяем разрешать такой маршрут или нет
network/length – привычная для нас запись, вроде, 192.168.14.0/24.
А вот дальше, внимание, сложнее – возможны ещё два параметра: ge и le. Как и при настройке NAT (или в ЯП Фортран), это означает “greater or equal” и “less or equal”.
То есть вы можете задать не только один конкретный префикс, но и их диапазон.
§
§
§
А теперь самое вкусное: представим, что в нашей схеме основной путь R4-R2-R1 обслуживает один провайдер, а запасной R4-R3-R1 – другой. Иногда у первого провайдера бывают проблемы с нагрузкой, которые приводят к тому, что наш голосовой трафик начинает страдать. При этом, другой маршрут ненагружен и хорошо бы в этот момент перенести голос на него. Ок, пишем роут-мап, как мы делали выше, который выделяет голосовой трафик и направляем его через нормально работающего провайдера. А тут – оп, ситуация поменялась на противоположную – опять надо менять все обратно. Будни техподдержки: “И такая дребедень целый день: то тюлень позвонит, то олень”. А вот бы было круто, если можно было бы отслеживать нужные нам характеристики основного канала (например, задержку или джиттер), и в, зависимости от их значения, автоматически направлять голос или видео по основному или резервному каналу, да? Так вот, чудеса бывают. В нашем случае чудо называется IP SLA.
§
§
§
§
§
§
§
§
§
§
§
§
As path prepend и контроль над входящим трафиком
Механизмы контроля над исходящим трафиком в BGP многочисленны и разнообразны. Входящий трафик — совсем другая история. В публичном интернете у тебя нет никаких способов прямого контроля над ним. Автономные системы на то и автономные, что не могут диктовать друг другу политики маршрутизации.
У любой автономной системы, однако, есть контроль над длиной AS path в исходящих анонсах, и это можно использовать как косвенный механизм контроля.
Как мы уже видели, один и тот же номер AS не может появляться в пути дважды в разных местах (то есть когда между экземплярами одного номера есть третий), иначе такой путь считается закольцованным. Однако несколько экземпляров одного номера подряд петлей не считаются.
Искусственное удлинение пути называется AS path prepend и часто используется для влияния на выбор пути другими сетями. Если у тебя два провайдера и одному ты анонсируешь с путем 64500, а второму с 64500 64500, маршрут через первого будет выглядеть для других сетей более привлекательным. По крайней мере, в теории.