Consideriamo la seguente figura:

In un largo AS è verosimile che ci siano più router BGP per connettersi agli altri AS. In queste condizioni è necessario disporre di un metodo per far comunicare fra loro questi router. Nell'esempio in figura, R3 impara le rotte di AS10, R4 dovrà annunciare ad AS30 anche queste rotte, ma come fa a conoscerle?

Una possibile soluzione è adoperare il protocollo IGP sottostante per comunicare anche le rotte apprese tramite BGP. Il problema è che tipicamente il numero di rotte è considerevole, quindi, il protocollo IGP verrebbe velocemente sovraccaricato, rendendo di fatto la soluzione non scalabile. In aggiunta, i protocolli IGP non prevedono meccanismi per trasportare le informazioni aggiuntive legate alle rotte BGP, come ad esempio gli ASPath.

Un tentativo di usare un protocollo IGP per far comunicare due router BGP di un AS sfociò in un noto malfunzionamento, noto come l'incidente dell'AS7007, che causò il blocco di Internet (in larga parte) per ore. Il problema fu che adoperando il protocollo di IGP per trasportare le rotte, l'AS7007 risultò agli altri router come destinazione della gran parte degli indirizzi IP imparati dalle rotte BGP, inoltre, non avendo l'informazione ASPath, il percorso attraverso l'AS7007 risultava il più breve poiché riportava solo quell'AS, questo causò un sovraccarico di traffico che bloccò la rete.

La soluzione alternativa è instaurare una connessione BGP anche fra i router interni allo stesso AS, si configurano così due diversi tipi di connessione BGP:

• iBGP: connessione BGP fra router appartenenti allo stesso AS;

• eBGP: connessione BGP fra router appartenenti ad AS diversi;

Le connessione iBGP devono essere mantenute da ogni router BGP di un AS, verso tutti gli altri router BGP di quell'AS (full iBGP mesh). Da notare che le connessioni iBGP non necessariamente seguono la topologia fisica della rete, poiché BGP viaggia su TCP.

Chiaramente ci sono delle differenze nella gestione delle due differenti connessioni BGP:

Innanzitutto, poiché il valore di local pref appartiene ad una impostazione locale, tale valore sarà incluso come informazione soltanto all'interno delle connessioni iBGP. Allo stesso modo, non ci sono solitamente filtri applicati alle sessioni iBGP, perché come detto i filtri si adoperano per applicare policy amministrative fra AS differenti.

La scelta della rotta migliore verso una destinazione è fatta dal router BGP che riceve l'annuncio di quella rotta. Effettuata la scelta, il router provvede ad informare solo della rotta selezionata gli altri router BGP del suo AS, tramite la connessione iBGP. Le rotte apprese da un router tramite la connessione iBGP non sono poi annunciate agli altri router dello stesso AS, poiché i router BGP di un ASsono fra loro connessi in full mesh, quindi già avranno ricevuto lo stesso annuncio.

In sintesi, mentre con eBGP si annunciano ai router di altri AS tutte le migliori rotte verso qualsiasi destinazione conosciuta, con iBGP si annunciano ai router del proprio AS solo le migliori rotte apprese tramite eBGP.

Quando si trasmette una rotta tramite iBGP i campi NextHop e ASPath non variano rispetto a quelli del messaggio eBGP ricevuto in origine, questo perché chiaramente non viene attraversato nessun ulteriore AS, inoltre, il campo NextHop contiene per definizione l'indirizzo IP del router BGP del prossimo AS da contattare per raggiungere la destinazione.

In Figure 25 è mostrato un esempio per chiarire quanto detto:

Facendo sempre riferimento al precedente esempio, scriviamo le tabelle di routing BGP ed IGP di R4:

• BGP routing table

  • 194.100.0.0/23 via R1

• IGP routing table

  • 194.100.0.0/30 via R3

Mettendo insieme queste informazioni, R4 costruisce la sua forwarding table:

• Farwarding table

  • 194.100.0.0/23 via R3

  • 194.100.0.0/30 via R3

Consideriamo adesso cosa succede nel momento in cui due router BGP interni ad un AS non sono fra loro fisicamente direttamente collegati, Abbiamo detto che la sessione iBGP viene stabilita senza problemi poiché viaggia su protocollo TCP, tuttavia, i router compresi fra i BGP router non è detto che sappiano instradare correttamente tutti i pacchetti IP che ricevono, poiché questi router non hanno le informazioni di BGP, ma solo quelle apprese tramite IGP (Figure 26).

E' dunque necessaria una strategia per consentire a questi router di instradare correttamente il traffico IP. Tre possibili soluzioni sono le seguenti:

1. Utilizzare un “tunnel” fra i router BGP per incapsulare i pacchetti destinati ad AS esterni. Generalmente questo approccio adopera due tecnologie per il tunneling:

• GRE tunnel: ha bisogno di una configurazione statica e necessita di grande attenzione nell'impostazione degli MTU;

• MPLS tunnel: i tunnel sono creati dinamicamente adoperando il sistema di labeling MPLS (che verrà trattato successivamente in questo testo);

2. Adoperare il protocollo di IGP per trasportare le informazioni EGP delle rotte verso i router interni dell'AS. Questa soluzione è applicabile se si evita che i router EGP annuncino come nuove rotte quelle esterne che il protocollo IGP sta redistribuendo all'interno dell'AS. Tuttavia, anche con questo accorgimento, il numero di rotte EGP velocemente sovraccarica il protocollo IGP.

3. E' possibile anche decidere di rendere tutti i router di backbone dell'AS dei router BGP. Tali router riceverebbero le rotte tramite iBGP, ma, poiché i router BGP non dichiarano mai rotte apprese tramite iBGP, non annuncerebbero mai rotte. Il problema principale di questo approccio è che comporta che tali router partecipino alla full mesh iBGP dell'AS, con conseguente aumento esponenziale del numero di connessioni iBGP