Sommario

Introduzione

Reti stub e reti di transito

Reti Hub-and-Spoke e ODR.

Raggi con un singolo punto di uscita

raggi con più punti di uscita

Bilanciamento del carico o backup con un unico hub

Bilanciamento del carico o backup con più hub

ODR e altri protocolli di routing

ODR e EIGRP

ODR e OSPF

Reti stub point-to-point OSPF

Reti stub point-to-multipoint OSPF

Confronto tra ODR e RIPv2

Circuito RIPv2 over demand

Progettazione di rete su larga scala con ODR.

ODR con EIGRP in esecuzione sugli hub

Ridondanza e riepilogo

ODR con OSPF in esecuzione sugli hub

Ridondanza e riepilogo

ODR con reti point-to-point

ODR con reti point-to-multipoint

ODR e più fornitori

Problemi di crescita futura

Prestazioni

Regolazione dei timer per una convergenza più rapida

Router hub

Router Spoke

Filtra e riepiloga route ODR

Regolazione timer Telco

Prestazioni CPU

Miglioramenti

Informazioni correlate

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.

Informazioni correlate

- Pagina di supporto per il routing IP

- Supporto tecnico – Cisco Systems