Inter-AS option A – B – C design

04.04 2020 | by massimiliano

---

Inter-AS option A option B option C design   Questo documento si prefigge di evidenziare le principali caratteristiche tecniche di […]

https://www.ingegnerianetworking.com/wp-content/uploads/2020/04/inter-as_option-a-88e.png

Inter-AS option A option B option C design

 

Questo documento si prefigge di evidenziare le principali caratteristiche tecniche di collegamento Inter-AS attraverso le tre opzioni possibili e riportare graficamente le sue features.

 

 

INTER-AS OPTION A:

 

E’ conosciuto come VRF back-to-back ed i router che collegano i due differenti AS sono chiamati ASBR

Tra il collegamento Inter-AS (tra Services Provider) non è attivo MPLS, ma solo IPv4 routes sono annunciate attraverso il protocollo EBGP.

Per ogni L3VPN esiste un solo collegamento logico su base sub-interface associato alle relativa VRF (è possibile anche un collegamento fisico dedicato)

Inter-AS option A ha il difetto che ogni ASBR deve mantenere tutte le routes delle VRF interessate creando un notevole dispendio in termini di CPU e memoria

Inter-AS option A è poco scalabile se abbiamo un numero elevato di L3VPN da configurare

Inter-AS option A, comunque risulta essere l’opzione più sicura in quanto nessun tipo di informazione è condivisa tra i due differenti AS

Inter-AS option A non richiede un meccanismo di control-plane (segnalazione tipo LDP, BGP LU, BGP VPNv4) ad eccezione del solo protocollo di routing IGP tra i due ASBR

Inter-AS option A in caso di IGP protocol tra i due ASBR è necessario un processo di redistribuzione in quanto le routes sono viste come BGP dal PE remoto

 

 

 

 

 

 

INTER-AS OPTION B:

 

Non vi è alcun protocollo IGP tra le coppie di ASBR

Inter-AS option B ha il vantaggio che ogni ASBR non deve mantenere tutte le routes per-VRF interessate (VRF table) ma esse sono mantenute nella tabella VPNv4 BGP 

Inter-AS option B non richiede l’impiego di sub-interface differenti e viene attivato tra i due ASBR un solo peering EBGP con address-family VPNv4

Inter-AS option B utilizza l’impiego di router reflector all’interno dei propri AS per annuciare le L3VPN route verso gli ASBR i quali re-annunciano queste routes tra differenti AS attraverso sessioni MP-BGP VPNv4

Route-Target extended community è attivato negli update VPNv4

Inter-AS option B non richiede MPLS/LDP tra differenti AS

 

Caveats:

Gli ASBR non dovrebbero accettare prefix L3VPN se non vi è corrispondenza di Route-Target; attraverso un comando ” no bgp route-target filter ” abilitato un nodo può accettare tutte le prefix L3VPN anche se i route-target sono differenti.

Un Route-Target rewrite può essere necessario per gli ASBR qualora i due AS utilizzano RT diversi

 

 

 

 

 

INTER-AS OPTION C:

 

In questa opzione le sessioni MP-EBGP VPNv4 sono attivate tra Router Reflector dei rispettivi AS

I due ASBR attivano un protocollo EBGP IPv4 + label unicast (LU) per annunciare i soli indirizzi di loopback RRs imparati via protocollo IGP locale al proprio AS.

 

IPv4 BGP-LU (AFI=1, SAFI=4) è un protocollo il cui obiettivo è quello di segnalare a livello end-to-end un LSP e possono esserci due tipi di sessioni:

 

– IBGP Multihop (ASBR-RR e ASBR-PE)

– EBGP Single-Hop (ASBR-ASBR)

 

queste sessioni propagano internal prefix labeled (di solito sono indirizzi di loopback dei router PE/ASBR e dei Router-Reflector) e solo gli ASBR hanno il compito di re-annunciare queste routes; quando gli ASBR re-annunciano queste routes, essi cambiano il routes BGP next-hop andando quindi a creare una nuova label per un nuovo LSP.

 

Inter-AS option C richiede una attenta configurazione per i seguenti steps:

 

– redistribuzione a livello Edge della rete

– VPNv4 neighborship tra RRs

– IPv4 BGP-LU tra ASBRs (label advertisement)

– Accordo dei valori di Route-Target tra differenti AS

 

Inter-AS option C può essere considerato insicuro in quanto gli indirizzi interni di un AS sono trasmessi (leaked) tra AS