> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/8.1.-ibgp/1.-praktika/3.-chto-mozno-ulutchit.md).

# Что мы можем улучшить?

Разумеется, процесс настройки BGP. Всё-таки это трудозатраты — сделать весьма похожие настройки на каждом узле. Для упрощения вводится понятие peer-group, которая исходя из названия позволяет объединять соседей в группы и одной командой задавать нужные параметры сразу всем.\
Дабы не быть голословными, внедрим это на нашей сети:

**R1**

```
router bgp 64500
network 100.0.0.0 mask 255.255.254.0
neighbor AS64500 peer-group
neighbor AS64500 remote-as 64500
neighbor AS64500 update-source Loopback0
neighbor AS64500 Next-Hop-self
neighbor 2.2.2.2 peer-group AS64500
neighbor 3.3.3.3 peer-group AS64500
neighbor 4.4.4.4 peer-group AS64500
```

Команда **neighbor AS64500 peer-group** создаёт группу соседей AS64500.\
Команда **neighbor AS64500 remote-as 64500** сообщает, что все соседи находятся в AS 64500.\
Команда **neighbor AS64500 update-source Loopback0** указывает, что со всеми соседями соединение будет устанавливаться с адреса Loopback-интрефейса.\
Команда **neighbor AS64500 Next-Hop-self** заставляет маршрутизатор менять адрес Next-Hop на свой при передаче анонсов всем соседям.\
Дальше, собственно, мы добавляем соседей в эту группу.

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

> Пара замечаний по Peer-group:
>
> 1. Для всех участников группы политики должны быть идентичны.
> 2. На самом деле cisco уже давно использует динамические Update-группы. Это позволяет сэкономить ресурсы процессора, так как обработка проводится не по разу на каждого члена группы, а один раз на всю группу. Фактические Peer-группы только облегчают конфигурацию, а оптимизация отдана на откуп Update-групп.

> Наверняка, у молодых зелёных инженеров возник вопрос: почему нельзя информацию про публичные адреса передавать по IBGP? Он же, вроде бы, для этого и предназначен? И даже более общий вопрос, почему нельзя обойтись вообще одним BGP, без OSPF или IS-IS, например? (Нет, серьёзно, на форумах иногда вскипают холивары на тему BGP vs OSPF). Ну, по сути ведь тоже протокол маршрутизации — какая разница, передавать информацию между AS или между маршрутизаторами — есть же Internal BGP.\
> На это я хочу сказать, что достаточно вам будет поработать немного с BGP на реальной сети, чтобы понять всю безумность такой затеи.
>
> **Самое главное препятствие — Full Mesh**. Придётся устанавливать соседство со всеми всеми маршрутизаторами вручную. OMG, мне дороги моя жизнь и здоровье. (Да, даже не смотря на наличие Route Reflector’ов и скриптов — это лишние операции)\
> **Другая проблема — медленная реакция и Дистанционно-Векторный подход** к распространению маршрутной информации.\
> Да и тут можно резонно возразить, что, дескать, существует BFD. Однако он уменьшит время обнаружение проблемы, но сходимость/восстановление связности всё равно будет медленным.\
> **Третий тонкий момент — отсутствие возможности автоматического изучения соседей.** Что ведёт к ручной их конфигурации.\
> Из всего вышеуказанного вытекают проблемы масштабируемости и обслуживания.
>
> Просто попробуйте сами использовать BGP вместо IGP на сети из 10 маршрутизаторов, и всё станет ясно.
>
> То же самое касается и распространения белых адресов — IBGP с этим справится, но на каждом маршрутизаторе придётся вручную прописывать все подсети.\
> Ну например, наша сеть 100.0.0.0/23. Допустим, к маршрутизатору R3 подключены 3 клиента по линковым адресам: 100.0.0.8/30, 100.0.0.12/30 и 100.0.0.16/0.\
> Так вот эти 3 подсети вам нужно будет ввести в BGP тремя командами **network**, в то время как в IGP достаточно активировать протокол на интерфейсе.\
> Можно, конечно, прибегнуть к хитрой редистрибуции маршрутов из IGP, но это попахивает уже костылями и ещё менее прозрачной конфигурацией.
>
> К чему всё это мы ведём? eBGP — протокол маршрутизации, без дураков. В то же время iBGP — не совсем. Он больше похож на приложение верхнего уровня, организующее распространение маршрутной информации по всей сети. В неизменном виде, а не сообщая при каждой итерации соседу «вон туда через меня». У IGP такое поведение тоже иногда встречается, но там это исключение, а тут — норма.\
> Я хочу подчеркнуть ещё раз, IGP и IBGP работают в паре, в связке, каждый из них выполняет свою работу.\
> IGP обеспечивает внутреннюю IP-связность, быструю (читай мгновенную) реакцию на изменения в сети, оповещение всех узлов об этом как можно быстрее. Он же знает о публичных адресах **нашей** AS.\
> IBGP занимается обработкой Интернетных маршрутов в нашей AS и их транзитом от Uplink’a к клиентам и обратно. Обычно он ничего не знает о структуре внутренней сети.
>
> Если вам пришёл в голову вопрос «что лучше BGP или IS-IS?» — это хорошо, значит у вас пытливый ум, но вы должны отчётливо понимать, что верный ответ тут только один — это принципиально разные вещи, их нельзя сравнивать и выбирать мисс “технология маршрутизации 2013”. **IBGP работает поверх IGP**.