Prestazioni lente della rete ATM

Introduzione

In questo documento vengono descritte le cause generali e specifiche della lentezza nelle prestazioni delle reti ATM e le procedure che consentono di risolvere il problema. Questo documento si concentra sulla risoluzione dei problemi di prestazioni IP, in particolare sulle reti ATM. In genere, le prestazioni vengono misurate utilizzando il ritardo e la velocità effettiva. Le prestazioni vengono spesso verificate utilizzando un FTP o altre applicazioni TCP/IP per trasferire un file tra due dispositivi terminali e quindi misurare il tempo necessario per il trasferimento del file. Quando la velocità di trasmissione osservata con il trasferimento dei file non è uguale alla larghezza di banda disponibile sul circuito ATM, questo viene percepito come un problema di prestazioni. Ci sono molti fattori come le impostazioni della finestra TCP, l'MTU, la perdita di pacchetti e il ritardo che determinano il throughput rilevato su un circuito ATM. Questo documento affronta i problemi che influiscono sulle prestazioni nelle implementazioni di PVC (Routed Permanent Virtual Circuit), SVC (Switched Virtual Circuits) e LANE (LAN Emulation) ATM. La causa dei problemi di prestazioni è comune nelle implementazioni di PVC, SVC e LANE con routing.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

Il primo passaggio per la risoluzione dei problemi relativi alle prestazioni consiste nella selezione di singoli dispositivi di origine e di destinazione tra cui eseguire il test. Identificare le condizioni in cui il problema si verifica e quelle in cui non si verifica. Selezionare i dispositivi di test per ridurre la complessità del problema. Ad esempio, non eseguire il test tra dispositivi con dieci hop di router separati se il problema si verifica quando si passa attraverso due router.

Una volta selezionati i dispositivi di test, determinare se le prestazioni sono correlate alla natura intrinseca delle applicazioni TCP o se il problema è causato da altri fattori. Eseguire il ping tra i dispositivi terminali per verificare se il pacchetto viene perso e il ritardo di andata e ritorno dei pacchetti ping. I test ping devono essere eseguiti su pacchetti di dimensioni diverse per determinare se le dimensioni del pacchetto influiscono sulla perdita del pacchetto. I test ping devono essere eseguiti dai dispositivi terminali sottoposti a test e non dai router. Il valore Round Trip Time (RTT) visualizzato quando si esegue il ping da e verso un router potrebbe non essere accurato. Infatti, il processo ping è a bassa priorità sul router e potrebbe non rispondere immediatamente al ping.

Problemi comuni

Natura intrinseca di TCP/IP

Un cliente ha un PVC ATM tra New York e Los Angeles. Il circuito virtuale (VC) è configurato con un SCR (Sustained Cell Rate) di 45 Mbps. Il cliente verifica questo circuito trasferendo un file tramite FTP da un server FTP a un client e scopre che la velocità di trasmissione per il trasferimento di file è di circa 7,3 Mbps. Quando si utilizza il protocollo TFTP, la velocità di trasmissione scende a 58 Kbps. Il tempo di risposta del ping tra il client e il server è di circa 70 ms.

La prima cosa da capire in questo esempio è che il protocollo TCP fornisce un trasporto affidabile dei dati tra i dispositivi. Il mittente invia i dati in un flusso in cui i byte sono identificati da numeri di sequenza. Il destinatario riconosce di aver ricevuto i dati inviando il numero di sequenza (numero di riconoscimento) del byte successivo di dati che si aspetta di ricevere. Il destinatario inoltre annuncia la propria finestra al mittente per annunciare la quantità di dati che può accettare.

I dispositivi terminali TCP/IP in genere includono la possibilità di configurare le dimensioni della finestra TCP/IP.

Se le dimensioni della finestra TCP dei dispositivi sono impostate su un valore troppo basso, questi dispositivi potrebbero non essere in grado di utilizzare l'intera larghezza di banda di un VC ATM.

L'RTT su un VC ATM può ridurre significativamente la velocità di trasmissione TCP se le dimensioni della finestra sono troppo basse.

Un dispositivo terminale invia circa una finestra di traffico in byte per RTT.

Ad esempio, se il valore RTT è 70 ms, utilizzare questa formula per calcolare le dimensioni della finestra necessarie per occupare un intero DS3 di larghezza di banda:

• .07s * 45 Mbps * 1 byte/8 bit = 393.750 byte

