differenze tra as-OVERRIDE e ALLOWAS-IN

introduzione

ALLOWAS – IN e as-OVERRIDE sono due funzionalità simili che possono essere impiegate in uno scenario in cui una come X (ad esempio provider) è connessa a un’altra come Y (ad esempio transit operator / backbone MPLS). Per comprendere meglio entrambe le funzionalità è opportuno analizzare come funziona il controllo dei loop nel protocollo BGP (RFC 4271).

la specifica del protocollo BGP fornisce diversi meccanismi per il controllo e la prevenzione del loop. In uno scenario iBGP (cioè sessioni BGP all’interno di uno stesso AS), ad esempio, la regola split-horizon è uno dei meccanismi di controllo e prevenzione del ciclo che impedisce che i prefissi annunciati da un vicino iBGP (A) al vicino iBGP (B) vengano nuovamente annunciati da (B) a un terzo vicino iBGP (C). Ci sono diverse possibili soluzioni disponibili per “rilassare” questa regola (l’uso dei riflettori del percorso è uno di questi, ad esempio), ma non saranno discussi in questo articolo.

già in scenari eBGP (cioè sessioni BGP tra diversi Assi) il meccanismo di controllo e prevenzione del ciclo più semplice è l’analisi dell’attributo as_path. In sostanza, se il peer eBGP(A) trova il proprio ASN nell’attributo as_path dei prefix pubblicizzati dal peer eBGP(B) (e viceversa), il router scarta il prefisso per evitare un possibile ciclo di routing. ALLOWAS-IN e as-OVERRIDE sono due soluzioni simili che possono essere impiegate in questo caso, e da quel punto descriveremo in dettaglio in che tipo di situazioni possiamo usare l’una o l’altra.

ALLOWAS-IN

considerare lo scenario in Figura 1 dove AS 20 (provider) è as 10 (upstream) transit client. Topologie di questa natura possono verificarsi con una certa frequenza, ad esempio, in provider Internet che non hanno alcuna connessione fisica tra i loro POP IP e hanno bisogno di acquistare IP transit da un Upstream per fornire accesso a Internet ai loro abbonati in ogni PoP/località.

Figura 1: client (AS 20) connesso all’ISP / UPSTREAM (as 10) in due POP in posizioni distinte.

in questo scenario, R2 annuncerà il prefisso 10.0.0.0 / 24 per Upstream, e l’as_path di quel prefisso sarà visto come segue sul router upstream:

R1_Upstream#sh ip bgp 10.0.0.0/24 Network Next Hop Metric LocPrf Weight Path*> 10.0.0.0/24 100.64.0.2 100 20 i

dopo il funzionamento “normale” del protocollo BGP (cioè ignorando filtri, criteri di routing, ecc.).), l’attributo as_path del prefisso verrà modificato in R1 prima che venga pubblicizzato nuovamente verso i suoi peer. Il” nuovo ” elenco as-PATH del prefisso sarà simile a:

AS_PATH: 10 20 i

tuttavia, quando il messaggio di aggiornamento BGP che porta il prefisso 10.0.0.0 / 24 raggiunge R3, R3 scarterà questo aggiornamento in considerazione che noterà la presenza del proprio ASN (20 in questo caso) nell’attributo as_path di quel prefisso. Un avviso simile a questo può essere visto nel log del router R3 (piattaforma Cisco IOS, modalità di debug):

questo è dove ALLOWAS-IN entra in gioco per rilassare questa restrizione. ALLOWAS-IN è configurato sul router del provider, in questo caso R3. L’effetto è che semplicemente BGP accetterà la possibile presenza propria COME nell’as_path dei prefissi ricevuti dall’Upstream.

sulla maggior parte delle piattaforme (Cisco, Juniper, ecc.) ALLOWAS-IN richiede un parametro, che è il numero massimo di occorrenze tollerate dal proprio ASN nell’attributo as_path associato ai prefissi ricevuti. Ad esempio, in Cisco IOS, se vogliamo consentire il verificarsi di fino a 2 volte il proprio ASN, negli aggiornamenti di percorso ricevuti tramite peer eBGP 1.1.1.1 (R1_Upstream) la configurazione è la seguente:

