По мере роста числа клиентов, количества BGP сессий вы убедитесь, что управлять становится все сложнее. То один попросит анонсировать в тот канал, но не анонсировать в другой и тому подобное. Потихоньку замечаешь что управление такой системой занимает черезчур много времени. Решение простое, нужно использовать community. Внедрение bgp сommunity снимает сразу ряд проблем. Первое – это мы можем передовать принадлежность комьюнити между своими маршрутизаторам, тем самым избавившись от проверок на каждом хосте access листами и второе, более важное, наши клиенты теперь смогут сами устанавливать принадлежность своих анонсов к той или иной community, тем самым сами смогут управлять поведением проходящих через вашу автономную систему анонсов. Главное все правильно и красиво спроектировать. А теперь вернемся к вопросу как же все таки работать c community.
Read more »

Если с отдачей трафика все в принципе понятно, то контролировать ситуацию откуда пойдет входящий трафик намного сложнее. Для управления входящим трафиком мы должны влиять на принятие решения куда направлять трафик, по какому пути, маршрутизатора удаленной системы. Вообще то, актуальными параметрами влияющими на то куда пойдет трафик являются:
1. LocalPreferences – на удаленной автономной системы на этот параметр мы повлиять ну никак не сможем.
2. Длительность и стабильность bgp сессии отвечающей за маршрут
3. Размер сети. Чем меньше размер сети тем выше ее приоритет в таблице роутинга.
4. Количество автономных систем которые нужно пройти пакету для достижения автономной системы назначения. То есть длина AS-PATH.

Фактически повлиять мы можем только на поледние 2 пункта и если размер анонсируемой сети мы можем контролировать только в нескольких случаях, то длину AS-PATH нам контролировать проще. На этом методе мы и остановимся.
Read more »

В своем предыдущем примере мы рассматривали модель, когда по резервному каналу у нас приходит маршрут по умолчанию, схема эта вполне рабочая и жизнеспособная. Но есть одно но, я об этом уже писал, весь паразитный трафик к несуществующим адресам будет уходить на этот канал, то есть туда будет уходить паразитный, безсмысленный трафик. Вполне логично что это не совсем хорошо. То есть конечно можно работать и так, но все же. Если позволяет оборудование(маршрутизаторы), лучше всего принять два фуллвьюва и тут сбалансировать с помощью такой штуки как local-preference. Вот эту модель мы и рассмотрим. За основу берем прежнюю схему известную нам по статье BGP – route-map, as-path, prefix-list. Управляем анонсами. Мы оставляем по прежнему роутер C резервным, а роутер B приоритетным каналом, но через роутер С мы теперь примем полный список сети и сбалансируем отдачу в роутер B c помощью local-preference.
Read more »

Есть в портах FreeBSD полезная утилита bgpq, автор ее Александр Снарский и предназначена она для того, что бы облегчить жизнь системному администратору. Эта утилита незаменима, если вы управляете транзитной автономной системой у которой насчитывается больше десятка клиентов с которыми построены bgp сессии. Утилита эта автоматически строит префикс листы базируясь на номере автономной системы клиента. Такая автоматизация позволит вам забыть о том, что клиент может получить еще несколько префиксов(сетей) и забыть вам об этом сообщить, а потом включить на новые префиксы своих уже клиентов и удивляться что ничего не бегает.
Read more »

При построении взаимодействия с аплинками(провайдерами) и даунлинками (клиентами), есть несколько правил которые нужно соблюдать. Во первых нельзя принимать и отдавать анонсы «серых сетей» – тех сетей которые выделены для использования внутри локальных сетей, для этого на вход и исход следует применить такой префикс лист:

ip prefix-list GREY seq 10 deny 10.0.0.0/8
ip prefix-list GREY seq 20 deny 172.16.0.0/12
ip prefix-list GREY seq 30 deny 192.168.0.0/16

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

ip prefix-list LOW-NET-DENY seq 20 permit 0.0.0.0/0 le 24

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

С точки зрения BGP интернет представляет из себя совокупность автономных систем взаимодействующих между собой. При этом можно разделить два вида автономных систем, это транзитные, через которые проходит путь к другим автономным системам и тупиковые, которые только принимают маршруты, но не ретранслируют маршруты к другим автономным системам. Как мы уже говорили, все маршруты которые приходят от партнеров по BGP, будут, по умолчанию, переданы и другим партнерам. Но если у вас тупиковая автономная система, предоставляющая доступ к интернет своим клиентам в своем адресном пространстве, то анонсы пришедшие от внешних автономных систем передавать не нужно, для этого нужно используя директиву route-map установить фильтр на исходящие анонсы используя директиву as-path.
Read more »

BGP, как мы уже говорили в статье Протокол динамической маршрутизации BGP. Настройка bgp в Quagga предназначен для передачи информации о маршрутах от одной автономной системы к другой, и считается нормальным если маршруты приходят в виде списка всех известных в интернете сетей, так называемый full-view, но иногда надо анонсировать именно дефолт гейт.
Read more »

Очень важным достоинством quagga или zebra, когда zebra развивалась на некоммерческой основе, является то, что синтаксис у нее полностью совместим с синтаксисом CLI Cisco и когда наконец то заработала командная строка quagga, называемая vtysh, удобство настройки quagga стало максимальным. В этой статье я коснусь только самых основ настройки bgp сессий, а в следующих статьях, уже разберем вполне работоспособные примеры.
Read more »