Il protocollo TCP standard consente una dimensione massima della finestra di 64.000 byte. L'opzione WINScale TCP consente di aumentare notevolmente le dimensioni della finestra se i dispositivi su entrambe le estremità supportano questa opzione e se anche l'applicazione FTP supporta questa opzione.

Utilizzare questa formula per impostare le dimensioni della finestra su 64.000 byte e utilizzare il valore RTT di 70 ms per risolvere il throughput.

• .07x * 1 byte/8 bit = 64000 byte

  dove x= 7,31428 Mbps

Se l'applicazione FTP supporta solo una dimensione di Windows di 32.000 byte, utilizzare questa formula.

• 0,07x * 1 byte/8 bit = 32000

  dove x= 3,657142 Mbps

Con il protocollo TFTP, il mittente invia pacchetti da 512 byte e deve ricevere una conferma per ciascun pacchetto prima di inviare il pacchetto successivo. Lo scenario migliore è l'invio di un pacchetto ogni 70 ms. Utilizzare questo calcolo del throughput.

• 1 pacchetto / 070 s = 14,28571 pacchetti/secondo

  512 byte/pacchetto * 8 bit/byte * 14,28571 pacchetti/secondo = 58,514 Kbps

Questo calcolo del throughput dimostra che il ritardo su un collegamento e le dimensioni della finestra TCP possono influire in modo significativo sul throughput su tale collegamento quando utilizza le applicazioni TCP/IP per misurare il throughput. Identificare la velocità effettiva prevista per ciascuna connessione TCP. Se si utilizza l'FTP per verificare la velocità effettiva, avviare più trasferimenti di file tra client e server diversi per stabilire se la velocità effettiva è limitata dalla natura intrinseca del protocollo TCP/IP o se il circuito ATM presenta altri problemi. Se l'applicazione TCP limita il throughput, dovrebbe essere possibile disporre di più server che inviano contemporaneamente e a velocità simili.

Successivamente, dimostrare che è possibile trasmettere il traffico attraverso il collegamento alla velocità SCR del circuito. A tale scopo, utilizzare un'origine del traffico e un collegamento che non utilizzi il protocollo TCP e inviare un flusso di dati attraverso VCI ATM. Verificare inoltre che la velocità ricevuta sia uguale alla velocità inviata. Inviare pacchetti ping estesi da un router con un valore di timeout 0 per generare traffico su un circuito ATM. Ciò dimostra che è possibile inviare il traffico attraverso il collegamento alla velocità configurata del circuito.

Soluzione: Aumentare le dimensioni della finestra TCP/IP.

Importante: Con un RTT molto piccolo e una finestra di dimensioni abbastanza grandi da riempire teoricamente l'SCR, non sarà mai in grado di raggiungere l'SCR a causa del sovraccarico dell'ATM. Se si considera l'esempio dei pacchetti da 512 byte inviati attraverso un PVC AAL5SNAP a 4 Mbps (SCR=PCR), calcolare il throughput IP reale misurato. Si presume che le dimensioni della finestra TCP e il valore RTT siano tali che l'origine possa inviare dati a 4 Mbps. Innanzitutto, ATM Adaptation Layer 5 (AAL5) e SNAP introducono ogni 8 byte di sovraccarico. Per questo motivo, potrebbe essere necessario eseguire il pad per assicurarsi che l'unità dati del protocollo (PDU) AAL5 possa essere divisa per 48. Quindi, in ciascuna cella, vengono introdotti 5 byte di sovraccarico. In questo caso significa che il livello AAL5 è 512+8+8=528 byte (non è necessaria alcuna spaziatura interna). Questi 528 byte richiedono 11 celle da trasmettere. Ciò significa che per ogni pacchetto da 512 byte da inviare, vengono inviati 583 byte in rete (11 * 53). In altre parole, vengono introdotti 71 byte di sovraccarico. Ciò significa che solo l'88% della larghezza di banda può essere utilizzata dai pacchetti IP. Pertanto, con il PVC di 4 Mbps, il throughput IP utilizzabile è solo di circa 3,5 Mbps.

Più piccole sono le dimensioni del pacchetto, maggiore è il sovraccarico e minore è il throughput.

Perdita di pacchetti