R3# conf tR3# (config) router bgp 20R3# (config-router) neighbor 1.1.1.1 allowas-in 2

nell’esempio precedente, eseguiamo la configurazione in modo da poter imparare i prefissi che contengono al massimo 2 occorrenze del proprio ASN nel campo as-PATH quando si allontana dal vicino 1.1.1.1, che soddisferebbe lo scenario del diagramma esposto in precedenza. È importante notare che ALLOWAS-IN deve essere configurato su tutti i router client su cui si desidera rilassare la regola di controllo del ciclo BGP!

diamo un’occhiata a un esempio più completo (e con la modalità di debug abilitata sulla piattaforma Cisco IOS). Nel terminale è possibile vedere abbastanza chiaramente il messaggio di AGGIORNAMENTO BGP contenente la struttura dati che contiene informazioni sul prefisso e sulla subnet mask (Informazioni sulla raggiungibilità del livello di rete – NLRI). Di seguito si può notare che il router ha rilevato la presenza di AS 20 nell’attributo as_path del prefisso 10.0.0.0 / 24 annunciato da r1_upstream (neighbor 1.1.1.1), ma ha installato il prefisso nella tabella di inoltro (FIB) a causa del rilassamento della restrizione imposta dalla configurazione “allowas-in” per neighbor 1.1.1.1:

AS-OVERRIDE

come già accennato, la funzionalità as-OVERRIDE è abbastanza simile a ALLOWAS-IN per quanto riguarda l’obiettivo desiderato che è quello di rilassare il controllo del loop del protocollo BGP. Tuttavia, la grande differenza tra i due è che modifica l’attributo as_path del prefisso sostituendo la presenza dell’ASN “causale” del ciclo con l’ASN dell’Upstream stesso. Di conseguenza, AS-OVERRIDE è sempre configurato sul lato upstream (fornitore di servizi) mentre tutta la configurazione allowas-in viene eseguita sul lato client.

vale anche la pena notare che l’uso di as-OVERRIDE è generalmente associato a scenari VPN Layer 3 (L3VPN) su una rete MPLS gestita. In questo tipo di scenario, il cliente ha diversi siti e utilizza BGP come protocollo di routing tra il suo CE upstream (Customer Edge) e PE (provider Edge). In questo caso, as-OVERRIDE viene applicato sui router PE e l’effetto sarà la sostituzione dell’ASN CE con l’ASN PE prima che i prefissi vengano nuovamente annunciati agli altri PE nella rete MPLS.

nel diagramma sopra il CE/R3 router visualizzato il prefisso 10.0.0.0 / 24 con il PERCORSO attributo “20 10” e poi vorrei chiudere l’annuncio a causa del BGP loop meccanismo di prevenzione, già discusso in precedenza. Tuttavia, se la configurazione as-OVERRIDE viene eseguita su PE1, il router CE/R3 riceverà il prefisso 10.0.0.0 / 24 con l’attributo as-path “10 10”, e il prefisso verrà quindi installato sul FIB. È estremamente importante sottolineare che AS-OVERRIDE deve essere configurato su tutti i router PE per garantire la raggiungibilità dei prefissi client all’interno di L3VPN!

da un punto di vista operativo la configurazione as-OVERRIDE è troppo semplice sulla maggior parte delle routers.As un esempio, diamo un’occhiata alla configurazione su Cisco IOS per lo scenario di cui sopra:

la configurazione as-OVERRIDE verrà ripristinata nella sessione BGP tra PE e CE. Di seguito sarà possibile controllare i prefissi originati o annunciati dai router CE di questo VPNv4 contiene solo l’ASN del PE (Upstream) nell’attributo AS_PATH:

l’uso di as-OVERRIDE deve essere ben pensato e pianificato per evitare problemi o incongruenze nell’inoltro dei pacchetti, dopotutto ci stiamo rilassando e ci stiamo rilassando. Un meccanismo ausiliario per prevenire questi problemi è l’uso della comunità estesa BGP “Site of Origin – SoO” per identificare i prefissi IP che ogni sito client VPN ha origine e annuncia ad altri CE attraverso L3VPN. Tuttavia, in questo articolo non discuteremo questo argomento ed è un argomento di ricerca aggiuntivo per il lettore.

autori: Daniel Damitoe Humberto Galiza

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.