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

Разумеется, процесс настройки 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**.


---

# 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/1.-praktika/3.-chto-mozno-ulutchit.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.