La causa più comune dei problemi di prestazioni è la perdita di pacchetti sui circuiti ATM. Qualsiasi perdita di cella in un circuito ATM causa un peggioramento delle prestazioni. La perdita di pacchetti implica la ritrasmissione e anche la riduzione delle dimensioni della finestra TCP. Il throughput risulta inferiore. In genere, un semplice test ping identifica se tra i due dispositivi si verificano perdite di pacchetti. Gli errori CRC (Cyclic Redundancy Check) e le perdite di celle/pacchetti sui circuiti ATM determinano la ritrasmissione dei dati. Se le celle ATM vengono eliminate da uno switch ATM a causa di un esaurimento delle policy o dei buffer, gli errori CRC vengono visualizzati sul dispositivo terminale quando le celle vengono ricomposte in pacchetti. I dispositivi periferici ATM possono perdere o ritardare i pacchetti quando la velocità dei pacchetti in uscita su un VC supera la velocità di traffic shaping configurata sul VC.

Vedere questi documenti per i dettagli sulla risoluzione dei problemi relativi alle cause più comuni della perdita di pacchetti sulle reti ATM:

• Guida alla risoluzione dei problemi CRC per interfacce ATM

• Risoluzione dei problemi di output sulle interfacce del router ATM

• Risoluzione dei problemi di ingresso sulle interfacce del router ATM

• Informazioni sui contatori di celle rifiutate/scartate sui router dello switch ATM

Soluzione: Risoluzione dei problemi ed eliminazione delle perdite di pacchetti.

Ritardo/Latenza

La quantità di tempo richiesta per il viaggio di un pacchetto dall'origine alla destinazione e la richiesta di conferma al mittente possono influire in modo significativo sul throughput rilevato su quel circuito. Il ritardo su un circuito ATM può essere il risultato di un normale ritardo di trasmissione. Ci vuole meno tempo per inviare un pacchetto da New York a Washington che da New York a Los Angeles quando il circuito ATM ha la stessa velocità. Altre cause del ritardo sono l'accodamento del ritardo tramite router e switch e il ritardo di elaborazione tramite i dispositivi di routing di layer 3. Il ritardo di elaborazione associato ai dispositivi di routing dipende in larga misura dalla piattaforma utilizzata e dal percorso di commutazione. I dettagli associati al ritardo di routing e al ritardo hardware interno esulano dalle finalità di questo documento. Questo ritardo influisce su qualsiasi router, a prescindere dal tipo di interfaccia. Inoltre, è trascurabile rispetto al ritardo associato alla trasmissione dei pacchetti e alle code. Tuttavia, se un router elabora il traffico di commutazione, può causare un ritardo significativo e deve essere preso in considerazione.

Il ritardo viene misurato in genere con l'uso di pacchetti ping tra i dispositivi terminali per determinare il ritardo medio e massimo di andata e ritorno. Le misurazioni dei ritardi devono essere effettuate durante i picchi di utilizzo e nei periodi di inattività. Ciò aiuta a determinare se il ritardo può essere attribuito al ritardo di accodamento su interfacce congestionate.

La congestione delle interfacce determina un ritardo di accodamento. La congestione è in genere causata da una mancata corrispondenza della larghezza di banda. Ad esempio, se si dispone di un circuito attraverso uno switch ATM che passa da un'interfaccia OC-12 a un'interfaccia DS3 ATM, potrebbe verificarsi un ritardo di accodamento. Ciò accade quando le celle arrivano sull'interfaccia OC-12 più rapidamente di quanto possano essere generate sull'interfaccia DS3. I router perimetrali ATM configurati per il traffic shaping limitano la velocità di output del traffico sull'interfaccia. Se la velocità di arrivo del traffico destinato al VC ATM è superiore alle velocità di traffic shaping dell'interfaccia, i pacchetti/le celle vengono accodati sull'interfaccia. In genere, il ritardo introdotto dal ritardo di accodamento è il ritardo che causa problemi di prestazioni.

Soluzione: Implementazione delle funzionalità IP to ATM Class of Service (CoS) per un servizio differenziato. Utilizzare funzionalità quali CBWFQ (Class Based Weighted Fair Queuing) e LLQ (Low Latency Queuing) per ridurre o eliminare il ritardo di accodamento per il traffico mission critical. Aumentare la larghezza di banda dei circuiti virtuali per eliminare la congestione.

Configurazione Traffic Shaping

