Практика Community
Last updated
Last updated
Мы же в качестве примера рассмотрим следующую ситуацию.
Основная схема статьи дополняется ещё одним маршрутизатором клиента и двумя линками.
R7 и R9 разнесены территориально — так называемое георезервирование. Главным является его правый сайт, левый — резервный. Внутри своей AS он без проблем настроил передачу исходящего трафика в нужном месте — через R3. А вот со входящим посложнее — MED не позволяет использовать религия, да и доверия ему нет.
Поэтому мы разработали схему взаимодействия, используя community. На самом деле она будет общая для всех. Например, ниже мы установим правило — если получили маршрут с коммьюнити 64500:150, увеличить Local Preference для него до 150. А потом такую политику применяем к нужным нам маршрутам.
На нашем оборудовании (на всём) мы определяем ip community-list:
Задаём правило обработки:
Это общий блок, который будет одинаков для всех устройств. После этого клиент может сказать, что хочет воспользоваться этой функцией и мы применяем карту на BGP-соседа: Применяем карту к BGP-соседу на R3:
Итак, если в анонсе от соседа 100.0.0.10 community совпадает со значением в условии, установить Local Preference для этих маршрутов в 150.
Часто такие политики (route-map) применяются по умолчанию на всех внешних соседей. Клиентам остаётся только настроить передачу нужной коммьюнити и даже не нужно просить о чём-то провайдера — всё сработает автоматически.
Это наша политика по использовании коммьюнити. О ней мы сообщаем клиенту, мол, хочешь Установить для своего маршрута Local Preference в 150 в нашей AS, используй community 64500:150 И вот он настраивает на R9:
В итоге R3 имеет маршрут с более высоким Local Preference:
Передаёт его рут-рефлектору (R1 и R2), который делает выбор и распространяет всем своим соседям:
И даже R4, которому рукой дотянуться до R7, будет отправлять трафик на R3:
Трафик идёт именно тем путём, который мы выбрали.
Пусть вас не пугает по 3 записи для каждого хопа — это говорит о балансировке трафика между равноценными линками R1<->R2<->R3 и R1<->R4<->R3. Просто один раз он идёт по одному пути, второй по другому. А вот вы лучше попробуйте ответить на вопрос, почему на первом хопе 1-я и 3-я попытки идут через R4, а вот на втором хопе на R3. Почему пакет “перепрыгивает”? Как так получается?
В приведённом примере видно, что коммьюнити позволяет работать не с отдельными анонсами и для каждого из них отдельно применять какие-то политики, а рассматривать их сразу как группу, что естественно, значительно упрощает обслуживание. Иными словами, коммьюнити — это группа анонсов с одинаковыми характеристиками.
При работе с 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:
Как видите, галочка стоит напротив более короткого пути через Филькин Сертификат, чего мы и добивались.
При необходимости то же самое он может настроить на R7. После clear ip bgp * soft в отправляемых анонсах мы можем увидеть community:
Кстати, не стоит забывать команду ip bgp-community new-format, а иначе вместо этого: вы увидите это: Отправляться будет то же самое, но в выводах show команд будет отображаться в удобном виде.
