Perché usare iBGP all'interno di un sistema autonomo, se i protocolli IGP soddisfano la necessità di comunicazione interna

22

Qualcuno può spiegare perché abbiamo bisogno di iBGP per le rotte quando abbiamo i protocolli IGP (OSPF, RIP) per la comunicazione interna all'interno dell'AS?

Ho letto molti articoli e libri, ma non sono riuscito a trovare la risposta.

— user2720323
fonte

26

Qualcuno può spiegarmi qual è la necessità della comunicazione IBGP per le rotte, quando abbiamo i protocolli IGP (OSPF, RIP) per la comunicazione interna?

Scalabilità ¹ : Immagina di ricevere 500.000 rotte EBGP in più di una posizione ² e che devi influenzare il punto di uscita per rotta nel tuo AS. BGP può gestire molte più rotte rispetto ai protocolli IGP. Pertanto, è richiesto iBGP a meno che tu non sia disposto a ridistribuire tutti i percorsi che hai imparato tramite eBGP
Applica limiti di fiducia / controllo: BGP ha più modi di filtrare i peer che gli IGP (per controllare ciò che pubblicizzi e ricevi).
Strutture di dati flessibili (in qualche modo correlate al precedente punto elenco): comunità BGP , comunità BGP Extended , pref pref locale , ecc ... rendono BGP un modo attraente per implementare politiche di routing personalizzate all'interno del proprio sistema autonomo (utilizzando iBGP).

Come per tutto ci sono dei compromessi; la scalabilità, il controllo e la flessibilità che ottieni da iBGP significa che è un protocollo convergente più lento rispetto agli IGP (in generale).

Note finali:

¹ scalabilità :

Usi BGP perché non vuoi portare l'intera tabella di routing Internet nel tuo IGP (ad esempio nel mio caso, OSPF) ...
OSPF non è stato progettato per gestire molte migliaia di percorsi nelle tabelle BGP di Internet ... se si tenta di utilizzare OSPF a tale scopo, si romperà la rete. Utilizzando l'esempio di OSPF, i requisiti di elaborazione / allagamento LSA da 500.000 rotte utilizzano troppe risorse nei router. Nomina qualsiasi altro IGP (EIGRP, RIPv1 / 2, IS-IS, IGRP) e la stessa storia è vera.
Ci sono stati alcuni casi noti in cui un ISP di livello 1 ha ridistribuito accidentalmente la propria tabella BGP nella propria IGP (anche quando la tabella Internet era una piccola frazione delle sue dimensioni attuali) e ha causato gravi interruzioni. Le contromisure sono state ora implementate nei protocolli IGP ( come questo per OSPF in IOS ) per evitare che la ridistribuzione da BGP a OSPF causi un'interruzione grave.

² esempio di routing iBGP :

Per capire perché potresti voler usare iBGP, considera questa voce di routing al 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 -->

Ci sono 32 percorsi da considerare ... In questo caso, BGP ha scelto di passare a 4.0.0.0/9 tramite 4.69.184.193 (notare la bestvoce sotto il RIB). In questo caso, BGP ha scelto questo perché questa route ha l'elenco AS Path più breve. Tuttavia, non tutti i percorsi saranno preferiti tramite AS3356 (allegato a R1). Alcuni possono essere preferiti R3 (tramite AS7660). iBGP ti dà la possibilità di sapere (in R2) quale strada seguire per percorrere il percorso BGP più breve.

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 e R3 sono completamente mesh mesh iBGP. Quando iBGP pubblicizza un percorso, l'hop successivo rimane invariato . Ciò significa che devo portare la sottorete per 4.69.184.193 in 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>

Quindi quando un pacchetto per 4.2.2.2 arriva a R2, R2 lo invia Serial2 / 1 perché è lì che iBGP ci dice che è l'hop successivo.

— Mike Pennington
fonte

Non sono sicuro di aver compreso questa parte: "È richiesto iBGP a meno che tu non sia disposto a ridistribuire tutti i percorsi che hai imparato tramite eBGP". Se disponiamo di due router eBGP di frontiera, il router A non conoscerà i percorsi appresi dal router B o viceversa. Devono scambiare le informazioni in qualche modo e questo è normalmente fatto usando iBGP. Come useresti eBGP per questo? Non sono sicuro di come eBGP possa rendere A e B entrambi consapevoli dei percorsi appresi dall'altro router.