I PVC e SVC ATM hanno parametri QoS (Quality of Service) associati a ciascun circuito. Viene stabilito un contratto di traffico tra il dispositivo periferico ATM e la rete. Quando si usano i PVC, questo contratto è configurato manualmente nella rete ATM (switch ATM). Con gli SVC, la segnalazione ATM viene utilizzata per stabilire questo contratto. I dati della forma traffico dei dispositivi periferici ATM devono essere conformi al contratto specificato. I dispositivi di rete ATM (switch ATM) monitorano il traffico sul circuito per verificarne la conformità al contratto specificato e il traffico (contrassegno) o di rifiuto (polizia) non conforme.

Se un dispositivo periferico ATM ha una velocità PCR/SCR configurata per una velocità superiore a quella del provisioning sulla rete, è probabile che si verifichi una perdita di pacchetti. Le velocità di traffic shaping configurate sul dispositivo periferico devono corrispondere a quelle configurate dall'utente finale sulla rete. Verificare che la configurazione corrisponda tramite tutti i dispositivi configurati. Se il dispositivo periferico invia in rete celle non conformi al contratto di cui viene eseguito il provisioning in tutta la rete, vengono in genere visualizzate le celle eliminate all'interno della rete. Questa condizione si verifica in genere quando il destinatario riceve un errore CRC sull'estremità remota del pacchetto quando cerca di ricomporre il pacchetto.

Un dispositivo periferico ATM con PCR/SCR configurato per una velocità inferiore a quella del provisioning sulla rete causa una riduzione delle prestazioni. In questo caso, la rete è configurata per fornire una larghezza di banda maggiore di quella inviata dal dispositivo periferico. Questa condizione può causare un ulteriore ritardo nell'accodamento e persino perdite nella coda di output sull'interfaccia di uscita del router ATM perimetrale.

Gli SVC sono configurati sui dispositivi periferici, ma la rete potrebbe non stabilire lo SVC end-to-end con gli stessi parametri di traffico. Gli stessi concetti e problemi si applicano agli SVC che si applicano ai PVC. La rete potrebbe non configurare il dispositivo SVC in modo completo con le stesse classi e gli stessi parametri QoS. Questo tipo di problema è in genere causato da un bug o da problemi di interoperabilità. Quando viene segnalato un SVC, il chiamante specifica i parametri QoS Traffic Shaping in avanti e indietro. È possibile che la parte chiamata non installi il SVC con i parametri di shaping corretti. La configurazione di Strict Traffic Shaping sulle interfacce del router può impedire la configurazione dei SVC con parametri di shaping diversi da quelli configurati.

L'utente deve tracciare il percorso del SVC attraverso la rete e verificare che sia stato stabilito con l'uso della classe QoS e dei parametri configurati sul dispositivo di origine.

Soluzione: Eliminazione delle incongruenze nella configurazione di regole e traffic shaping. Se vengono utilizzati SVC, verificare che siano configurati in modo completo con i parametri di shaping/policing corretti. Configurare Strict Traffic Shaping sulle interfacce del router ATM con il comando atm sig-traffic-shaping strict.

SVC su percorsi non ottimali

Gli SVC configurati per UBR (Unspecified Bit Rate) possono essere configurati su percorsi non ottimali. La larghezza di banda di un VC UBR è limitata alla velocità di linea dei collegamenti attraversati dal VC. Pertanto, se un collegamento ad alta velocità dovesse interrompersi, i VC che lo attraversano potrebbero essere ristabiliti su un collegamento più lento. Anche quando il collegamento ad alta velocità viene ripristinato, i sistemi di videoconferenza non vengono eliminati e ristabiliti usando il collegamento più veloce. Infatti il percorso più lento soddisfa i parametri QoS richiesti (non specificati). Questo problema è molto comune nelle reti LANE che hanno percorsi alternativi attraverso la rete. Nei casi in cui i percorsi alternativi abbiano la stessa velocità di collegamento, il guasto di uno dei collegamenti causa il routing di tutti gli SVC sullo stesso percorso. Questa situazione può influire notevolmente sul throughput e sulle prestazioni della rete, poiché la larghezza di banda effettiva della rete viene dimezzata.

