Questa settimana il capitolo 5 del libro su IS-IS, che tratta un argomento chiave: la formazione delle adiacenze e i tipi (due).

Abbiamo visto in un precedente Post, che la funzionalità BGP PIC consente di velocizzare la convergenza del BGP tramite l'installazione nella FIB di un percorso di backup. Affinché questo accada è necessaria, ovviamente, l'esistenza di un percorso BGP di backup. In molti casi questo avviene di default, ma in altrettanti casi importanti nelle applicazioni pratiche, ciò non si verifica.
 

SCENARIO DI RIFERIMENTO

Vediamo ad esempio cosa accade di default nel classico caso di un AS single-homed, con doppio collegamento a due router di un altro AS, di cui uno viene utilizzato come primario e l'altro come backup. Per contestualizzare meglio lo scenario, farò riferimento a un servizio L3VPN BGP/MPLS, ma ciò che illustrerò è valido anche in un contesto di semplice accesso a Internet fornito da un ISP a un Cliente.

Lo scenario complessivo è riportato nella figura seguente.

 

 

Il router CE-12 ha un doppio collegamento con i router PE-1 e PE-2. Come protocollo di routing PE-CE, come sovente avviene nelle applicazioni pratiche, viene utilizzato il BGP. La politica di routing desiderata è che il collegamento CE-12 <--> PE-1 sia utilizzato come primario (indicato nella figura con la lettera P), e l'altro come backup (indicato con la lettera B).

