Progettazione di reti stub su larga scala con ODR.
Sommario
Introduzione
L'ODR (On-Demand Routing) è un miglioramento del Cisco Discovery Protocol (CDP), un protocollo utilizzato per rilevare altri dispositivi Cisco su supporti broadcast o non broadcast. Con l'aiuto del CDP, è possibile trovare il tipo di dispositivo, l'indirizzo IP, la versione Cisco IOS® in esecuzione sul dispositivo adiacente Cisco, le funzionalità del dispositivo adiacente e così via. Nel software Cisco IOS versione 11.2, l'ODR è stato aggiunto al CDP per annunciare il prefisso IP connesso di un router stub tramite CDP. Questa funzione richiede cinque byte aggiuntivi per ciascuna rete o subnet, quattro byte per l'indirizzo IP e un byte per annunciare la subnet mask insieme all'IP. ODR può trasportare le informazioni VLSM (Variable Length Subnet Mask).
ODR è stato progettato per i clienti aziendali al dettaglio che non desiderano utilizzare la larghezza di banda della rete per il routing degli aggiornamenti del protocollo. In un ambiente X.25, ad esempio, spesso è molto costoso eseguire un protocollo di routing su quel collegamento. Il routing statico è una buona scelta, ma il sovraccarico è eccessivo per la gestione manuale delle route statiche. ODR non richiede un utilizzo intensivo della CPU e viene utilizzato per propagare dinamicamente le route IP sul layer 2.
ODR non è un protocollo di routing e non deve essere considerato come tale durante la configurazione. Le configurazioni tradizionali per diversi protocolli di routing IP non funzioneranno in ODR, poiché ODR utilizza CDP sul layer 2. Per configurare ODR, utilizzare il comando router order sul router hub. La progettazione, l'implementazione e l'interazione di ODR con altri protocolli di routing IP può essere difficile.
ODR non può essere eseguito su router Cisco serie 700 o su collegamenti ATM, ad eccezione dell'emulazione LAN (LANE).
Reti stub e reti di transito
Quando nessuna informazione passa attraverso la rete, si tratta di una rete stub. La topologia hub e spoke è un buon esempio di rete stub. Questo tipo di topologia viene utilizzato dalle grandi organizzazioni con molti siti connessi a un centro dati.
I router di fascia bassa come Cisco serie 2500, 1600 e 1000 vengono utilizzati sul lato spoke. Se le informazioni passano attraverso i router spoke per raggiungere un'altra rete, quel router stub diventa un router di transito. Questa configurazione viene eseguita quando un spoke è collegato a un altro router diverso dal router hub.
Una preoccupazione comune riguarda la quantità di aggiornamenti ODR che può essere inviata da un spoke. In genere, i raggi sono collegati solo a un hub. Se gli spoke sono collegati ad altri router, non sono più stub e diventano una rete di transito. I sistemi di fascia bassa hanno in genere una o due interfacce LAN. Ad esempio, Cisco 2500 può supportare due interfacce LAN. In situazioni normali, viene inviato un pacchetto da 10 byte (nel caso vi siano due LAN sul lato spoke) come parte del CDP. Il CDP è abilitato per impostazione predefinita, quindi non vi è alcun problema di sovraccarico. Non ci sarà mai una situazione in cui vi sia un grande aggiornamento ODR. La dimensione degli aggiornamenti ODR non costituisce un problema in un ambiente hub e spoke vero e proprio.
Reti Hub-and-Spoke e ODR.
Una rete hub e spoke è una rete tipica in cui un hub (router di fascia alta) serve molti spoke (router di fascia bassa). In casi speciali, è possibile che vi sia più di un hub, sia a scopo di ridondanza che per supportare ulteriori raggi tramite un hub separato. In questo caso, abilitare ODR su entrambi gli hub. È inoltre necessario disporre di un protocollo di routing per lo scambio di informazioni di routing ODR tra i due hub.
Figura 1: Topologia hub e spoke 
Raggi con un singolo punto di uscita
Nella figura 1, i raggi sono collegati a un hub in modo da poter utilizzare il gateway predefinito anziché ricevere tutte le informazioni di routing per l'hub con un punto di uscita. Non è necessario trasmettere tutte le informazioni agli spoke, in quanto uno spoke non deve prendere una decisione intelligente riguardo al routing. Un spoke invia sempre il traffico all'hub, quindi i spoke necessitano solo di un percorso predefinito che punti verso un hub.
È necessario che sia disponibile un modo per inviare le informazioni della subnet del spoke all'hub. Prima di Cisco IOS 11.2, l'unico modo per ottenere questo risultato era abilitare un protocollo di routing allo spoke. Utilizzando ODR, tuttavia, non è necessario abilitare i protocolli di routing sul lato spoke. Con ODR, solo Cisco IOS 11.2 e un percorso statico predefinito che punta a un hub sono necessari sullo spoke.
raggi con più punti di uscita
Un spoke può avere più connessioni all'hub a scopo di ridondanza o backup nel caso in cui il collegamento primario si interrompa. Per questa ridondanza è spesso necessario un hub separato. In questo caso, i raggi hanno più punti di uscita. ODR funziona bene anche in questa rete.
Gli spoke devono essere point-to-point, altrimenti la route statica mobile predefinita non funzionerà. In una configurazione multipunto, non è possibile rilevare un guasto dell'hop successivo, come nel caso dei supporti di broadcast.
Bilanciamento del carico o backup con un unico hub
Per ottenere il bilanciamento del carico, definite due route statiche predefinite sui raggi con la stessa distanza e il raggio eseguirà il bilanciamento del carico tra i due percorsi. Se esistono due percorsi alla destinazione, ODR manterrà entrambi i percorsi nella tabella di routing e eseguirà il bilanciamento del carico sull'hub.
Per i backup, definire due route statiche predefinite con una distanza di una migliore rispetto all'altra. Il spoke utilizzerà il collegamento primario e, quando il collegamento primario diventa inattivo, la route statica mobile funzionerà. Nel router hub, utilizzare il comando distance per ciascun indirizzo adiacente CDP e specificare una distanza migliore dell'altra. Con questa configurazione, le route ODR apprese tramite un collegamento verranno preferite rispetto all'altro. Questa configurazione è utile in un ambiente in cui sono presenti collegamenti primari veloci e collegamenti di backup lenti (con larghezza di banda ridotta) e in cui non si desidera il bilanciamento del carico.
Nota: oggi, non esiste un altro metodo sul lato spoke per preferire un collegamento all'altro in una situazione hub singola, ad eccezione di quanto descritto sopra. Se si utilizza IOS 12.0.5T o versione successiva, l'hub invia automaticamente il percorso predefinito tramite entrambi i collegamenti e lo spoke non riesce a distinguere tra i due percorsi e li installa nella relativa tabella di routing. L'unico modo per preferire una route predefinita rispetto all'altra consiste nell'utilizzare una route statica predefinita sul spoke con un percorso con una distanza amministrativa inferiore per cui si desidera preferire. In questo modo vengono automaticamente ignorati i percorsi predefiniti in arrivo sugli spoke tramite ODR. Al momento, si sta valutando l'idea di fornire al raggio una manopola, dove possa preferire un collegamento rispetto all'altro.
Figura 2: Raggi con più punti di uscita e un singolo hub 
Bilanciamento del carico o backup con più hub
Queste configurazioni possono essere utilizzate anche per il bilanciamento del carico o per i backup in presenza di più hub. Tutti gli hub devono essere dotati di mesh completa in modo che se uno dei collegamenti dello spoke ha esito negativo, la destinazione possa comunque essere raggiunta attraverso un secondo hub. Per una spiegazione più dettagliata, vedere la sezione ODR rispetto ad altri protocolli di routing di questo documento. Analogamente, nel caso di più hub, se si utilizza IOS 12.0.5T o versione successiva, gli hub inviano i percorsi predefiniti ODR agli spoke e gli spoke vengono installati nella tabella di routing. Un miglioramento futuro consentirà a un raggio di preferire un hub all'altro. Attualmente, è possibile eseguire questa operazione tramite una route statica predefinita definita sul router dello spoke e usare la distanza di amministrazione nel comando route statica per preferire un hub all'altro. Ciò non influisce sulle situazioni di bilanciamento del carico.
Figura 3: Raggi con più punti di uscita e più hub 
ODR e altri protocolli di routing
Il maggiore vantaggio di ODR sul routing IP è che il router hub apprenderà i prefissi IP senza abilitare i protocolli di routing sul layer 3. Gli aggiornamenti ODR fanno parte di CDP sul layer 2.
ODR e EIGRP
In un ambiente hub e spoke reale, non è necessario passare tutte le informazioni di routing a tutti i spoke. Il collegamento lento comporta uno spreco della larghezza di banda negli aggiornamenti del routing e nella gestione delle relazioni con i router adiacenti. Abilitando il protocollo EIGRP (Enhanced Interior Gateway Routing Protocol) sugli spoke, gli aggiornamenti del routing vengono inviati agli spoke. Nelle reti di grandi dimensioni, questi aggiornamenti diventano enormi, sprecano la larghezza di banda della CPU e possono richiedere più memoria sui router spoke.
Un approccio migliore con l'EIGRP consiste nell'applicare filtri all'hub. Le informazioni di routing vengono controllate in modo che gli hub inviino dinamicamente ai raggi solo una route predefinita. Questi filtri consentono di ridurre le dimensioni della tabella di routing sul lato spoke, ma se l'hub perde un router adiacente, invierà query a tutti gli altri router adiacenti. Queste query non sono necessarie perché l'hub non riceverà mai una risposta da un router adiacente.
L'approccio migliore consiste nell'eliminare il sovraccarico delle query EIGRP e della manutenzione dei router adiacenti tramite ODR. Regolando i timer ODR, è possibile aumentare il tempo di convergenza.
Oggi, abbiamo una nuova caratteristica in EIGRP che scala EIGRP molto meglio in una situazione hub e spoke. Per ulteriori informazioni sulla funzione stub EIGRP, fare riferimento a Enhanced IGRP Stub Routing.
ODR e OSPF
Open Shortest Path First (OSPF) offre diverse opzioni per gli ambienti hub e spoke e l'opzione stub no-summary ha il minore sovraccarico.
È possibile che si verifichino problemi durante l'esecuzione di OSPF su reti hub e spoke su larga scala. Gli esempi in questa sezione utilizzano Frame Relay perché è la topologia hub e spoke più comune.
Reti stub point-to-point OSPF
In questo esempio, OSPF è abilitato su 100 spoke connessi da una configurazione point-to-point. Innanzitutto, gli indirizzi IP sprecati sono numerosi, anche se si utilizza una subnet mask /30. In secondo luogo, se si includono questi 100 raggi in un'area e uno dei raggi è lampeggiato, verrà eseguito l'algoritmo SPF (Shortest Path First) che può diventare ad uso intensivo della CPU. Questa situazione è particolarmente vera per i router spoke se il collegamento lampeggia costantemente. L'uso di più lembi dei router adiacenti può causare problemi ai router spoke.
In OSPF, l'area è lo stub e non l'interfaccia. Se in una rete stub sono presenti 100 router, è necessaria più memoria sugli spoke per contenere il database di grandi dimensioni. Questo problema può essere risolto dividendo una grande area di stub in piccole aree. Tuttavia, un lembo in un'area di stub attiverà l'SPF per l'esecuzione sui raggi, quindi questo sovraccarico non può essere curato creando una piccola area di stub senza riassunto e senza componenti esterni.
Un'altra opzione consiste nell'includere ogni collegamento in un'area. Con questa opzione, il router hub dovrà eseguire un algoritmo SPF separato per ciascuna area e creare un messaggio pubblicitario di stato del collegamento (LSA) di riepilogo per le route nell'area. Questa opzione può ridurre le prestazioni del router hub.
Il passaggio a una piattaforma migliore non è una soluzione permanente; tuttavia, ODR fornisce una soluzione. Le route apprese tramite ODR possono essere ridistribuite in OSPF per informare altri router hub su tali route.
Reti stub point-to-multipoint OSPF
Nelle reti point-to-multipoint, lo spazio degli indirizzi IP viene salvato inserendo ogni spoke nella stessa subnet. Inoltre, le dimensioni dell'hub LSA del router generato verranno dimezzate, in quanto verrà generato un solo collegamento di stub per tutti i collegamenti point-to-point. Una rete point-to-multipoint forzerà l'inclusione dell'intera subnet in un'unica area. In caso di link flap, lo spoke esegue SPF, che può richiedere un uso intensivo della CPU.
La tempesta Hello
I pacchetti hello OSPF sono piccoli, ma se ci sono troppi vicini, le loro dimensioni possono diventare grandi. Poiché gli hop sono multicast, il router elabora i pacchetti. L'hub OSPF invia e riceve pacchetti hello composti da 20 byte di intestazione IP, 24 byte di intestazione OSPF, 20 byte di parametri hello e 4 byte per ogni router adiacente visualizzato. Un pacchetto hello OSPF proveniente da un hub in una rete point-to-multipoint con 100 router adiacenti può diventare lungo 464 byte e verrà inviato a tutti i spoke ogni 30 secondi.
Tabella 1. Pacchetto Hello OSPF per 100 router adiacenti| 20 byte - intestazione IP |
| 24 byte - intestazione OSPF |
| Parametri hello da 20 byte |
| 4 byte per ogni ID router adiacente (RID) |
| . . . |
| . . . |
| . . . |
| . . . |
| . . . |
Il sovraccarico viene risolto in ODR perché non viene inviata alcuna informazione aggiuntiva dall'hub ai raggi. Gli spoke inviano il prefisso IP di 5 byte per subnet al router hub. Considerando le dimensioni del pacchetto hello, confrontare i 5 byte in ODR (le informazioni di invio spoke di una subnet connessa) con i 68 byte di OSPF (le dimensioni del pacchetto hello più piccole che includono un'intestazione IP inviata dall'hub spoke all'hub) più 68 byte (il pacchetto hello più piccolo inviato dall'hub allo spoke) durante un intervallo di 30 secondi. Inoltre, gli hellop OSPF si verificano sul layer 3 mentre gli aggiornamenti ODR si verificano sul layer 2. Con ODR, vengono inviate meno informazioni, quindi la larghezza di banda del collegamento può essere utilizzata per i dati importanti.
Confronto tra ODR e RIPv2
Il protocollo RIPv2 (Routing Information Protocol versione 2) è inoltre una buona scelta per ambienti hub e spoke. Per progettare RIPv2, inviare il percorso predefinito dall'hub ai raggi. I raggi quindi annunciano l'interfaccia connessa tramite RIP. RIPv2 può essere utilizzato quando vi sono indirizzi secondari sugli spoke che devono essere pubblicizzati, se vengono utilizzati router di diversi fornitori o se la situazione non è realmente un hub e spoke.
Circuito RIPv2 over demand
La versione 2 presenta alcune modifiche, ma non modifica il protocollo in modo drastico. In questa sezione vengono illustrati alcuni miglioramenti apportati a RIP per i circuiti di richiesta.
Le attuali reti interconnesse si stanno muovendo nella direzione delle reti di connessione remota o dei backup dei siti primari per fornire connessioni a un gran numero di siti remoti. Questi tipi di connessione possono passare un traffico di dati molto ridotto o nullo durante il normale funzionamento.
Il comportamento periodico di RIP causa problemi su questi circuiti. RIP presenta problemi relativi alla larghezza di banda ridotta e alle interfacce point-to-point. Gli aggiornamenti vengono inviati ogni 30 secondi con tabelle di routing di grandi dimensioni che utilizzano una larghezza di banda elevata. In questa situazione, è preferibile utilizzare il RIP attivato.
RIP attivato
Il protocollo RIP attivato è progettato per i router che scambiano tutte le informazioni di routing con i router adiacenti. Se vengono apportate modifiche al routing, solo le modifiche vengono propagate al router adiacente. Il router ricevente applica le modifiche immediatamente.
Gli aggiornamenti RIP attivati vengono inviati solo quando:
-
Ricevuta richiesta di aggiornamento del routing.
-
Vengono ricevute nuove informazioni.
-
La destinazione è cambiata da circuito in circuito in circuito in su.
-
Il router viene acceso per primo.
Di seguito è riportato un esempio di configurazione per RIP attivato:
Spoke# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Spoke(config)# int s0.1
Spoke(config-if)# ip rip triggered
Spoke(config)# int s0.2
Spoke(config-if)# ip rip triggered
interface serial 0
encapsulation frame-relay
interface serial 0.1 point /* Primary PVC */
ip address 10.x.x.x 255.255.255.0
ip rip triggered
frame-relay interface-dlci XX
interface serial 0.2 point /* Secondary PVC */
ip address 10.y.y.y 255.255.255.0
ip rip triggered
frame-relay interface-dlci XX
router rip
network 10.0.0.0
Spoke# show ip protocol
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0 1 1 2
Serial0.1 1 1 2 Yes
Serial0.2 1 1 2 Yes
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
il comando ip rip triggered deve essere configurato sull'interfaccia del router hub che si connette allo spoke.
Quando si confronta RIPv2 con ODR, ODR è una scelta migliore perché RIPv2 funziona sul layer 3 e ODR si verifica sul layer 2. Quando l'hub invia aggiornamenti RIPv2 a più di 1000 spoke, deve replicare il pacchetto sul layer 3 per ogni spoke. ODR non invia alcun messaggio dall'hub ad eccezione del consueto aggiornamento CDP ogni minuto sul layer 2, che non richiede un utilizzo intensivo della CPU. L'invio di informazioni sulla subnet connessa nel layer 2 dallo spoke richiede un utilizzo della CPU molto inferiore rispetto all'invio di RIPv2 sul layer 3.
Progettazione di rete su larga scala con ODR.
In una rete su larga scala, ODR funziona meglio di qualsiasi altro protocollo di routing. Il principale vantaggio di ODR è che non è necessario abilitare i protocolli di routing sui collegamenti seriali collegati. Al momento, non sono disponibili protocolli di routing in grado di inviare informazioni di routing senza abilitarli sull'interfaccia connessa.
ODR con EIGRP in esecuzione sugli hub
Quando si esegue EIGRP, stabilire una connessione di interfaccia passiva alla rete hub e spoke in modo che non invii gli hellop EIGRP non necessari sul collegamento. Se possibile, è meglio non inserire istruzioni di rete per le reti tra l'hub e gli spoke perché, se il collegamento si interrompe, EIGRP non invierà query non necessarie ai core neighbors. Scegliere sempre una rete fittizia tra l'hub e gli spoke in modo che tali collegamenti non vengano inclusi nel dominio EIGRP perché non si inseriscono istruzioni di rete nelle configurazioni.
Ridondanza e riepilogo
In una situazione di hub singolo, non sono necessarie impostazioni aggiuntive. Riepilogate le sottoreti specifiche e connesse dei raggi e rilasciatele nel nucleo. I costi generali delle query, tuttavia, saranno sempre presenti. Se si perdono percorsi specifici da uno dei spoke, inviare le query a tutti i router adiacenti nei router principali.
In caso di hub multipli, è molto importante che entrambi gli hub siano connessi e che l'EIGRP sia in esecuzione tra gli hub. Se possibile, questo collegamento deve essere una rete principale unica in modo che non interferisca con altri collegamenti che vanno ai raggi. Questa configurazione è necessaria perché l'EIGRP non può essere abilitato su un'interfaccia specifica, quindi anche se rendiamo l'interfaccia passiva, verrà comunque pubblicizzata tramite l'EIGRP. Se l'interfaccia viene riepilogata, le query verranno comunque inviate in caso di perdita di un spoke. La configurazione deve funzionare correttamente purché il collegamento tra i due hub non si trovi nella stessa rete principale dello spoke.
Figura 4: Ridondanza e riepilogo: Il core riceve un riepilogo dei percorsi 
Un vantaggio dell'EIGRP è che può riepilogare a livello di interfaccia, quindi il percorso riepilogato delle subnet spoke verrà inviato al core e invierà un percorso più specifico all'altro hub. Se il collegamento tra un hub e uno spoke si interrompe, è possibile raggiungere la destinazione tramite il secondo hub.
ODR con OSPF in esecuzione sugli hub
In questo scenario, non è necessario abilitare OSPF sul collegamento che collega gli spoke. In uno scenario normale, se OSPF è abilitato sul collegamento e un collegamento specifico lampeggia costantemente, possono verificarsi diversi problemi, tra cui l'esecuzione di SPF, la rigenerazione LSA del router, la rigenerazione LSA di riepilogo e così via. Quando si esegue ODR, non includere il collegamento seriale connesso nel dominio OSPF. La preoccupazione principale è quella di ricevere le informazioni sul segmento LAN degli spoke. Queste informazioni possono essere ottenute tramite ODR. Se un collegamento lampeggia continuamente, non interferirà con il protocollo di routing nel router hub.
Ridondanza e riepilogo
Tutti i collegamenti specifici possono essere riepilogati prima di penetrare nel core per evitare il calcolo del percorso se una delle interfacce connesse di uno spoke si guasta. Non è possibile rilevarlo se le informazioni principali sul router sono riepilogate.
Figura 5: Ridondanza e riepilogo: Il router principale riceve il riepilogo dei percorsi 
In questo esempio, è molto importante che gli hub siano collegati tra loro per scopi di ridondanza. Questa connessione riepiloga anche le subnet connesse a spoke prima di penetrare nel core OSPF.
NSSA con miglioramenti futuri
Alla fine ci sarà una funzione OSPF Not-So-Stubby Areas (NSSA) che permetterà non solo di riepilogare nel core, ma anche informazioni più specifiche attraverso l'hub attraverso il collegamento NSSA. Il vantaggio dell'esecuzione di NSSA è che le route riepilogate possono essere inviate nel core. Quindi, il core può inviare il traffico a entrambi gli hub per raggiungere la destinazione dello spoke. Se il collegamento tra un hub e uno spoke si interrompe, in entrambi gli hub sarà presente un'LSA di tipo 7 più specifica per raggiungere la destinazione attraverso un altro hub.
Di seguito è riportato un esempio di configurazione che utilizza NSSA:
N2507: Hub 1
router odr
timers basic 8 24 0 1
!
router ospf 1
redistribute odr subnets
network 1.0.0.0 0.255.255.255 area 1
area 1 nssa
N2504: Hub 2
router odr
timers basic 8 24 0 1
!
router ospf 1
redistribute odr subnets
network 1.0.0.0 0.255.255.255 area 1
area 1 nssa
N2507# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Ethernet0
o 150.0.0.0/16 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
o 200.1.1.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
o 200.1.2.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
N2504# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.4.0 is directly connected, TokenRing0
C 5.0.0.0/8 is directly connected, Loopback0
C 6.0.0.0/8 is directly connected, Loopback1
O N2 150.0.0.0/16 [110/20] via 1.0.0.1, 00:12:06, Serial0
O N2 200.1.1.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0
O N2 200.1.2.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0
Riepilogo e miglioramenti futuri con NSSA
Assegnare un blocco contiguo di subnet ai raggi in modo che tali subnet possano essere riepilogate correttamente nel nucleo OSPF, come illustrato nell'esempio seguente. Se le subnet non vengono riepilogate e una subnet connessa si blocca, l'intero core la rileverà e ricalcolerà le route. Inviando la route di riepilogo per un blocco contiguo, se la subnet spoke si flap, il core non la rileverà.
N2504# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
N2504(config)# router ospf 1
N2504(config-router)# summary-address 200.1.0.0 255.255.0.0
N2504# show ip ospf database external
OSPF Router with ID (6.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 1111
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 200.1.0.0 (External Network Number )
Advertising Router: 6.0.0.1
LS Seq Number: 80000001
Checksum: 0x2143
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 127
Metric: 16777215
Forward Address: 0.0.0.0
External Route Tag: 0
Problema di distanza
In questo esempio vengono ricevute informazioni più specifiche da entrambi gli hub. Poiché la distanza OSPF è 110 e la distanza ODR è 160, le informazioni interferiranno con ODR quando vengono ricevute dall'altro hub sulla stessa subnet. L'altro hub sarà sempre preferito per raggiungere la destinazione spoke, causando un routing non ottimale. Per risolvere il problema, ridurre la distanza ODR a un valore inferiore a 110 con il comando distance, in modo che la route ODR venga sempre preferita alla route OSPF. Se la route ODR ha esito negativo, la route esterna OSPF verrà installata nella tabella di routing dal database.
N2504(config)# router odr
N2504(config-router)# distance 100
N2504(config-router)# end
N2504# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.4.0 is directly connected, TokenRing0
C 5.0.0.0/8 is directly connected, Loopback0
C 6.0.0.0/8 is directly connected, Loopback1
o 150.0.0.0/16 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
o 200.1.1.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
o 200.1.2.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
O 200.1.0.0/16 is a summary, 00:04:38, Null0
Le route N2 sono ancora presenti nel database e diventeranno attive se il collegamento hub principale allo spoke non è attivo.
N2504# show ip ospf database nssa
OSPF Router with ID (6.0.0.1) (Process ID 1)
Type-7 AS External Link States (Area 1)
LS age: 7
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 150.0.0.0 (External Network Number )
Advertising Router: 6.0.0.1
LS Seq Number: 80000002
Checksum: 0x965E
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.2
External Route Tag: 0
Con il miglioramento a NSSA, il tipo 7 più specifico LSA sarà nel database NSSA. Anziché una route riepilogata, l'output del database NSSA verrà visualizzato come illustrato di seguito:
LS age: 868
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 200.1.1.0 (External Network Number)
Advertising Router: 3.3.3.1
LS Seq Number: 80000001
Checksum: 0xDFE0
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.1
External Route Tag: 0
LS age: 9
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 200.1.2.0 (External Network Number)
Advertising Router: 3.3.3.1
LS Seq Number: 80000002
Checksum: 0xFDC3
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.2
External Route Tag: 0
Circuito a richiesta
Il circuito di richiesta è una funzione di Cisco IOS 11.2 che può essere utilizzata anche nelle reti hub e spoke. Questa funzione è in genere utile in scenari di backup dial e in ambienti X.25 o Frame Relay Switched Virtual Circuit (SVC). Di seguito è riportato un esempio di configurazione di un circuito a richiesta:
router ospf 1
network 1.1.1.0 0.0.0.255 area 1
area 1 stub no-summary
interface Serial0 /* Link to the hub router */
ip address 1.1.1.1 255.255.255.0
ip ospf demand-circuit
clockrate 56000
Spoke#show ip o int s0
Serial0 is up, line protocol is up
Internet Address 1.1.1.1/24, Area 1
Process ID 1, Router ID 141.108.4.2, Network Type POINT_TO_POINT, Cost: 64
Configured as demand circuit.
Run as demand circuit.
DoNotAge LSA not allowed (Number of DCbitless LSA is 1).
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 130.2.4.2
Suppress hello for 0 neighbor(s)
L'utilizzo della funzionalità del circuito a richiesta in una rete hub e spoke consente di attivare il circuito e creare nuove adiacenze in caso di modifiche nella topologia. Ad esempio, se in un raggio c'è una subnet che lampeggia, il circuito di domanda solleverà l'adiacenza e inonderà queste informazioni. In un ambiente di tipo stubby, queste informazioni verranno trasmesse in tutta l'area di stub. ODR risolve questo problema non perdendo queste informazioni agli altri raggi. Per ulteriori informazioni, fare riferimento alla funzione del circuito di richiesta OSPF.
ODR con reti point-to-point
Lo stato corrente di Cisco IOS 12.0 sui limiti IDB (Interface Descriptor Block) è il seguente:
| Router | Limite |
|---|---|
| 1000 | 300 |
| 2600 | 300 |
| 3600 | 800 |
| 4x00 | 300 |
| 5200 | 300 |
| 5300 | 700 |
| 5800 | 3000 |
| 7200 | 3000 |
| RSP | 1000 |
Prima di IOS 12.0, il numero massimo di spoke che un hub poteva supportare era 300 a causa dei limiti IDB. Se una rete richiedeva più di 300 spoke, la configurazione point-to-point non era una buona scelta. Inoltre, è stato generato un pacchetto CDP separato per ciascun collegamento. La complessità temporale per l'invio degli aggiornamenti CDP su collegamenti point-to-point è n2. La tabella precedente fornisce i limiti IDB per le diverse piattaforme. il numero massimo di spoke supportati su ciascuna piattaforma varia, ma il sovraccarico della creazione di un pacchetto CDP separato per ciascun collegamento è ancora un problema. Pertanto, in una situazione hub e spoke di grandi dimensioni, la configurazione di un'interfaccia point-to-multipoint è una soluzione migliore rispetto a un'interfaccia point-to-point.
ODR con reti point-to-multipoint
In una rete point-to-multipoint in cui un hub supporta più spoke, le problematiche principali sono tre:
-
L'hub è in grado di supportare con facilità più di 300 raggi. Ad esempio, una rete 10.10.0.0/22 potrebbe supportare i spoke 1024-2 con un'interfaccia multipunto.
-
In un ambiente multipunto, viene generato un pacchetto CDP per tutti i router adiacenti e viene replicato sul layer 2. La complessità dell'aggiornamento CDP si riduce a n.
-
In una configurazione point-to-multipoint è possibile assegnare solo una subnet a tutti i raggi.
ODR e più fornitori
Un errore comune è che ODR non funzionerà se si utilizzano più fornitori. ODR funziona se la rete è una vera rete hub e spoke. Ad esempio, se sono presenti 100 spoke e due di essi sono router di un fornitore diverso, è possibile abilitare un protocollo di routing sui collegamenti che si connettono a router diversi ed eseguire ancora l'ODR sui restanti 98 spoke Cisco.
Figura 6: ODR con più fornitori 
Il router hub connesso ai 98 router Cisco riceverà gli aggiornamenti della subnet tramite ODR e gli aggiornamenti del protocollo di routing dagli altri due router diversi. I collegamenti che si connettono ai diversi router devono trovarsi su subnet point-to-point o point-to-multipoint separate.
Problemi di crescita futura
Se un'organizzazione esegue ODR su 100 spoke, potrebbe essere opportuno modificare la propria topologia da una rete hub e spoke. Ad esempio, potrebbero decidere di aggiornare uno spoke a una piattaforma più grande, rendendolo un hub per altri 20 spoke nuovi.
Figura 7: Crescita futura 
È possibile eseguire un protocollo di routing sul nuovo hub e mantenere la struttura dell'ODR inalterata. Se il nuovo hub supporta 20 o più nuovi spoke, ODR può essere eseguito sul nuovo hub. Il nuovo hub può conoscere le nuove subnet spoke tramite ODR e ridistribuire queste informazioni all'hub originale tramite un altro protocollo di routing.
Questa situazione è simile quando ODR inizia con due hub. La modifica dei protocolli non comporta alcun sovraccarico. In pratica, l'ODR può essere eseguito finché il router è uno stub.
Prestazioni
È possibile regolare diverse impostazioni per una convergenza più rapida e prestazioni migliori durante l'esecuzione di ODR.
Regolazione dei timer per una convergenza più rapida
In un ambiente ODR di grandi dimensioni, regolare i timer ODR per una convergenza più rapida e aumentare i timer dell'aggiornamento CDP dall'hub al spoke per ridurre al minimo le prestazioni della CPU dell'hub.
Router hub
Il timer di aggiornamento del CDP deve essere impostato su 60 secondi per ridurre la quantità di traffico dall'hub agli spoke. Il tempo di attesa deve essere aumentato al massimo (255 secondi). Poiché il router hub deve mantenere troppe tabelle adiacenti CDP e nel caso in cui qualche router adiacente si guasti, non eliminare le voci CDP dalla memoria per 255 secondi (il tempo massimo di attesa consentito). Questa configurazione offre flessibilità al router hub perché se il router adiacente viene ripristinato entro quattro minuti, non sarà necessario ricreare l'adiacenza CDP. È possibile utilizzare la voce precedente della tabella e aggiornare il timer di controllo.
Di seguito è riportato un esempio di modello di configurazione IP per un router centrale:
cdp holdtime 255
router odr
timers basic 8 24 0 1 /* odr timer's are update, invalid, hold down, flush
router eigrp 1
network 10.0.0.0
redistribute odr
default-metric 1 1 1 1 1
Da ciascun sito remoto (magazzino, regione e deposito) sono disponibili tre PVC (Permanent Virtual Circuit). Due dei PVC vengono inviati a due router centrali distinti. Il terzo PVC viene inviato a un router PayPoint. È necessario che il PVC per la route di PayPoint venga utilizzato per il traffico destinato alla rete PayPoint. Gli altri due PVC servono funzioni primarie e di backup per tutto il resto del traffico. In base a questi requisiti, vedere il modello di configurazione seguente per ciascun router remoto.
È molto importante regolare i timer ODR come non validi, bloccati e scaricati per una convergenza più rapida. Anche se il CDP non invia un prefisso IP una volta configurato l'ordine del router, il timer di aggiornamento ODR deve corrispondere al timer di aggiornamento CDP del router adiacente, in quanto il timer di convergenza può essere impostato solo se è presente un timer di aggiornamento. Questo timer è diverso dal timer CDP e può essere utilizzato solo per una convergenza più rapida.
Router Spoke
Poiché gli spoke inviano aggiornamenti ODR in pacchetti CDP, il timer per gli aggiornamenti CDP dovrebbe essere ridotto per una convergenza più rapida. In un ambiente spoke vero, non ci sono restrizioni al tempo di attesa per il vicino CDP, dal momento che ci sono solo alcune voci che il spoke può tenere nella sua tabella CDP. Si consiglia un tempo di attesa massimo di 255 secondi, in modo che se il PVC dell'hub si blocca e ritorna entro quattro minuti, non è necessaria alcuna nuova adiacenza CDP, in quanto è possibile utilizzare la voce precedente della tabella.
Di seguito è riportato un esempio di modello di configurazione IP per un sito remoto:
cdp timer 8
cdp holdtime 255
interface serial 0
encapsulation frame-relay
cdp enable
interface serial 0.1 point /* Primary PVC */
ip address 10.x.x.x 255.255.255.0
frame-relay interface-dlci XX
interface serial 0.2 point /* Secondary PVC */
ip address 10.y.y.y 255.255.255.0
frame-relay interface-dlci XX
interface bri 0
interface BRI0
description Backup ISDN for frame-relay
ip address 10.c.d.e 255.255.255.0
encapsulation PPP
dialer idle-timeout 240
dialer wait-for-carrier-time 60
dialer map IP 10.x.x.x name ROUTER2 broadcast xxxxxxxxx
ppp authentication chap
dialer-group 1
isdn spid1 xxxxxxx
isdn spid2 xxxxxxx
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 LIST 101
/* following are the static routes that need to be configured on the remote routers
ip route 0.0.0.0 0.0.0.0 10.x.x.x
ip route 0.0.0.0 0.0.0.0 10.y.y.y
ip route 0.0.0.0 0.0.0.0 bri 0 100
ip classless
Le route statiche predefinite non sono necessarie se si utilizza IOS 12.0.5T o versioni successive, in quanto il router hub invia automaticamente la route predefinita a tutti i spoke.
Filtra e riepiloga route ODR
Le route ODR possono essere filtrate prima di essere filtrate nel core. Usare il comando distribute-list in. Tutte le subnet connesse dei raggi devono essere riepilogate quando si verificano perdite nel nucleo. Se il riepilogo non è possibile, è possibile filtrare le route non necessarie sul router hub. Nelle reti con più hub, gli spoke possono annunciare l'interfaccia connessa che è il collegamento a un altro hub.
In questo caso, è necessario applicare il comando distribute-list in modo che l'hub non inserisca tali route nella tabella di routing. Quando l'ODR viene ridistribuito nell'hub, tali informazioni non vengono trapelate nel core.
Regolazione timer Telco
È importante regolare il timer di telco per aumentare il tempo di convergenza dei raggi. Se il PVC dal lato dell'hub si abbassa, gli spoke dovrebbero essere in grado di rilevarlo rapidamente per passare al secondo hub.
Prestazioni CPU
Il processo ODR non richiede un utilizzo eccessivo della CPU. ODR è stato testato per circa 1000 vicini con un utilizzo della CPU del 3-4%. L'impostazione aggressiva del timer dell'ODR sull'hub consente una convergenza più rapida. Se si utilizzano le impostazioni predefinite, l'utilizzo della CPU rimane pari a zero o all'1%.
Anche con timer ODR e CDP aggressivi, l'output seguente mostra che non c'è stato un elevato utilizzo della CPU. Questo test è stato eseguito con un processore a 150 MHz su un Cisco 7206.
Hub# show proc cpu
CPU utilization for five seconds: 4%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588036 15783316 734 0.73% 1.74% 1.95% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588484 15783850 734 2.21% 1.83% 1.96% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588676 15784090 734 1.31% 1.79% 1.95% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 1%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588824 15784283 734 0.65% 1.76% 1.94% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11589004 15784473 734 1.96% 1.85% 1.95% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11589188 15784661 734 1.63% 1.83% 1.94% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Miglioramenti
La versione di ODR precedente a Cisco IOS 12.0.5T presentava alcune limitazioni. Di seguito sono elencati i miglioramenti apportati a Cisco IOS versione 12.0.5T e successive:
-
Prima di CSCdy48736, le subnet secondarie vengono pubblicizzate come /32 in un aggiornamento CDP. Questo è fissato nella versione 12.2.13T e successive.
-
Gli hub CDP propagano ora le route predefinite agli spoke, pertanto non è necessario aggiungere route statiche predefinite negli spoke. Il tempo di convergenza aumenta in modo significativo. Quando l'hop successivo scade, spoke lo rileva rapidamente tramite ODR e converge. Questa funzione è stata aggiunta nella versione 12.0.5T tramite il bug CSCdk91586.
-
Se il collegamento tra l'hub e lo spoke è IP senza numero, il percorso predefinito inviato dall'hub potrebbe non essere visualizzato in corrispondenza degli spoke. Il bug CSCdx6917 è stato risolto nella versione 12.2.14, 12.2.14T e successive di IOS.
-
Per aumentare/diminuire la distanza ODR sui raggi in modo che possano preferire un hub rispetto all'altro, è stato fatto un suggerimento che è stato tracciato via CSCdr35460. Il codice è già stato testato e sarà disponibile presto per i clienti.
Feedback