Anche gli SVC a bit variabile (VBR) e a bit costante (CBR) possono essere instradati su percorsi non ottimali. I dispositivi terminali richiedono parametri di traffico specifici (PCR, SCR, dimensione massima burst {MBS}). Lo scopo delle interfacce PNI (Private Network-Interface) e ATM è quello di fornire un percorso che soddisfi i requisiti QoS della richiesta. Nel caso di chiamate CBR e VBR-rt, questo include anche il ritardo massimo di trasferimento della cella. Un percorso può soddisfare i requisiti specificati dal richiedente dal punto di vista della larghezza di banda, ma non essere il percorso ottimale. Questo problema è comune quando vi sono percorsi con un ritardo maggiore che soddisfano ancora i requisiti di larghezza di banda per i VC VBR e CBR. Questo può essere percepito come un problema di prestazioni per il cliente che ora vede caratteristiche di ritardo più grandi attraverso la rete.

Soluzione: Gli SVC in una rete ATM vengono stabiliti su richiesta e in genere non vengono eliminati né reindirizzati su un percorso diverso a meno che non vengano disattivati (a causa di inattività o rilasciati per altri motivi). Gli switch Cisco LightStream 1010 e Catalyst 8500 ATM offrono la funzionalità di ottimizzazione della route in PVC morbido. Questa funzionalità consente di reindirizzare in modo dinamico un PVC morbido quando è disponibile una route migliore. Una funzionalità simile non è disponibile per gli SVC che non terminano sugli switch ATM.

Una possibile soluzione a questo problema è l'uso di PVC tra i dispositivi periferici ATM e gli switch ATM collegati. I PVC morbidi con ottimizzazione del percorso configurata tra switch ATM offrono la possibilità di reindirizzare il traffico da percorsi non ottimali dopo l'errore del collegamento e il successivo ripristino.

Configurare l'Intervallo di timeout di inattività per i SVC su un valore basso, in modo che i SVC vengano eliminati e ristabiliti con maggiore frequenza. Usare il comando idle-timeout seconds [minimum-rate] per modificare la quantità di tempo e di velocità del traffico che causano l'arresto del SVC. Questa procedura potrebbe non essere efficace in quanto la videoconferenza deve essere inattiva per poter essere reindirizzata sul percorso ottimale.

Se il problema persiste, verificare che il percorso ottimale sia stato ripristinato e riavviare una delle interfacce ATM associate al percorso ridondante a bassa velocità o una delle interfacce del router che termina il SVC.

Problemi hardware

Problemi di prestazioni PA-A1

L'architettura dell'adattatore della porta PA-A1 ATM e la mancanza di memoria integrata possono causare una riduzione delle prestazioni. Il problema può manifestarsi in interruzioni, sovraccarichi, ignoramenti e CRC sull'interfaccia. Il problema è aggravato quando viene utilizzato con un router Cisco 7200 con NPE-100/175/225/300.

Per ulteriori informazioni, fare riferimento a Risoluzione degli errori di input sugli adattatori porte ATM PA-A1.

Soluzione: Sostituire gli adattatori porte ATM PA-A1 con gli adattatori porte ATM PA-A3 (almeno revisione 2) o PA-A6.

PA-A3 versione 1

La revisione 1 dell'hardware PA-A3 non ricompone le celle in pacchetti che utilizzano la RAM statica integrata (SRAM) sull'adattatore della porta. L'adattatore inoltra le celle attraverso il bus PCI (Peripheral Component Interconnect) alla memoria host Versatile Interface Processor (VIP) o Network Processing Engine (NPE) in cui ricompone i pacchetti. Ciò comporta problemi di prestazioni simili a quelli riscontrati con l'adattatore della porta ATM PA-A1.

Per ulteriori informazioni, fare riferimento a Risoluzione dei problemi di input e output sugli adattatori porte ATM PA-A3.

Soluzione: Sostituire gli adattatori di porte ATM PA-A3 revisione hardware 1 con gli adattatori di porte PA-A3 (almeno revisione 2) o PA-A6 ATM.

Due PA-A3 PA in VIP2-50

PA-A3-OC3SMM, PA-A3-OC3SMI e PA-A3-OC3SML sono progettati per fornire le massime prestazioni di commutazione quando una singola scheda di rete è installata in una singola interfaccia VIP2-50. Una singola interfaccia PA-A3-OC3SMM, PA-A3-OC3SMI o PA-A3-OC3SML in una porta VIP2-50 fornisce fino a circa 85.000 pacchetti al secondo di capacità di commutazione in ciascuna direzione utilizzando pacchetti da 64 byte. Si noti che un singolo PA-A3-OC3SMM, PA-A3-OC3SMI o PA-A3-OC3SML da solo può utilizzare l'intera capacità di commutazione di un singolo VIP2-50.

