Questo documento offre linee guida pratiche per la progettazione della rete LANE (LAN Emulation). Queste linee guida vi assisteranno nella progettazione di reti LANE ad alte prestazioni, scalabili e ad alta disponibilità. Anche se questo documento si concentra sulle apparecchiature Cisco, gli stessi concetti possono essere applicati quando si integrano prodotti di terze parti.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
I lettori di questo documento devono essere a conoscenza delle operazioni di base e delle configurazioni delle reti LANE.
Questo documento è incentrato sulle configurazioni Ethernet LANE.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Di seguito vengono illustrati i vari server LANE e i relativi requisiti.
La specifica LAN Emulation Over ATM versione 1.0 richiede che ogni client di emulazione LAN (LEC) stabilisca un circuito virtuale (VC) nel server di configurazione dell'emulazione LAN (LECS) quando questo diventa attivo. Il LEC richiede quindi l'indirizzo ATM del server di emulazione LAN (LES) corrispondente. Una volta che il LEC ha il suo indirizzo ATM LES, il VC tra il LEC e il LECS viene rimosso, e il LEC non tenta più di comunicare con il LECS. Quando l'ambiente è stabile e tutti i LEC sono attivi e operativi, il LECS è inattivo.
Quando i LEC si uniscono alla LAN emulata (ELAN), ciascuno di essi contatta il LECS singolarmente. Tuttavia, quando la rete LANE subisce un guasto (ad esempio, quando la scheda LECS primaria non funziona), tutti i client si interrompono.
Nota: l'eccezione si verifica quando si utilizza il protocollo FSSRP (Fast Simple Server Redundancy Protocol).
Poiché tutti i LEC vengono interrotti contemporaneamente, tutti contatteranno il LECS di backup contemporaneamente. Pertanto, per l'hosting di LECS, è necessario un dispositivo che:
è in grado di gestire un improvviso aumento di traffico diretto a livello di processo.
può accettare contemporaneamente quasi tutte le impostazioni delle chiamate in arrivo dai LEC.
è nota per la sua stabilità. Se il LECS si interrompe, l'intera rete si interrompe (di nuovo, ad eccezione di FSSRP). Pertanto, non è consigliabile inserire il LECS su un dispositivo su cui è in esecuzione una versione software sperimentale.
Ciascun LEC mantiene una VC bidirezionale verso il LES della ELAN (può essere più di una ELAN se si utilizza FSSRP). In un ambiente con carico elevato, molte richieste LE_ARP (LAN Emulation Address Resolution Protocol) verranno inviate al sistema LES. L'implementazione di LES sui dispositivi Cisco è abbastanza semplice. Tutti i frame LE_ARP in ingresso verranno inoltrati al controllo Distribute Virtual Channel Connection (VCC).
Non è possibile implementare una semplice replica di celle hardware da control direct a control distribution poiché alcuni frame (come le richieste di join) devono essere analizzati dal processo LES. Pertanto, un dispositivo che può funzionare come un buon LES è un dispositivo che:
dispone di una CPU potente e può accettare molte impostazioni di chiamata in poco tempo. Ciò è necessario quando molti clienti si uniscono contemporaneamente all'ELAN, ma è meno importante che per la LECS, poiché solo i LEC nell'ELAN devono unirsi.
dispone di un forte supporto hardware per la segmentazione e il riassemblaggio (SAR). Poiché tutte le celle in ingresso devono essere ricomposte in frame, se un sacco di richieste di unione arrivano contemporaneamente, dovranno essere ricomposte molto rapidamente.
Tenere presente che nell'implementazione di Cisco, i processi LES e Broadcast e Unknown Server (BUS) sono combinati (ossia, non è possibile posizionare il LES per ELAN-1 su un dispositivo e il BUS per ELAN-1 su un altro dispositivo).
Un'altra cosa da tenere a mente è il possibile comportamento preventivo. Se è abilitata la prelazione, il servizio LES/BUS con la priorità più alta (secondo il database LANE) assumerà sempre la funzione primaria di LES/BUS. In altre parole, se il LES/BUS primario si guasta, tutti i LEC dell'ELAN si interromperanno e si riconnetteranno al LES/BUS di backup. Se è configurata la preemptività, nel caso in cui l'LES/BUS primario dovesse aumentare di nuovo, tutti i LEC si abbasseranno di nuovo e si riconnetteranno all'LES/BUS con la massima priorità. Nel software del modulo LANE versione 3.2.8 e successive e nel software Cisco IOS® versione 11.3(4) e successive, la funzione di preemptività può essere attivata e disattivata. La funzione di preemptività può essere configurata come descritto nella documentazione relativa alla configurazione dell'emulazione LAN.
Il lavoro del BUS è molto simile a quello del LES. Ogni LEC deve avere un multicast da inviare al BUS. Il LEC invia tutto il suo traffico multicast, broadcast o sconosciuto. Il BUS ha un VCC point-to-multipoint per tutti i LEC nell'ELAN. I frame non devono essere esaminati in dettaglio dal BUS. In altre parole, ogni frame in ingresso sull'invio multicast può essere inoltrato alla rete multicast.
Un buon dispositivo BUS:
dispone del supporto hardware per la copia del frame dal multicast in ingresso inviato al multicast in uscita in avanti. Se si dispone di hardware "intelligente", è possibile eseguire questa operazione di copia prima del riassemblaggio. Ciò significa che le celle in ingresso nell'invio multicast vengono inoltrate nell'inoltro multicast. In questo modo viene salvata una segmentazione e il riassemblaggio per fotogramma.
richiede una CPU potente se non è disponibile il supporto hardware per BUS.
deve essere in grado di elaborare contemporaneamente molte impostazioni di chiamata, ma con un limite inferiore rispetto al LECS.
Sul dispositivo bootflash o slot0: | Throughput BUS (Kpps) |
---|---|
Catalyst 6K LANE/MPOA Module (OC-12) | 600 |
Catalyst 5K LANE/MPOA Module (OC-12) | 600 |
Catalyst 5K LANE/MPOA Module (OC-3) | 166 |
Catalyst 5K LANE Module (OC-3) | 122 |
RSP4 - VIP-2-50+PA-A1 | 92 |
RSP4 - VIP-2-500+PA-A3 | 84 |
RSP4 - VIP-2-40+PA-A3 | 78 |
RSP4 - VIP-2-40+PA-A1 | 77 |
4700 | 40 |
LS1010 | 30 |
In questa sezione vengono descritte le funzionalità dei dispositivi Cisco più comuni utilizzati per eseguire LEC, LECS, LES e BUS. Questi dispositivi sono i moduli Cisco LANE, Lightstream 1010, Catalyst 8510MSR e 8540MSR e 7500/RSP. Le loro capacità vengono confrontate con i requisiti elencati sopra.
L'architettura di tutti i moduli LANE per Catalyst 5000 e 6000 si basa approssimativamente sulla seguente vista di alto livello:
La segmentazione e il riassemblaggio vengono eseguiti dall'hardware. Il chip SAR è in qualche modo intelligente e può inoltrare direttamente i fotogrammi riassemblati al bus di telaio del catalizzatore (il backplane del catalizzatore). Per i frame di controllo, il chip SAR può inoltrare i frame alla CPU del modulo LANE. Un frame di controllo è un frame che deve essere analizzato (ad esempio, ILMI (Interim Local Management Interface), segnalazione e frame destinati a LES), in arrivo al modulo LANE tramite un VC specificato.
Il chip SAR può anche reindirizzare le celle provenienti dal multicast inviandole al multicast forward (cioè, multicast, broadcast, e celle sconosciute provenienti dai LEC). Le celle non vengono ricomposte in cornici. La sua facilità di implementazione si traduce in ottime prestazioni del BUS.
Dopo aver creato un "data direct" e una voce nella tabella della memoria indirizzabile al contenuto (CAM), i frame riassemblati vengono inviati direttamente al frame BUS e contrassegnati con l'ID VLAN (Virtual LAN) corretto. Un modulo LANE è un ottimo LEC perché, una volta stabilito il "data direct", la CPU non è più coinvolta.
LS1010 e Catalyst 8510MSR non dispongono del supporto hardware per SAR. Di conseguenza, questi dispositivi non rappresentano una scelta adeguata per l'implementazione delle funzionalità LES/BUS. Tuttavia, sono adatte per il LECS (fare riferimento al modello di esempio 2 di seguito).
Lo switch 8540MSR supporta hardware per SAR. Dispone inoltre di un potente processore Risc 5000. 8540MSR non è consigliato per supportare LES/BUS per due motivi:
Le prestazioni del BUS sono di circa 50 Kpps per pacchetti da 64 byte, molto al di sotto di qualsiasi modulo LANE. Ciò è dovuto al fatto che non vi è alcuna accelerazione hardware per il BUS.
Se lo switch 8540MSR viene utilizzato con schede ATM ed Ethernet, la CPU può essere utilizzata principalmente per comunicare con schede di linea Ethernet. In questo caso, la CPU dell'8540MSR non deve essere utilizzata come LES.
Il router più comunemente utilizzato per il routing tra ELAN è la piattaforma Cisco 7500 (sono molto diffusi anche il Route Switch Module (RSM) e il Cisco 7200). L'adattatore della porta contiene il chip hardware SAR. i processori di switching/routing (RSP), come l'RSP4, hanno una potenza di CPU sufficiente per elaborare rapidamente i frame in ingresso; quindi, sono una buona scelta per il LES. Le prestazioni del BUS, tuttavia, sono inferiori a quelle dei moduli LANE.
LANE viene utilizzato principalmente nelle reti grandi e critiche. Di conseguenza, la ridondanza è obbligatoria. Il protocollo SSRP (Simple Server Redundancy Protocol) è il protocollo di ridondanza più utilizzato. Se il software è recente, FSSRP è il protocollo preferito (fare riferimento alla linea guida n. 11).
Supponiamo di avere una rete piuttosto grande, ad esempio 100 VLAN/ELAN e 100 catalizzatori, ciascuno con un modulo LANE a doppio uplink. Ciò significa che su ciascun modulo LANE potrebbe essere necessario un LEC per ELAN, in questo caso 10.000 LEC. Si presume inoltre che venga utilizzato l'indirizzo IP e che la progettazione includa una classe sicura C (254 indirizzi host IP, 254 indirizzi MAC) per VLAN.
In questo progetto, è stato scelto un modulo LANE per eseguire i 100 server LES/BUS. Allo stesso tempo, il LECS primario si trova sullo stesso modulo LANE. Come illustrato nel disegno seguente:
Quando si creano i LEC sul modulo LANE, tutti i LEC aumentano non appena vengono configurati. Durante il funzionamento, il processo LES potrebbe sovraccaricare e il modulo LANE potrebbe esaurire la memoria. La progettazione 2 descritta di seguito risolve entrambi i problemi.
Il problema principale di questa rete si verifica quando si verifica un problema grave. Si supponga che il modulo LANE che ospita la licenza LECS, LES o BUS non sia più raggiungibile. Ciò può verificarsi, ad esempio, se il modulo LANE di Catalyst 1 diventa difettoso. È possibile verificare che la ridondanza sia in corso, ma il tempo di ridondanza (ovvero il tempo che intercorre tra un guasto primario a LECS, LES o BUS e il riavvio dell'ultimo LEC) può durare fino a due ore! Una buona progettazione potrebbe ridurre questo numero a decine di secondi o a pochi minuti in reti di grandi dimensioni.
Il problema risiede nella segnalazione implicata con i LEC che si uniscono all'ELAN. Se il LECS deve essere contattato da ogni LEC, riceverà 10.000 impostazioni di chiamata (100 moduli LANE con 100 LEC ciascuno) quasi contemporaneamente. Il modulo LANE è progettato per collegare in modo efficiente il frame bus al collegamento di cella, ma non per gestire molte impostazioni di chiamata al secondo. La CPU del modulo LANE non è abbastanza potente per gestire questo volume di impostazioni di chiamata. L'output seguente mostra il tempo di ridondanza in una rete LANE con circa 1600 LEC (viene visualizzata solo una parte del comando show processes cpu):
ATM#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 98%; five minutes: 69% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process <snip> 7 13396 207 64714 16.55% 10.85% 3.77% 0 ATM ILMI Input 8 13600 188 72340 13.45% 10.54% 3.72% 0 ILMI Process <snip> 35 107892 553 195103 68.94% 55.34% 26.72% 0 ATMSIG Input 36 34408 1125 30584 12.29% 9.45% 6.63% 0 ATMSIG Output <snip>
Come si può vedere, il modulo LANE è sovrautilizzato a causa dell'attività di segnalazione in ingresso. Qual è la ragione delle due ore di ridondanza? La risposta sta nella nozione di timeout. Le specifiche di segnalazione indicano chiaramente che se il dispositivo non riceve un messaggio "connect" dopo un determinato periodo di tempo quando viene inviata una "call setup", deve ricominciare. Le specifiche LANE richiedono che il LEC torni al suo stato iniziale e ricominci da capo. Ciò significa che se un LEC è in grado di contattare il LECS e connettersi ad esso, la sua impostazione delle chiamate al LES potrebbe scadere, e torna allo stato iniziale di tentativo di contattare il LECS! Questo può accadere anche con le connessioni dal LES, e da/verso il BUS.
In base alle spiegazioni precedenti, di seguito sono riportate alcune raccomandazioni di progettazione di base:
Provare a distribuire il LES/BUS per le diverse ELAN sui vari dispositivi che possono implementarlo in modo efficiente. Idealmente, un LES/BUS primario su ciascun modulo LANE, con i successivi che eseguono il backup del primo. In pratica, questo genererebbe un database LECS molto lungo. L'esperienza ha dimostrato che 10 server LES/BUS per modulo LANE sembrano essere un numero sicuro.
Cercare di non collocare il LECS nella stessa posizione di altri importanti server LES/BUS. Provare inoltre a posizionare il LECS su un dispositivo con una potenza di CPU sufficiente per gestire in modo efficiente le informazioni di segnalazione. La scheda LECS deve essere su un router (si consiglia Cisco 7200 o 7500, preferibilmente senza LES/BUS) o su uno switch ATM.
Supponendo che per ciascuna VLAN venga utilizzato un intervallo IP e uno di classe C, circa 250 indirizzi MAC sono un numero valido per il compito dell'interfaccia LES. Per 10 LES su un modulo LANE, indica la CPU di un modulo LANE per un massimo di 2500 indirizzi MAC. Tenete a mente che non ci sono numeri fissi e ufficiali, ma questa è una stima sicura e conservativa. D'altra parte, 200 LES/BUS su un modulo LANE, con ciascuna ELAN contenente 1000 stazioni terminali, sono sicuri finché la stazione rimane praticamente inattiva (fare riferimento alla linea guida n. 3 per ulteriori dettagli).
In questo progetto, abbiamo messo il LECS sullo switch ATM. Abbiamo distribuito il LES/BUS su diversi moduli LANE. Valori elevati della CPU di processo non sono visibili su alcun modulo LANE e la ridondanza è normale.
Le linee guida presentate di seguito sono solo raccomandazioni pratiche, basate sull'installazione delle reti LANE di produzione. Sebbene esistano esempi di reti di successo che superano le raccomandazioni, prima di superare queste linee guida è necessaria una comprensione approfondita di come influiranno sulla rete.
Se si intende utilizzare il protocollo HSRP (Hot Standby Router Protocol) su LANE, accertarsi di eseguire l'aggiornamento a una versione recente e di aver letto Implementazione di HSRP su LANE.
Distribuire LANE BUS sui dispositivi con la massima capacità di throughput BUS e dove avrà un impatto minimo sugli altri processi del dispositivo.
LANE BUS è responsabile dell'inoltro di tutti i frame unicast di destinazione broadcast, multicast e sconosciuti ricevuti dai membri di un'ELAN a tutti i membri dell'ELAN. Poiché LANE utilizza il layer di adattamento ATM 5 (AAL5), che non consente l'interfoliazione delle celle da unità PDU (Protocol Data Unit) diverse, il BUS deve serializzare i frame prima dell'inoltro. Questo richiede che il BUS ricomponga i frame ricevuti, segmenti ogni frame uno per uno e inoltri le celle. Il requisito di riassemblare e segmentare ogni frame limita in modo significativo il throughput di inoltro del BUS, il che influenza notevolmente la scalabilità di un'ELAN. La proliferazione delle applicazioni multicast IP intensifica ulteriormente questa attività. Tenere presente che solo i moduli LANE possono ricevere le celle su invio multicast e inoltrarle sull'inoltro multicast. Questa operazione viene eseguita senza riassemblaggio.
Distribuire i servizi LANE su più moduli e dispositivi.
Abbiamo affermato che 10 LES/BUS con ciascuna ELAN corrispondente a una rete IP di Classe C (circa 250 utenti) sono sicuri e conservativi; tuttavia, esistono reti LANE di successo con 10-60 coppie LES/BUS per modulo. Ciò dipende leggermente dal modulo, ma il controllo del progetto implica sempre il controllo dell'utilizzo della CPU (tramite il comando show PROCESSES cpu) e della memoria più bassa disponibile (tramite il comando show memory). Ciò dovrebbe, ovviamente, essere effettuato durante i picchi di utilizzo della rete, in quanto l'utilizzo complessivo della CPU da parte di LES è direttamente correlato al processo LE_ARP.
In un ambiente LANE, è comune vedere le coppie LES/BUS posizionate su un singolo dispositivo che supporta l'intera rete LANE. Ciò non solo rappresenta un singolo punto di errore, ma limita le prestazioni del BUS all'interno di ciascuna ELAN.
La distribuzione dei servizi LANE su più piattaforme offre una maggiore scalabilità in ambienti multi-ELAN, nonché una maggiore disponibilità del sistema e migliori prestazioni del BUS aggregato (ad esempio, le prestazioni del BUS aggregato nella rete aumentano man mano che vengono configurati più dispositivi e interfacce per il supporto del BUS). Per ottenere la massima capacità del BUS dal punto di vista della progettazione, i moduli Catalyst 5000 e 6000 ATM possono essere dedicati ai servizi LES e BUS.
Conoscendo la capacità del BUS e stimando la quantità di traffico broadcast o multicast previsto in ciascuna ELAN, è possibile calcolare il numero di coppie LES/BUS che possono essere applicate a una determinata interfaccia. È anche possibile misurare la capacità del BUS.
Stimare la quantità di traffico broadcast o multicast per ciascuna ELAN è, tuttavia, più difficile. Un metodo per stimare la quantità di traffico broadcast o multicast per ciascuna ELAN è misurare questo traffico sulla rete esistente. È possibile inserire nella LAN esistente un analizzatore di rete o una sonda RMON (monitoraggio da remoto) per misurare la quantità di traffico broadcast e multicast. In alternativa, è possibile eseguire una query sugli oggetti mib "ifOutMulticastPkts" e "ifOutBroadcastPkts". Verificare innanzitutto se sono supportati sulla piattaforma o sul sistema operativo IOS in uso.
In alternativa, è possibile, in una certa misura, calcolare la quantità di traffico broadcast o multicast calcolando, ad esempio, la larghezza di banda utilizzata dalle trasmissioni del protocollo di routing. Per IPX (Internetwork Packet Exchange), RIP (Routing Information Protocol) e SAP (Service Advertising Protocol), è possibile determinare con precisione il consumo della larghezza di banda se il numero di route IPX e SAP è noto. Lo stesso vale per l'IP e il protocollo di routing in uso.
Lo spazio aggiuntivo per la capacità del BUS deve essere riservato per:
Supporto del traffico unicast durante la definizione di una VC data direct e fino alla conferma di un pacchetto flush sul LEC ricevente.
Applicazioni multicast IP su richiesta utilizzate in momenti diversi della giornata (da considerare nel volume multicast complessivo).
Traffico di routing aggiuntivo quando un protocollo è in esecuzione e in uno stato di convergenza, ovvero annunci LSA (Link State Advertising) scambiati durante una modifica della topologia OSPF (Open Shortest Path First).
Elevati volumi di richieste ARP (Address Resolution Protocol), in particolare al mattino, quando le workstation accedono per la prima volta ai server di rete e LAN.
Con qualsiasi metodo disponibile, l'obiettivo è quello di ottenere una descrizione accurata della quantità di traffico broadcast e multicast che esisterà su ciascuna ELAN. Sfortunatamente, queste informazioni sono raramente disponibili per il progettista di rete per vari motivi. Di fronte a questa situazione, si possono usare alcune linee guida generali conservatrici. Si consiglia di assegnare una capacità del BUS di almeno 10 Kpps a una rete tipica con 250 utenti per ELAN, che esegue le applicazioni più comuni. La tabella 1 mostra il numero massimo consigliato di coppie LES/BUS per interfaccia.
Questi numeri devono essere usati insieme alla linea guida n. 4, che limita a 250 il numero di LEC serviti da tutte le coppie LES/BUS configurate su un'interfaccia. Inoltre, questi numeri devono essere adeguati in base al numero effettivo di utenti in ciascuna ELAN, prestando particolare attenzione alle applicazioni broadcast o multicast che verranno eseguite sulla ELAN.
Limitare il numero totale di LEC serviti dalla coppia LES/BUS a un massimo di 250. Durante l'inizializzazione e a seguito di un errore di rete, affinché i client LANE possano unirsi alla ELAN, devono stabilire più connessioni e effettuare richieste ai componenti del servizio LANE. Poiché i dispositivi che supportano i servizi LANE dispongono di una velocità limitata alla quale possono elaborare le connessioni e le richieste, si consiglia di configurare le coppie LES/BUS su un servizio di interfaccia per un massimo di 250 client LANE. Ad esempio, un'interfaccia può essere configurata con 10 coppie LES/BUS, ciascuna delle quali serve 25 LEC per un totale di 250 LEC serviti dall'interfaccia. Ciò garantirà l'inizializzazione tempestiva e il ripristino in caso di errore.
Posizionare il bus per una determinata ELAN in prossimità di una delle principali fonti di traffico broadcast o multicast.
In un ambiente LANE, in particolare quando vengono utilizzate applicazioni multicast (ovvero IP/TV), è buona norma posizionare il BUS il più vicino possibile alla sorgente multicast nota. Poiché il traffico multicast deve prima essere inviato al BUS, che a sua volta inoltra il traffico a tutti i client, posizionando il BUS in prossimità della sorgente multicast si risparmia il traffico che attraversa due volte la backbone ATM.
Ciò consente alla rete LANE di scalare a una grandezza maggiore. Inoltre, il BUS non deve trovarsi sulla stessa interfaccia della LEC che supporta la sorgente multicast, poiché il traffico multicast attraverserebbe il collegamento di trasmissione due volte.
Prestare attenzione se si sta considerando LANE come tecnologia di rete per il supporto di un ambiente multicast. LANE supporta il traffico multicast, ma in modo piuttosto inefficiente. LANE invia il traffico multicast a tutti i client della ELAN, indipendentemente dal fatto che facciano o meno parte del gruppo multicast. L'eccesso di traffico multicast può ridurre significativamente le prestazioni delle workstation (come indicato nella linea guida n. 6), mentre il comportamento di allagamento spreca la larghezza di banda della backbone.
Limitare il numero di sistemi terminali in una determinata ELAN a 500 o meno, nel caso in cui la rete trasporti solo pacchetti IP. La tabella 2 seguente fornisce alcune raccomandazioni di base basate sulla quantità di trasmissioni generate dal protocollo. Anche in questo caso, se non si è completamente certi dei protocolli necessari, tenere presente la raccomandazione sulle 250 stazioni terminali che abbiamo dato in passato.
Per definizione, un'ELAN rappresenta un dominio di trasmissione. Pertanto, all'interno di un'ELAN, tutti i pacchetti broadcast e multicast vengono trasmessi a tutti i membri dell'ELAN. Le workstation devono elaborare ogni pacchetto broadcast e multicast ricevuto per determinare se è di proprio interesse. L'elaborazione di pacchetti broadcast "poco interessanti" spreca i cicli della CPU della workstation. Quando il livello dell'attività di trasmissione diventa elevato (rispetto alla capacità di elaborazione delle workstation), queste possono subire un grave impatto e non essere in grado di svolgere le attività previste.
Il numero di sistemi terminali, applicazioni e protocolli in uso determina il livello di trasmissione all'interno di una ELAN. I test hanno dimostrato che, in assenza di applicazioni broadcast intensive, il numero di sistemi terminali configurabili in modo sicuro in una singola ELAN varia da 200 a 500 a seconda della combinazione di protocolli.
Tabella 2. Numero massimo di sistemi finali consigliati per ELAN in base alla combinazione di protocolliTipo di protocollo | Numero di sistemi finali |
---|---|
IP | 500 |
IPX | 300 |
AppleTalk | 200 |
Misto | 200 |
Calcolare l'utilizzo della rete VC per verificare che rientri nella capacità dei dispositivi ATM.
Gli switch ATM e i dispositivi periferici supportano un numero limitato di VC. Nella progettazione di reti ATM, è importante garantire che la capacità dell'apparecchiatura di videoconferenza non venga superata. Ciò è particolarmente importante nelle reti LANE, poiché LANE non è nota per l'efficienza delle videoconferenze. Durante la fase di progettazione della rete, è necessario calcolare l'uso previsto del VC per la backbone e per ogni singolo dispositivo periferico. L'utilizzo di VC della backbone corrisponde al numero totale di VC previsti nella rete. Questa quantità deve essere confrontata con il numero di VC supportati dagli switch ATM.
Poiché non tutti i VC attraversano un determinato switch, questo numero funge da limite superiore. Per determinare se la capacità dei VCI degli switch ATM verrà superata, occorre considerare la topologia effettiva della backbone e i modelli di traffico.
Analogamente, è necessario calcolare l'utilizzo di VC per ciascun dispositivo periferico. Ciò si riferisce al numero di VC che termineranno su una determinata interfaccia di un dispositivo periferico. Questo numero deve essere confrontato con la capacità del VC dell'interfaccia.
Le seguenti formule possono essere utilizzate per calcolare l'utilizzo della rete VC. Queste formule presuppongono l'utilizzo dei servizi e dei client LANE di Cisco e si applicano a SSRP e FSSRP. Se presenti, vengono indicate le differenze nell'utilizzo di VC tra i due protocolli.
a. LEC-LANE Service VCs: SSRP: 4 (#LEC_per_ELAN)(#ELAN) FSSRP: 4 (#LEC_per_ELAN)(#LES/BUS_per_ELAN)(#ELAN) b. LECS-LES Control VCs: (#LES/BUS_per_ELAN)(#ELAN) c. LECS-LECS Control VCs: (#LECS)(#LECS - 1) / 2 d. LEC-LEC Data Direct VCs: If mesh_factor < 1.0: (#LEC_per_ELAN) [(#LEC_per_ELAN)(mesh_factor)/2](#ELAN) If mesh_factor = 1.0: (recommended in most designs) (#LEC_per_ELAN) [((#LEC_per_ELAN) - 1)/2](#ELAN) where: mesh_factor = fraction of LECs within an ELAN communicating a given time. (When determining the fraction of LECs within an ELAN communicating at a given time, the data direct timeout period must be considered. Even a brief conversation between two LECs will cause a data direct connection to be maintained for the timeout period. Therefore, unless the traffic patterns are very clearly understood, a mesh_factor = 1.0 is highly recommended). Backbone VC Usage = a + b + c + d
a. LEC-LANE Service VCs: SSRP: (#active_LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2) FSSRP: (#LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2) b. LECS-LES Control VC's: (#LES/BUS_on_interface) c. LECS-LECS Control VCs (#LECS - 1) d. LEC-LEC Data Direct VCs: (#LEC)[(#LEC_per_ELAN)(#LEC_per_ELAN)(mesh_factor)/2] Interface VC usage = a + b + c + d
Dopo aver calcolato l'utilizzo del VC, confrontare i risultati con la capacità del VC dei dispositivi interessati utilizzando la Tabella 3.
Tabella 3. Routing inter-ELAN - Capacità VC per diversi dispositivi CiscoSul dispositivo bootflash o slot0: | Budget circuito virtuale |
---|---|
Catalyst 8540 MSR | 256 k |
Catalyst 8510 MSR/LS1010 | 16 MB di memoria dinamica ad accesso casuale (DRAM) = 4k |
32 MB di DRAM = 16k | |
64 MB di DRAM = 32 k | |
Cisco 7500/7200 ATM Deluxe | 4k |
Cisco 7500/7200 ATM Lite | 2k |
Catalyst 6K - LANE/MPOA OC-12 | 4k |
Catalyst 5K - LANE/MPOA OC-12 | 4k |
Catalyst 5K - LANE/MPOA OC-3 | 4k |
Catalyst 5K - LANE OC-3 | 4k |
Catalyst 2900 XL - LANE OC-3 | 1k |
Per collegare diverse reti ATM del campus con percorsi virtuali permanenti (PVP), effettuare sempre il "routing" tra i siti anziché consentire alle ELAN native di estendersi su diverse reti ATM del campus.
Valutare la capacità del router necessaria stimando la quantità di routing tra ELAN richiesta.
La quantità di capacità di routing richiesta in una determinata rete LANE varia notevolmente. Pertanto, la quantità di capacità di routing deve essere stimata durante il processo di progettazione della rete. Dopo aver determinato la capacità richiesta, è possibile determinare il numero di router e interfacce router necessarie utilizzando la seguente tabella di velocità effettiva di inoltro:
Tabella 4. Capacità di routing tra ELAN per diversi dispositivi CiscoSul dispositivo bootflash o slot0: | Cisco Express Forwarding (CEF) Distributed (Kpps) | Cisco Express Forwarding (CEF) Forwarding (Kpps) |
---|---|---|
RSP4/VIP2-50 ATM PA-A3 | 118 | 101 |
RSP4/VIP2-50 ATM PA-A1 | 91 | 91 |
RSP4/VIP2-40 ATM PA-A3 | 83 | 60 |
RSP4/VIP2-40 ATM PA-A1 | 66 | 66 |
Mentre la configurazione a "un braccio" del router è popolare nei progetti LANE, in genere non fornisce una capacità di routing adeguata. Sono invece necessarie più interfacce e/o router. Le velocità di inoltro CEF elencate nella tabella precedente presuppongono una configurazione di router con un solo braccio. Per raggiungere queste velocità, il processore centrale del router è spinto a un utilizzo pari a quasi il 100%. Al contrario, le velocità di inoltro distribuite vengono ottenute utilizzando il processore residente sul Versatile Interface Processor (VIP), senza alcun impatto sul processore del router centralizzato. Di conseguenza, è possibile installare più interfacce ATM nel router per ottenere un throughput di aggregazione molto più elevato.
Fornire dispositivi periferici ATM dual-home ad almeno due switch ATM diversi per la ridondanza.
In una rete LANE, lo switch ATM che supporta i dispositivi periferici può essere un singolo punto di errore per la connettività alla backbone. I catalyst 6K e 5K forniscono moduli uplink OC-12/OC-3 dual-physical subayer (PHY) per la connettività ridondante agli switch ATM a valle. I moduli LANE dual-homed forniscono una funzionalità dual-PHY simile a FDDI (Fiber Distributed Data Interface). Questo modulo di uplink dual-PHY fornisce un'interfaccia ATM primaria e secondaria. Se l'interfaccia primaria perde la connettività di collegamento allo switch ATM, il modulo passa automaticamente la connessione all'interfaccia secondaria.
Si consiglia vivamente al progettista della rete di sfruttare le interfacce dual-PHY sui moduli LANE e di fornire uplink dual-homed a due switch ATM diversi nel core. In questo modo i dispositivi periferici saranno protetti dal guasto di un singolo switch ATM.
Utilizzare FSSRP a meno che il budget VC non abbia vincoli.
Poiché i vari componenti del servizio LANE sono singoli punti di errore in una rete LANE, le reti di produzione devono essere progettate con ridondanza. Cisco supporta due schemi di ridondanza per i servizi LANE: Protocollo SSRP (Simple Server Redundancy Protocol) e FSSRP (Fast SSRP).
FSSRP è lo schema di ridondanza consigliato nella maggior parte dei casi. Fornisce il failover quasi immediato senza perdita di dati, anche nelle reti di grandi dimensioni. D'altra parte, il protocollo SSRP causerà una perdita durante un failover e i tempi di ripristino possono essere considerevoli (talvolta minuti) nelle reti di grandi dimensioni.
In una situazione in cui è consigliabile utilizzare SSRP rispetto a FSSRP: quando la rete è vincolata da VC. A differenza del protocollo SSRP, i LEC FSSRP mantengono connessioni di backup alle coppie LES/BUS ridondanti. È possibile configurare fino a tre coppie di backup LES/BUS rispetto a un totale di quattro per ELAN. L'aumento dell'utilizzo di VC riscontrato dalla rete in FSSRP può essere calcolato utilizzando la seguente formula:
4 (#LEC_per_ELAN) (#LES/BUS_per_ELAN - 1) (#ELAN)
Pertanto, se la rete raggiunge la capacità VC, è consigliabile utilizzare SSRP. Se si utilizza FSSRP, è necessario ridurre il numero di componenti LES/BUS ridondanti. Nella maggior parte dei casi, un totale di due coppie LES/BUS per ELAN offre un equilibrio accettabile tra l'utilizzo di VC e l'eliminazione dei singoli punti di errore.