# Практика Community

Мы же в качестве примера рассмотрим следующую ситуацию.

Основная схема статьи дополняется ещё одним маршрутизатором клиента и двумя линками.

![](http://img-fotki.yandex.ru/get/9166/83739833.2f/0_c72dc_b5f04e3a_XXL.png)

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:\
![](http://img-fotki.yandex.ru/get/9747/83739833.36/0_d4c6c_f3bf3a6a_XXL.png)

В итоге R3 имеет маршрут с более высоким Local Preference:

![](http://img-fotki.yandex.ru/get/9062/83739833.2f/0_c72de_927369c1_XL.png)

Передаёт его рут-рефлектору (R1 и R2), который делает выбор и распространяет всем своим соседям:

![](http://img-fotki.yandex.ru/get/9171/83739833.2f/0_c72df_6de773eb_XL.png)

И даже R4, которому рукой дотянуться до R7, будет отправлять трафик на R3:

![](http://img-fotki.yandex.ru/get/9252/83739833.2f/0_c72e0_245dce0d_XL.png)

Трафик идёт именно тем путём, который мы выбрали.

![](http://img-fotki.yandex.ru/get/9161/83739833.2f/0_c72e1_25a155db_L.png)

> Пусть вас не пугает по 3 записи для каждого хопа — это говорит о балансировке трафика между равноценными линками *R1<->R2<->R3* и *R1<->R4<->R3*. Просто один раз он идёт по одному пути, второй по другому. А вот вы лучше попробуйте ответить на вопрос, почему на первом хопе 1-я и 3-я попытки идут через R4, а вот на втором хопе на R3. Почему пакет “перепрыгивает”? Как так получается?

Кстати, не стоит забывать команду **ip bgp-community new-format**, а иначе вместо этого:\
![](http://img-fotki.yandex.ru/get/9494/83739833.2f/0_c72e3_c257e926_M.png)\
вы увидите это:\
![](http://img-fotki.yandex.ru/get/6718/83739833.2f/0_c72e2_cf91a1ac_M.png)\
Отправляться будет то же самое, но в выводах show команд будет отображаться в удобном виде.

[Конфигурация устройств](https://docs.google.com/document/d/1WFjksUR5aD2KhuN_ypA1IOMFavRzOX6p5ledbhyAN8o/pub)

В приведённом примере видно, что коммьюнити позволяет работать не с отдельными анонсами и для каждого из них отдельно применять какие-то политики, а рассматривать их сразу как группу, что естественно, значительно упрощает обслуживание.\
Иными словами, коммьюнити — это группа анонсов с одинаковыми характеристиками.

При работе с 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.

![](http://img-fotki.yandex.ru/get/9348/83739833.2f/0_c72e4_cae17b05_L.png)

Вот как видит нас маршрутизатор из AS 64503:

![](http://img-fotki.yandex.ru/get/9359/83739833.2f/0_c72e5_a81ea8d5_XL.png)

Маршрут в Балаган-Телеком выбран предпочтительным

Какие мысли?\
Анонсировать определённые сети в Филькин Сертификат, а остальные оставить в Балаган Телеком? Негибко, немасштабируемо.\
Вешать препенды на маршруты, отдаваемые в Балаган Телеком? Тогда, скорее всего, куча другого трафика перетечёт на Филькин Сертификат.\
Попросить инженера Балаган-Телекома вручную удлинить наши маршруты при передаче их в AS64503. Уже ближе к истине, и это даже сработает, но, скорее всего, инженер провайдера пошлёт вас… на сайт с табличкой, где прописана их политика Community.

Собственно, всё, что нужно сделать нам — на маршрутизаторе R1 применить route-map по добавлению коммьюнити 64500:1031 к соседу R5(напоминаем, что 103Х — это для соседа из AS 64503). Дальше всё сделает автоматика.

Вот как R5 видит маршрут сам:

![](http://img-fotki.yandex.ru/get/5012/83739833.30/0_c72e6_656200ee_XL.png)

Всё без изменений.

Вот как его видит R8:

![](http://img-fotki.yandex.ru/get/9172/83739833.30/0_c72e7_762d55ee_XL.png)

Как видите, галочка стоит напротив более короткого пути через Филькин Сертификат, чего мы и добивались.

![](http://img-fotki.yandex.ru/get/9507/83739833.30/0_c72e8_9af66ca4_L.png)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://linkmeup.gitbook.io/sdsm/8.1.-ibgp/3.-atributy-bgp/4.-community/1.-praktika.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.