Il problema dello scaling: full-mesh iBGP

All’interno di un Autonomous System, BGP impone una regola fondamentale di prevenzione dei loop nota come iBGP split-horizon: un prefisso appreso da un peer iBGP non viene rilanciato ad altri peer iBGP. La conseguenza di design è drastica: ogni router iBGP deve avere una sessione diretta con tutti gli altri, ovvero un full-mesh logico.

Il numero di sessioni cresce con la formula n(n-1)/2. Con 10 router servono 45 sessioni; con 50 router salgono a 1.225. Questo genera un carico insostenibile su configurazione, memoria (ogni peer mantiene tabelle e keepalive) e operatività. ENSLD chiede di riconoscere quando il full-mesh non è più scalabile e quale delle due soluzioni adottare.

Route Reflector (RR)

Il Route Reflector rilassa la regola di split-horizon: un RR può riflettere prefissi appresi da un peer verso altri peer iBGP. Si distinguono:

  • RR client: peer configurati come clienti del reflector.
  • Non-client: peer iBGP ordinari (che restano in full-mesh tra loro e con i RR).

Le regole di riflessione sono:

Origine del prefisso Verso chi viene riflesso
Da un client A tutti (altri client, non-client, eBGP)
Da un non-client Solo ai client
Da un peer eBGP A tutti

Per prevenire loop, i RR usano due attributi non-transitivi: ORIGINATOR_ID (router-id di chi ha originato il prefisso nell’AS) e CLUSTER_LIST (elenco dei cluster attraversati). Un RR scarta un update se vi trova il proprio cluster-id. Per ridondanza si usano RR multipli nello stesso cluster o cluster distinti; è buona pratica avere almeno due RR per evitare single point of failure.

Confederation

La BGP confederation suddivide l’AS in sub-AS privati (64512-65534). Tra sub-AS si stabilisce una sessione intra-confederation eBGP, mentre all’interno di ogni sub-AS si torna al full-mesh iBGP (o a RR locali). Verso l’esterno la confederazione appare come un unico AS, perché i sub-AS sono racchiusi in AS_CONFED_SEQUENCE e rimossi in uscita.

Aspetto chiave: nelle sessioni intra-confederation eBGP, LOCAL_PREF, MED e NEXT_HOP vengono preservati (a differenza di una eBGP normale). RR e confederation risolvono lo stesso problema; nella pratica moderna il RR è nettamente più diffuso per semplicità operativa.

Design eBGP multi-provider

Verso più ISP il design tipico è dual-homed / multihoming. Il traffic engineering si realizza con gli attributi, ricordando la direzione che ciascuno controlla:

  • LOCAL_PREF (default 100, valore più alto vince): propagato in iBGP, governa l’uscita dell’AS. È lo strumento principe per scegliere l’ISP di uscita preferito.
  • AS-PATH prepend: allunga artificialmente il path per rendere meno attraente un ingresso; governa l’ingresso (influenza le decisioni degli AS remoti).
  • MED (più basso vince, default 0): suggerisce all’AS vicino quale ingresso preferire quando esistono più link verso lo stesso AS. È non-transitivo: non si propaga oltre l’AS che lo riceve.
  • Community (es. no-export, o community custom concordate con l’ISP): route tagging per attivare policy predefinite lato provider senza toccare i prefissi.

Trappole tipiche d’esame

  • Next-hop-self sul Route Reflector → Il RR riflette i prefissi senza modificare NEXT_HOP di default. Su prefissi eBGP riflessi ai client, se il next-hop (indirizzo del peer esterno) non è raggiungibile via IGP, le route restano inaccessible. La risposta corretta è configurare next-hop-self sul router che riceve l’eBGP (tipicamente il RR/border), non affidarsi al comportamento di default.

  • Full-mesh residuo con i RR → I non-client e i RR stessi devono rimanere in full-mesh tra loro. Uno scenario in cui alcuni prefissi non si propagano nasce spesso da un RR configurato ma con i restanti router lasciati come peer ordinari senza mesh completo.

  • Policy asimmetriche in/out → LOCAL_PREF alza la preferenza in uscita, ma NON influenza come il traffico entra. Se lo scenario chiede di attrarre/respingere traffico in ingresso, la risposta è AS-PATH prepend o MED, mai LOCAL_PREF.

  • MED che non funziona cross-AS → Il MED è confrontato solo tra path provenienti dallo stesso AS vicino (salvo always-compare-med) e non si propaga oltre un AS. Aspettarsi che il MED influenzi un ISP a due hop di distanza è la trappola.

  • Confederation e attributi → Nelle sessioni intra-confederation, LOCAL_PREF e MED si preservano; chi risponde “vengono azzerati come in eBGP normale” sbaglia.