ReissBlog: BGP & SDN : Prima puntata

In questo post precedente, dove ho parlato del ruolo del BGP e di MPLS nell'era SDN, ho citato, parlando del ruolo di MPLS, che per determinare in maniera ottimale i percorsi tra due qualsiasi router, è necessario avere una visione completa della topologia della rete.

E questo è possibile solo con un piano di controllo centralizzato, perché come noto, nelle applicazioni attuali, dove il piano di controllo è distribuito sui vari nodi della rete, non si riesce ad avere da parte dei singoli nodi una visione globale della topologia della rete. Si pensi ad esempio a un dominio di routing partizionato in aree OSPF. I router interni a un'area conoscono solo la topologia della propria area e non delle altre aree.

Lasciando da parte per il momento il problema della determinazione dei percorsi ottimi, in questo post affronterò il problema di come i nodi della rete possano "comunicare" a un controller centralizzato, l'intera topologia.

Illustrerò una soluzione in via di standardizzazione in IETF, ma già implementata nei router dei principali vendor, come Cisco e Juniper. La soluzione è basata sul BGP, ed è utilizzabile solo nel caso in cui la rete sottostante utilizzi un protocollo di routing di tipo Link-State (ossia, OSPF o IS-IS). Per questo è nota come BGP Link-State (BGP-LS) (NOTA: in qualche documento meno recente potreste trovare la vecchia nomenclatura BGP-TE, ossia BGP Traffic Engineering).

ASPETTI GENERALI

Per illustrare l'idea base del BGP-LS, farò riferimento alla figura seguente, che riporta un semplice dominio di routing OSPF, partizionato in tre aree.

L'idea del BGP-LS è molto semplice. Dapprima si realizzano delle sessioni BGP con una particolare address-family definita ad-hoc (di cui illustrerò alcuni dettagli nella prossima sezione). Nel caso di un dominio partizionato in aree, come quello della figura, le sessioni non possono essere realizzate tra due nodi qualsiasi, ma tra nodi in grado di fornire tutte le informazioni topologiche necessarie.

Ad esempio, nella figura ho scelto un nodo dal quale ho stabilito una sessione BGP-LS verso il controller. Da questo nodo poi sono state stabilite due sessioni BGP-LS, la prima con uno dei due ABR tra l'area 1 e l'area 0, la seconda con uno dei due ABR tra l'area 2 e l'area 0. Attraverso queste due sessioni, il nodo centrale viene a conoscenza della topologia delle due aree 1 e 2, e poiché il nodo che ha la sessione con il controller conosce la topologia dell'area 0, ecco che questo è in grado di comunicare al controller l'intera topologia della rete.

Nel caso invece in cui il dominio di routing non sia partizionato in aree, è sufficiente una singola sessione BGP-LS tra un qualsiasi router e il controller (in realtà, nelle applicazioni pratiche le sessioni BGP-LS sono sempre ridondate).

Le informazioni topologiche veicolate non sono solo quelle classiche di OSPF, ma anche quelle apprese attraverso l'estensione di OSPF al Traffic Engineering MPLS (es. proprietà amministrative dei link, banda disponibile, banda residua, metriche IGP e TE, ecc.). Ricordo che queste informazioni aggiuntive vengono veicolate attraverso un nuovo LSA opaco (LSA di tipo 10), che ha ambito di propagazione la singola area (NOTA: nel caso IS-IS trovate tutto nel Capitolo 11 del libro, pubblicato in questo post).

Uno potrebbe chiedersi, ma perché scomodare il BGP per veicolare verso il controller le informazioni topologiche ? Non sarebbe stato sufficiente "prolungare" il dominio di routing includendo il controller, in modo che questo potesse avere una visione globale della topologia delle singole aree ? Ad esempio, nella figura sopra sarebbe stato sufficiente creare dei Tunnel GRE tra gli ABR e il controller e quindi stabilire su questi Tunnel delle adiacenze OSPF. Molto semplice e lineare, ma ...

Il controller dovrebbe implementare il codice sia di OSPF che di IS-IS. Questo perché in applicazioni al routing ottimo interdominio, un dominio di routing potrebbe utilizzare OSPF e l'altro IS-IS.
I protocolli IGP sono un po' troppo "chiacchieroni", inviano continuamente degli Hello, eseguono il flooding di LSA/LSP, ripetono i LSA/LSP (anche se con un periodo molto lungo), sottraendo così tempo di elaborazione alla CPU).
Nel caso di aree che sono distribuite su zone geografiche lontane, potrebbe essere un problema dove piazzare il controller.

L'utilizzo del BGP ha invece dei vantaggi, tra cui:

Il controller deve solo implementare il BGP.
Il BGP è tendenzialmente meno "chiacchierone" dei protocolli IGP.
Nel caso di routing interdominio, il BGP è il protocollo utilizzato per lo scambio delle informazioni di routing.

Questo è il BGP-LS, niente di speciale, ma solo una delle ormai innumerevoli applicazioni del BGP, che si riconferma anche in questo caso, come un protocollo "tuttofare". E ora vediamo alcuni dettagli.

BGP-LS: DETTAGLI DI FUNZIONAMENTO

Poiché l'obiettivo di BGP-LS è quello di ricostruire la topologia di un dominio di routing Link-State, deve avere un qualche modo per rappresentarla, per poi veicolare la topologia al controller, il quale non ha implementato alcun protocollo Link-State.

Le specifiche del protocollo sono definite nel draft IETF draft-ietf-idr-ls-distribution "North-Bound Distribution of Link-State and TE Information using BGP".

Le specifiche sono divise in due parti:

