/ 8.1.-ibgp / 1.-praktika / 1.-ibgp / 3.-chto-mozno-ulutchit.md
3.-chto-mozno-ulutchit.md
 1  # Что мы можем улучшить?
 2  
 3  Разумеется, процесс настройки BGP. Всё-таки это трудозатраты — сделать весьма похожие настройки на каждом узле. Для упрощения вводится понятие peer-group, которая исходя из названия позволяет объединять соседей в группы и одной командой задавать нужные параметры сразу всем.  
 4  Дабы не быть голословными, внедрим это на нашей сети:  
 5  
 6  **R1**  
 7  
 8  ```text
 9  router bgp 64500
10  network 100.0.0.0 mask 255.255.254.0
11  neighbor AS64500 peer-group
12  neighbor AS64500 remote-as 64500
13  neighbor AS64500 update-source Loopback0
14  neighbor AS64500 Next-Hop-self
15  neighbor 2.2.2.2 peer-group AS64500
16  neighbor 3.3.3.3 peer-group AS64500
17  neighbor 4.4.4.4 peer-group AS64500
18  ```
19  
20  Команда **neighbor AS64500 peer-group** создаёт группу соседей AS64500\.  
21  Команда **neighbor AS64500 remote-as 64500** сообщает, что все соседи находятся в AS 64500.  
22  Команда **neighbor AS64500 update-source Loopback0** указывает, что со всеми соседями соединение будет устанавливаться с адреса Loopback-интрефейса.  
23  Команда **neighbor AS64500 Next-Hop-self** заставляет маршрутизатор менять адрес Next-Hop на свой при передаче анонсов всем соседям.  
24  Дальше, собственно, мы добавляем соседей в эту группу.  
25  
26  Причём мы можем запросто копировать команды конфигурации группы соседей на другие маршрутизаторы, меняя только адреса соседей.  
27  
28  > Пара замечаний по Peer-group:  
29  > 1) Для всех участников группы политики должны быть идентичны.  
30  > 2) На самом деле cisco уже давно использует динамические Update-группы. Это позволяет сэкономить ресурсы процессора, так как обработка проводится не по разу на каждого члена группы, а один раз на всю группу. Фактические Peer-группы только облегчают конфигурацию, а оптимизация отдана на откуп Update-групп.
31  
32  > Наверняка, у молодых зелёных инженеров возник вопрос: почему нельзя информацию про публичные адреса передавать по IBGP? Он же, вроде бы, для этого и предназначен? И даже более общий вопрос, почему нельзя обойтись вообще одним BGP, без OSPF или IS-IS, например? (Нет, серьёзно, на форумах иногда вскипают холивары на тему BGP vs OSPF). Ну, по сути ведь тоже протокол маршрутизации — какая разница, передавать информацию между AS или между маршрутизаторами — есть же Internal BGP.  
33  > На это я хочу сказать, что достаточно вам будет поработать немного с BGP на реальной сети, чтобы понять всю безумность такой затеи.  
34  >   
35  > **Самое главное препятствие — Full Mesh**. Придётся устанавливать соседство со всеми всеми маршрутизаторами вручную. OMG, мне дороги моя жизнь и здоровье. (Да, даже не смотря на наличие Route Reflector’ов и скриптов — это лишние операции)  
36  > **Другая проблема — медленная реакция и Дистанционно-Векторный подход** к распространению маршрутной информации.  
37  > Да и тут можно резонно возразить, что, дескать, существует BFD. Однако он уменьшит время обнаружение проблемы, но сходимость/восстановление связности всё равно будет медленным.  
38  > **Третий тонкий момент — отсутствие возможности автоматического изучения соседей.** Что ведёт к ручной их конфигурации.  
39  > Из всего вышеуказанного вытекают проблемы масштабируемости и обслуживания.  
40  >   
41  > Просто попробуйте сами использовать BGP вместо IGP на сети из 10 маршрутизаторов, и всё станет ясно.  
42  >   
43  > То же самое касается и распространения белых адресов — IBGP с этим справится, но на каждом маршрутизаторе придётся вручную прописывать все подсети.  
44  > Ну например, наша сеть 100.0.0.0/23\. Допустим, к маршрутизатору R3 подключены 3 клиента по линковым адресам: 100.0.0.8/30, 100.0.0.12/30 и 100.0.0.16/0\.  
45  > Так вот эти 3 подсети вам нужно будет ввести в BGP тремя командами **network**, в то время как в IGP достаточно активировать протокол на интерфейсе.  
46  > Можно, конечно, прибегнуть к хитрой редистрибуции маршрутов из IGP, но это попахивает уже костылями и ещё менее прозрачной конфигурацией.  
47  >   
48  > К чему всё это мы ведём? eBGP — протокол маршрутизации, без дураков. В то же время iBGP — не совсем. Он больше похож на приложение верхнего уровня, организующее распространение маршрутной информации по всей сети. В неизменном виде, а не сообщая при каждой итерации соседу «вон туда через меня». У IGP такое поведение тоже иногда встречается, но там это исключение, а тут — норма.  
49  > Я хочу подчеркнуть ещё раз, IGP и IBGP работают в паре, в связке, каждый из них выполняет свою работу.  
50  > IGP обеспечивает внутреннюю IP-связность, быструю (читай мгновенную) реакцию на изменения в сети, оповещение всех узлов об этом как можно быстрее. Он же знает о публичных адресах **нашей** AS.  
51  > IBGP занимается обработкой Интернетных маршрутов в нашей AS и их транзитом от Uplink’a к клиентам и обратно. Обычно он ничего не знает о структуре внутренней сети.  
52  >   
53  > Если вам пришёл в голову вопрос «что лучше BGP или IS-IS?» — это хорошо, значит у вас пытливый ум, но вы должны отчётливо понимать, что верный ответ тут только один — это принципиально разные вещи, их нельзя сравнивать и выбирать мисс “технология маршрутизации 2013”. **IBGP работает поверх IGP**.