Configurazione della frammentazione e dell'interfoliazione del collegamento (LFI) con gli switch ATM del campus

Introduzione

Questo documento offre una panoramica tecnica di Link Fragmentation and Interleaving (LFI) su una connessione Frame Relay a ATM Interworking (IWF) (come definito dal Frame Relay Forum o dal contratto FRF.8), nonché una configurazione di esempio per usare LS1010 o Catalyst 8500 come dispositivo IWF nel cloud WAN. LFI utilizza le funzionalità di frammentazione integrate di incapsulamento MLPPP (Multilink Point-to-Point Protocol) su ATM e Frame Relay per fornire una soluzione di frammentazione end-to-end e interfoliazione per collegamenti a bassa velocità con larghezze di banda fino a 768 kbps.

Prerequisiti

Requisiti

Questo documento richiede la comprensione di quanto segue:

• Ambiente FRF.8 tipico e modalità di conversione e trasparenza FRF.8: vedere Informazioni sulle modalità di conversione e trasparenza con FRF.8.

• Familiarità con i comandi di configurazione LS1010 e Catalyst 8500 e con il modo in cui Channelized E1 Frame Relay Port Adapter o Channelized DS3 Frame Relay Port Adapter eseguono l'interoperabilità tra un endpoint Frame Relay e un endpoint ATM.

• Ritardo di serializzazione e jitter. Vedere Collegamenti VoIP over PPP con priorità Quality of Service (LLQ/IP RTP, LFI, cRTP) e VoIP su Frame Relay con qualità del servizio (frammentazione, traffic shaping, priorità IP RTP).

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.

Perché MLPPP su ATM e Frame Relay?

La frammentazione è una tecnica chiave per controllare il ritardo di serializzazione e la variazione del ritardo sui collegamenti a bassa velocità che trasportano traffico in tempo reale e non. Il ritardo di serializzazione è il ritardo fisso richiesto per registrare una voce o un frame di dati nell'interfaccia di rete ed è direttamente correlato alla frequenza di clock sul trunk. È necessario un flag aggiuntivo per separare i frame per velocità di clock ridotte e dimensioni di frame ridotte.

LFI utilizza le funzionalità di frammentazione incorporate di MLPPP per prevenire ritardi e jitter (variazioni di ritardo) causati da pacchetti di grandi dimensioni a dimensione variabile in coda tra pacchetti voce relativamente piccoli. Con il protocollo LFI, i pacchetti più grandi delle dimensioni del frammento configurato vengono incapsulati in un'intestazione MLPPP. La RFC 1990 definisce l'intestazione MLPPP e quanto segue:

• (B)Il bit di inizio del frammento è un campo di un bit impostato su 1 sul primo frammento derivato da un pacchetto PPP e impostato su 0 per tutti gli altri frammenti dello stesso pacchetto PPP.

• (E)Il bit finale del frammento è un campo a un bit impostato su 1 sull'ultimo frammento e su 0 su tutti gli altri frammenti.

• Il campo Sequence (Sequenza) è un numero a 24 bit o a 12 bit che viene incrementato per ciascun frammento trasmesso. Per impostazione predefinita, il campo della sequenza è lungo 24 bit, ma può essere negoziato in modo da essere lungo solo 12 bit con l'opzione di configurazione LCP descritta di seguito.

Oltre alla frammentazione, i pacchetti sensibili al ritardo devono essere pianificati con priorità adeguata tra i frammenti di un pacchetto grande. Con la frammentazione, Weighted Fair Queueing (WFQ) diventa "consapevole" del fatto che un pacchetto faccia parte di un frammento o sia non frammentato. WFQ assegna un numero di sequenza a ciascun pacchetto in arrivo e quindi programma i pacchetti in base a tale numero.

La frammentazione di livello 2 offre una soluzione superiore a tutti gli altri approcci per la risoluzione del "problema dei pacchetti di grandi dimensioni". Nella tabella seguente vengono elencati i vantaggi e gli svantaggi di altre possibili soluzioni.