— user4205580

La dichiarazione ti riferisci si presuppone che alcuni non parlano eBGP. Supponendo che non puoi semplicemente vivere con percorsi predefiniti per i tuoi upstream di eBGP, a questo punto puoi: A) ridistribuire i prefissi eBGP nel tuo IGP (di solito una cattiva idea) o B) usare iBGP. La mia risposta passa la maggior parte del tempo a spiegare perché l'iBGP è utile.

— Mike Pennington,

10

IGP di solito è OSPF o ISIS che sono basati sullo stato dei collegamenti, questo ci dà tutte le informazioni della rete, tutti conoscono la rete dal punto di vista di tutti, il che consente opzioni di convergenza molto interessanti e opzioni di ingegneria del traffico.

BGP è essenzialmente un vettore di distanza, conosce una visione molto limitata della rete nel suo insieme. BGP gestisce molto bene il filtraggio e la modifica delle informazioni di routing.

Il protocollo dello stato di collegamento è piuttosto costoso rispetto al vettore di distanza, sarebbe piuttosto problematico ridimensionarlo alla dimensione INET DFZ.

Quindi la ragione per cui abbiamo entrambi, è perché all'interno di una rete specifica, abbiamo una complessità sufficientemente bassa da gestirla con il protocollo link-state, che ci consente di ottenere tutti i vantaggi di un alto grado di conoscenza della rete.
Ma poiché non si ridimensiona alle dimensioni di Internet, abbiamo bisogno di un'altra rete per connettere queste molte isole link-state.

All'interno della tua rete potresti portare tutti i prefissi (incluso il cliente) nel tuo IGP, ma avrà un impatto negativo sulle prestazioni dell'IGP, mentre tutti i vantaggi di convergenza e TE possono essere ottenuti semplicemente trasportando gli indirizzi di loopback dei router core. L'aggiunta di prefissi dei clienti a IGP danneggia solo le prestazioni della rete rendendo IGP inutilmente complesso.

— ytti
fonte

1

BGP è un protocollo Path Vector , che non è lo stesso di un Distance Vector Protocol

— Mike Pennington,

3

Il vettore di percorso è essenzialmente un caso specifico del vettore di distanza. È importante rendersi conto che sono molto simili in termini di complessità e costi mentre il collegamento-stato è completamente diverso. Dal libro BGP di Sam Halabi e Danny McPhersons, pagina 98 "Questa sezione non sarebbe completa senza menzionare che BGP rientra nella categoria dei vettori di distanza"

— ytti,

2

Il vettore di percorso è simile ma ha ancora un algoritmo diverso. Puoi leggere di più su questo nel libro di Danny McPherson e Russ White, Practical BGP , pubblicato nel 2004. collegamento mobile

— Mike Pennington,

2

Quale pagina afferma che BGP non è un vettore di distanza?

— ytti,

2

AS percorso è distanza-vettore. Sì, puoi manipolare le selezioni del percorso facoltativamente anche con altri parametri. Quindi Sam e Danny lo mettono come vettore di percorso oltre che come vettore di distanza, condivido completamente il loro punto di vista sull'argomento. Potrebbe essere un modo divertente di consumare pinta per discutere della questione, ma quasi costruttivo.

— ytti,

7

Uno dei motivi che ho visto abbastanza spesso è la chiarezza: tutti i percorsi sono trasportati all'interno di un protocollo di routing (BGP), IS-IS, OSPF o RIP viene utilizzato solo per adiacenza. Di conseguenza non è necessario ridistribuire le route da un protocollo di routing a un altro.

— Teun Vink
fonte

3

iBGP non è realmente utilizzato per il routing interno, è utilizzato da tutti i router eBGP per condividere i loro percorsi.

Esempio: se stai eseguendo il peering con altre 3 reti, vuoi che tutti i tuoi router eBGP conoscano le rotte ricevute dagli altri in modo che possano propagare tali informazioni ai peer se necessario / necessario (aprendo così la possibilità del tuo peer usando il transito attraverso tu)

— Remi Letourneau
fonte