eBGP e iBGP: due facce della stessa sessione

BGP distingue due tipi di adiacenza in base all’AS dei peer coinvolti:

  • eBGP (external): sessione tra router in AS diversi. Per default i pacchetti BGP viaggiano con TTL = 1, quindi i peer devono essere direttamente connessi; per neighbor separati da più hop serve neighbor x.x.x.x ebgp-multihop.
  • iBGP (internal): sessione tra router nello stesso AS. I peer non devono essere adiacenti: la raggiungibilità dell’indirizzo di neighbor è garantita dall’IGP (OSPF, EIGRP) o da route statiche. Tipicamente si usano indirizzi di loopback con update-source Loopback0 per rendere la sessione indipendente dal singolo link fisico.

Entrambe le adiacenze passano per gli stati Idle → Connect → Active → OpenSent → OpenConfirm → Established. La prefix diventa utilizzabile solo dopo Established e solo se supera la validazione del next-hop.

L’algoritmo di best-path selection

Quando BGP riceve più percorsi verso lo stesso prefisso, ne installa uno solo nella tabella di routing seguendo un ordine rigido. I primi attributi valutati sono:

# Criterio Preferenza Note
1 Weight più alto Cisco proprietary, locale al router, default 0 (32768 se originato localmente)
2 Local Preference più alto default 100, propagato solo dentro l’AS
3 Locally originated percorso locale route da network/aggregate/redistribute
4 AS-Path più corto conteggio degli AS attraversati
5 Origin i < e < ? IGP migliore di EGP, migliore di Incomplete
6 MED più basso confrontato solo tra percorsi dallo stesso AS adiacente

Se il tie persiste si prosegue con: eBGP preferito su iBGP, minor metrica IGP verso il next-hop, percorso più vecchio, router-ID più basso e infine indirizzo di neighbor più basso.

Weight vs Local Preference è la coppia più insidiosa. Il weight governa la scelta di un singolo router e non viene mai annunciato ai neighbor: se voglio che tutto l’AS preferisca un’uscita, il weight non basta. La local preference è l’attributo giusto per influenzare l’uscita a livello di intero AS, perché viene propagata a tutti i peer iBGP.

Il problema del next-hop in iBGP

Quando un router riceve un prefisso via eBGP, il next-hop è l’indirizzo del router esterno sul link di peering. Propagando quella route ai peer iBGP, BGP per default non modifica il next-hop: rimane l’indirizzo esterno. Se quell’indirizzo non è nella tabella IGP interna, i router interni considerano la route inaccessibile e la marcano come inaccessible / not synchronized: la best path non viene installata.

Due soluzioni:

  1. neighbor x.x.x.x next-hop-self sul router di bordo: riscrive il next-hop con il proprio indirizzo (tipicamente la loopback annunciata dall’IGP). È l’approccio standard.
  2. Annunciare la subnet del link eBGP dentro l’IGP, così il next-hop originale diventa raggiungibile.
router bgp 65001
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 next-hop-self

Route reflector e la regola di non-ripubblicazione

Per prevenire loop, iBGP applica una split-horizon rule: un prefisso appreso via iBGP non viene riannunciato ad altri peer iBGP. Ne consegue l’obbligo di full-mesh tra tutti i router iBGP, con n(n-1)/2 sessioni — insostenibile su larga scala.

Il route reflector (RR) rimuove questo vincolo. Configurato con neighbor x.x.x.x route-reflector-client, riflette i prefissi secondo regole precise:

  • da un client → a tutti (client, non-client, eBGP);
  • da un non-client → solo ai client;
  • da un peer eBGP → a tutti.

La prevenzione dei loop passa a Originator-ID e Cluster-List al posto del full-mesh. L’alternativa architetturale sono le confederation, che spezzano l’AS in sub-AS. Il RR è la scelta prevalente per scalabilità e semplicità operativa.

Trappole tipiche d’esame

  • Scenario: una route iBGP appare ma non entra in RIB, marcata come “inaccessible”. → Risposta: il next-hop eBGP non è raggiungibile via IGP; applicare next-hop-self sul router di bordo (o annunciare il link nell’IGP).
  • Scenario: imposti weight alto su R1 ma gli altri router dell’AS scelgono un’uscita diversa. → Risposta: il weight è locale e non propagato; per influenzare l’intero AS usare Local Preference.
  • Scenario: due percorsi con AS-Path di uguale lunghezza, uno con weight 0 e local-pref 200, l’altro con weight 100 e local-pref 100. → Risposta: vince il weight (valutato per primo, prima della local preference).
  • Scenario: tutti i router iBGP hanno sessioni ma alcuni prefissi non si propagano oltre il primo hop interno. → Risposta: manca il full-mesh o un route reflector; iBGP non ripubblica prefissi iBGP-learned.
  • Scenario: il MED sembra ignorato pur essendo più basso su un percorso. → Risposta: il MED si confronta solo tra percorsi provenienti dallo stesso AS adiacente; se gli AS di origine differiscono non viene comparato (salvo bgp always-compare-med).