Soluzione potenziale	Vantaggi	Svantaggi
Interrompere la trasmissione del pacchetto grande e rimetterlo in coda dietro il traffico sensibile al ritardo.	Rimanda solo la trasmissione dei pacchetti. La ritrasmissione del pacchetto può causare lo stesso problema. Se i pacchetti vengono continuamente riaccodati e persino scartati, potrebbe verificarsi una carenza di larghezza di banda.	Alcune interfacce fisiche non supportano la trasmissione interrotta o introducono una penalità a livello di prestazioni per tale trasmissione (ad esempio, la reimpostazione dell'intera coda di trasmissione).
Frammentare il pacchetto grande usando le tecniche di frammentazione a livello di rete.	Sia IP che CLNP supportano la frammentazione su qualsiasi router, con il riassemblaggio sull'host di destinazione. Può evitare di frammentare il pacchetto grande con il rilevamento dell'MTU. Utilizza un meccanismo globale per superare quello che è essenzialmente un problema locale (one-hop) - tutti gli hop a valle devono gestire un numero più elevato di pacchetti da commutare, anche se tutti i collegamenti successivi sono veloci. Annulla l'opzione di compressione dell'intestazione TCP/IP.	Molte applicazioni non accettano la frammentazione e impostano il bit "Do Not Fragment" (Non frammentare) nell'intestazione IP. Se frammentati, questi pacchetti verranno scartati. Le applicazioni che non sono in grado di accettare pacchetti frammentati saranno rese inutilizzabili in questo ambiente.
Frammentare il pacchetto utilizzando le tecniche del livello di collegamento.	Supportato con qualsiasi pacchetto a livello di rete o pacchetto con bridging.	Permette la frammentazione per collegamento anziché richiedere il trasporto completo dei pacchetti frammentati. Solo i router collegati al collegamento lento devono gestire e riassemblare i pacchetti aggiuntivi.

Le dimensioni ideali del frammento per il protocollo MLPPPoATM (Multilink Point-to-Point Protocol over ATM) devono consentire l'inserimento dei frammenti in un multiplo esatto di celle ATM. Per istruzioni sulla selezione dei valori di frammentazione, vedere Link Fragmentation and Interleaving per Frame Relay e circuito virtuale ATM.

Intestazioni MLPPPoA e MLPPPoFR

Una configurazione tipica di FRF.8 è costituita dai seguenti elementi:

• Un endpoint Frame Relay

• Un endpoint ATM

• Una periferica di interworking (IWF)

Ciascun endpoint incapsula i pacchetti dati e voce in un'intestazione di incapsulamento di layer 2, che comunica il protocollo incapsulato e trasportato nel frame o nella cella. Sia Frame Relay che ATM supportano le intestazioni di incapsulamento Network Layer Protocol ID (NLPID). Il documento ISO/International Electrotechnical Commission (IEC) TR 9577 definisce valori NLPID noti per un numero selezionato di protocolli. Al protocollo PPP viene assegnato il valore 0xCF.

La RFC 1973 definisce il protocollo PPP in Frame Relay e l'intestazione MLPPPoFR, mentre la RFC 2364 definisce il protocollo PPP su AAL5 e l'intestazione MLPPPoA. Entrambe le intestazioni utilizzano un valore NLPID di 0xCF per identificare PPP come protocollo incapsulato.

Ciascuna di queste intestazioni è illustrata nella Figura 1 seguente.

Figura 1. PPP over AAL5, MLPPPoA con incapsulamento NLPID e MLPPPoA con multiplexing VC

Nota: l'intestazione MLPPPoFR include anche un campo flag a un byte di 0x7e, che non è mostrato nella Figura 1. Dopo le intestazioni, il byte numero 5 avvia i campi del protocollo PPP o MLPPP.

Tabella 1 - FRF.8 Trasparente rispetto a FRF.8 Transazionale.

Figura 2. Come il pacchetto MLPPPoATM viene frammentato usando NLPID.

Figura 3. Come il pacchetto MLPPPoATM viene frammentato usando il multiplexing VC.

Il significato dei valori in byte è illustrato di seguito:

• 0xFEFE - Identifica i punti di accesso al servizio di origine e di destinazione nell'intestazione LLC (Logical Link Control). Il valore 0xFEFE indica che il successivo è un'intestazione NLPID in formato breve, utilizzata con i protocolli con un valore NLPID definito.

• 0x03 - Campo di controllo utilizzato con molti incapsulamenti, compreso il controllo HDLC (High Level Data Link Control). Indica anche che il contenuto del pacchetto è costituito da informazioni senza numero.

• 0xCF - Valore NLPID noto per PPP.

FRF.8 Modalità trasparenti e di conversione

L'accordo FRF.8 definisce due modalità operative per il dispositivo IWF:

• Trasparente: il dispositivo IWF inoltra le intestazioni dell'incapsulamento inalterate. Non esegue la mappatura, la frammentazione o il riassemblaggio dell'intestazione del protocollo.

• Traduzione: il dispositivo IWF esegue il mapping protocollo-intestazione tra le due intestazioni di incapsulamento per tenere conto di piccole differenze tra i tipi di incapsulamento.

La modalità configurata sul dispositivo IWF, che può essere uno switch campus Cisco ATM o un router serie 7200 con un adattatore della porta PA-A3 ATM, modifica il numero di byte dell'intestazione di layer 2 sui segmenti ATM e Frame Relay del collegamento di interoperabilità. Vediamo più in dettaglio queste spese generali.

Le due tabelle seguenti mostrano il sovraccarico dei byte per i pacchetti dati e i pacchetti Voice over IP (VoIP).

Tabella 2 - Sovraccarico del collegamento dati in byte per un pacchetto dati su un collegamento FRF.8.

Modalità FRF.8			Trasparente					Traduzione
Direzione traffico			Frame Relay su ATM			ATM su Frame Relay		Frame Relay su ATM			ATM su Frame Relay
Frame Relay o gamba ATM di PVC			Frame Relay		ATM	ATM	Frame Relay	Frame Relay	ATM		ATM		Frame Relay
Flag frame (0x7e)			1		0	0	1	1	0		1		0
Intestazione Frame Relay			2		0	0	2	2	0		0		2
LLC DSAP/SSAP (0xfefe)			0		0	2	2	0	2		2		0
Controllo LLC (0x03)			1		1	1	1	1	1		1		1
NLPID (0xcf per PPP)			1		1	1	1	1	1		1		1
ID protocollo MLP (0x003d)			2		2	2	2	2	2		2		2
Numero di sequenza MLP			4		4	4	4	4	4		4		4
ID protocollo PPP (solo 1° frammento)			2		2	2	2	2	2		2		2
Payload (livello 3+)			0		0	0	0	0	0		0		0
Layer di adattamento ATM (AAL)5			0		8	8	0	0	8		8		0
FCS (Frame Check Sequence)			2		0	0	2	2	0		0		2
Sovraccarico totale (byte)			15		18	20	17	15	20		20		15

Tabella 3 - Sovraccarico del collegamento dati in byte per un pacchetto VoIP su un collegamento FRF.8.

Modalità FRF.8	Trasparente				Traduzione				Da Frame Relay a Frame Relay
Direzione traffico	Frame Relay su ATM		ATM su Frame Relay		Frame Relay su ATM		ATM su Frame Relay
Frame Relay o gamba ATM di PVC	Frame Relay	ATM	ATM	Frame Relay	Frame Relay	ATM	ATM	Frame Relay
Flag frame (0x7e)	1	0	0	1	1	0	0	1	1
Intestazione Frame Relay	2	0	0	2	2	0	0	2	2
LLC DSAP/SSAP (0xfefe)	0	0	2	2	0	2	2	0	0
Controllo LLC (0x03)	1	1	1	1	1	1	1	1	1
NLPID (0xcf per PPP)	1	1	1	1	1	1	1	1	1
ID PPP	2	2	2	2	2	2	2	2	0
Payload (IP+User Datagram Protocol (UDP)+RTP+Voice)	0	0	0	0	0	0	0	0	0
AAL5	0	8	8	0	0	8	8	0	0
FCS	2	0	0	2	2	0	0	2	2
Sovraccarico totale (byte)	9	12	14	11	9	14	14	9	7

Nell'esaminare le tabelle precedenti, tenere presente quanto segue:

• I pacchetti di dimensioni inferiori alla dimensione di frammentazione specificata vengono incapsulati solo in un'intestazione PPP e non in un'intestazione MLPPP. Analogamente, i pacchetti più grandi delle dimensioni di frammentazione specificate vengono incapsulati sia in un'intestazione PPP che in un'intestazione MLPPP. Pertanto, i pacchetti VoIP hanno fino a otto byte in meno di sovraccarico.

• Solo il primo frammento Multilink PPP (MLP) include un campo ID protocollo PPP. Pertanto, il primo frammento presenta due byte in più di sovraccarico.

• In modalità trasparente, le intestazioni di incapsulamento vengono passate senza essere modificate dal dispositivo IWF. In questo modo, il sovraccarico varia in ogni direzione e su ogni segmento. In particolare, un'intestazione MLPPPoA inizia con un'intestazione NLPID in formato breve 0xFEFE. In modalità trasparente, questa intestazione viene passata senza modifiche dal dispositivo IWF dal segmento ATM al segmento Frame Relay. Tuttavia, nella direzione Frame Relay to ATM, non esiste alcuna intestazione di questo tipo in modalità trasparente su nessuno dei due segmenti.

• In modalità di conversione, il dispositivo IWF modifica le intestazioni di incapsulamento. Pertanto, il sovraccarico è lo stesso su ciascun segmento in entrambe le direzioni. In particolare, nella direzione ATM - Frame Relay, l'endpoint ATM incapsula il pacchetto in un'intestazione MLPPPoA. Il dispositivo IWF rimuove l'intestazione NLPID prima di passare il frame rimanente al segmento Frame Relay. Nella direzione Frame Relay to ATM, il dispositivo IWF manipola nuovamente il frame e precede un'intestazione NLPID prima di passare il frame segmentato all'endpoint ATM.

• Quando si progettano collegamenti FRF con MLP, accertarsi di tenere conto del numero corretto di byte di sovraccarico del collegamento dati. Tale sovraccarico influenza la quantità di larghezza di banda utilizzata da ciascuna chiamata VoIP. Svolge inoltre un ruolo importante nel determinare le dimensioni ottimali del frammento MLP. Ottimizzare le dimensioni del frammento per adattarlo a un numero intero di celle ATM è fondamentale, in particolare sui PVC a bassa velocità dove una quantità significativa di larghezza di banda può essere sprecata riempiendo l'ultima cella su un multiplo pari di 48 byte.

Per maggiore chiarezza, osserviamo i passaggi del processo di incapsulamento dei pacchetti quando un pacchetto va nella direzione Frame Relay - ATM con modalità trasparente:

1. L'endpoint Frame Relay incapsula il pacchetto in un'intestazione MLPPPoFR.

2. Il dispositivo IWF rimuove l'intestazione Frame Relay da due byte con DLCI (Data Link Connection Identifier). Infine, inoltra il pacchetto rimanente all'interfaccia ATM dello IWF, che segmenta il pacchetto in celle e lo inoltra attraverso il segmento ATM.

3. L'endpoint ATM esamina l'intestazione del pacchetto ricevuto. Se i primi due byte del pacchetto ricevuto sono 0x03CF, l'endpoint ATM considera il pacchetto come un pacchetto MLPPPoA valido.

4. Le funzioni MLPPP sull'endpoint ATM eseguono ulteriori elaborazioni.

Guardare il processo di incapsulamento del pacchetto quando un pacchetto va nell'ATM in direzione Frame Relay con modalità trasparente:

1. L'endpoint ATM incapsula il pacchetto in un'intestazione MLPPPoA. Quindi, segmenta i pacchetti in celle e li inoltra al segmento ATM.

2. Il file IWF riceve il pacchetto, lo inoltra all'interfaccia Frame Relay e precede un'intestazione Frame Relay di due byte.

3. L'endpoint Frame Relay esamina l'intestazione del pacchetto ricevuto. Se i primi quattro byte dopo l'intestazione Frame Relay da due byte sono 0xfefe03cf, il flusso IWF considera il pacchetto come un pacchetto MLPPPoFR valido.

4. Le funzioni MLPPP sull'endpoint Frame Relay eseguono un'ulteriore elaborazione.

Le illustrazioni che seguono mostrano il formato dei pacchetti MLPPPoA e MLPPPoFR.

Figura 6. Sovraccarico MLPPPoA Solo il primo frammento ha un'intestazione PPP.

Figura 7. Sovraccarico MLPPPoFR. Solo il primo frammento ha un'intestazione PPP.

Requisiti di larghezza di banda VoIP

Quando si esegue il provisioning della larghezza di banda per il protocollo VoIP, il sovraccarico del collegamento dati deve essere incluso nei calcoli della larghezza di banda. La tabella 4 mostra i requisiti di larghezza di banda per chiamata per il VoIP a seconda del codec e dell'uso del protocollo RTP (Real-Time Transport Protocol) compresso. I calcoli riportati nella tabella 4 si basano sullo scenario ottimale per la compressione dell'intestazione RTP (cRTP), ovvero senza errori di checksum UDP o di trasmissione. Le intestazioni vengono quindi compresse in modo coerente da 40 byte a due byte.

Tabella 4 - Requisiti di larghezza di banda per chiamata VoIP (kbps).

Modalità FRF.8	Trasparente				Traduzione				Da Frame Relay a Frame Relay
Direzione traffico	Frame Relay su ATM		ATM su Frame Relay		Frame Relay su ATM		ATM su Frame Relay
Frame Relay o gamba ATM di PVC	Frame Relay	ATM	ATM	Frame Relay	Frame Relay	ATM	ATM	Frame Relay
G729 - 20 ms Esempi - No cRTP	27.6	42.4	42.4	28.4	27.6	42.4	42.4	27.6	26.8
G729 - 20 ms Esempi - cRTP	12.4	21.2	21.2	13.2	12.4	21.2	21.2	12.4	11.6
G729 - 30 ms Esempi - No cRTP	20.9	28.0	28.0	21.4	20.9	28.0	28.0	20.9	20.3
G729 - 30 ms - Esempi - cRTP	10.8	14.0	14.0	11.4	10.8	14.0	14.0	10.8	10.3
G711 - 20 ms Esempi - No cRTP	83.6	106.0	106.0	84.4	83.6	106.0	106.0	83.6	82.8
G711 - 20 ms Esempi - cRTP	68.4	84.8	84.8	69.2	68.4	84.8	84.8	68.4	67.6
G711 - 30 ms Esempi - No cRTP	76.3	97.9	97.9	76.8	76.3	97.9	97.9	76.3	75.8
G711 - Esempi da 30 ms - cRTP	66.3	84.0	84.0	66.8	66.3	84.0	84.0	66.3	65.7

Poiché il sovraccarico varia a seconda del segmento del PVC, si consiglia di progettare uno scenario che si verifichi nel peggiore dei casi. Ad esempio, consideriamo il caso di una chiamata G.279 con campionamento di 20 msec e cRTP su PVC trasparente. Sulla gamba Frame Relay, il requisito di larghezza di banda è 12,4 kbps in una direzione e 13,2 kbps nell'altra. Pertanto, si consiglia di effettuare il provisioning in base a 3,2 kbps per chiamata.

A scopo di confronto, la tabella mostra anche i requisiti di larghezza di banda VoIP su un PVC Frame Relay end-to-end configurato con frammentazione FRF.12. Come indicato nella tabella, il protocollo PPP utilizza tra 0,5 kbps e 0,8 kbps di larghezza di banda aggiuntiva per chiamata per supportare i byte dell'intestazione di incapsulamento aggiuntivi. Pertanto, si consiglia di utilizzare FRF.12 con Frame Relay VC end-to-end.

Il protocollo Compressed RTP (cRTP) over ATM richiede il software Cisco IOS® versione 12.2(2)T. Quando cRTP è abilitato con MLPoFR e MLPoATM, la compressione delle intestazioni TCP/IP viene abilitata automaticamente e non può essere disabilitata. Questa restrizione deriva dalla RFC 2509, che non consente la negoziazione PPP della compressione dell'intestazione RTP senza negoziare anche la compressione dell'intestazione TCP.

Traduzione e supporto trasparente sui dispositivi Cisco

In origine, LFI richiedeva che i dispositivi IWF utilizzassero la modalità trasparente. Più di recente, il forum Frame Relay ha introdotto FRF.8.1 per supportare la modalità di traduzione. Cisco ha introdotto il supporto per FRF.8.1 e la modalità di traduzione nelle seguenti versioni del software Cisco IOS:

• 12.0(18)W5(23) per LS1010 e Catalyst serie 8500 con 4CE1 FR-PAM (CSCdt39211)

• 12.2(3)T e 12.2(2) su router Cisco IOS con interfacce ATM, come PA-A3 (CSCdt70724)

Alcuni provider di servizi non supportano ancora la traduzione PPP sui dispositivi FRF.8. In questo caso, il provider deve configurare i PVC per la modalità trasparente.

Hardware e software

Questa configurazione utilizza i seguenti componenti hardware e software:

• Endpoint ATM - PA-A3-OC3 in un router serie 7200 con software Cisco IOS versione 12.2(8)T. (Nota: la funzionalità LFI è supportata solo sui router PA-A3-OC3 e PA-A3-T3. non è supportato sulle schede di porta IMA e ATM OC-12).

• Dispositivo IWF - LS1010 con modulo Channelized T3 port adapter e software Cisco IOS versione 12.1(8)EY.

• Endpoint Frame Relay - PA-MC-T3 in un router serie 7200 con software Cisco IOS versione 12.2(8)T.

Diagramma topologico

Configurazioni

Questa sezione illustra come configurare la funzione LFI su un collegamento FRF.8 in modalità trasparente. Utilizza un modello virtuale sui due endpoint del router, da cui viene duplicata l'interfaccia di accesso virtuale del bundle MLP. LFI supporta interfacce dialer e modelli virtuali per specificare i parametri a livello di protocollo di MLPPP. Il software Cisco IOS versione 12.2(8)T incrementa a 200 il numero di modelli virtuali univoci che possono essere configurati per router. Le versioni precedenti supportano solo fino a 25 modelli virtuali per router. Questa limitazione può essere un problema di scalabilità su un router di distribuzione ATM se è necessario che ogni PVC abbia un indirizzo IP univoco. Per ovviare al problema, usare IP come senza numero o sostituire i modelli virtuali con interfacce dialer sui collegamenti numerati.

Cisco IOS versione 12.1(5)T ha introdotto il supporto per LFI su un solo collegamento membro per bundle MLPPP. Pertanto, questa configurazione utilizza solo una singola VC per ciascun endpoint. Il supporto di più sistemi di videoconferenza per bundle è previsto per la prossima versione di Cisco IOS.

Endpoint Frame Relay

L'adattatore della porta T3 canalizzata richiede la creazione di un gruppo di canali e la specifica dei timeslot. Per impostazione predefinita, non esistono interfacce. FRAMEside#show ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 172.16.142.231 YES NVRAM up up Loopback1 191.1.1.1 YES NVRAM up up Utilizzare il comando show diag per determinare la scheda di porta installata. In questo esempio, T3 PA si trova nello slot 3. Le versioni correnti di Cisco IOS visualizzano ora il numero di parte sostituibile (FRU) da ordinare in caso di guasto hardware. FRAMEside#show diag 3 Slot 3: CT3 single wide Port adapter, 1 port Port adapter is analyzed Port adapter insertion time 13:16:35 ago EEPROM contents at hardware discovery: Hardware revision 1.0 Board revision A0 Serial number 23414844 Part number 73-3037-01 FRU Part Number: PA-MC-T3= (SW) Test history 0x0 RMA number 00-00-00 EEPROM format version 1 EEPROM contents (hex): 0x20: 01 A0 01 00 01 65 48 3C 49 0B DD 01 00 00 00 00 0x30: 50 00 00 00 00 10 30 00 FF FF FF FF FF FF FF FF L'esecuzione del comando show controller t3 visualizza gli allarmi e le statistiche del livello fisico. FRAMEside#show controller t3 3/0 T3 3/0 is up. Hardware is CT3 single wide port adapter CT3 H/W Version : 1.0.1, CT3 ROM Version : 1.1, CT3 F/W Version : 2.4.0 FREEDM version: 1, reset 0 resurrect 0 Applique type is Channelized T3 No alarms detected. FEAC code received: No code is being received Framing is M23, Line Code is B3ZS, Clock Source is Internal Rx throttle total 0, equipment customer loopback Data in current interval (75 seconds elapsed): 2 Line Code Violations, 1 P-bit Coding Violation 0 C-bit Coding Violation, 1 P-bit Err Secs 0 P-bit Severely Err Secs, 0 Severely Err Framing Secs 0 Unavailable Secs, 1 Line Errored Secs 0 C-bit Errored Secs, 0 C-bit Severely Errored Secs [output omitted] Selezionate un T1 dalla modalità di configurazione del controller T3, create un gruppo di canali e assegnate al gruppo una serie di tempi. FRAMEside(config)#controller t3 3/0 b13-8-7204(config-controller)#? Controller configuration commands: cablelength cable length in feet (0-450) clock Specify the clock source for a T3 link default Set a command to its defaults description Controller specific description equipment Specify the equipment type for loopback mode exit Exit from controller configuration mode framing Specify the type of Framing on a T3 link help Description of the interactive help system idle Specify the idle pattern for all channels on a T3 interface loopback Put the entire T3 line into loopback mdl Maintenance Data Link Configuration no Negate a command or set its defaults shutdown Shut down a DS3 link (send DS3 Idle) t1 Create a T1 channel b13-8-7204(config-controller)#t1 ? <1-28> T1 Channel number <1-28> b13-8-7204(config-controller)#t1 1 channel-group ? <0-23> Channel group number b13-8-7204(config-controller)#t1 1 channel-group 1 ? timeslots List of timeslots in the channel group b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots ? <1-24> List of timeslots which comprise the channel b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots 1-2 b13-8-7204(config-controller)# 13:22:28: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to down 13:22:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down 13:22:46: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to up 13:22:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to up 13:23:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down Nota: se l'interfaccia remota collegata non è configurata in modo simile, viene visualizzato il livello di collegamento della nuova interfaccia canalizzata, ma il protocollo di linea rimane inattivo. L'interfaccia serial 3/0/1:1 identifica la nuova interfaccia canalizzata. Configurare l'interfaccia per Frame Relay Encapsulation, quindi abilitare Frame Relay Traffic Shaping (FRTS) sull'interfaccia principale. FRAMEside(config)#int serial 3/0/1:1 FRAMEside(config-if)#encapsulation frame-relay ietf FRAMEside(config-if)#frame-relay traffic-shaping !--- FRTS must be enabled for MLPoFR. Configurare una classe mappa Frame Relay per applicare i parametri di traffic shaping a Frame Relay VC (che verrà creato di seguito). FRAMEside(config)#map-class frame-relay mlp FRAMEside(config-map-class)#frame-relay cir ? <1-45000000> Applied to both Incoming/Outgoing CIR, Bits per second in Incoming CIR out Outgoing CIR FRAMEside(config-map-class)#frame-relay cir 128000 FRAMEside(config-map-class)#frame-relay mincir 128000 FRAMEside(config-map-class)#frame-relay bc ? <300-16000000> Applied to both Incoming/Outgoing Bc, Bits in Incoming Bc out Outgoing Bc <cr> FRAMEside(config-map-class)#frame-relay bc 1280 !--- Configure a burst committed (Bc) value of 1/100th of the CIR or 1280 bps. FRAMEside(config-map-class)#frame-relay be 0 !--- Configure an excess burst (Be) value of 0. FRAMeside(config-map-class)#no frame-relay adaptive-shaping Creare un criterio servizio QoS. Utilizzate gli stessi parametri del lato ATM. Vedere di seguito per riferimento. FRAMEside#show policy-map example Policy Map example Class voice Weighted Fair Queueing Strict Priority Bandwidth 110 (kbps) Burst 2750 (Bytes) Class class-default Weighted Fair Queueing Flow based Fair Queueing Bandwidth 0 (kbps) Max Threshold 64 (packets) Creare un'interfaccia di modello virtuale e applicare i parametri MLPPP. Applicare inoltre la policy sui servizi QoS al sistema VC. FRAMEside(config)#interface Virtual-Template1 FRAMEside(config-if)#ip address 1.1.1.2 255.255.255.0 FRAMEside(config-if)#service-policy output example FRAMEside(config-if)#ppp multilink FRAMEside(config-if)#ppp multilink fragment-delay 10 FRAMEside(config-if)#ppp multilink interleave FRAMEside(config-if)#end Creare una sottointerfaccia e assegnare il numero DLCI (Data Link Identifier) di Frame Relay. Applicare quindi l'incapsulamento PPP, il modello virtuale e la classe map. FRAMEside(config)#int serial 3/0/1:1.1 point FRAMEside(config-subif)#frame-relay interface-dlci ? <16-1007> Define a switched or locally terminated DLCI FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp ? Virtual-Template Virtual Template interface FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp Virtual-Template 1 FRAMEside(config-fr-dlci)#class mlp Usare il comando show frame-relay pvc per confermare i parametri virtual-template e map-class sul VC. FRAMEside#show frame-relay pvc 20 PVC Statistics for interface Serial3/0/1:1 (Frame Relay DTE) DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial3/0/1:1.1 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 00:03:24, last time pvc status changed 00:03:24 Bound to Virtual-Access1 (down, cloned from Virtual-Template1) cir 128000 bc 1280 be 0 byte limit 160 interval 10 mincir 128000 byte increment 160 Adaptive Shaping none pkts 0 bytes 0 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo Output queue 0/40, 0 drop, 0 dequeued Usare il comando show controller serial 3/0/1:1 per verificare che il collegamento Frame Relay sia nello stato attivo e non presenti allarmi sul livello fisico. A ciascuna interfaccia canalizzata viene assegnato un numero "VC". Nell'output seguente, al gruppo di canali 1 (3/0/1:1) viene assegnato un numero VC pari a 0. FRAMEside#show controller serial 3/0/1:1 CT3 SW Controller 3/0 ROM ver 0x10001, h/w ver 1.0.1, f/w ver 2.4.0, FREEDM rev 1 !--- FREEDM is the HDLC controller on the channelized T3 port adapter. It extracts data from the 24 timeslots of a T1, validates the CRC, and checks for any other frame errors. T3 linestate is Up, T1 linestate 0x00000002, num_active_idb 1 Buffer pool size 640, particle size 512, cache size 640, cache end 128/127 Rx desctable 0xF1A5A20, shadow 0x628C6AFC, size 512, spin 128 !--- When it initializes, the interface driver builds a control structure known as the receive ring. The receive ring consists of a list of 512 packet buffer descriptors. As packets arrive, FREEDM DMAs the data into the buffer to which a descriptor points. rx queue 0xF1B8000, cache 0xF1B8000, fq base 0xF1B8800 rdq base 0xF1B8000, host_rxrdqr 0xF1B8004, host_rxfqw 0xF1B8804 Tx desctable 0xF1A7A60, shadow 0x628B6AD0, size 4096, spin 256 !--- When it initializes, the interface driver also creates the transmit queue or transmit ring. In the case of the channelized T3 PA, the driver creates a queue of 4096 entries and sets all fields in the descriptors to NULL or empty. tx queue 0xF1C0000, cache 0xF1C0000 host_txrdqw 1802, fq base 0xF1C4000, host_txfqr 0xF1C5C20 dynamic txlimit threshold 4096 TPD cache 0x628C7A54, size 4096, cache end 4096/4094, underrun 0 RPD cache 0x628C7328, size 448, cache end 0 Freedm fifo 0x628AA7B0, head ptr 0x628AA7C8, tail ptr 0x628AB7A8, reset 0 PCI bus 6, PCI shared memory block 0xF1A454C, PLX mailbox addr 0x3D820040 FREEDM devbase 0x3D800000, PLX devbase 0x3D820000 Rx overruns 0, Tx underruns 0, tx rdq count 0 !--- The "tx rdq count" indicates the number of outstanding transmit packets in FREEDM's "transmit ready" queue. This queue holds a packet before it reaches the transmit ring. Tx bad vc 0 FREEDM err: cas 0, hdl 0, hdl_blk 0, ind_prov 0, tavail 0, tmac busy 0, rmac b usy 0 rxrdq_wt 0x2, rxrdq_rd 0x1, rxsfq_wt 0x201, rxsfq_rd 0x206 VC 0 (1:1) is enabled, T1 1 is enabled/Up, rx throttle 0 Interface Serial3/0/1:1 is up (idb status 0x84208080) xmitdelay 0, max pak size 1608, maxmtu 1500, max buf size 1524 started 8, throttled 0, unthrottled 0, in_throttle FALSE VC config: map 0xC0000000, timeslots 2, subrate 0xFF, crc size 2, non-inverted data freedm fifo num 3, start 0x628AA7B0, end 0x628AA7C0, configured = TRUE Rx pkts 0, bytes 0, runt 0, giant 0, drops 0 crc 0, frame 0, overrun 0, abort 1, no buf 0 Tx pkts 194313, bytes 2549490, underrun 0, drops 0, tpd udr 0 tx enqueued 0, tx count 0/36/0, no buf 0 tx limited = FALSE !--- The "tx count x/y/z" counter includes the following information: !--- "x" = Number of transmit ring entries in use. !--- "y" = Maximum number of packets allowed on the transmit queue. !--- "z" = Number of times that the transmit limit has been exceeded.

Configurazione LS1010

Utilizzare il comando show hardware per verificare che il sistema LS1010 sia dotato di un modulo PAM (Channel Relay Port Adapter Module). LS1010#show hardware LS1010 named LS1010, Date: 07:36:40 UTC Mon May 13 2002 Feature Card's FPGA Download Version: 11 Slot Ctrlr-Type Part No. Rev Ser No Mfg Date RMA No. Hw Vrs Tst EEP ---- ------------ ---------- -- -------- --------- -------- ------- --- --- 0/0 155MM PAM 73-1496-03 A0 02829507 May 07 96 00-00-00 3.1 0 2 1/0 1CT3 FR-PAM 73-2972-03 A0 12344261 May 17 99 00-00-00 3.0 0 2 2/0 ATM Swi/Proc 73-1402-03 B0 03824638 Sep 14 96 00-00-00 3.1 0 2 2/1 FeatureCard1 73-1405-03 B0 03824581 Sep 14 96 00-00-00 3.2 0 2 Usare il comando show ip int brief per identificare l'interfaccia del controller. LS1010#show ip int brief Interface IP-Address OK? Method Status Protocol ATM0/0/0 unassigned YES unset up up ATM0/0/1 unassigned YES unset down down ATM0/0/2 unassigned YES unset down down ATM0/0/3 unassigned YES unset down down ATM-P1/0/0 unassigned YES unset up up T3 1/0/0 unassigned YES unset up up Creare un'interfaccia canalizzata e selezionare gli stessi timeslot dell'adattatore della porta seriale (PA). LS1010(config)#controller t3 1/0/0 LS1010(config-controller)#channel-group 1 t1 ? <1-28> T1 line number <1-28> LS1010(config-controller)#channel-group 1 t1 1 timeslots ? <1-24> List of timeslots which comprise the channel LS1010(config-controller)#channel-group 1 t1 1 timeslot 1-2 LS1010(config-controller)# 2w1d: %LINK-3-UPDOWN: Interface Serial1/0/0:1, changed state to up 2w1d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:1, changed state to up Configurare l'incapsulamento Frame Relay sulla nuova interfaccia seriale. Inoltre, modificare il tipo di Local Management Interface (LMI) da NNI a DCE. LS1010(config)#int serial 1/0/0:1 LS1010(config-if)#encap frame ? ietf Use RFC1490 encapsulation LS1010(config-if)#encap frame ietf LS1010(config-if)#frame-relay intf-type dce Per confermare l'incapsulamento Frame Relay, usare il comando show interface serial. LS1010#show int serial 1/0/0:1 Serial1/0/0:1 is up, line protocol is up Hardware is FRPAM-SERIAL MTU 4096 bytes, BW 128 Kbit, DLY 0 usec, reliability 139/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY IETF, loopback not set Keepalive set (10 sec) LMI enq sent 32, LMI stat recvd 0, LMI upd recvd 0 LMI enq recvd 40, LMI stat sent 40, LMI upd sent 0, DCE LMI up LMI DLCI 1023 LMI type is CISCO frame relay DCE !--- By default, the serial PAM and the serial PA use LMI type Cisco. The serial PAM should show DCE LMI status of "up", and the serial PA should show DTE LMI status of "up". Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 Last input 00:00:03, output 00:00:05, output hang never Last clearing of "show interface" counters 00:06:40 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 44 packets input, 667 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 71 packets output, 923 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Timeslots(s) Used: 1-2 on T1 1 Frames Received with: DE set: 0, FECN set :0, BECN set: 0 Frames Tagged : DE: 0, FECN: 0 BECN: 0 Frames Discarded Due to Alignment Error: 0 Frames Discarded Due to Illegal Length: 0 Frames Received with unknown DLCI: 5 Frames with illegal Header : 0 Transmit Frames with FECN set :0, BECN Set :0 Transmit Frames Tagged FECN : 0 BECN : 0 Transmit Frames Discarded due to No buffers : 0 Default Upc Action : tag-drop Default Bc (in Bits) : 32768 LS1010#show frame lmi LMI Statistics for interface Serial1/0/0:1 (Frame Relay DCE) LMI TYPE = CISCO< Invalid Unnumbered info 0 Invalid Prot Disc 0 Invalid dummy Call Ref 0 Invalid Msg Type 0 Invalid Status Message 0 Invalid Lock Shift 0 Invalid Information ID 0 Invalid Report IE Len 0 Invalid Report Request 0 Invalid Keep IE Len 0 Num Status Enq. Rcvd 120 Num Status msgs Sent 120 Num Update Status Sent 0 Num St Enq. Timeouts 0 Prima di configurare il PVC, verificare che l'interfaccia ATM sia attiva/attiva. LS1010#show int atm 0/0/0 ATM0/0/0 is up, line protocol is up Hardware is oc3suni MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 0 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 2 packets/sec 253672 packets input, 13444616 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 2601118 packets output, 137859254 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Oltre alle due interfacce fisiche, l'LS1010 utilizza un'interfaccia logica per collegare il lato ATM e il lato Frame Relay. L'interfaccia logica è identificata come "atm-p1" sulla pseudo interfaccia ATM. LS1010#show int atm-p1/0/0 ATM-P1/0/0 is up, line protocol is up Hardware is ATM-PSEUDO MTU 4470 bytes, sub MTU 4470, BW 45000 Kbit, DLY 0 usec, reliability 0/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Keepalive not supported Encapsulation(s): 2000 maximum active VCs, 0 current VCCs VC idle disconnect time: 300 seconds Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out In modalità di configurazione interfaccia seriale, configurare il PVC di interoperabilità. interface Serial1/0/0:1 no ip address encapsulation frame-relay IETF no arp frame-relay frame-relay intf-type dce frame-relay pvc 20 service transparent interface ATM0/0/0 1 100 Confermare la configurazione con il comando show vc interface atm. LS1010#show vc int atm 0/0/0 Interface Conn-Id Type X-Interface X-Conn-Id Encap Status ATM0/0/0 0/5 PVC ATM0 0/39 QSAAL UP ATM0/0/0 0/16 PVC ATM0 0/35 ILMI UP ATM0/0/0 1/100 PVC Serial1/0/0:1 20 UP

Endpoint ATM

Assicurarsi di utilizzare un PA ATM o PA-A3 migliorato. Per confermare, usare il comando show interface atm. ATMside#show int atm 1/0/0 ATM1/0/0 is up, line protocol is up Hardware is cyBus ENHANCED ATM PA MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Encapsulation(s): AAL5 4095 maximum active VCs, 0 current VCCs [output omitted] Configurare i parametri del livello ATM del circuito virtuale permanente (PVC). In questa configurazione, viene utilizzata una sottointerfaccia point-to-point con una velocità di cella sostenuta (SCR) di 150 kbps. Questo valore è stato selezionato per essere circa il 15% più alto del CIR di 128 kbps dell'endpoint Frame Relay. Il 15% in più aiuta a garantire che la videoconferenza offra una larghezza di banda equivalente al traffico utente su entrambi i lati della connessione, tenendo conto anche del sovraccarico di gestione del terminale ATM. Vedere anche Configurazione del traffic shaping su Frame Relay su PVC ATM Service Interworking (FRF.8). ATMside(config)#int atm 1/0/0.1 point ATMside(config-subif)#pvc 1/100 ATMside(config-if-atm-vc)#vbr-nrt 300 150 ? <1-65535> Maximum Burst Size(MBS) in Cells <cr> ATMside(config-if-atm-vc)#vbr-nrt 300 150 ATMside(config-if-atm-vc)#end ATMside(config-if-atm-vc)#tx-ring-limit 4 !--- Tune down the transmit ring to push most queueing to the layer-3 queues, where our service policy will apply. Confermare che il VC sia visualizzato nella tabella VC. Eseguire il comando show atm vc. Il router assegna una dimensione massima della frammentazione (MBS) predefinita di 94 in quanto non è stato immesso un valore esplicito. ATMside#show atm vc VCD / Peak Avg/Min Burst Interface Name VPI VCI Type Encaps SC kbps kbps Cells Sts 1/0/0.1 1 1 100 PVC SNAP VBR 300 150 94 UP Creare un criterio servizio QoS. Nel criterio mostrato di seguito sono state create quattro classi, inclusa la classe predefinita classe creata dal router. Creare una mappa di classe per i pacchetti VoIP (Voice over IP). ATMside(config)#class-map voice ATMside(config-cmap)#match ip rtp ? <2000-65535> Lower bound of UDP destination port ATMside(config-cmap)#match ip rtp 16384 ? <0-16383> Range of UDP ports ATMside(config-cmap)#match ip rtp 16384 16383 !--- Cisco IOS H.323 devices use this UDP port range to transmit VoIP packets. Creare una mappa di classe per i pacchetti di segnalazione vocale. In questo esempio viene usato H.323 Fast Connect. (Vedere anche la sezione "Linee guida per la configurazione LLQ" di VoIP over PPP Links with Quality of Service (LLQ / IP RTP Priority, LFI, cRTP). class-map voice-signaling match access-group 103 ! access-list 103 permit tcp any eq 1720 any access-list 103 permit tcp any any eq 1720 Creare una mappa dei criteri denominata e assegnare azioni QoS a ogni classe. In questo esempio viene assegnata la coda di priorità ai pacchetti utente VoIP con il comando priority e una garanzia di larghezza di banda minima ai pacchetti di segnalazione delle chiamate con il comando bandwidth. Tutto il resto del traffico viene indirizzato alla classe predefinita, che separa il traffico nei flussi del livello IP e fornisce una coda equa tra i flussi. policy-map example class call-control bandwidth percent 10 class voice priority 110 class class-default fair-queue Confermare la configurazione. ATMside#show policy-map example Policy Map example Class call-control bandwidth percent 10 Class voice priority 110 Class class-default fair-queue Creare un modello virtuale e applicarvi i criteri del servizio QoS. interface Virtual-Template1 bandwidth 150 ip address 1.1.1.1 255.255.255.0 service-policy output example ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave !--- You select a fragment size indirectly by specifying the maximum tolerable serialization delay. The recommended maximum per-hop serialization delay for voice environments is 10 milliseconds (ms). LFI also requires ppp multilink interleave. Applicare il modello virtuale e l'incapsulamento multilink-PPP al PVC ATM. ATMside(config)#int atm 1/0/0.1 ATMside(config-subif)#pvc 1/100 ATMside(config-if-atm-vc)#protocol ppp ? Virtual-Template Virtual Template interface dialer pvc is part of dialer profile ATMside(config-if-atm-vc)#protocol ppp Virtual-Template 1 Confermare le impostazioni sul PVC ATM. ATMside#show run int atm 1/0/0.1 Building configuration... Current configuration : 127 bytes ! interface ATM1/0/0.1 point-to-point pvc 1/100 vbr-nrt 300 150 tx-ring-limit 4 protocol ppp Virtual-Template1 ! end Il router crea automaticamente un'interfaccia di accesso virtuale. Se MLPPP non è configurato sull'endpoint Frame Relay, lo stato dell'interfaccia di accesso virtuale è attivo/inattivo. ATMside#show int virtual-access 1 Virtual-Access1 is up, line protocol is down Hardware is Virtual Access interface Internet address is 1.1.1.1/24 MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 5 seconds on reset LCP Listen, multilink Closed Closed: LEXCP, BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP, IPV6CP Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 Cloned from virtual-template: 1

Comandi show e debug

Endpoint ATM

Per verificare il corretto funzionamento di LFI, utilizzate i seguenti comandi sull'endpoint ATM. Prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.

• show ppp multilink - LFI utilizza due interfacce di accesso virtuale, una per PPP e una per il bundle MLP. Utilizzare il comando show ppp multilink per distinguere i due tipi di collegamento.

  ATMside#show ppp multilink 
  Virtual-Access2, bundle name is FRAMEside 
  
  !--- The bundle interface is assigned to VA 2.
  
    Bundle up for 01:11:55 
    Bundle is Distributed 
    0 lost fragments, 0 reordered, 0 unassigned 
    0 discarded, 0 lost received, 1/255 load 
    0x1E received sequence, 0xA sent sequence 
    Member links: 1 (max not set, min not set) 
      Virtual-Access1, since 01:11:55, last rcvd seq 00001D  187 weight 
  
  !--- The PPP interface is assigned to VA 1.
  
  

• show interface virtual-access 1: conferma che l'interfaccia di accesso virtuale è attiva/attiva e incrementa i contatori dei pacchetti di input e output.

  ATMside#show int virtual-access 1 
  Virtual-Access1 is up, line protocol is up 
    Hardware is Virtual Access interface 
    Internet address is 1.1.1.1/24 
    MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, 
       reliability 255/255, txload 1/255, rxload 1/255 
    Encapsulation PPP, loopback not set 
    DTR is pulsed for 5 seconds on reset 
    LCP Open, multilink Open 
    Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 
    Cloned from virtual-template: 1 
    Last input 01:11:30, output never, output hang never 
    Last clearing of "show interface" counters 2w1d 
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
    Queueing strategy: fifo 
    Output queue :0/40 (size/max) 
    5 minute input rate 0 bits/sec, 0 packets/sec 
    5 minute output rate 0 bits/sec, 0 packets/sec 
       878 packets input, 13094 bytes, 0 no buffer 
       Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
       0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
       255073 packets output, 6624300 bytes, 0 underruns 
       0 output errors, 0 collisions, 0 interface resets 
       0 output buffer failures, 0 output buffers swapped out 
       0 carrier transitions 
  

• show policy-map in virtual-access 2: confermare che il criterio del servizio QoS è associato all'interfaccia del bundle MLPPP.

  ATMside#show policy-map int virtual-access 2 
   Virtual-Access2 
  
    Service-policy output: example 
  
      queue stats for all priority classes: 
        queue size 0, queue limit 27 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
  
      Class-map: call-control (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: access-group 103 
        queue size 0, queue limit 3 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
        Bandwidth: 10%, kbps 15 
  
      Class-map: voice (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: ip rtp 16384 16383 
        Priority: kbps 110, burst bytes 4470, b/w exceed drops: 0 
  
      Class-map: class-default (match-any) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: any 
        queue size 0, queue limit 5 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
        Fair-queue: per-flow queue limit 2
  

• debug ppp packet e debug atm packet: utilizzare questi comandi se tutte le interfacce sono attive/attive, ma non è possibile eseguire il ping da un'estremità all'altra. È inoltre possibile utilizzare questi comandi per acquisire pacchetti keepalive PPP, come illustrato di seguito.

  2w1d: Vi1 LCP-FS: I ECHOREQ [Open] id 31 len 12 magic 0x52FE6F51 
  2w1d: ATM1/0/0.1(O): 
  VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
  2w1d: CFC0 210A 1F00 0CB1 2342 E300 0532 953F 
  2w1d: 
  2w1d: Vi1 LCP-FS: O ECHOREP [Open] id 31 len 12 magic 0xB12342E3 
  
  !--- This side received an Echo Request and responded with an outbound Echo Reply.
  
  2w1d: Vi1 LCP: O ECHOREQ [Open] id 32 len 12 magic 0xB12342E3 
  2w1d: ATM1/0/0.1(O): 
  VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
  2w1d: CFC0 2109 2000 0CB1 2342 E300 049A A915 
  2w1d: Vi1 LCP-FS: I ECHOREP [Open] id 32 len 12 magic 0x52FE6F51 
  2w1d: Vi1 LCP-FS: Received id 32, sent id 32, line up
  
  !--- This side transmitted an Echo Request and received an inbound Echo Reply.
  
  

Endpoint Frame Relay

Per verificare il corretto funzionamento di LFI, usare i comandi seguenti sull'endpoint Frame Relay. Prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.

• show ppp multilink - LFI utilizza due interfacce di accesso virtuale, una per PPP e una per il bundle MLP. Utilizzare il comando show ppp multilink per distinguere i due tipi di collegamento.

  FRAMEside#show ppp multilink 
  
  Virtual-Access2, bundle name is ATMside 
    Bundle up for 01:15:16 
    0 lost fragments, 0 reordered, 0 unassigned 
    0 discarded, 0 lost received, 1/255 load 
    0x19 received sequence, 0x4B sent sequence 
    Member links: 1 (max not set, min not set) 
      Virtual-Access1, since 01:15:16, last rcvd seq 000018  59464 weight 
  

• show policy-map interface virtual-access: conferma che il criterio del servizio QoS è associato all'interfaccia del bundle MLPPP.

  FRAMEside#show policy-map int virtual-access 2 
   Virtual-Access2 
    Service-policy output: example 
  
      Class-map: voice (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: ip rtp 16384 16383 
        Weighted Fair Queueing 
          Strict Priority 
          Output Queue: Conversation 264 
          Bandwidth 110 (kbps) Burst 2750 (Bytes) 
          (pkts matched/bytes matched) 0/0 
          (total drops/bytes drops) 0/0 
  
      Class-map: class-default (match-any) 
        27 packets, 2578 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: any 
        Weighted Fair Queueing 
          Flow Based Fair Queueing 
          Maximum Number of Hashed Queues 256 
          (total queued/total drops/no-buffer drops) 0/0/0 
  
  

• debug frame packet e debug ppp packet: utilizzare questi comandi se tutte le interfacce sono attive/attive, ma non è possibile eseguire il ping da estremità a estremità.

  FRAMEside#debug frame packet 
  Frame Relay packet debugging is on 
  FRAMEside# 
  FRAMEside#ping 1.1.1.1 
  Type escape sequence to abort. 
  Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: 
  !!!!! 
  Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms 
  FRAMEside# 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52
  
  

Accodamento e LFI

MLPPPoA e MLPPPoFR duplicano due interfacce di accesso virtuale dall'interfaccia di connessione o dal modello virtuale. Una di queste interfacce rappresenta il collegamento PPP, l'altra rappresenta l'interfaccia del bundle MLP. Usare il comando show ppp multilink per determinare l'interfaccia specifica usata per ciascuna funzione. A partire da questa scrittura, è supportato un solo VC per bundle, e quindi solo un'interfaccia di accesso virtuale dovrebbe apparire nell'elenco dei membri del bundle nell'output show ppp multilink.

Oltre alle due interfacce di accesso virtuale, ogni PVC è associato a un'interfaccia principale e a una sottointerfaccia. Ognuna di queste interfacce fornisce una qualche forma di coda. Tuttavia, solo l'interfaccia di accesso virtuale che rappresenta l'interfaccia del bundle supporta le code complesse tramite una policy di servizio QoS applicata. Le altre tre interfacce devono avere una coda FIFO. Quando si applica una policy di servizio a un modello virtuale, il router visualizza il messaggio seguente:

cr7200(config)#interface virtual-template 1
cr7200(config)#service-policy output Gromit
Class Base Weighted Fair Queueing not supported on interface Virtual-Access1

Nota: Class Based Weighted Fair Queueing è supportato solo sull'interfaccia del bundle MLPPP.

Questi messaggi sono normali. Nel primo messaggio viene indicato che i criteri di servizio non sono supportati nell'interfaccia di accesso virtuale PPP. Il secondo messaggio conferma l'applicazione della policy sui servizi all'interfaccia di accesso virtuale del bundle MLP. Per confermare il meccanismo di coda sull'interfaccia del bundle MLP, usare i comandi show interface virtual-access, show queue virtual-access e show policy-map interface virtual-access.

MLPPPoFR richiede che il Frame Relay Traffic Shaping (FRTS) sia abilitato sull'interfaccia fisica. FRTS attiva le code per-VC. Sulle piattaforme come le serie 7200, 3600 e 2600, la tecnologia FRTS è configurata con i due comandi seguenti:

• traffic shaping frame-relay sull'interfaccia principale

• map-class con qualsiasi comando shaping.

Nelle versioni correnti di Cisco IOS viene stampato il seguente messaggio di avviso se MLPPoFR viene applicato senza FRTS.

"MLPoFR not configured properly on Link x Bundle y"

Se viene visualizzato questo messaggio di avviso, verificare che FRTS sia stato configurato sull'interfaccia fisica e che i criteri del servizio QoS siano stati associati al modello virtuale. Per verificare la configurazione, utilizzare i comandi show running-config serial interface e show running-config virtual-template. Quando MLPPPoFR è configurato, il meccanismo di accodamento dell'interfaccia cambia in FIFO doppio, come mostrato di seguito. La coda ad alta priorità gestisce pacchetti voce e pacchetti di controllo, ad esempio l'interfaccia di gestione locale (LMI), mentre la coda a bassa priorità gestisce pacchetti frammentati, presumibilmente dati o pacchetti non voce.

Router#show int serial 6/0:0 
    Serial6/0:0 is up, line protocol is down 
      Hardware is Multichannel T1 
      MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, 
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation FRAME-RELAY, crc 16, Data non-inverted 
      Keepalive set (10 sec) 
      LMI enq sent  236, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down 
      LMI enq recvd 353, LMI stat sent  0, LMI upd sent  0 
      LMI DLCI 1023  LMI type is CISCO  frame relay DTE 
      Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 
      Last input 00:00:02, output 00:00:02, output hang never 
      Last clearing of "show interface" counters 00:39:22 
      Queueing strategy: dual fifo 
      Output queue: high size/max/dropped 0/256/0
 !--- high-priority queue

      Output queue 0/128, 0 drops; input queue 0/75, 0 drops
 !--- low-priority queue

      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
         353 packets input, 4628 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         353 packets output, 4628 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
         0 carrier transitions 
      no alarm present 
      Timeslot(s) Used:12, subrate: 64Kb/s, transmit delay is 0 flags

LFI utilizza due livelli di accodamento: il livello di bundle MLPPP, che supporta le code complesse, e il livello PVC, che supporta solo le code FIFO. L'interfaccia del bundle mantiene la propria coda. Tutti i pacchetti MLP passano attraverso il bundle MLP e i livelli di accesso virtuale prima del livello Frame Relay o ATM. LFI monitora le dimensioni delle code hardware dei collegamenti membro e rimuove i pacchetti dalle code hardware quando scendono al di sotto di una soglia, che in origine era un valore di due. In caso contrario, i pacchetti vengono accodati nella coda del bundle MLP.

Risoluzione dei problemi e problemi noti

Nella tabella seguente vengono elencati i problemi noti relativi a LFI su collegamenti FRF e vengono descritte le operazioni da eseguire per risolvere i problemi e individuare eventuali sintomi in un bug risolto.

Sintomo	Procedura di risoluzione dei problemi	Bug risolti
Throughput ridotto su gamba ATM o frame relay	Eseguire il ping tra i pacchetti di varie dimensioni da 100 byte e l'MTU Ethernet. I pacchetti di grandi dimensioni hanno timeout?	CSCdt59038 - Con i pacchetti da 1500 byte e la frammentazione impostata su 100 byte, ci sono 15 pacchetti frammentati. Il ritardo è stato causato da più livelli di coda. CSCdu18344 - Con FRTS, i pacchetti vengono rimossi dalla coda più lentamente del previsto. La funzione di rimozione dalla coda del bundle MLPPP controlla le dimensioni della coda di Traffic Shaper. FRTS è stato troppo lento nella cancellazione della coda.
Pacchetti non in ordine	Eseguire il comando show ppp multilink. Cercare i valori incrementali per i contatori "frammenti persi", "scartati" e "persi ricevuti". Virtual-Access4, bundle name is xyz Bundle up for 03:56:11 2524 lost fragments, 3786 reordered, 0 unassigned 1262 discarded, 1262 lost received, 1/255 load 0x42EA1 received sequence, 0xCF7 sent sequence Member links: 1 (max not set, min not set) Virtual-Access1, since 03:59:02, last rcvd seq 042EA0 400 weight Abilitare il debug di eventi multipli ppp e cercare i messaggi "Frammento perso" e "Non sincronizzato con il peer". *Mar 17 09:14:08.216: Vi4 MLP: Lost fragment 3FED9 in 'dhartr21' (all links have rcvd higher seq#) *Mar 17 09:14:08.232: Vi4 MLP: Received lost fragment seq 3FED9, expecting 3FEDC in 'dhartr21' *Mar 17 09:14:08.232: Vi4 MLP: Out of sync with peer, resyncing to last rcvd seq# (03FED9) *Mar 17 09:14:08.236: Vi4 MLP: Unusual jump in seq number, from 03FEDC to 03FEDA	CSCdv89201 - Quando l'interfaccia ATM fisica è congestionata, i frammenti MLP vengono scartati o ricevuti in modo non corretto sull'estremità remota. Questo problema riguarda solo i moduli di rete ATM sulle serie 2600 e 3600. La causa è da come il driver di interfaccia stesse scambiando erroneamente i pacchetti nel percorso rapido (ad esempio, con la commutazione veloce o con Cisco Express Forwarding). In particolare, il secondo frammento del pacchetto corrente è stato inviato dopo il primo frammento del pacchetto successivo
Perdita di connettività end-to-end quando la serie 3600 esegue il protocollo IWF in modalità trasparente	Impostate la modalità di traslazione e ripetete il test.	CSCdw11409 - Assicura che il CEF esegua la ricerca nella posizione corretta del byte per iniziare l'elaborazione delle intestazioni di incapsulamento dei pacchetti MLPPP

Informazioni correlate

• Configurazione della frammentazione e dell'interfoliazione del collegamento per Frame Relay e circuiti virtuali ATM
• Progettazione e distribuzione di Multilink PPP su Frame Relay e ATM
• RFC2364, PPP over AAL5, luglio 1998
• RFC1973, PPP in Frame Relay, giugno 1996
• RFC1717 - Protocollo MP (Multilink Protocol) PPP, novembre 1994
• Accordo di implementazione per l'interworking dei servizi Frame Relay / ATM PVC FRF.8
• Ulteriori informazioni su ATM
• Strumenti e risorse - Cisco Systems
• Documentazione e supporto tecnico – Cisco Systems