Per le applicazioni che richiedono la massima densità delle porte o costi di sistema inferiori, sono ora supportate configurazioni con adattatore a due porte con la versione OC-3/STM-1 del PA-A3 nello stesso VIP2-50. Le due schede di porta dello stesso VIP2-50 condividono circa 95.000 pacchetti al secondo di capacità di switching in ciascuna direzione utilizzando pacchetti da 64 byte.

Il VIP-50 fornisce fino a 400 megabit al secondo (mbps) di larghezza di banda aggregata, a seconda delle combinazioni di adattatori di porta. Nella maggior parte delle configurazioni di schede a due porte con PA-A3-OC3SMM, PA-A3-OC3SMI o PA-A3-OC3SML, la combinazione di schede di porta supera questa capacità di larghezza di banda aggregata.

Di conseguenza, le prestazioni condivise tra le due schede di rete installate nello stesso VIP2-50 sono limitate dalla capacità di switching aggregata (95 kpps) a pacchetti di piccole dimensioni e dalla larghezza di banda aggregata (400 mbps) a pacchetti di grandi dimensioni.

Quando si designano reti ATM con PA-A3-OC3SMM, PA-A3-OC3SMI o PA-A3-OC3SML, è necessario tenere in considerazione queste avvertenze relative alle prestazioni. A seconda del modello, le prestazioni delle schede a due porte dello stesso VIP2-50 possono essere accettabili o meno.

Per ulteriori informazioni, fare riferimento alle configurazioni PA-A1 e PA-A3 VIP2 supportate.

Problemi LANE

LANE Broadcast Domain

Un numero eccessivo di sistemi terminali in una singola ELAN LANE può ridurre significativamente le prestazioni di tutte le stazioni terminali. Un'ELAN rappresenta un dominio broadcast. Tutte le workstation e i server all'interno della ELAN ricevono traffico broadcast e possibilmente multicast da tutti gli altri dispositivi della ELAN. Se il livello del traffico di trasmissione è elevato rispetto alla capacità di elaborazione della workstation, le prestazioni della workstation ne risentono.

Soluzione: Limitare il numero di stazioni terminali all'interno di una singola ELAN a meno di 500. Controllare la rete per rilevare tempeste di tipo Broadcast/Multicast che potrebbero influire negativamente sulle prestazioni di server/workstation.

Per ulteriori informazioni, consultare LANE Design Recommendation.

Modifiche eccessive alla topologia del traffico LE-ARP e dello Spanning Tree

Altri problemi che possono portare a prestazioni scadenti in una rete LANE sono l'eccessiva attività LANE ARP (LE-ARP) e le modifiche alla topologia Spanning Tree. Questi problemi portano a LE-ARP irrisolti che portano al traffico inviato sul bus. Ciò può anche portare a un elevato utilizzo della CPU sui LEC della rete, che può causare problemi legati alle prestazioni. Per ulteriori informazioni su questi problemi, consultare il documento sulla risoluzione dei problemi di Spanning-Tree su LANE.

Configurare Spanning Tree PortFast sulle porte host degli switch Ethernet collegati a LANE per ridurre le modifiche della topologia dello Spanning Tree. Configurare la riverifica LE-ARP locale sugli switch Catalyst 5000 e 6000 configurati per LANE per ridurre il traffico LE-ARP.

SVC VBR-nrt Data Direct

Utilizzando LANE versione 1, gli SVC sono configurati come categoria di servizio UBR. LANE versione 2 supporta la possibilità di stabilire SVC Data Direct con l'utilizzo di altre categorie di servizi come VBR-nrt. Un fornitore terzo ha un bug nell'implementazione del client LANE che può causare la configurazione VBR-nrt degli SVC Data Direct impostati per i dispositivi Cisco con un SCR di 4 Kbps. Se la backbone ATM è costituita da collegamenti trunk OC-3 (155 Mbps) e OC-12 (622 Mbps) e si imposta SVC su tali trunk con una velocità di cella sostenuta di 4 Kbps, le prestazioni ne risentono. Benché questo particolare problema non sia comune, indica un'esigenza importante quando si devono risolvere i problemi di prestazioni sui circuiti ATM. È necessario tenere traccia del percorso che i SVC attraversano la rete e verificare che la VC sia stata stabilita con la categoria di servizio e i parametri di traffico desiderati.

I VC Data Direct non sono stabiliti

