Inter-AS option A – B – C design
04.04 2020 | by massimilianoInter-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