Мы же в качестве примера рассмотрим следующую ситуацию.
Основная схема статьи дополняется ещё одним маршрутизатором клиента и двумя линками.
R7 и R9 разнесены территориально — так называемое георезервирование. Главным является его правый сайт, левый — резервный.
Внутри своей AS он без проблем настроил передачу исходящего трафика в нужном месте — через R3. А вот со входящим посложнее — MED не позволяет использовать религия, да и доверия ему нет.
Поэтому мы разработали схему взаимодействия, используя community. На самом деле она будет общая для всех. Например, ниже мы установим правило — если получили маршрут с коммьюнити 64500:150, увеличить Local Preference для него до 150. А потом такую политику применяем к нужным нам маршрутам.
На нашем оборудовании (на всём) мы определяем ip community-list:
ip community-list 1 permit 64500:150
Задаём правило обработки:
route-map LP150 permit 10
match community 1
set local-preference 150
Это общий блок, который будет одинаков для всех устройств. После этого клиент может сказать, что хочет воспользоваться этой функцией и мы применяем карту на BGP-соседа:
Применяем карту к BGP-соседу на R3:
router bgp 64500
neighbor 100.0.0.10 remote-as 64504
neighbor 100.0.0.10 route-map LP150 in
Итак, если в анонсе от соседа 100.0.0.10 community совпадает со значением в условии, установить Local Preference для этих маршрутов в 150.
Часто такие политики (route-map) применяются по умолчанию на всех внешних соседей. Клиентам остаётся только настроить передачу нужной коммьюнити и даже не нужно просить о чём-то провайдера — всё сработает автоматически.
Это наша политика по использовании коммьюнити. О ней мы сообщаем клиенту, мол, хочешь Установить для своего маршрута Local Preference в 150 в нашей AS, используй community 64500:150
И вот он настраивает на R9:
router bgp 64504
neighbor 100.0.0.9 remote-as 64500
neighbor 100.0.0.9 route-map LP out
neighbor 100.0.0.9 send-community
route-map LP permit 10
set community 64500:150
При необходимости то же самое он может настроить на R7.
После clear ip bgp * soft в отправляемых анонсах мы можем увидеть community:
В итоге R3 имеет маршрут с более высоким Local Preference:
Передаёт его рут-рефлектору (R1 и R2), который делает выбор и распространяет всем своим соседям:
И даже R4, которому рукой дотянуться до R7, будет отправлять трафик на R3:
Трафик идёт именно тем путём, который мы выбрали.
Пусть вас не пугает по 3 записи для каждого хопа — это говорит о балансировке трафика между равноценными линками R1<->R2<->R3 и R1<->R4<->R3. Просто один раз он идёт по одному пути, второй по другому. А вот вы лучше попробуйте ответить на вопрос, почему на первом хопе 1-я и 3-я попытки идут через R4, а вот на втором хопе на R3. Почему пакет “перепрыгивает”? Как так получается?
Кстати, не стоит забывать команду ip bgp-community new-format, а иначе вместо этого:
вы увидите это:
Отправляться будет то же самое, но в выводах show команд будет отображаться в удобном виде.
В приведённом примере видно, что коммьюнити позволяет работать не с отдельными анонсами и для каждого из них отдельно применять какие-то политики, а рассматривать их сразу как группу, что естественно, значительно упрощает обслуживание.
Иными словами, коммьюнити — это группа анонсов с одинаковыми характеристиками.
При работе с community важно понимать, что настройка необходима с двух сторон — чтобы желаемое заработало, у провайдера тоже должна быть выполнена соответствующая конфигурация.
Часто у провайдеров бывает уже выработанная политика использования коммьюнити, и они просто дают вам те номера, которые необходимо использовать. То есть после того, как вы добавите к анонсу номер коммьюнити, провайдеру не придётся ничего делать руками — всё произойдёт автоматически.
Например, у Балаган-Телекома может быть такая политика:
| **Значение ** | Действие |
|---|---|
| 64501:100Х | При анонсировании маршрута соседу A добавить Х препендов, где Х от 1 до 6 |
| 64501:101X | При анонсировании маршрута соседу B добавить Х препендов, где Х от 1 до 6 |
| 64501:102X | При анонсировании маршрута соседу C добавить Х препендов, где Х от 1 до 6 |
| 64501:103X | При анонсировании маршрута в AS64503 добавить Х препендов, где Х от 1 до 6 |
| 64501:20050 | Установить Local Preference для полученных маршрутов в 50 |
| 64501:20150 | Установить Local Preference для полученных маршрутов в 150 |
| 64501:666 | Установить Next-Hop для маршрут в Null — создать Black Hole |
| 64501:3333 | Выполнить скрипт по уничтожению конфигурации BGP на всех маршрутизаторах AS |
Исходя из этой таблички, которая опубликована на сайте Балаган-телекома, мы можем сами принять решение об управлении трафиком.
Как это реально может помочь нам?
У нас Dual-homing подключение к двум различным провайдерам — Балаган Телеком и Филькин Сертификат. У датацентра подключение также к обоим провайдерам. Он принадлежит какому-то контент-генератору, допустим это оператор потового видео.
По умолчанию, в нашу сеть всё ходит через Балаган-Телеком (AS64501). Канал там хоть и широкий, но его утилизация уже достаточно высока. Мы хотим продавать домашним клиентам услугу IPTV и прогнозируем значительный рост входящего трафика. Неплохо было бы его завернуть в Филькин Сертификат и не бояться о том, что основной канал забьётся. При этом, естественно, весь другой трафик переносить не нужно.
В таблице BGP проверяем, где находится сеть 103.0.0.0. Видим, что это AS64503, которая достижима через обоих провайдеров с равным числом AS в AS-Path.
Вот как видит нас маршрутизатор из AS 64503:
Маршрут в Балаган-Телеком выбран предпочтительным
Какие мысли?
Анонсировать определённые сети в Филькин Сертификат, а остальные оставить в Балаган Телеком? Негибко, немасштабируемо.
Вешать препенды на маршруты, отдаваемые в Балаган Телеком? Тогда, скорее всего, куча другого трафика перетечёт на Филькин Сертификат.
Попросить инженера Балаган-Телекома вручную удлинить наши маршруты при передаче их в AS64503. Уже ближе к истине, и это даже сработает, но, скорее всего, инженер провайдера пошлёт вас… на сайт с табличкой, где прописана их политика Community.
Собственно, всё, что нужно сделать нам — на маршрутизаторе R1 применить route-map по добавлению коммьюнити 64500:1031 к соседу R5(напоминаем, что 103Х — это для соседа из AS 64503). Дальше всё сделает автоматика.
Вот как R5 видит маршрут сам:
Всё без изменений.
Вот как его видит R8:
Как видите, галочка стоит напротив более короткого пути через Филькин Сертификат, чего мы и добивались.
