Кто-нибудь может объяснить, почему нам нужен iBGP для маршрутов, когда у нас есть протоколы IGP (OSPF, RIP) для внутренней связи внутри AS?
Я прочитал много статей и книг, но не смог найти ответ.
Кто-нибудь может объяснить, почему нам нужен iBGP для маршрутов, когда у нас есть протоколы IGP (OSPF, RIP) для внутренней связи внутри AS?
Я прочитал много статей и книг, но не смог найти ответ.
Ответы:
Может кто-нибудь объяснить мне, что нужно для связи IBGP для маршрутов, когда у нас есть протоколы IGP (OSPF, RIP) для внутренней связи?
Укрепить границы доверия / контроля: BGP имеет больше способов фильтровать одноранговые узлы, чем IGP (для контроля того, что вы рекламируете и получаете).
Гибкие структуры данных (несколько связанных с предыдущей пулей): BGP сообщество , BGP Extended сообщество , местные прив , и т.д ... они делают BGP привлекательным способа для реализации пользовательских маршрутизации политики в своей собственной автономной системе (с помощью IBGP).
Как и во всем, есть компромиссы; Масштабируемость, контроль и гибкость, которые вы получаете от iBGP, означают, что это более медленный конвергентный протокол, чем IGP (в целом).
1 Масштабируемость :
2 Пример маршрутизации iBGP :
Чтобы понять, почему вам может понадобиться iBGP, рассмотрите эту запись о маршрутизации в 4.2.2.2 ...
R2>sh ip bgp 4.2.2.2
BGP routing table entry for 4.0.0.0/9, version 3146
Paths: (32 available, best #7, table Default-IP-Routing-Table)
... <!-- extra BGP RIB entries deleted -->
7660 2516 3356, (aggregated by 3356 4.69.130.4)
203.181.248.168 from 203.181.248.168 (203.181.248.168)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
Community: 2516:1030
3356, (aggregated by 3356 4.69.130.6)
4.69.184.193 from 4.69.184.193 (4.69.184.193)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2012
... <!-- extra BGP RIB entries deleted -->
Есть 32 пути для рассмотрения ... В этом случае BGP решил перейти к 4.0.0.0/9 через 4.69.184.193 (обратите внимание bestна запись под RIB). В этом случае BGP выбрал это, потому что у этого маршрута самый короткий список AS Path. Однако не все маршруты будут предпочтительными через AS3356 (подключен к R1). Некоторые могут быть предпочтительнее из R3 (через AS7660). iBGP дает вам возможность узнать (на R2), какой путь выбрать кратчайший путь BGP.
BGP route to 4.0.0.0/9 via
NH: 4.69.184.193 [Path: 3356]
-------->
eBGP w/ AS3356 }{ iBGP inside AS64000 }{ eBGP w/ AS7660
S1/0 S1/2 S2/1 S2/3 S3/2 S3/0
Peered w/ AS3356 +------+ +------+ +------+ Peered w/ AS7660
4.69.184.193 <------| R1 |---------| R2 |--------| R3 |-----> 203.181.248.168
+------+ +------+ +------+
| S2/0
|
^
^
| Ingress packet to 4.2.2.2
|
R1, R2 и R3 являются полностью iBGP-сетками. Когда iBGP объявляет маршрут, следующий переход остается неизменным . Это означает, что мне нужно нести подсеть для 4.69.184.193 в OSPF ...
R2>sh ip route 4.69.184.193
Routing entry for 4.69.184.192/30
Known via "ospf 100", distance 110, metric 65536, type intra area
Last update from 192.0.2.109 on GigabitEthernet3/1, 1w0d ago
Routing Descriptor Blocks:
* 192.0.2.109, from 192.0.2.3, 1w0d ago, via Serial2/1
Route metric is 65536, traffic share count is 1
R2>
Таким образом, когда пакет для 4.2.2.2 поступает в R2, R2 отправляет его в Serial2 / 1, потому что именно там iBGP сообщает нам о следующем переходе.
IGP обычно представляет собой OSPF или ISIS, которые основаны на состоянии канала, это дает нам всю информацию о сети, каждый знает сеть с любой точки зрения, что позволяет использовать очень интересные варианты конвергенции и инженерии трафика.
BGP по сути является вектором расстояний, он знает очень ограниченное представление о сети в целом. BGP отлично справляется с фильтрацией и изменением информации о маршрутизации.
Протокол состояния канала довольно дорог по сравнению с вектором расстояния, было бы весьма проблематично масштабировать его до размера INET DFZ.
Поэтому причина того, что у нас есть оба, заключается в том, что внутри одной конкретной сети у нас достаточно низкая сложность, чтобы справиться с ней с помощью протокола состояния канала, что позволяет нам получить все преимущества высокой степени знания сети.
Но так как он не масштабируется до размера Интернета, нам нужна какая-то другая сеть, чтобы соединить эти многочисленные островки состояния канала.
Внутри вашей собственной сети вы можете нести все префиксы (включая клиентов) в вашем IGP, но это отрицательно скажется на производительности IGP, в то время как все преимущества конвергенции и TE можно получить, просто передавая петлевые адреса основных маршрутизаторов. Добавление пользовательских префиксов в IGP только снижает производительность вашей сети, делая IGP излишне сложным.
Одна из причин, которую я видел довольно часто, это ясность: все маршруты передаются в рамках одного протокола маршрутизации (BGP), IS-IS, OSPF или RIP используются только для смежности. В результате нет необходимости перераспределять маршруты от одного протокола маршрутизации к другому.
iBGP на самом деле не используется для внутренней маршрутизации, он используется всеми вашими маршрутизаторами eBGP для обмена своими маршрутами.
Пример: если вы используете одноранговую сеть с 3 другими сетями, вы хотите, чтобы все ваши маршрутизаторы eBGP знали маршруты, полученные другими, чтобы они могли передавать эту информацию одноранговым узлам, если это необходимо / необходимо (открывая, таким образом, возможность вашего узла использовать транзит через ты)