просто о BGP

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

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

В настоящее время для построения глобальной маршрутизации используется протокол BGP (Border Gateway Protocol) версии 4. Как видно из названия, это протокол пограничной маршрутизации, который отвечает за маршрутизацию трафика за границу нашей сети. Для того, чтобы о нашем адресном пространстве узнали вне нашей сети, нужно договориться с каждым из аплинков о построении пограничной маршрутизации – так называемой BGP-сессии. Для этого нужно передать техникам аплинка адрес нашего пограничного маршрутизатора, номер нашей автономной системы и список сетей, которые мы будем анонсировать аплинку. У него же нужно взять адрес его пограничного маршрутизатора, а так же номер его автономной системы. Для простой и корректной работы считается общепринятым, когда оба пограничных маршрутизатора находятся в одной подсети /30. Это нестрогое правило, но его несоблюдение приводит к резкому увеличению сложности настройки и большому числу неочевидных глюков.

Итак, сессия поднята и мы начинаем анонсировать нашу сеть аплинку. Что это значит? Это значит, что мы машем флагом: мы здесь! Кому нужно передать пакет для нашего адреса – шлите его сюда! Аплинк в свою очередь анонсирует нашу сеть своим пограничным соседям, они – своим, и так далее, на весь Интернет. В каждом пограничном маршрутизаторе сети Интернет с полной таблицей маршрутизации появляется запись о нашей сети и о пути к ней. И если кому надо передать нам пакет данных – путь уже известен! И таким образом несложно догадаться, что анонсы идут в
противоположную трафику сторону (мы аплинку – анонсы себя, аплинк нам – трафик для нас).

Теперь усложним ситуацию. Аплинк у нас не один, а несколько. И в каждый мы анонсим себя. Откуда в этом случае будет приходить трафик? Протокол BGP в этом случае определяет понятие наилучшего пути (best path) и резервных путей на случай отказа этого самого лучшего. Естественно, трафик будет приходить из того аплинка, который будет в наилучшем пути к нам для источника этого трафика. В идеале, если у нас, допустим, три аплинка и пользователи обращаются к разным ресурсам с равной вероятностью – то трафика со всех трех аплинков будет поровну. Но это – в идеале. Рассмотрим, что же есть этот самый наилучший путь с точки зрения протокола BGP.
Наилучшим считается тот путь, при котором пакет проходит по дороге наименьшее число автономных систем. Вот и все. Увы. Не учитываются ни задержки, ни потери пакетов, ни ширина каналов, ни число роутеров внутри каждой автономной системы. Поэтому путь трафика в протоколе BGP и называется AS-путь (AS-path). В нем перечислен список автономных систем по дороге до нашей сети.

Понятное дело, что на практике в большинстве случаев нас такое дело не устраивает. Для частичного исправления ситуации в BGP были придуманы методы, позволяющие использовать и административные критерии для управления трафиком. Эти критерии получили название local-pref и prepend. Если мы видим, что из одного канала идет 70% трафика, а из остальных – по 15%, то мы понимаем, что с этим надо чего-то делать. В первую очередь конечно это означает, что тот аплинк, от которого поступает больше трафика, лучше включен в сеть Интернет сам (то есть средний BGP AS-путь меньше). Если мы все же хотим, чтобы трафика с этого линка было меньше – мы вставляем один или два препенда в AS-путь. Это значит, мы искусственно удлиняем AS-путь на 1-2 AS, как будто бы нашу сеть анонсируем не мы, а кто-то на 1-2 автономных системы дальше. Тогда часть маршрутизаторов, ранее считавших путь через этот аплинк лучшим, выберут другие пути. Так можно балансировать загрузку своих входящих каналов. Теперь предположим, что у нас есть основной (как правило, самый дешевый) аплинк и запасной аплинк. Как сделать запасной аплинк резервным? А практически так же. Добавляем в анонсы в резервный аплинк 3-5 препендов, и делаем искусственно путь через этот аплинк совсем уж длинным по сравнению с основным. Тогда если вдруг связность с основным аплинком исчезнет, то BGP-сессия с ним порвется, основной аплинк перестанет от нас получать анонсы наших сетей, и соответственно перестанет их анонсировать дальше. Тогда основной путь исчезнет из таблиц маршрутизации пограничных рутеров сети Интернет, а останется только тот длинный путь через резервный линк. Он и будет выбран в качестве лучшего: других-то вариантов нет! И все это произойдет автоматически, без вмешательства системного администратора, скриптов или чего-то еще!

Стоит отметить, что таким путем мы лишь снижаем вероятность того, что резервный путь будет выбран как лучший. Гарантировать это нельзя никаким числом препендов. А все потому, что кроме технических критериев выбора пути есть еще и административные. И как бы ни был длинен резервный путь, он тем не менее может быть выбран. Например, многие выбирают путь через точки обмена трафиком более предпочтительным, чем через аплинк, потому что он дешевле и быстрее. Аплинки выбирают всегда прямой путь к своим клиентам, даже при наличии других путей. В некоторых странах законодательно запрещено использовать путь через заграницу при наличии пути внутри страны. И так далее. Как правило, через резервный линк будет проходить 5-10% трафика от основного линка. Но все зависит от того, как эти линки включены в мировой Интернет. Кстати, на практике в бывшем СССР ответ на этот вопрос, увы, звучит так – одинаково плохо.

Другой возможностью управлять трафиком в случае, если вы – клиент крупного правильного провайдера – выставлять на своих аннонсах специальные флажки – community, которые говорят маршрутизатору провайдера, куда и как надо анонсировать ваши сети. Скажем, "в Телию – с тремя препендами, в М9 – нормально". Не существует стандартного набора флагов community, поэтому уточняйте их у админов вашего провайдера. Как правило, эти флаги описываются в описании автономной системы в базе данных RIPE в поле комментариев.

Все, о чем я говорил, касается входящего к вам трафика. Теперь поговорим об исходящем трафике. Для управления им и резервирования его нужно принять отдельные меры. Соответственно, нужно принять анонсы мировых сетей от наших провайдеров, и на базе этих анонсов и наших административных критериев построить свою таблицу маршрутизации. Прямой путь "в лоб" - это принять от всех аплинков по полной таблице маршрутизации (full view) – списку всех сетей, существующих в мировой сети Интернет. На момент написания статьи – это 230000 маршрутов, но это число очень быстро растет. Такой объем таблицы маршрутизации (а их нужно как минимум две) – это сотни мегабайт оперативной памяти в маршрутизаторе. Естественно, не каждый маршрутизатор может такое обработать. Что же делать? Если вас устроит, что один провайдер будет для вас строго основным по исходящему трафику, а другой – строго резервным – попросите их вместо всех тех сотен тысяч префиксов анонсировать всего один: 0.0.0.0/0, или дефолтный маршрут. Принимайте от одного провайдера (основного) его с большим приоритетом local-preference, а от другого – c меньшим. Вот вам и резерв. Если возникнут проблемы на основном провайдере – будет принят в качестве лучшего маршрута дефолтный маршрут от запасного провайдера. Такую конфигурацию по используемой памяти потянет даже Cisco 800-й серии. Можно еще даже принять маршруты локальных точек обмена трафиком (как правило, до тысячи маршрутов), "бесплатные" сети того или иного провайдера, сети его ресурсов и т.д.

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