Una delle buzzword del momento è NFV (Network Function Virtualization), ossia la virtualizzazione di alcune funzioni di rete che oggi sono realizzate attraverso apparati hardware dedicati e proprietari. Lo svantaggio dell'utilizzo di hardware dedicato è che l'introduzione di un nuovo servizio, l'aggiornamento del software e dell'hardware spesso richiedono un intervento "fisico" sulla rete, aumentando i costi e il time-to-market.
Una funzione che ben si presta ad essere implementata come VNF è la classica e ben nota funzionalità di BGP Route Reflection, adottata in modo pervasivo nelle reti degli ISP e nelle grandi reti Enterprise. Questa funzionalità, che è essenzialmente una funzionalità del piano di controllo, senza particolare impatto sul piano dati, è oggi implementata tramite router dedicati (es. Cisco ASR 1000), ma questo è sicuramente uno spreco di risorse. Infatti, le uniche risorse di cui ha bisogno un BGP Route Reflector (da qui in poi abbreviato in RR) sono CPU e memoria. Un RR è tipicamente (o almeno è buona regola che sia così) fuori dal forwarding path del traffico, e quindi non ha bisogno di ASIC dedicati in grado di smaltire grandi quantità di traffico. L'unico traffico che un RR deve smaltire è quello dei messaggi BGP.
AMARCORD ... LA FUNZIONALITA' BGP ROUTE REFLECTION
Le moderne architetture di routing delle grandi reti IP sono basate sull’utilizzo combinato di un protocollo IGP, tipicamente di tipo Link-State (OSPF o IS-IS) e sessioni iBGP tra i router di edge (noti come router PE) e tutti gli altri router della rete (di transito, noti come router P, e di edge).
Il ruolo del protocollo IGP è quello di creare i percorsi per il collegamento di due qualsiasi elementi della rete. È quindi un protocollo molto snello, con bassa occupazione di memoria e soprattutto veloce a convergere. Il ruolo delle sessioni iBGP è invece quello di importare all’interno della rete tutti i prefissi appresi dall’esterno (prefissi dei propri Clienti, di Clienti degli altri ISP, la “Full Internet Routing Table”, ecc.). La differenziazione delle funzioni deriva dal fatto che i protocolli IGP non sono stati progettati per gestire grosse quantità di prefissi (il numero dei prefissi esterni è sempre molto elevato, dell’ordine delle migliaia) mentre il protocollo BGP ha invece una struttura dati molto semplice e ottimizzata per la gestione di grandi tabelle di prefissi.
Quasi sempre è poi presente anche una terza componente, MPLS, che insieme alle altre consente la realizzazione di servizi avanzati come le L3VPN, L2-pseudowire, VPLS, EVPN, 6PE, 6VPE, ecc. .
Riassumendo, l’architettura di routing interna di una grande rete ISP, si basa su un modello che può essere riassunto come segue:
- Un protocollo IGP che trasporta esclusivamente informazioni di routing interne della rete (interfacce di Loopback e subnet utilizzate per numerare l’infrastruttura interna).
- Una maglia completa di LSP MPLS tra i router PE (realizzata o attraverso il protocollo LDP, o più raramente attraverso il protocollo RSVP-TE, o magari in futuro via Segment Routing).
- Una maglia di sessioni iBGP tra ciascun router PE e tutti gli altri router della rete (P e PE).
Per funzionare correttamente, l'architettura di routing ha quindi bisogno di una grande quantità di sessioni iBGP. E questo è il punto debole di questo modello. Infatti, in reti di grandi dimensioni, il numero di sessioni iBGP potrebbe essere troppo elevato, e quindi di difficile gestione.
Sono disponibili due tecniche per risolvere il problema:
- Utilizzare il concetto di Route Reflection.
- Utilizzare una Confederazione BGP.
I grandi ISP preferiscono utilizzare la prima soluzione, anche se questa comporta l’aggiunta alla rete di ulteriori router. In realtà, le funzioni di Route Reflection potrebbero essere svolte anche da alcuni router della rete, ma per evitare sovraccarichi della CPU, si preferisce utilizzare router dedicati.
Il risparmio di sessioni iBGP utilizzando i RR è elevatissimo. Ad esempio, ipotizzando una rete IP+MPLS con 200 router PE, sono necessarie, in assenza di RR, 200*(200-1)/2 = 19.900 sessioni iBGP. In presenza di RR, ipotizzando per affidabilità, due sessioni iBGP verso due diversi RR per ciascun router PE, le sessioni iBGP necessarie diventano 2x200 = 400, più poche sessioni tra i RR (il numero esatto dipende da quanti sono i RR installati), contro le 19.900 richieste senza RR.
Oltre a questo, c'è anche un ulteriore vantaggio nell'introdurre in rete i RR. Si immagini ad esempio di aggiungere alla rete un nuovo PE. Senza l'ausilio di RR è necessario agire sia sul nuovo PE, configurando un elevato numero di sessioni iBGP (ad esempio 200 con i numeri sopra), che su tutti gli altri PE (sempre 200 con i numeri sopra) per configurare la controparte della sessione iBGP verso il nuovo PE. In presenza di RR invece tutto si risolve configurando sul nuovo PE un paio di sessioni iBGP verso una coppia di RR (in teoria ne basterebbe una, due solo per maggiore affidabilità), e sui RR la controparte della sessione iBGP verso il nuovo PE. Tutti gli altri non hanno bisogno di alcuna configurazione.
Ricordate queste proprietà, passiamo ai virtual RR (vRR).
VIRTUAL RR (vRR)
Poiché, come detto sopra, le uniche risorse di cui ha bisogno un RR sono CPU e memoria, e poiché gli RR sono tipicamente (o almeno è buona regola che sia così) fuori dal forwarding path del traffico, e quindi non hanno bisogno di ASIC dedicati in grado di smaltire grandi quantità di traffico (l'unico traffico che un RR deve smaltire è quello dei messaggi BGP), ha poco senso utilizzare dei (costosi) router dedicati per realizzare dei RR, sprecando così risorse preziose dell'hardware di forwarding, che di norma non vengono utilizzate, o almeno utilizzate molto poco.
Inoltre, le soluzioni basate su hardware proprietari possono soffrire, come è già accaduto, di problemi di scalabilità, poiché la FIRT (Full Internet Routing Table) cresce continuamente (ad oggi ha superato le 600k righe, vedi il BGP Routing Table Analysis Reports a questo link). Una soglia critica per molti apparati è stato il raggiungimento delle 512k righe, vedi ad esempio questo documento per un survey sugli apparati Cisco.
In conclusione, le funzionalità di BGP Route Reflection potrebbero essere implementate come VNF su un qualsiasi server COTS x86. Gli operatori degli Internet eXchange Point (IXP) implementano già da tempo questo approccio, utilizzando nei loro route server implementazioni open-source del BGP come Bird o Quagga.
Gli ISP non possono utilizzare lo stesso approccio poiché i software open-source come Bird o Quagga, non supportano tutte le address-family che consentono la fornitura dei servizi BGP/MPLS citati sopra (L3VPN, L2VPN, ecc.). Inoltre per i grandi ISP, il supporto e l'affidabilità del software sono una componente essenziale, non garantita dai software open-source.
I grandi ISP hanno quindi fatto pressioni sui classici vendor di router come Cisco, Juniper, Nokia-ALU, per avere a disposizione software affidabili e completi da utilizzare come VM in server COTS arbitrari, ottenendo così una soluzione più economica e più semplice da gestire, in sostanza con benefici sia nel CAPEX che nell'OPEX.
Cisco mette oggi a disposizione il suo router virtuale CSR1000v, che utilizza l'IOS XE, o anche il suo IOS XRv, basato per l'appunto sull'IOS XR. Juniper mette a disposizione il suo software vRR, che può essere anche instanziato utilizzando OpenStack (vedi ad esempio questo esempio nella documentazione Juniper). Infine, anche Nokia-ALU ha il suo VSR-RR, e Brocade il suo Vyatta 5600 vRouter.
DALLA TEORIA ALLA PRATICA
Quali caratteristiche deve avere un server COTS per supportare la funzionalità BGP Route Reflection ? Niente di particolare, solo per fare un esempio, vi riporto di seguito i requisiti richiesti dal vRR Juniper, tratti dal documento citato sopra:
- CPU: 4-core Intel(R) Xeon(R) E5620 processor @ 2.40GHz
- Available RAM: 48 Gb (32 Gb per VM instance per vRR instance)
- On-chip cache memory: Level 1 cache
- Instruction cache (I-cache): 32KB
- Data cache (D-cache): 32KB
- Level 2 cache: 256KB
- Level 3 cache: 12MB
- Linux distribution: CentOS release 7.1 or 7.2 - KVM/QEMU
Per un esempio reale di applicazione, date uno sguardo a questa presentazione di Mark Tinka di Seacom, che ripercorre l'esperienza di messa in produzione dei loro vRR. Mark ha utilizzato il software CSR1kv di Cisco, basato sull'IOS XE. Il kit di installazione comprende:
- HP ProLiant DL360p Gen8 1U servers.
- 2x 6-core 2.6GHz E5-2630v2 64-bit CPU’s.
- 512GB DRAM.
- 2x 600GB hard drives.
- 4-port 1Gbps Ethernet card.
- VMware ESXi 5.5 (NOTA: il CSR1kv, a partire dalla versione IOS XE 3.12S, supporta come Hypervisor anche Citrix XenServer, KVM e Microsoft Hyper-V).
- VMware vSphere Client.
- Cisco CSR1000v software image.
Tutti i dettagli dell'installazione nella presentazione, che vi invito a leggere, è molto interessante.
CONCLUSIONI
Se avete bisogno di implementare nella vostra rete dei RR che siano fuori dal forwarding path del traffico (ricordo che questo è un aspetto chiave !), non sprecate soldi nell'acquisto di router dedicati. Utilizzate piuttosto server COTS commerciali e software BGP open-source come Bird o Quagga, oppure, per soluzioni più affidabili e più supportate, i sistemi operativi di rete classici dei vari vendor tradizionali. Certo, sarebbe bello che questi ultimi producessero dei package appositi per i RR, in fondo, per la funzionalità BGP Route Reflection sono sufficienti le implementazioni (più o meno complete) del BGP e dei protocolli IGP link-state (OSPF e IS-IS). Parafrasando il mitico Califfo (al secolo, Franco Califano) "tutto il resto è noia ...".
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 i lettori del blog, spese di spedizione gratuite; per l'acquisto inviate una e-mail a libri@ssgrr.com). Oppure seguite i nostro corsi IPN246 "BGP: aspetti base" e IPN247 "BGP: aspetti avanzati".
Nessun commento:
Posta un commento