Фулвью ор нот фулвью: о пользе и вреде полной BGP-таблицы
На любом околосетевом форуме легко найти с десяток веток о выборе оборудования для BGP-пиринга с возможностью «держать две, три, пять, двадцать пять фулвью». Большинство таких веток выливается в холивары на тему Cisco vs. Juniper или еще чего похуже. Офлайновое же их развитие нередко напоминает мультфильм о шести шапках из одной овичины. В общем, бывает смешно.
И крайне редко обсуждается вопрос о необходимости этого самого фулвью.
Немножко «теории»
Не пугайтесь, я не стану рассказывать все с начала. Уверен, что большинству читателей хорошо известно содержимое моей теоретической вводной. Желающие могут смело ее пропустить. Однако же я регулярно сталкиваюсь с некоторой неуверенностью вполне компетентных в практических вопросах людей, когда речь заходит о нижеизлагаемом. Так что все-таки давайте немножко синхронизируем термины, прежде чем обсуждать матчасть.
Все, что впрямую не касается темы интернетной BGP-таблицы, в частности IGP, MPLS, VRF/VPN и т. п., оставим за скобками.
Роутинг и ричабилити
Фулвью — это практически справочник «Желтые страницы» для всего интернета. Только именно «Желтые страницы», а не ваша личная записная книжка. Принципиальная разница тут в том, что помимо разрешения букв в цифры — для чего в интернете служит не фулвью, а DNS — периодические справочники дают нам возможность знать о появлении и исчезновении объектов. Нужно же нам как-то узнавать, что тот или иной адрес вообще есть в интернете. Мало того, если вдруг он для нас доступен только через линк А, а через Б недоступен — мы ведь тоже хотим об этом знать. Это и есть сигнализация доступности (reachability). Не будем слишком глубоко в вдаваться в абстракции, отметим лишь важность осознавать, что ричабилити и роутинг суть разные вещи.
Роутинг (маршрутизация) — нахождение лучшего пути передачи трафика для заданного направления. Этот процесс мало похож на поиск в телефонном справочнике, а скорее имеет отношение к карте города: если один и тот же адрес x.x.x.x доступен нам и через линк А, и через линк Б, нужно принять решение, куда же посылать пакеты.
Предположим, что читатель знаком с протоколом IP и в курсе, что такое префикс, зачем ему длина, и с чем едят правило лонгест мач.
Итак, как видно из показанного выше знаменитого графика c bgp.potaroo.net, полная таблица интернет-маршрутизации (здесь и далее речь в основном об IPv4, хотя почти все кроме цифр справедливо также и для IPv6) нынче содержит почти 350 тысяч записей. Это число растет экспоненциально и довольно быстро. Каждая из записей представляет собой, собственно, маршрут: IP-префикс назначения (подсеть с маской), некстхоп (следующий узел aka «куда посылать») и разные там другие параметры, определяющие ценность этого маршрута. Когда есть два (полученных от разных маршрутизаторов-соседей) маршрута для одного префикса, в ход идут как раз эти атрибуты. Они определяют, какой некстхоп будет использован для передачи.
Здесь показаны три маршрута к префиксу 8.8.8.0/24, полученные от трех разных маршрутизаторов-соседей. По некоторой причине — кстати, в данном случае нетривиальной — первый из них был выбран наилучшим (в примере причина не показана). Пусть вас не смущает и то, что у всех трех маршрутов один и тот же некстхоп: данные сняты с весьма специфического маршрутизатора, не передающего транзитный трафик. И да, маршрутизатор-сосед и некстхоп — это не одно и то же.
Анонсируются маршруты между маршрутизаторами при помощи протокола BGP, который собой являет, ну, практически RSS-трансляцию (да простят меня теоретики за кощунственное сравнение). Собственно, термин Full View — популярен в основном у нас, иностранные коллеги чаще говорят Full BGP, Full Table или Full Feed.
То есть сам протокол ничего сложного из себя не представляет — просто способ автоматизированного обмена данными, обернутыми в лучших программистских традициях в нечто вроде контейнеров, которые стандарт протокола позволяет более-менее гибко расширять по мере необходимости. Механизмы поиска наилучшего пути (роутинга) и контроля связности (ричабилити) у него довольно просты, если не сказать примитивны. В частности BGP считает, что трафик передается не между маршрутизаторами, а между укрупненными сущностями: автономными системами (АС, произносится «а-эс») и почти ничего не знает об их внутренней структуре — путь через две транзитных АС, каждая из которых включает, скажем, десять внутренних хопов (маршрутизаторов), BGP сочтет более выгодным, чем путь через пять АС, каждая из которых внутри имеет два хопа. Кроме того, BGP практически ничего не знает о пропускной способности линков; в нашем приближении можно считать, что этот аспект вообще никак не учитывается при выборе маршрута.
По сравнению с другими протоколами он не слишком быстр в обнаружении изменений связности и, как мы только что убедились, далеко не всегда оптимально ищет лучшие пути. Однако это все — не только минус, но и плюс BGP, т. к. именно благодаря своей относительной прямолинейности и «укрупненности мазков» протокол хорошо приспособлен для передачи большого объема маршрутной информации.
Так вот таблица в 340 тысяч записей с кучей атрибутов — это довольно много. А таблиц таких нужно обычно не меньше двух («мэньше нэ былло смы-исла», но об этом потом). Одно лишь хранение всего этого добра требует многих сотен мегабайт памяти, а кроме передачи и держания в памяти, таблицы нужно «обсчитать», в результате чего получить набор наилучших (активных) маршрутов.
Например. Один маршрутизатор-сосед анонсировал нам, что он знает маршрут, скажем, к Гуглу, и другой сосед — тоже анонсировал. Теперь мы знаем, что Гугл доступен нам через каждого из соседей (ричабилити) и хотим принять решение, какой же из двух маршрутов использовать для передачи пакетов (роутинг). Для этого BGP сравнивает показания (разные атрибуты маршрутов: Local Preference, AS-PATH и другие) и принимает решение (по каким-то там, не имеющим сейчас значения критериям), что, допустим, через первого соседа лучше. И так для каждого префикса. Таким образом из нескольких таблиц (каждая из которых состоит из 340 тыс. записей), полученных от разных соседей, «компилируется» одна таблица на 340 тыс. активных маршрутов:
Или то же самое плюс IPv6 на Juniper:
Конструкция из нескольких еще необсчитанных BGP-фидов (если быть точнее, то не только их, но и данных других протоколов), называется RIB (routing information base). Хранится она как правило в самой обычной оперативной памяти и обрабатывается самым обычным процессором. Соответственно именно к этим двум элементам и предъявляются требования, когда речь идет о количестве полных BGP-таблиц, которые можно впихнуть в RIB. Общее количество записей тут определяется как сумма всех полученных от соседей маршрутов: две фулвью — почти 700 тыс. префиксов, три — за миллион и т. д.
Вывод первый. Грузить фулвью, если у вас только одна сессия с внешним миром — бессмыслица. Обладание этим массивом информации не даст ничего, кроме нагрузки на оборудование, т. к. трафик можно передать только одним способом: «Адам, это Ева, выбирай себе жену». Представьте, что Адам решил бы прежде проанализировать 340 тысяч параметров Евы — где бы мы теперь были? Из данного правила есть редкие исключения, однако если вы не знаете, какие именно, то они — точно не ваш случай.
Памяти под RIB с несколькими фулвью нужно не то чтобы прям очень много, но сотни мегабайт — единицы гигабайт (в зависимости от количества фулвью, реализации и массы других аспектов). Процессору подчас тоже приходится не очень сладко, особенно в реализациях, имеющих BGP-сканер. Например апдаун сессии, через которую передается полная таблица, на иных платформах может приводить к стопроцентной загрузке процессора где-нибудь на полчасика.
Однако же понятно, что гигабайты памяти и гигагерцы процессорной частоты давно перестали быть чем-то особенным. И даже в контексте сетевого оборудования, производители которого славятся умением продавать обычную, как в компьютере, DRAM по цене космических летательных аппаратов, делая вид, что 2 ГБ — вершина прогресса, приведенные цифры не так уж страшно выглядят. Участники упомянутых в начале топика форумных дискуссий довольно часто приходят именно к такому выводу. Мол, главное памяти побольше. Это утверждение, в общем, верно, но к сожалению на нем дело отнюдь не заканчивается.
Давайте посмотрим, что происходит с фулвью дальше. Но прежде еще одно маленькое, но очень важное замечание.
Маршрутная информация всегда передается навстречу трафику, который коммутируется на ее основе. То есть на базе фулвью передается исходящий из вашей АС трафик. Не смотря на всю очевидность этого тезиса, далеко не всегда практическое его значение осознается в полной мере.
Форвадинг
Дальше эта «скомпилированная» таблица активных маршрутов исп
ользуется для передачи трафика. Называется она FIB (forwarding information base), и количество записей в ней, грубо говоря, равно количеству записей в одной фулвью (340 тыс.). С ней все гораздо интереснее.
Лирическое отступление. Вообще говоря, Full View (в отличии от Full BGP Feed) — это как раз FIB. То есть в большинстве случаев правильнее было бы говорить не «мне нужен маршрутизатор, способный держать три фулвью», а «мне нужен маршрутизатор, способный держать три пира с фулвью».
И, кстати, подпись по оси ординат на великой и ужасной картинке, приведенной в начале поста, неправильная. Это не RIB, а FIB. Заголовок на внутренней странице об этом тоже какбе намекает.
Большинство современных маршрутизаторов, способных передавать трафик на скоростях от пары гигабит в секунду и выше, — «аппаратные». Аппаратность их в том, что FIB и ее атрибуты помещается не в обычную, а в специальную, грубо говоря, «быструю» коммутационную память (SRAM, TCAM, RLDRAM и пр.), к которой обращаются специальные же процессоры обработки пакетов. Эта память — едва ли не самый дорогой ресурс в маршрутизаторе. А возможная изощренность работы с ней — уж точно самый главный из факторов, влияющих на цену железа.
Есть также программные коробки (производительностью, грубо говоря, до гигабита-двух), у которых, соответственно, FIB, как и RIB, хранится в обычной оперативке. У них, вообще, частенько слишком много всего в ней хранится, но об этом как-нибудь в другой раз — главное, что она (оперативка) не резиновая. Мало того, программный поиск по массиву с нахождением наилучшего соответствия (longest match) — ну очевидно же, что тем медленнее, чем больше в массиве элементов, каким алгоритмом не ищи.
Протокол BGP. Маршрутизация по-взрослому.
Назначим и Loopback-интерфейсу какой-нибудь адрес, чтобы далее проверить связность:
Сначала поднимаем процесс BGP и назначаем AS Number, именно тот, что выдал нам LIR!
Далее настраиваем пиринг, задаем информацию о соседе:
В CLI появится сообщение:
Ура? Ура, но проверим состояние процесса.
Одно состояние сменяет другое и вот достигнут Established. Маршрутизатор за это время отправил одно OPEN-сообщение и аналогичное получил, а также получил и принял по два KEEPALIVE.
Проверим о каких сетях знает BGP.
sh ip bgp
Ни-че-го. Смотрим на R2.
И тут тоже самое.
А всё тут просто. До прописанной командой network сети должен быть точный маршрут, в противном случае она не окажется в таблице BGP. А муршрута нет:
А его и вписывать некуда, кроме разве что Loopback-интерфейса. Ну нет нигде этой сети. Исхитримся так:
Давайте резюмировать. Если у вас нет цели гонять через себя транзитный трафик (подключать через себя другие AS) и не требуется гибкое распределение исходящего трафика, то вам дорога к Default Route.
Но вот точно не имеет смысла принимать от одного провайдера анонсы Full View, а от другого Default Route, т.к. один линк всегда будет простаивать и не станет гонять через себя исходящий трафик, ведь выбираться будет более специфический маршрут, который точно найдется среди анонсированного вам Full View.
Но ничего не мешает брать от всех провов Default Route и в нагрузку определенные префиксы (конкретно этого провайдера, например). Тогда до нужных ресурсов у вас будут специфические маршруты, но при этом без Full View.
Взглянем на пример настройки Default Route для линка в нижестоящему маршрутизатору:
Тогда на нашем бордере таблица маршрутов будет такой:
Теперь кроме обычных входящих в Full View маршрутов будет присутствовать и маршрут по-умолчанию.
Принципы работы протокола BGP
Сегодня мы рассмотрим протокол BGP. Не будем долго говорить зачем он и почему он используется как единственный протокол. Довольно много информации есть на этот счет, например тут.
Итак, что такое BGP? BGP — это протокол динамической маршрутизации, являющийся единственным EGP( External Gateway Protocol) протоколом. Данный протокол используется для построения маршрутизации в интернете. Рассмотрим как строится соседство между двумя маршрутизаторами BGP.
Рассмотрим соседство между Router1 и Router3. Настроим их при помощи следующих команд:
Соседство внутри одной автономной системы — AS 10. После ввода данных на маршрутизаторе, например на Router1, данный маршрутизатор пытается настроить отношения соседства с маршрутизатором Router3. Начальное состояние, когда ничего не происходит называется Idle. Как только будет настроен bgp на Router1, он начнет слушать TCP порт 179 — перейдет в состояние Connect, а когда пытается открыть сессию с Router3, то перейдет в состояние Active.
После того, как сессия установится между Router1 и Router3, то происходит обмен Open сообщениями. Когда данное сообщение отправит Router1, то данное состояние будет называться Open Sent. А когда получит Open сообщение от Router3, то перейдет в состояние Open Confirm. Рассмотрим более подробно сообщение Open:
В данном сообщение передается информация о самом протоколе BGP, который использует маршрутизатор. Обмениваясь Open сообщениями, Router1 и Router3 сообщают друг другу информацию о своих настройках. Передаются следующие параметры:
Для установления соседства необходимо выполнения следующих условий:
Здесь указывают сети, о которых сообщает Router1 и Path attributes, которые являются аналогом метрик. О Path attributes мы поговорим более подробно. Также внутри TCP сессии передаются Keepalive сообщения. Они передаются, по умолчанию, каждые 60 секунд. Это Keepalive Timer. Если в течении Hold Timer-а не будет получено Keepalive сообщение, то это будет означать потерю связи с соседом. По умолчанию, он равен — 180 секундам.
Вроде бы разобрались как маршрутизаторы передают друг другу информацию, теперь попытаемся разобраться с логикой работы протокола BGP.
Чтобы анонсировать какой-нибудь маршрут в таблицу BGP, как и в протоколах IGP, используется команда network, но логика работы отличается. Если в IGP, после указание маршрута в команде network, IGP смотрит — какие интерфейсы принадлежат данной подсети и включает их в свою таблицу, то команда network в BGP смотрит в таблицу маршрутизации и ищет точное совпадение с маршрутом в команде network. При нахождении таких, данные маршруты попадут в таблицу BGP.
Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if the IP route exists, put the equivalent NLRI into the local BGP table.
Теперь поднимем BGP на всех оставшихся и посмотрим как происходит выбор маршрута внутри одной AS. После того, как BGP маршрутизатор получит маршруты от соседа, то начинается выбор оптимального маршрута. Здесь надо понять какого вида соседи могут быть — внутренние и внешние. Маршрутизатор по конфигурации понимает является ли сконфигурированный сосед внутренним или внешним. Если в команде:
в качестве параметра remote-as указан AS, который сконфигурирован на самом маршрутизаторе в команде router bgp 10. Маршруты, пришедшие из внутренней AS считаются внутренними, а маршруты из внешней соответственно внешними. И по отношению к каждому работает разная логика получения и отправки. Рассмотрим такую топологию:
На каждом маршрутизаторы настроен loopback интрефейс с ip: x.x.x.x 255.255.255.0 — где x номер маршрутизатора. На Router9 у нас есть loopback интерфейс с адресом — 9.9.9.9 255.255.255.0. Его мы будем анонсировать по BGP и посмотрим как он распространяется. Данный маршрут будет передан на Router8 и Router12. С Router8 данный маршрут попадет на Router6, но на Router5 в таблице маршрутизации его не будет. Также и на Router12 данный маршрут попадет в таблицу, но на Router11 его также не будет. Попытаемся разобраться с этим. Рассмотрим какие данные и параметры передается Router9 своим соседям, сообщая об этом маршруте. Пакет внизу будет отправлен с Router9 на Router8.
Информация о маршруте состоит из аттрибутов пути (Path attributes).
Атрибуты пути разделены на 4 категории:
Атрибут Origin — указывает на то, каким образом был получен маршрут в обновлении. Возможные значения атрибута:
Далее, Next-hop. Атрибут Next-hop
Теперь Router6 передал маршрут Router5 и первому правилу Next-hop не изменил. То есть, Router5 должен добавить 9.9.9.0 [20/0] via 192.168.68.8, но у него нет маршрута до 192.168.68.8 и поэтому данный маршрут добавлен не будет, хотя информация о данном маршруте будет храниться в таблице BGP:
Та же самая ситуация произойдет и между Router11-Router12. Чтоб избежать такой ситуации необходимо настроить, чтоб Router6 или Router12, передавая маршрут своим внутренним соседям, подставляли в качестве Next-hop свой ip адрес. Делается при помощи команды:
После данной команды, Router6 отправит Update сообщение, где для маршрутов в качества Next-hop будет указан ip интерфейса Gi0/0 Router6 — 192.168.56.6, после чего данный маршрут уже попадет в таблицу маршрутизации.
Пойдем дальше и посмотрим появиться ли этот маршрут на Router7 и Router10. В таблице маршрутизации его не окажется и мы могли бы подумать, что проблема как в первом с параметром Next-hop, но если мы посмотрим вывод команды show ip bgp, то увидим, что там маршрут не был получен даже с неправильным Next-hop, что означает, что маршрут даже не передавался. И это нас приведет к существованию еще одного правила:
Маршруты, полученные от внутренних соседей не передаются другим внутренним соседям.
Так как, Router5 получил маршрут от Router6, то другому своему внутреннему соседу он передаваться не будет. Для того, чтобы передача произошла необходимо настроить функцию Route Reflector, либо настроить полносвязные отношения соседства ( Full Mesh), то есть Router5-7 каждый будет соседом с каждым. Мы будем в данном случае использовать Route Reflector. На Router5 необходимо использовать данную команду:
Route-Reflector меняет поведение BGP при передаче маршрута внутреннему соседу. Если внутренний сосед указан как route-reflector-client, то данным клиентам будут анонсироваться внутренние маршруты.
Маршрут не появился на Router7? Не забываем также и про Next-hop. После данных манипуляций маршрут должен и на Router7, но этого не происходит. Это нас подводит к еще одному правилу:
Правило next-hop работает только для External маршрутов. Для внутренних маршрутов замена атрибута next-hop не происходит.
И мы получаем ситуацию, в которой необходимо создать среду при помощи статичной маршрутизации или протоколов IGP сообщить маршрутизаторам о всех маршрутах внутри AS. Пропишем статические маршруты на Router6 и Router7 и после этого получим нужный маршрут в таблице маршрутизаторе. В AS 678 же мы поступим немного иначе — пропишем статические маршруты для 192.168.112.0/24 на Router10 и 192.168.110.0/24 на Router12. Далее, установим отношения соседства между Router10 и Router12. Также настроим на Router12 отправку своего next-hop для Router10:
Итогом будет то, что Router10 будет получать маршрут 9.9.9.0/24, он будет получен и от Router7 и от Router12. Посмотрим какой выбор сделает Router10:
Как мы видим, два маршрута и стрелка ( > ) означает, что выбран маршрут через 192.168.112.12.
Посмотрим как происходит процесс выбора маршрута:
Теперь все маршруты от данного соседа будут иметь такой вес. Посмотрим как изменится выбор маршрута после данной манипуляции:
Но как видим один маршрут через Router6. А где же маршрут через Router7? Может и на Router7 его нет? Смотрим:
Странно, вроде все в порядке. Почему же он не передается на Router5? Все дело в том, что у BGP есть правило:
Маршрутизатор передает только те маршруты, которые использует сам.
Router7 используется маршрут через Router5, поэтому маршрут через Router10 передаваться не будет. Вернемся к Local Preference. Давайте зададим Local Preference на Router7 и посмотрим как отреагирует на это Router5:
Итак, мы создали route-map, в который попадаются все маршруты и сказали Router7, чтоб при получение он менял параметр Local Preference на 250, по умолчанию равен 100. Смотрим, что произошло на Router5:
Посмотрим, что произойдет, если допустим Router6 потеряет маршрут 9.9.9.0/24 через Router9. Отключим интерфейс Gi0/1 Router6, который сразу поймет, что BGP сессия с Router8 оборвана и сосед пропал, а значит и маршрут, полученные от него не действительны. Router6 сразу отправляет Update сообщения, где указывает сеть 9.9.9.0/24 в поле Withdrawn Routes. Как только Router5 получит подобное сообщение, отправит его к Router7. Но так как у Router7 есть маршрут через Router10, то в ответ сразу отправит Update c новым маршрутом. Если детектировать падения соседа по состоянию интерфейса не получается, то придеться ждать срабатывания Hold Timer-а.
Если помните, то мы говорили о том, что часто приходится использовать полносвязную топологию. С большим количеством маршрутизаторов в одной AS это может доставить большие проблемы, чтоб избежать этого необходимо использовать конфедерации. Одна AS разбивается на несколько sub-AS, что позволяет работать им без требования полносвязной топологии.
Здесь ссылка на данную лабу, а тут конфигурация для GNS3.
Пришлось бы настраивать Route-Reflector или полносвязые отношения соседства. Разбивая одну AS 2345 на 4 sub-AS ( 2,3,4,5) для каждого маршрутизатора, мы в итоге получаем другую логику работы. Все отлично описано здесь.
Автономномые системы – AS
BGP неразрывно связан с понятием Автономной Системы (AS – Autonomous System), которое уже не раз встречалось в нашем цикле.
Согласно определению вики, АС — это система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую политику маршрутизации с Интернетом.
Чтобы было немного понятнее, можно, например, представить, что город – это автономная система. И как два города связаны между собой магистралями, так и две АС связываются между собой BGP. При этом внутри каждого города есть своя дорожная система – IGP.
Вот как это выглядит с небольшого отдаления: 
В BGP AS – это не просто какая-то абстрактная вещь для удобства. Эта штука весьма формализована, есть специальные окошки в собесе, где можно в будние дни с 9 до 6 получить номер автономной системы. Выдачей этих номеров занимаются RIR (Regional Internet Registry) или 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
Так вот для того, чтобы нам из своей 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 может подвиснуть, если
Вот пример неуспешного установления 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-сессия поднялась, должны соблюдаться следующие условия:
Также внизу вы можете увидеть поддерживает ли маршрутизатор дополнительные возможности протокола.
Получив 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 отправляет эти параметры в сообщении 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 сообщает о происхождении маршрута:
Второй плюсик – это собственно информация о маршрутах – 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 не должно быть повторяющихся номеров
На самом деле ASN может повторяться в AS-Path в двух случаях
а) Когда вы используете AS-Path Prepend, о котором ниже.
б) Когда вы хотите соединить два куска одной AS, не имеющих прямой связи друг сдругом.
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.Х.Х.Х. Не то, чтобы это что-то запрещённое, но обычно-таки придерживаются этого правила.
Начнём с банального.
Настройка интерфейсов:
Теперь назначим какой-нибудь адрес на интерфейс Loopback, чтобы потом проверить связность:
Черёд BGP. Тут заострим внимание на каждой строчке.
Сначала мы запускаем BGP процесс и указываем номер AS. Именно тот номер, который выдал LIR. Это вам не OSPF – вольности недопустимы.
Теперь поднимаем пиринг.
Командой neighbor мы указываем, с кем устанавливать сессию. Именно на адрес 101.0.0.1 маршрутизатор будет отсылать сначала TCP-SYN, а потом OPEN. Также мы обязаны указать номер удалённой Автономной Системы – 64501.
Конфигурация с обратной стороны симметрична:
Уже по одному сообщению
можно судить, что BGP поднялся, но давайте проверим его состояние: 
Вот они пробежали по всем состояниям и сейчас их статус Established.
Получал и отправлял наш маршрутизатор по одному OPEN и успел за это время отослать и принять уже 2 KEEPALIVE.
Командой sh ip bgp можно посмотреть какие сети известны BGP: 
Пусто. Надо указать, что есть у нас вот эта сеточка 100.0.0.0/23 и передать её провайдерам?
Для этого существует три варианта:
– определить сети командой network
– импортировать из другого источника (direct, static, IGP)
– создать аггрегированный маршрут командой aggregate-address
Забегая вперёд, заметим, что network имеет больший приоритет, а с импортированием нужно быть аккуратнее, чтобы не хватануть лишку.
Смотрим появилась ли наша сеть в таблице: Странно, но нет, ничего не появилось. На R2 тоже. 
А дело тут в том, что в ту сеть, которую вы прописали командой network должен быть точный маршрут, иначе она не будет добавлена в таблицу BGP – это обязательное условие. Конечно, такого маршрута нет. Откуда ему взяться: 
Поскольку реально у нас некуда прописывать такой маршрут – кроме одного Loopback-интерфейса, нигде этой сети нет, мы можем поступить следующим образом:
Данный маршрут говорит о том, что все пакеты в эту подсеть будут отброшены. Но, не пугайтесь, нормальная работа не будет нарушена. Если у вас есть более точные маршруты (с маской больше /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, по названиям вполне понятно, чем они отличаются. В последнем случае от каждого провайдера приходит только один маршрут по умолчанию, вместо сотен тысяч специфических (хотя вообще-то может и вместе).
Позвольте привести небольшие аргументы в пользу того и другого.
В общем, очень грубый совет прозвучит так:
Если вы не собираетесь организовывать через себя транзит (подключать клиентов со своими АС) и нет нужды в тонком распределении исходящего трафика, то вам хватит Default Route.
Но уж точно нет смысла принимать от одного провайдера Full View, а от другого Default – в этом случае один линк будет всегда простаивать на исходящий трафик, потому что маршрутизатор будет выбирать более специфический путь.
При этом от всех провайдеров вы можете брать Default плюс определённые префиксы (например, именно этого провайдера). Таким образом до нужных ресурсов у вас будут специфические маршруты без Full View.
Вот пример настройки передачи Default Route нижестоящему маршрутизатору:
И вот как после этого выглядит таблица маршрутов на нашем бордере: 
То есть помимо обычных маршрутов (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 это принципиальный вопрос. Когда вы анонсируете свои маршруты, фактически вы создаёте путь для входящего трафика. То есть маршруты исходят от вас, а трафик к вам.
Выбор маршрута
Ситуация с маршрутами у нас такая.
Есть BGP-таблица, в которой хранятся абсолютно все маршруты, полученные от соседей.
То есть если есть у нас несколько маршрутов, до сети 100.0.0.0/23, то все они будут в BGP-таблице, независимо от “плохости” оных: 
А есть знакомая нам таблица маршрутизации, хранящая только лучшие из лучших. Точно также BGP анонсирует не все приходящие маршруты, а только лучшие. То есть от одного соседа вы никогда не получите два маршрута в одну сеть.
Итак, критерии выбора лучших:
Все технологии маршрутизации, которые мы применяли до этого момента в наших статьях, будь то статическая маршрутизация, динамическая маршрутизация (IGP или EGP), в своей работе принимали во внимание только один признак пакета: адрес назначения. Все они, упрощенно, действовали по одному принципу: смотрели, куда идет пакет, находили в таблице маршрутизации наиболее специфичный маршрут до пункта назначения (longest match), и переправляли пакет в тот интерфейс, который был записан в таблице напротив этого самого маршрута. В этом, в общем-то, и состоит суть маршрутизации. А что, если такой порядок вещей нас не устраивает? Что, если мы хотим маршрутизировать пакет, отталкиваясь от адреса источника? Или нам нужно мальчики HTTP направо, девочки SNMP налево?
В такой ситуации нам приходит на помощь маршрутизация на базе политик ака PBR (Policy based routing). Эта технология позволяет нам управлять трафиком, базируясь на следующих признаках пакета:
Плюсы использования PBR очевидны: невероятная гибкость маршрутизации. Но и минусы тоже присутствуют:
Политика, на основе которой осуществляется PBR, создается командой route map POLICY_NAME, и содержит два раздела:
Немного практики для закрепления
Имеем вот такую топологию: 
В данный момент трафик R1-R5 и обратно идет по маршруту R1-R2-R4-R5, для удобства, адреса присвоены так, чтобы последняя цифра адреса была номером маршрутизатора:
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 (с его адресом в источнике) шел по маршруту R5-R4-R3-R1. По схеме очевидно, что решение об этом должен принимать R4. На нем сначала создаем ACL, который отбирает нужные нам пакеты:
Затем создаем политику маршрутизации с именем “BACK”:
Внутри нее говорим, какой трафик нас интересует:
И что с ним делать:
После чего заходим на интерфейс, который смотрит в сторону R5 (PBR работает с входящим трафиком!) и применяем на нем полученную политику:
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, у нас заворачивается на R3 весь трафик с источником R5. А это значит, что если, например, R5 захочет попасть на R2, он, вместо короткого и очевидного маршрута R5-R4-R2, будет послан по маршруту R5-R4-R3-R1-R2. Поэтому, нужно очень аккуратно и вдумчиво составлять ACL для PBR, делая его максимально специфичным.
В этом примере мы в качестве действия, применяемого к трафику, выбрали переопределение некстхопа (узла сети, куда дальше отправится пакет). А что еще можно сделать с помощью PBR? Имеются в наличие команды:
С первыми двумя все относительно понятно – они переопределяют некстхоп и интерфейс, из которого пакет будет выходить (чаще всего 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
=====================Задача №8
Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).
Схема и конфигурация. Маршрутизаторы провайдеров также не используют BGP.
Задание: Настроить переключение между провайдерами.
Маршрут по умолчанию к Балаган Телеком должен использоваться до тех пор, пока приходят icmp-ответы на пинг google (103.0.0.10) ИЛИ yandex (103.0.0.20). Запросы должны отправляться через Балаган Телеком. Если ни один из указанных ресурсов не отвечает, маршрут по умолчанию должен переключиться на провайдера Филькин Сертификат. Для того чтобы переключение не происходило из-за временной потери отдельных icmp-ответов, необходимо установить задержку переключения, как минимум, 5 секунд.
Подробности задачи тут
=====================
IP SLA
А теперь самое вкусное: представим, что в нашей схеме основной путь R4-R2-R1 обслуживает один провайдер, а запасной R4-R3-R1 – другой. Иногда у первого провайдера бывают проблемы с нагрузкой, которые приводят к тому, что наш голосовой трафик начинает страдать. При этом, другой маршрут ненагружен и хорошо бы в этот момент перенести голос на него. Ок, пишем роут-мап, как мы делали выше, который выделяет голосовой трафик и направляем его через нормально работающего провайдера. А тут – оп, ситуация поменялась на противоположную – опять надо менять все обратно. Будни техподдержки: “И такая дребедень целый день: то тюлень позвонит, то олень”. А вот бы было круто, если можно было бы отслеживать нужные нам характеристики основного канала (например, задержку или джиттер), и в, зависимости от их значения, автоматически направлять голос или видео по основному или резервному каналу, да? Так вот, чудеса бывают. В нашем случае чудо называется IP SLA.
Эта технология, по сути, есть активный мониторинг сети, т.е. генерирование некоего трафика с целью оценить ту или иную характеристику сети. Но мониторингом все не заканчивается – роутер может, используя полученные данные, влиять на принятие решений по маршрутизации, таким образом реагируя и разрешая проблему. К примеру, разгружать занятой канал, распределяя нагрузку по другим.
Без лишних слов, сразу к настройке. Для начала, нам нужно сказать, что мы хотим мониторить. Создаем объект мониторинга, назначаем ему номер:
Так-с, что мы тут можем мониторить?
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
Нужно сказать, что синтаксис команд, относящихся к IP SLA, претерпел некоторые изменения: начиная с IOS 12.4(4)T он такой, как в статье, до этого некоторые команды писались по другому. Например, вместо ip sla 1 было rtr 1 или вместо ip sla responder – rtr responder
Как видите, список внушительный, поэтому останавливаться не будем, для интересующихся есть подробная статья на циско.ком.
=====================Задача №9
Схема и конфигурация. Маршрутизаторы провайдеров также не используют BGP.
Задание:
Настроить маршрутизацию таким образом, чтобы HTTP-трафик из локальной сети 10.0.1.0 шел через Балаган Телеком, а весь трафик из сети 10.0.2.0 через Филькин Сертификат. Если в адресе отправителя фигурирует любой другой адрес, трафик должен быть отброшен, а не маршрутизироваться по стандартной таблице маршрутизации (задание надо выполнить не используя фильтрацию с помощью ACL, примененных на интерфейсе).
Дополнительное условие: Правила PBR должны работать так только если соответствующий провайдер доступен (в данной задаче достаточно проверки доступности ближайшего устройства провайдера). Иначе должна использоваться стандартная таблица маршрутизации.
Подробности задачи тут
=====================
Обычно, работу IP SLA рассматривают на простейшем примере icmp-echo. То есть, в случае, если мы можем пинговать тот конец линии, трафик идет по ней, если не можем – по другой. Но мы пойдем путем чуть посложнее. Итак, нас интересуют характеристики канала, важные для голосового трафика, например, джиттер. Конкретнее, udp-jitter, поэтому пишем
В этой команде после указания вида проверки (udp-jitter) идет ip адрес, куда будут отсылаться пробы (т.е. меряем от нас до 192.168.200.1 – это лупбек на R1) и порт (от балды 55555). Затем можно настроить частоту проверок (по умолчанию 60 секунд):
и предельное значение, при превышении которого объект ip sla 1 рапортует о недоступности:
Некоторые виды измерений в IP SLA требуют наличия “на той стороне” так называемого “ответчика” (responder), некоторые (например, FTP, HTTP, DHCP, DNS) нет. Наш udp-jitter требует, поэтому, прежде чем запускать измерения, нужно подготовить R1:
Теперь нам нужно запустить сбор статистики. Командуем
Т.е. запускаем объект мониторинга 1 прямо сейчас и до конца дней.
Мы не можем менять параметры объекта, если запущен сбор статистики. Т.е. чтобы поменять, например, частоту проб, нам нужно сначала выключить сбор информации с него: 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 (неправильный, но понятный перевод “отслеживатель”). Именно к его состоянию привязываются впоследствии действия в роут-мапе. В track можно выставить задержку переключения между состояниями, что позволяет решить проблему, когда у нас по одной неудачной пробе меняется маршрутизация, а по следующей, уже удачной, меняется обратно. Указываем номер track и к какому номеру объекта ip sla мы его подключаем (rtr 1):
Это означает: если объект мониторинга упал и не поднялся в течение 15 секунд, переводим track в состояние down. Если объект был в состоянии down, но поднялся и находится в поднятом состоянии хотя бы 10 секунд, переводим track в состояние up.
Следующим действием нам нужно привязать track к нашей роут-мапе. Напомню, стандартный путь от R5 к R1 идет через R2, но у нас имеется роут-мапа 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, получим обратный нужному эффект: в случае падения трека (из-за превышения показателя джиттера в sla 1), мапа не будет отрабатываться (все будет идти согласно таблице маршрутизации), и наоборот, в случае нормальных значений, трек будет up, и трафик будет идти через R3.
Как это работает: роутер видит, что пакет подпадает под условия match, но потом не сразу делает set, как в предыдущем примере с PBR, а промежуточным действием проверяет сначала состояние трека 1, а затем, если он поднят (up), уже делается set, если нет – переходит к следующей строчке роут-мапы.
Для того, чтобы наша мапа заработала, как надо, нам нужно как-то инвертировать значение трека, т.е. когда джиттер большой, наш трек должен быть UP, и наоборот. В этом нам поможет такая штука, как track list. В IP SLA существует возможность объединять в треке список других треков (которые, по сути, выдают на выходе 1 или 0) и производить над ними логические операции OR или AND, а результатом этих операций будет состояние этого трека. Кроме этого, мы можем применить логическое отрицание к состоянию трека. Создаем трек-лист:
Единственным в этом “списке” будет логическое отрицание значения трека 1:
Теперь привязываем роут-мап к этому треку
Цифра 10 после адреса некстхопа – это его порядковый номер (sequence number). Мы можем, к примеру, использовать его так:
Тут такая логика: выбираем трафик, подпадающий под ACL 100, затем идет промежуточная проверка track 1, если он up, ставим пакету некстхоп 192.168.3.3, если down, переходим к следующему порядковому номеру (20 в данном случае), опять же промежуточно проверяем состояние трека (уже другого, 2), в зависимости от результата, ставим некстхоп 192.168.2.2 или отправляем с миром (маршрутизироваться на общих основаниях).
Давайте теперь немножко словами порассуждаем, что же мы такое накрутили: итак, измерения джиттера у нас идут от источника R4 к респондеру R1 по маршруту через R2. Максимальное допустимое значение джиттера на этом маршруте у нас – 10. В случае, если джиттер превышает это значение и держится на этом уровне 15 секунд, мы переключаем трафик, генерируемый R5, на маршрут через R3. Если джиттер падает ниже 10 и держится там минимум 10 секунд, пускаем трафик от R5 по стандартному маршруту. Попробуйте для закрепления материала найти, в каких командах задаются все эти значения.
Итак, мы достигли цели: теперь, в случае ухудшения качества основного канала (ну, по крайней мере, значений udp-джиттера), мы переходим на резервный. Но что, если и там тоже не очень? Может, попробуем с помощью IP SLA решить и эту проблему?
Попробуем выстроить логику того, что мы хотим сделать. Мы хотим перед переключением на резервный канал проверять, как у нас обстоит дело с джиттером на нем. Для этого нам нужно завести дополнительный объект мониторинга, который будет считать джиттер на пути R4-R3-R1, пусть это будет 2. Сделаем его аналогичным первому, с теми же значениями. Условием переключения на резервный канал тогда будет: объект 1 down И объект 2 up. Чтобы измерять джиттер не по основному каналу, придется пойти на хитрость: сделать loopback-интерфейсы на R1 и R4, прописать статические маршруты через R3 туда-обратно, и использовать эти адреса для объекта SLA 2.
Теперь меняем условие трека 2, к которому привязана роут-мапа:
Вуаля, теперь трафик R5->R1 переключается на запасной маршрут только в том случае, если джиттер основного канала больше 10 и, в это же время, джиттер запасного меньше 10. В случае, если высокий джиттер наблюдается на обоих каналах, трафик идет по основному и молча страдает.
Состояние трека можно привязать также к статическому маршруту: например, мы можем командой ip route 0.0.0.0 0.0.0.0 192.168.1.1 track 1 сделать шлюзом по умолчанию 192.168.1.1, который будет связан с треком 1 (который, в свою очередь, может проверять наличие этого самого 192.168.1.1 в сети или измерять какие-нибудь важные характеристики качества связи с ним). В случае, если связанный трек падает, маршрут убирается из таблицы маршрутизации.
Также будет полезным упомянуть, что информацию, получаемую через IP SLA, можно вытащить через SNMP, чтобы потом можно было ее хранить и анализировать где-нибудь в вашей системе мониторинга. Можно даже настроить SNMP-traps.
=====================Задача №10
Схема: как и для других задач по PBR. Конфигурация ниже.
Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).
На маршрутизаторе msk-arbat-gw1 настроена PBR: HTTP-трафик должен идти через провайдера Филькин Сертификат, а трафик из сети 10.0.2.0 должен идти через Балаган Телеком. Указанный трафик передается правильно, но не маршрутизируется остальной трафик из локальной сети, который должен передаваться через провайдера Балаган Телеком.
Задание:
Исправить настройки таким образом, чтобы они соответствовали условиям.
Подробности задачи и конфигурация тут
=====================
Полезные ссылки
IP SLA
Статью для вас подготовили eucariot и Gluck. За помощь спасибо JDima. Задачки нам написала несравненная Наташа Самойленко.