Definizione di un nuovo NLRI, che consiste di vari moduli di tipo TLV (Type-Length-Value), e che contiene informazioni su tre tipi di oggetti: nodi, link e prefissi IP (v4/v6). Con la combinazione di nodi e link viene comunicata la topologia, con i prefissi IP le informazioni di raggiungibilità.
Definizione di nuovi attributi BGP (solo per i cultori del BGP, di tipo optional non-transitive), attraverso i quali sono codificate informazioni associate agli oggetti di cui al punto precedente (nodi, link, prefissi IP). Ad esempio, informazioni tipo il nome dei nodi, le metriche IGP e TE, la banda residua, proprietà amministrative, ecc. . Anche i nuovi attributi BGP sono codificati utilizzando una moduli di tipo TLV.

Il BGP-LS utilizza l'estensione Multi-Protocollo del BGP (MP-BGP). Il supporto dell'address family BGP-LS viene negoziato attraverso le classiche BGP capabilities, nel messaggio BGP Open. Il codice AFI/SAFI che identifica l'address family BGP-LS è 16388/71.

Il formato generico del NLRI è riportato nella figura seguente (tratta dal draft IETF citato sopra), che contiene anche la codifica dei vari tipi di NLRI.

Il tipo 1 (Node NLRI) è sufficientemente auto-esplicativo. Come informazione contiene un identificativo del nodo (tipicamente il BGP Router-ID).

Il tipo 2 (Link NLRI) serve a definire un link della rete, dove ciascun link è identificato dai due nodi estremi. Un link è in realtà la composizione di due "mezzi-link" unidirezionali, e quindi per descrivere completamente un link sono necessari due messaggi BGP UPDATE con NLRI di tipo 2, ciascuno generato da uno dei due nodi agli estremi.

I tipi 3 e 4 (IPv4/IPv6 Topology Prefix NLRI) servono ad annunciare i prefissi direttamente connessi ai nodi.

Non riporto qui il formato dei vari tipi di NLRI, perché di scarso interesse pratico. I più curiosi possono consultare il draft, dove tutto è descritto con dovizia di particolari.

Oltre ai nuovi NLRI, il draft introduce nuovi attributi BGP da associare ai vari BGP-LS NLRI. Questi attributi aggiuntivi sono necessari per trasportare informazioni aggiuntive relative ai nodi, link e prefissi IP. Tutti gli attributi sono codificati nel formato TLV.

Attributi associati ai nodi: contengono informazioni su l'identificativo multi-topology (NOTA: se non siete familiari con la funzionalità multi-topology, trovate tutto nel Capitolo 11 del libro su IS-IS, pubblicato in questo post), varie flag presenti nei LSA/LSP (es. per IS-IS: bit Overload, bit Attached; per OSPFv2: bit External, bit ABR; per OSPFv3: bit Router, bit V6), nome del nodo (es. hostname), Area IS-IS di appartenenza, Router-ID IPv4/IPv6, ecc..
Attributi associati ai link: contengono informazioni classiche come i Router-ID dei nodi locale e remoto, e varie informazioni di interesse del Traffic Engineering MPLS (es. appartenenza a un gruppo amministrativo, banda totale disponibile, banda residua, metriche TE, appartenenza a un gruppo SRLG, ecc.).
Attributi associati ai prefissi IP: contengono informazioni su vari tipi di flag (es. bit up/down IS-IS, bit P OSPF, ecc.), tag IS-IS normali ed estese (vedi RFC 5130), metrica associata al prefisso, OSPF Forwarding Address, ecc. .

Anche qui, non riporto il formato dei vari attributi, perché di scarso interesse pratico. I più curiosi possono consultare il draft, dove tutto è descritto con dovizia di particolari.

Ora, dopo tutta questa poesia, è ora di passare a un po' di prosa. Sia Juniper, a partire dalla versione 14.2 del JUNOS, che Cisco, a partire dalla versione 5.1.1 dell'IOS-XR, implementano BGP-LS.

Ho fatto una prova di laboratorio con la topologia della figura seguente. In realtà al momento ho sostituito il controller con un router, ma per il futuro stiamo lavorando per sostituire il router con un controller OpenDaylight o ONOS, entrambi supportano BGP-LS.

Secondo quanto descritto nelle sezioni precedenti, i BGP-LS NLRI sono in totale 4 (= n.ro dei nodi) + 10 (= 2*5 link) + 14 (= numero di prefissi). I 14 prefissi derivano dai /24 dei link punto-punto, più una interfaccia di loopback per ciascun nodo. Per arrivare a 14 si noti che R1 e R4 annunciano 3 prefissi, mentre R2 e R3 annunciano 4 prefissi ciascuno.

BGP-LS NELL'IOS-XR
L'IOS-XR Cisco installa le informazioni sulla topologia della rete e le informazioni aggiuntive del Traffic Engineering MPLS nel Traffic Engineering Database (TED), presente in ciascun nodo. Le informazioni contenute nel TED vengono quindi importate nel BGP-LS, e da qui esportate (via BGP-LS NLRI) verso il controller. Le informazioni sui nodi e sui link presenti nel TED, sono convertite in BGP-LS NLRI, che vengono annunciati al controller.

La prova è stata effettuata utilizzando il VIRL. Riporto di seguito solo le parti rilevanti della configurazione del router R4, in particolare le configurazioni di IS-IS e BGP-LS. I comandi perninenti a BGP-LS sono sottolineati. Le configurazioni negli altri router sono solo semplici configurazioni di IS-IS, senza alcun comando relativo all'implementazione di BGP-LS.

Configurazione IS-IS

RP/0/0/CPU0:R4#sh run router isis

Wed Apr 6 08:57:57.182 UTC

router isis REISS

is-type level-2-only

net 49.0001.0000.0000.0004.00

distribute bgp-ls level 2