I VCI LANE Data Direct sono SVC bidirezionali point-to-point configurati tra due client di emulazione LAN (LEC) e utilizzati per lo scambio di dati tra tali client. I client LANE inviano richieste LE-ARP per conoscere gli indirizzi ATM associati a un indirizzo MAC. Tentano quindi di configurare una VC Data Direct per tale indirizzo ATM. Prima della creazione di VC Data Direct, i client LANE inviano pacchetti unicast sconosciuti al server broadcast e sconosciuto (BUS). Un client LANE potrebbe non riuscire a stabilire una VC Data Direct con un altro LEC allo scopo di inviare i dati unicast. In questo caso, potrebbe verificarsi un calo delle prestazioni. Il problema è significativo se il dispositivo scelto per eseguire i servizi BUS è sottoalimentato, inadeguato o sovraccarico. Inoltre, alcune piattaforme possono limitare il numero di unicast che vengono inoltrati al BUS. Il modulo LANE di Catalyst 2900XL è uno di questi dispositivi che limita il traffico unicast inviato al BUS, a differenza di Catalyst 5000 e Catalyst 6000.

Il SVC Data Direct potrebbe non essere stato stabilito o non essere utilizzato per uno dei seguenti motivi:

• Il LEC non riceve una risposta alla richiesta LE-ARP.

• Impossibile creare il SVC a causa di problemi di routing o segnalazione ATM.

• Errore del protocollo LANE Flush Message. Una volta stabilito il VC Data Direct, il LEC invia una richiesta Flush al Multicast Send VC per assicurarsi che tutti i frame di dati inviati tramite il BUS abbiano raggiunto la destinazione. Quando il LEC che ha inviato la richiesta Flush riceve una risposta, inizia a inviare i dati tramite la VC Data Direct. Il meccanismo Flush può essere disattivato con il comando no lane client flush.

Problemi IMA

PVC UBR su interfacce IMA

I VC UBR su interfacce IMA (Inverse Multiplexing) vengono configurati con una PCR di 1,5 Mbps anziché con la somma di tutte le interfacce fisiche up/up configurate nel gruppo IMA. Questa condizione degrada le prestazioni in quanto il VC ha una forma di traffico inferiore alla larghezza di banda combinata di tutti i collegamenti nel gruppo IMA.

In origine, la larghezza di banda di un'interfaccia IMA group era limitata al numero minimo di collegamenti IMA attivi necessari per mantenere attiva l'interfaccia IMA. Il comando per definire questo valore è IMA active-links-minimum. Ad esempio, se quattro interfacce fisiche ATM sono configurate come membri del gruppo IMA zero e il valore minimo dei collegamenti attivi IMA è impostato su uno, la larghezza di banda è uguale a un T1 o 1,5 Mbps e non a 6 Mbps.

L'ID bug Cisco CSCdr12395 (solo utenti registrati) modifica questo comportamento. L'adattatore PA-A3-8T1IMA ora utilizza la larghezza di banda di tutte le interfacce fisiche ATM up/up configurate come membri del gruppo IMA.

Gli ID bug Cisco CSCdt67354 (solo utenti registrati) e CSCdv67523 (solo utenti registrati) sono richieste di miglioramento successivo per aggiornare la larghezza di banda di IMA Group VC quando un'interfaccia viene aggiunta o rimossa dal gruppo IMA, viene chiusa/non chiusa o rimbalzata a causa di un errore di collegamento o viene modificata sull'estremità remota. Le modifiche implementate nel bug Cisco IDCSCdr12395 (solo utenti registrati) configurano la larghezza di banda del gruppo IMA in base alla larghezza di banda totale dei relativi collegamenti membri solo quando viene visualizzato il gruppo IMA. Le modifiche apportate al gruppo IMA dopo lo stato attivo iniziale non vengono riflesse.

Per ulteriori informazioni, fare riferimento a Risoluzione dei problemi dei collegamenti ATM sull'IMA Port Adapter 7x00.

Informazioni correlate

• Selezione route PNNI (Private Network-to-Network Interface)
• Ridimensionamento finestra TCP
• Risoluzione dei problemi relativi ai collegamenti ATM sull'IMA Port Adapter 7x00
• Configurazioni PA-A1 e PA-A3 VIP2 supportate
• Dettagli sull'implementazione TCP/IP di Microsoft Windows 2000
• Risoluzione dei problemi TCP/IP
• Supporto tecnico – Cisco Systems

Cronologia delle revisioni