La realizzazione di questa politica utilizza strumenti classici del BGP. Per quanto riguarda il traffico outbound (da sito 12 della VPN-A verso la rete dell'ISP), è possibile utilizzare l'attributo standard Local Preference (NOTA: in ambiente Cisco, in uno scenario come quello della figura, sarebbe possibile anche utilizzare il parametro proprietario weight, ma io mi sento di sconsigliarlo vivamente primo perché non è standard e poi perché non essendo propagato tramite gli annunci iBGP, ha applicazioni limitate al solo scenario di un CE con due o più collegamenti verso uno o più PE). Per il traffico inbound invece vi sono varie alternative tra cui l'utilizzo lato CE del MED o dell'AS_PATH Prepending, o lato PE del Local Preference. Quest'ultima soluzione viene spesso utilizzata dagli ISP, in modo secondo me molto elegante, congiuntamente all'utilizzo dell'attributo BGP Community lato CE. L'idea è molto  semplice: partendo dalla ovvia osservazione che il punto di ingresso in un AS può essere determinato attraverso una opportuna scelta del punto di uscita di un altro AS, previo accordo tra AS è possibile, tramite un annuncio eBGP, comunicare ad un altro AS di assegnare un appropriato valore di Local Preference (LP) all’annuncio. Così facendo, si dà la possibilità ad un AS di scegliersi il punto di ingresso, chiedendo all’altro AS di far uscire il traffico dal proprio AS in un punto opportuno. Lo strumento per comunicare ad un AS l’opportuna assegnazione del LP, è l’attributo BGP Community. Questo elegante metodo è stato illustrato nella RFC 1998 An Application of the BGP Community Attribute in Multi-home Routing, e rappresenta una delle applicazioni più interessanti dell’attributo BGP Community.

Vediamo ora cosa accade in pratica nello scenario descritto sopra. Supponiamo che a fronte di un determinato valore dell’attributo BGP Community ricevuto, agli annunci della "NET X" ricevuti da CE-12 il router PE-1 assegni LP=200 e il router PE-2 LP=150 (NOTA: in realtà si potrebbe semplificare la procedura assegnando un solo valore di LP e sfruttando il valore di default LP=100 che quasi tutti i costruttori utilizzano, ma per maggiore chiarezza utilizzerò assegnazioni "personalizzate" in entrambi i PE).

Supporrò inoltre che venga stabilita prima la sessione eBGP tra CE-12 e PE-1 e poi quella tra CE-12 e PE-2. Il risultato finale sarebbe comunque identico se si ipotizzasse il contrario.

Gli annunci eBGP, secondo le regole dell'attributo LP, si propagano all’interno dell’AS dell'ISP attraverso le sessioni MP-iBGP, lasciando inalterati i valori di LP (NOTA: in realtà, come noto, in uno scenario L3VPN vengono propagati annunci del prefisso VPN-IPv4 RD:<NET X>, dove RD è il valore di Route Distinguisher, impostato via configurazione manuale). In particolare, l'annuncio ricevuto da PE-1, al quale viene assegnato il valore di LP=200, verrà propagato a PE-2 e PE-3 con LP=200. Entrambi questi router sceglieranno come best-path BGP l'unico percorso annunciato.
Quando, dopo che la sessione eBGP tra CE-12 e PE-2 raggiunge lo stato Established, PE-2 riceve l'annuncio eBGP della "NET X" da CE-12, avrà a disposizione due annunci e quindi esegue il processo di selezione BGP. Poiché all'annuncio eBGP è assegnato un valore LP=150 mentre l'annuncio MP-iBGP ricevuto da PE-1 ha LP=200, viene eletto best-path il percorso che ha BGP Next-Hop PE-1. Per la regola dello split horizon BGP, questo best-path non viene annunciato ai router PE-1 e PE-3, i quali quindi si troveranno internamente un solo annuncio MP-iBGP per la "NET X".

Cosa accade in caso di fuori servizio del collegamento primario tra CE-12 e PE-1 ? Bene, la convergenza verso il collegamento di backup avviene per PE-1 e PE-3 interamente sul piano di controllo, mentre per PE-2 può avvenire anche sul piano dati abilitando la funzionalità PIC. La sequenza degli eventi è classica ed è già stata vista in precedenti Post, comunque "repetita iuvant (sed continuata secant)". Il router PE-1, appena rilevato il fuori servizio del collegamento primario, grazie alla funzionalità BGP fast external fall-over (o al BFD, se applicato), chiude immediatamente la sessione eBGP con CE-12 e invia un messaggio BGP UPDATE a PE-2 e PE-3 per ritirare la NET X, non più raggiungibile (vedi figura seguente). 

 

 

Il messaggio raggiunge PE-2, il quale avendo in memoria un secondo annuncio (l'annuncio eBGP ricevuto da CE-12), converge immediatamente sul percorso eBGP (NOTA: la convergenza avviene sul piano dati nel caso su PE-2 sia abilitata la funzionalità BGP PIC, sul piano di controllo se non abilitata). In ogni caso, PIC o non PIC, PE-2 elegge il nuovo BGP best-path e lo annuncia a PE-1 e PE-3. A questo punto, sia PE-1 che PE-3 avranno il nuovo percorso disponibile e il traffico dall'AS dell'ISP verso il sito 12 della VPN-A utilizzerà il collegamento di backup.

 

 

Tutto è bene quel che finisce bene quindi. In realtà, il film è finito bene, ... ma ci ha messo un sacco di tempo ! La musica sarebbe stata diversa se PE-1 e PE-3 avessero avuto a disposizione il percorso di backup. PIC o non PIC, la convergenza in ogni caso sarebbe stata più veloce. Con il BGP PIC abilitato, ancora più veloce.

 

LA FUNZIONALITA' BGP BEST EXTERNAL

Come è possibile fare in modo che PE-1 e PE-3 abbiano a disposizione anche il percorso di backup ? Bene, sarebbe sufficiente variare un po' il comportamento di default del BGP nel seguente modo: consentire al router PE-2 di annunciare comunque il percorso eBGP, anche se questo non è best-path. Così facendo, sia PE-1 che PE-3 si troverebbero in memoria oltre al best-path scelto da PE-1, anche un secondo percorso, che è quello eBGP propagato da PE-2. Questa variazione nel comportamento di default del BGP viene detta funzionalità BGP Best External e comunque riguarda gli annunci eBGP non best-path. Per questa ragione non è applicabile in uno scenario in cui sono presenti Route Reflector. In presenza di Route Reflector è necessario utilizzare altre tecniche (Add-Path, Diverse Path), che tratterò in Post successivi.
E' curioso notare che nella specifica originale del BGPv4 (RFC 1771) questo comportamento era già previsto, ma non è mai stato implementato dai costruttori, che invece, per evitare possibili routing e forwarding loop e un consumo eccessivo di memoria a causa del maggior numero di annunci, annunciano di default il solo best-path. Nel nostro scenario l'applicazione della regola originale, dal punto di vista dei loop è comunque innocua e il consumo di memoria trascurabile.

 

IMPLEMENTAZIONI CISCO E JUNIPER

Nei ruoter Cisco, la funzionalità BGP Best External si attiva nell'IOS/IOS XE, con la seguente configurazione:
 

router bgp numero-AS

...

address-family {ipv4 [unicast | vrf nome-VRF] | vpnv4}

 bgp advertise-best-external

 

mentre nell'IOS-XR con la configurazione:

 

router bgp numero-AS

...

address-family ...

  advertise best-external

 

con il comando che può essere eseguito praticamente per tutte le address-family. Nella sua versione più completa, il comando è disponibile nell'IOS a partire dalle versioni 12.2(33)SRE, 15.2(3)T, 15.2(4)S, 15.1(1)SY, nell'IOS XE a partire dalla versione 3.2S e nell'IOS-XR a partire dalla versione 4.0.0.

Nei router Juniper la configurazione da eseguire è la seguente:

 

[edit protocols bgp group nome-gruppo]

  advertise-external {conditional}

 

dove l'opzione conditional consente l'annuncio del secondo percorso se e solo se il processo di selezione, nella determinazione del best-path, arriva al punto in cui si confronta l'attributo MED. Come conseguenza con l'utilizzo dell'opzione conditional si ha che un annuncio esterno non best-path che ha un AS_PATH più lungo del best-path, non viene propagato.

Nel JUNOS la funzionalità BGP Best External è disponibile a partire dalla versione 9.3.
 

ESEMPIO

Questa volta, per evitare che i miei amici di Juniper mi dicano che nei miei Post sono troppo Cisco-oriented, illustrerò un esempio in ambiente Juniper. Lo scenario di rete e il relativo piano di numerazione è riportato nella figura seguente.

 

Riportiamo per brevità le sole configurazioni rilevanti del router PE-2, che è l'unico nel nostro esempio che richiede l'abilitazione della funzionalità BGP Best External (anche se nella pratica il comando poi si mette su tutti i PE).

 

[edit protocols bgp]

tt@PE-2# show

group IBGP {

    type internal;

    local-address 192.168.0.2;

    advertise-external;

    family inet-vpn {

        unicast;

    }

    neighbor 192.168.0.1;

    neighbor 192.168.0.3;

}

 

[edit routing-instances SSGRR]

tt@PE-2# show

instance-type vrf;

interface fe-0/0/1.0;

route-distinguisher 3269:1;

vrf-target target:3269:1;

protocols {

    bgp {

        group CE {

            type external;

            peer-as 65201;

            as-override;

            neighbor 10.1.21.2;

        }

    }

}

 

Sul router PE-1 abbiamo assegnato a tutti gli annunci provenienti da CE1-1 un LP=200, per fare in modo che il collegamento tra PE-1 e CE-12 sia utilizzato come primario.

 

[edit policy-options policy-statement SETLP]

tt@PE-1# show

then {

    local-preference 200;

}

 

[edit routing-instances SSGRR]

tt@PE-1# show

instance-type vrf;

interface fe-0/0/1.0;

route-distinguisher 3269:1;

vrf-target target:3269:1;

protocols {

    bgp {

        group CE {

            type external;

            import SETLP;

            peer-as 65201;

            as-override;

            neighbor 10.1.11.2;

        }

    }

}

 

Vediamo ora i percorsi presenti nella tabella di routing associata alla VRF SSGRR su PE-3, verso la rete 10.1/16 annunciata da CE-12, prima e dopo l'applicazione della funzionalità BGP Best External.

 

Prima:  

 

tt@PE-3> show route table SSGRR.inet.0 10.1/16 exact

SSGRR.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

10.1.0.0/16  *[BGP/170] 00:06:23, localpref 200, from 192.168.0.1

                      AS path: 65201 I

                    > to 172.30.1.1 via fe-0/0/1.0, Push 300000, Push 299808(top)

 

 

Dopo:

 

tt@PE-3> show route table SSGRR.inet.0 10.1/16 exact

SSGRR.inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

10.1.0.0/16 *[BGP/170] 00:08:14, localpref 200, from 192.168.0.1

                      AS path: 65201 I

                    > to 172.30.1.1 via fe-0/0/1.0, Push 300000, Push 299808(top)

                     [BGP/170] 00:00:06, localpref 100, from 192.168.0.2

                      AS path: 65201 I

                    > to 172.30.1.1 via fe-0/0/1.0, Push 300016, Push 299824(top)

 

Come si può notare, prima dell'applicazione della funzionalità BGP Best External, PE-3 ha in memoria un solo percorso, quello annunciato da PE-1. Dopo l'applicazione invece, PE-3 si trova oltre al percorso annunciato da PE-1, anche un percorso annunciato da PE-2, percorso che per PE-2 non è best-path. Quest'ultimo è per PE-2 il percorso eBGP.

 

ESEMPIO CON ROUTE REFLECTOR

Nell'esempio del paragrafo precedente, abbiamo accuratamente evitato l'utilizzo di Route Reflector (RR). Ma questo nelle applicazioni pratiche è uno scenario realistico solo in presenza di pochissimi PE (4, al massimo 5). Ho già detto che in presenza di RR è necessario utilizzare altre funzionalità, come Add-Path e Diverse Path, che tratterò nel seguito.

Ma nel (solo) caso delle L3VPN BGP/MPLS è possibile utilizzare comunque la funzionalità BGP Best External, insieme a un trucchetto semplice semplice: si assegnano alle due VRF dove sono attestati i due collegamenti del sito VPN, due diversi Route Distinguisher (RD). Così facendo in qualche modo si "imbroglia" il BGP, facendogli credere di essere in presenza di due NLRI diversi. Ma in realtà ad essere diversa è la sola componente RD del prefisso VPN-IPv4, mentre la componente IP è identica.
Cosa accade è presto detto. Facendo riferimento alla prima figura in alto, nell'ipotesi di presenza di un RR, grazie alla funzionalità BGP Best External abilitata su PE-2, questo riceverà due annunci del prefisso NET X, uno da PE-1 e l'altro da PE-2 (quest'ultimo grazie alla funzionalità BGP Best External). L'annuncio ricevuto da PE-1 è in realtà l'annuncio del prefisso VPN-IPv4 RD1:<NET X>, mentre analogamente, quello ricevuto da PE2 è in realtà del prefisso VPN-IPv4 RD2:<NET X> (con RD1 diverso da RD2). Per cui il RR vedrà due NLRI diversi, e ciascun percorso sarà eletto best-path. Per cui il RR rifletterà ai suoi RR-Client (tutti i router PE, anche quello da cui viene ricevuto il best-path !) due best-path diversi. E così su tutte le VRF dell'istanza VPN si avranno due percorsi verso il prefisso VPN NET X, uno con BGP Next-Hop PE-1 e l'altro con BGP Next-Hop PE-2. Tra i due viene ovviamente eletto come best-path il percorso con BGP Next-Hop PE-1, avendo il relativo annuncio un LP più elevato (200 contro 150, sempre facendo riferimento allo scenario iniziale con l'aggiunta di un RR). A parte qualche dettaglio, nulla cambierebbe nella sostanza se invece di un singolo RR se ne avessero due (o anche più). 

Vale la pena utilizzare questo trucchetto, invece di funzionalità più generali e più eleganti come Add-Path o Diverse Path ? Secondo me no, per la semplice ragione che l'applicazione ha validità limitata all'ambito di servizi L3VPN e per reti con pochi siti VPN. E' impensabile che un grande ISP con migliaia di siti con collegamenti ridondati possa utilizzare un simile trucchetto. Sarebbe un incubo da un punto di vista gestionale !!! Però io conosco una grande rete Enterprise che implementa servizi L3VPN per soli (pochi) Clienti interni, che lo utilizza con successo.

E allora perché ho voluto illustrarlo ? La ragione, come vedremo in futuro, è che la funzionalità Add-Path si basa su un ragionamento molto simile.

 

CONCLUSIONI

Con questo Post ho iniziato la seconda (e ultima) trilogia che riguarda la convergenza del BGP. La funzionalità che ho descritto ha senso implementarla sempre, ma trova la sua applicazione naturale congiuntamente all'implementazione della funzionalità BGP PIC.

Nei prossimi due Post che completeranno questa trilogia tratterò le funzionalità Add-Path e Diverse Path.

Siete nuovi al BGP, oppure avete bisogno di ulteriori approfondimenti ? Acquistate il mio libro "BGP: dalla teoria alla pratica" (al prezzo speciale di 30 Euro per gli utenti registrati al sito, spese di spedizione gratuite). Oppure seguite i nostro corsi IPN246 e IPN247.