bgp router-reflection terminologia e regole di riflessione path

09.01 2020 | by massimiliano

---

bgp router-reflection terminologia e regole di riflessione path   La funzione dei Router Reflector (RR) è quella di permettere meccanismi […]

https://www.ingegnerianetworking.com/wp-content/uploads/2020/01/bgp-rules-RR-1ce.png

bgp router-reflection terminologia e regole di riflessione path

 

La funzione dei Router Reflector (RR) è quella di permettere meccanismi di scalabilità in reti di grandi dimensioni (ad esempio quelle di un Services Provider) dove il numero di sessioni BGP tra PE può essere molto grande.

Di fatto i RR riflettono gli annunci ricevuti da un sorgente a tutti i PE della rete attraverso sessioni IBGP con essi, evitando però ai nodi PE di avere lo stesso numero di sessioni moltiplicato per il numero degli stessi, ma attivando le sole sessioni IBGP verso i router reflector.

Con questa riflessione i router RR violano la regola dello split-horizon che vieta la propagazione di annunci su sessioni IBGP ricevute sempre da nodi via IBGP (le regole di propagazione sono basate sulla provenienza dell’annuncio, sempre che siano best-path)

 

 

 

I router possono essere definiti come:

 

RR-Client: sono nodi client a cui un RR riflette gli annunci ricevuti via IBGP; un RR con questo tipo di router forma un cluster identificato da un cluster ID.

RR-NON-Client: sono normali peer dei RR ed affinchè tutti i peer ricevano gli annunci è necessario che questo tipo di router deve avere una maglia completa di sessioni IBGP

 

 

 

 

Le regole per un RR dicono:

 

un RR riflette solo il best path

in caso di add-path vedi: https://www.massimilianosbaraglia.it/routing/bgp/bgp-design-cisco/bgp-router-reflector-functions-with-orr-and-add-path

 

un RR riflette sempre gli annunci su EBGP peer

 

un RR propaga gli annunci ricevuti da sessioni EBGP su tutte le sessioni BGP

 

un RR-Client segue la regola dello split-horizon

 

Se un annuncio IBGP viene ricevuto da un NON-Client, questo viene propagato a tutti i RR-Client (dalla RFC 4456 che permette la propagazione a tutti i RR-Client che ha originato l’annuncio, ma quest’ultimo viene scartato dal RR-Client per via dell’attributo ORIGINATOR-ID; il vantaggio è quello di permettere ai RR di inviare una sola copia di UPDATE message e di risparmiare CPU)

 

Per evitare il formarsi di routing loop, un RR non modifica di default gli attributi NEXT-HOP, AS-PATH, LOCAL-PREFERENCE e MED.

NOTA: seppur questi attributi sono gestiti tutti di default, è possibile però seguire regole operative diverse tra diversi costruttori di router 

 

 

In caso di cluster RR con due o più router-reflector per motivi di HA e Fault-Tolerance per evitare routing loop o forwarding loop, la RFC 4456 introduce due attributi fondamentali:

 

• – ORIGINATOR-ID

   un RR non può creare un attributo Originator-ID se già presente nell’annuncio

   un peer bgp che riconosce l’attributo Originator-ID deve ignorare l’annuncio se il valore di Originator-ID coincide con il proprio RID

 

• – CLUSTER-LIST
•     consiste in un meccanismo di rilevazione loop solo dai RR
•     un RR che riceve un annuncio contenente il proprio Cluster-ID nell’attributo Cluster-List deve ignorare l’annuncio

 

 

Vedi anche:

https://www.massimilianosbaraglia.it/routing/bgp/bgp-teoria/bgp-attributi-valori-e-definizioni

https://www.massimilianosbaraglia.it/routing/bgp/bgp-teoria/bgp-attributi-funzionalita-e-formato-header