Progettazione di reti di composizione per provider di servizi su larga scala con OSPF
Sommario
Introduzione
La progettazione di una rete di connessione è un'attività complessa per i provider di servizi Internet (ISP). Ogni ISP utilizza un metodo univoco per progettare le reti di connessione. Tuttavia, tutti gli ISP condividono le stesse aree di preoccupazione quando progettano reti di connessione, come indicato di seguito:
-
In che modo le route del pool devono essere propagate nel core dell'ISP?
-
Quale protocollo di routing deve essere utilizzato per trasportare questi percorsi nel core?
-
Riepilogare le route di accesso remoto prima di inviarle nel core?
-
Quali elementi devono essere presi in considerazione al momento della distribuzione dei pool?
-
Cosa succede se i pool sono statici?
Questo documento affronta la maggior parte delle domande precedenti e tratta le procedure di progettazione relative all'utilizzo di IGP (Interior Gateway Protocol) Open Shortest Path First (OSPF) in un ambiente di connessione ISP. OSPF viene spesso utilizzato nella rete principale degli ISP. In questo documento, si evita di introdurre un protocollo separato per il trasporto delle route del pool di connessioni: viene utilizzato OSPF per propagare le route del pool di connessioni nel core.
Topologia della rete
La topologia mostrata di seguito è una topologia di rete di connessione ISP tipica. Gli ISP che forniscono servizi di connessione remota dispongono in genere di una serie di server di accesso alla rete (NAS, Network Access Server), generalmente AS5300 o AS5800. I server sono responsabili della fornitura dell'indirizzo IP a tutti gli utenti che si connettono all'ISP e desiderano utilizzare i servizi Internet. I server NAS vengono quindi collegati a un dispositivo di aggregazione, in genere un router Cisco 6500. Il router 6500 propaga le route di accesso remoto nel core, consentendo ai router principali di fornire servizi Internet agli utenti finali. La Figura 1 mostra un tipico scenario di punto di presenza (POP).
Figura 1 - Uno scenario POP tipico 
Pool di connessioni remote ISP
Un ISP in genere gestisce due tipi di indirizzi IP del pool:
-
Statico
-
Centrale
Pool statico
Con i pool statici, gli ISP dispongono di un insieme specifico di indirizzi IP dedicati a ciascun server NAS. Un utente che incontra un NAS riceve uno degli indirizzi IP dedicati dal pool. Ad esempio, se l'intervallo di indirizzi del pool statico NAS1 è 192.168.0.0/22, saranno presenti circa 1023 indirizzi IP. Un utente che incontra NAS1 riceve uno degli indirizzi compresi nell'intervallo da 192.168.0.0 a 192.168.3.254.
Pool centrale
Con i pool centrali, gli ISP dispongono di una gamma più ampia di indirizzi IP distribuiti su tutti i NAS in un unico POP. Un utente che rileva un NAS riceve un indirizzo IP dal pool centrale, che è un intervallo molto ampio. Ad esempio, se l'intervallo di indirizzi del pool centrale è 192.168.0.0/18 e questi sono distribuiti tra 14 server NAS, saranno presenti circa 14000 indirizzi IP.
Progettazione dialup con pool statico
I pool statici sono più facili da gestire dal punto di vista del routing. Quando si definisce un pool statico su un server NAS, il pool deve essere propagato al core ai fini del routing.
Utilizzare i seguenti metodi per propagare le route di accesso remoto da un server NAS:
-
Creare una route statica all'intervallo di indirizzi IP del pool, che punti a 0 null, con l'indirizzo del pool ridistribuito sul server NAS.
-
Assegnare l'indirizzo IP del pool su un loopback, su NAS con tipo di rete point-to-point OSPF, incluso il loopback in un'area OSPF.
-
Configurare un percorso statico su un router di confine area (ABR) per l'indirizzo IP del pool che punti verso ASBR (NAS autonomo system boundary router). Questo è il metodo preferito in quanto è possibile eseguire il riepilogo in ABR.
Crea una route statica all'intervallo di indirizzi del pool che punta a null 0
Se si utilizza questo metodo, è necessario creare una route statica per ogni NAS. La route statica deve coprire l'esatto indirizzo dell'intervallo di pool statico che punta a 0 null. Ad esempio, se l'indirizzo del pool statico è 192.168.0.0/22, la configurazione della route statica su NAS è:
NAS1(config)# ip route 192.168.0.0 255.255.252.0 null0 NAS1(config)# router ospf 1 NAS1(config-router)# redistribute static subnets NAS1(config-router)# end
L'indirizzo del pool viene ridistribuito in OSPF, che propaga queste informazioni nel core nel formato LSA (Link State Advertising) esterno di tipo 5.
Assegnare l'indirizzo del pool su un loopback su un NAS con tipo di rete point-to-point OSPF
Se si utilizza questo metodo, non è necessaria alcuna route statica. L'indirizzo del pool viene assegnato come subnet in un'interfaccia di loopback. Il tipo di rete predefinito sull'interfaccia di loopback è LOOPBACK, che, secondo la RFC 2328 
, deve essere pubblicizzato in OSPF come /32. Per questo motivo è necessario modificare il tipo di rete sul loopback in point-to-point. Il tipo di rete point-to-point forza OSPF ad annunciare l'indirizzo di subnet del loopback, che in questo caso è 192.168.0.0/22. Di seguito è riportata la configurazione:
NAS1(config)# interface loopback 1 NAS1(config-if)# ip addreess 192.168.0.1 255.255.252.0 NAS1(config-if)# ip ospf network-type point-to-point NAS1(config-if)# router ospf 1 NAS1(config-router)# network 192.168.0.0 0.0.3.255 area 1 NAS1(config-router)# end
Questa configurazione crea un collegamento di stub del router nella LSA del router e viene propagata come route OSPF interna anziché come route OSPF esterna.
Configurare il percorso statico sull'ABR per l'indirizzo del pool, puntando al server NAS (ASBR)
Se si utilizza questo metodo, non è necessario eseguire alcuna configurazione su un server NAS. Tutta la configurazione avviene sul dispositivo di aggregazione o ABR. I pool di indirizzi sono statici. Pertanto, il percorso statico viene generato facilmente e il router può puntare l'hop successivo verso il rispettivo NAS, il router ASBR (Autonomal System Boundary Router). Queste route statiche devono essere ridistribuite in OSPF tramite le subnet statiche di ridistribuzione in OSPF. Ad esempio:
ABR(config)# ip route 192.168.0.0 255.255.252.0
Questo è il metodo preferito in quanto il riepilogo può essere eseguito sulla funzione ABR. Il riepilogo può essere eseguito anche nei primi due metodi, ma le configurazioni di riepilogo sono necessarie su ogni NAS rispetto a questo metodo, dove una configurazione di riepilogo è necessaria solo su questo router.
Se i pool statici si trovano nel blocco contiguo, è possibile eseguire il riepilogo su ABR perché tutte le route statiche si trovano su ABR. Ad esempio:
ABR(config)# router ospf 1 ABR(config-router)# summary-address 192.168.0.0 255.255.192.0 ABR(config-router)# end
Progettazione dialup con assegnazione IP dinamico da un pool di indirizzi centrale
Per questa progettazione della connessione remota, si supponga che il pool di indirizzi IP centrale sia configurato nel server RADIUS (Remote Authentication Dial-In User Service). Ogni POP dispone di un numero DNIS (Number Information Service) composto e il server RADIUS dispone di pool di indirizzi IP separati per ogni DNIS. Inoltre, tutti i NAS che terminano le chiamate per un DNIS si trovano nella stessa area e parlano con lo stesso router di aggregazione.
I pool di indirizzi IP centrali comportano una certa complessità nella progettazione dei protocolli di routing. Quando si compone un numero DNIS per un POP, non vi è alcuna garanzia sul server NAS a cui ci si connette e sull'indirizzo IP che verrà assegnato dal pool di indirizzi IP centrale per tale server DNIS. Di conseguenza, la creazione di un riepilogo su ciascun server NAS non è possibile per gli indirizzi assegnati all'esterno del pool DNIS. La subnet connessa ridistribuita è necessaria in ogni NAS in modo da poter propagare tutte le informazioni all'ABR o al dispositivo di aggregazione. Questo progetto presenta un problema, in quanto le LSA esterne possono essere riepilogate solo sull'ASBR e, in questo progetto, le ASBR sono i server NAS, in che modo l'ABR eseguirà il riepilogo delle route esterne provenienti dai NAS?
Per risolvere questo problema di progettazione, Cisco consiglia di configurare l'area a cui appartengono i server NAS in un'area di stubby diversa (NSSA) (vedere la Figura 2):
Figura 2 - Configurazione in un'area di stubby inferiore 
Per ulteriori informazioni sugli NSSA OSPF, fare riferimento a OSPF Not-So-Stubby Area (NSSA).
Di seguito sono riportati i vantaggi se si definisce un'area come NSSA:
-
Tutti i percorsi NAS possono essere riepilogati in ABR in quanto ABR rigenera/converte il tipo 7 di LSA nel tipo 5 di LSA.
-
Ogni POP non conterrà route appartenenti a un altro POP perché NSSA non consente LSA esterni.
La configurazione di subnet ridistribuite e connesse è necessaria in tutti i sistemi NAS, in quanto i pool di indirizzi IP in tutti i sistemi NAS non sono statici: qualsiasi sistema NAS può trasportare qualsiasi indirizzo IP all'interno dell'intervallo di indirizzi IP centrale.
NAS1(config)# router ospf 1 NAS1(config-router)# redistribute connected subnets NAS1(config-router)# end
Se si esegue questa configurazione su tutti i NAS, viene eseguita una configurazione di riepilogo sull'ABR perché tutti gli LSA di tipo 7 vengono rigenerati sull'ABR e convertiti in LSA di tipo 5. Poiché ABR genera un LSA di tipo 5 completamente nuovo e l'ID del router pubblicitario è l'ID del router ABR, ABR agisce come ASBR e consente di riepilogare le route che in precedenza erano LSA di tipo 7 (originate dai NAS).
ABR(config)# router ospf 1 ABR(config-router)# summary-address 192.168.0.0 255.255.192.0 ABR(config-router)# end
Si noti che l'area tra ABR e NAS è NSSA, che può essere configurata come segue:
ABR(config)# router ospf 1 ABR(config-router)# network 10.10.10.0 0.0.0.255 area 1 nssa ABR(config-router)# end
Problema di scalabilità dell'area
Se si dispone di molti server NAS in un'area e ogni server NAS ridistribuisce 1000 o più percorsi nell'area, la domanda si pone: quanti server NAS devono essere inclusi in ogni area? Se tutti i server NAS si trovano nella stessa area, quest'ultima può diventare instabile in quanto l'area deve trasportare 1000 o più route da tutti i server NAS. In questo esempio di 14 server NAS, è possibile ridistribuire potenzialmente 14.000 route, un numero enorme. Per aumentare la scalabilità dell'area, Cisco consiglia di dividere l'area in più sottoaree, in modo da garantire che ogni area non influisca sulle altre se si verifica una certa instabilità in un'area (vedere Figura 3):
Figura 3 - Divisione dell'area 
Per determinare il numero di server NAS da mantenere in un'area, è necessario verificare il numero di percorsi che ogni server NAS deve inserire. Tre server NAS in un'area possono essere sufficienti se ogni NAS inserisce 3000 o più route. Non collocare un numero troppo basso di server NAS in ciascuna area perché, se si dispone di un numero eccessivo di aree, è possibile che l'ABR venga sovraccaricato a causa della creazione di riepiloghi in ciascuna area. Tuttavia, è possibile risolvere questo problema se si rende tutte le aree completamente stubby NSSA, che non consente la ridistribuzione di alcuna route di riepilogo nell'area. Questa azione riduce la quantità di informazioni che ogni NAS trasporta in aggiunta alle proprie 1000 o più route e riduce il carico che l'ABR deve sostenere attraverso la ridistribuzione delle LSA di riepilogo in ogni area. Aggiungere la parola chiave no-summary sul tasto ABR per eseguire la configurazione, come mostrato di seguito:
ABR#(config)# router ospf 1 ABR#(config-router)# network 10.10.10.0 0.0.0.255 area 1 nssa no-summary ABR#(config-router)# end
Il collegamento tra ABR e i server NAS non deve necessariamente essere eseguito in ciascuna area, quindi ABR non deve creare riepiloghi in ciascuna area per questi percorsi collegati. Il principale vantaggio di NSSA è che tutte le 3000 o più rotte in una zona non perdono in altre zone poiché NSSA non porta LSA esterni. Quando l'ABR converte tutti gli LSA NSSA tipo 7 nell'area 0, non invia alcun LSA tipo 5 in altre aree a causa delle caratteristiche dell'NSA.
Conclusioni
La progettazione di una rete di connessione ISP può essere un'attività complessa, ma con alcune considerazioni può essere migliorata e fornire una soluzione più scalabile. L'integrazione di NSSA può essere efficace nella gestione della scalabilità in quanto consente una riduzione significativa della quantità di percorsi che ogni NAS deve portare rispetto a una situazione in cui NSSA non viene utilizzato. Il riepilogo consente inoltre di ridurre le dimensioni della tabella di routing, in particolare nel caso del pool di indirizzi IP centrali, poiché sui server NAS è necessario il comando di configurazione redistribute connected. L'assegnazione di blocchi di indirizzi IP contigui in ogni NAS è utile anche durante il riepilogo, in quanto ogni POP può essere riepilogato in un unico grande blocco e il core non deve avere un numero eccessivo di percorsi.
Feedback