Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Perché MLPPP su ATM e Frame Relay?

Intestazioni MLPPPoA e MLPPPoFR

FRF.8 Modalità trasparenti e di conversione

Requisiti di larghezza di banda VoIP

Traduzione e supporto trasparente sui dispositivi Cisco

Hardware e software

Diagramma topologico

Configurazioni

Comandi show e debug

Endpoint ATM

Endpoint Frame Relay

Accodamento e LFI

Risoluzione dei problemi e problemi noti

Informazioni correlate

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

1. 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

2. 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

3. 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]

4. 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.

5. 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.

6. 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

7. 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)

8. 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

9. 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

10. 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

11. 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

1. 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

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

1. 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]

2. 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.

3. 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

4. Creare un criterio servizio QoS. Nel criterio mostrato di seguito sono state create quattro classi, inclusa la classe predefinita classe creata dal router.

1. 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.

2. 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

3. 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

4. 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

5. 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.

6. 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

7. 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

8. 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