Чи може хтось пояснити, навіщо нам потрібен iBGP для маршрутів, коли у нас є протоколи IGP (OSPF, RIP) для внутрішнього спілкування в межах AS?
Я прочитав багато статей і книг, але не зміг знайти відповіді.
Чи може хтось пояснити, навіщо нам потрібен iBGP для маршрутів, коли у нас є протоколи IGP (OSPF, RIP) для внутрішнього спілкування в межах AS?
Я прочитав багато статей і книг, але не зміг знайти відповіді.
Відповіді:
Чи може хто-небудь пояснити мені, у чому полягає потреба в спілкуванні IBGP для маршрутів, коли у нас є протоколи IGP (OSPF, RIP) для внутрішнього спілкування?
Забезпечення меж довіри / контролю: BGP має більше способів фільтрації однолітків, ніж IGP (для контролю того, що ви рекламуєте та отримуєте).
Гнучкі структури даних (кілька пов'язаних з попередньою кулею): BGP співтовариство , BGP Extended співтовариство , місцеві прив , і т.д ... вони роблять BGP привабливим способу для реалізації користувальницьких маршрутизації політики у своїй власній автономній системі (за допомогою IBGP).
Як і у всьому, що є розпродажі; масштабованість, контроль та гнучкість, які ви отримуєте від iBGP, означає, що це протокол, який повільніше конвергується, ніж ІГП (загалом).
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-маршрутизатори знали маршрути, отримані іншими, щоб вони могли поширювати цю інформацію для однолітків, якщо це необхідно / потрібно (відкриваючи таким чином можливість вашого однолітка за допомогою транзиту через ти)