Configuración de la Fragmentación y el entrelazado de link (LFI) con switches campus ATM

Introducción

Este documento provee una descripción técnica general de Fragmentación y Entrelazado de Link (LFI) sobre una conexión Frame Relay a Conexión Entre Redes ATM (IWF) (según se define en el Foro de Frame Relay o el acuerdo FRF.8), así como una configuración de ejemplo para usar LS1010 o Catalyst 8500 dispositivo IWF en la nube WAN. LFI utiliza las capacidades de fragmentación incorporadas de la encapsulación del Multilink Point-to-Point Protocol (MLPPP) sobre ATM y Frame Relay para proporcionar una solución de fragmentación y entrelazado de extremo a extremo para links de baja velocidad con anchos de banda de hasta 768 kbps.

Prerequisites

Requirements

Este documento requiere la comprensión de lo siguiente:

• Entorno FRF.8 típico y modos de traducción y transparente FRF.8. Consulte Comprensión de los modos de traducción y transparente con FRF.8.

• Familiaridad con los comandos de configuración LS1010 y Catalyst 8500 y cómo el Adaptador de Puerto de Frame Relay E1 canalizado o el Adaptador de Puerto de Frame Relay DS3 canalizado realizan la interconexión entre un punto final de Frame Relay y un punto final ATM.

• Fluctuación y retraso de serialización. Consulte VoIP sobre links PPP con calidad de servicio (LLQ / prioridad IP RTP, LFI, cRTP) y VoIP sobre Frame Relay con calidad de servicio (fragmentación, modelado de tráfico, prioridad IP RTP).

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Por qué MLPPP sobre ATM y retransmisión de tramas

La fragmentación es una técnica clave para controlar la demora de serialización y la variación de demora en links de baja velocidad que transportan tráfico en tiempo real y no en tiempo real. La demora de serialización es la demora fija necesaria para registrar una trama de voz o datos en la interfaz de red, y está directamente relacionada con la velocidad de reloj en el trunk. Se necesita un indicador adicional para separar las tramas para velocidades de reloj bajas y tamaños de trama pequeños.

LFI utiliza las capacidades de fragmentación integradas de MLPPP para evitar la demora y la fluctuación (variaciones en la demora) causadas por paquetes grandes de tamaño variable que se colocan en cola entre paquetes de voz relativamente pequeños. Con LFI, los paquetes mayores que un tamaño de fragmento configurado se encapsulan en un encabezado MLPPP. RFC 1990 define el encabezado MLPPP así como lo siguiente:

• (B) El bit de fragmento inicial es un campo de un bit establecido en 1 en el primer fragmento derivado de un paquete PPP y establecido en 0 para todos los demás fragmentos del mismo paquete PPP.

• (E)El bit de fragmento final es un campo de un bit establecido en 1 en el último fragmento y en 0 para todos los demás fragmentos.

• El campo de secuencia es un número de 24 o 12 bits que se incrementa para cada fragmento transmitido. De forma predeterminada, el campo de secuencia es de 24 bits de longitud, pero se puede negociar para que sea solamente de 12 bits con la opción de configuración LCP que se describe a continuación.

Además de la fragmentación, los paquetes sensibles al retardo deben programarse con la prioridad adecuada entre fragmentos de un paquete grande. Con la fragmentación, Weighted Fair Queueing (WFQ) es "consciente" de si un paquete es parte de un fragmento o no está fragmentado. WFQ asigna un número de secuencia a cada paquete que llega y luego programa los paquetes en función de este número.

La fragmentación de la capa 2 proporciona una solución superior a todos los demás enfoques para resolver el "problema del paquete grande". En la tabla siguiente se enumeran las ventajas y desventajas de otras posibles soluciones.

Solución potencial	Ventajas	Desventajas
Aborte la transmisión del paquete grande y vuelva a ponerlo en cola detrás del tráfico sensible al retardo.	Sólo pospone la transmisión de paquetes. Cuando se retransmite el paquete, puede ocurrir el mismo problema. Si los paquetes se vuelven a poner en cola continuamente e incluso se descartan, puede ocurrir la escasez de ancho de banda.	Algunas interfaces físicas no admiten la transmisión anulada o introducen una penalización de rendimiento por hacerlo (como el restablecimiento de la cola de transmisión completa).
Fragmente el paquete grande mediante técnicas de fragmentación de la capa de red.	Tanto IP como CLNP admiten la fragmentación en cualquier router, con el reensamblado en el host de destino. Puede evitar la necesidad de fragmentar el paquete grande con detección de MTU. Utiliza un mecanismo global para superar lo que es esencialmente un problema local (de un salto): todos los saltos descendentes deben tratar con un mayor número de paquetes para conmutar, incluso si todos los links subsiguientes son rápidos. Anula la opción de compresión de encabezado TCP/IP.	Muchas aplicaciones no aceptan la fragmentación y establecen el bit "No fragmentar" en el encabezado IP. Estos paquetes se descartarán si se fragmentan. Las aplicaciones que no son capaces de aceptar paquetes fragmentados quedarán inoperables en este entorno.
Fragmente el paquete usando técnicas de capa de link.	Compatible con cualquier paquete de capa de red o paquete puenteado.	Proporciona fragmentación por enlace en lugar de requerir que los paquetes fragmentados se transporten de extremo a extremo. Sólo los routers conectados al link lento necesitan acomodar la administración y el reensamblado de paquetes adicionales.

El tamaño de fragmento ideal para el protocolo punto a punto multilink sobre ATM (MLPPPoATM) debería permitir que los fragmentos encajen en un múltiplo exacto de celdas ATM. Consulte Fragmentación y entrelazado de links para Frame Relay y circuito virtual ATM para obtener orientación sobre la selección de valores de fragmentación.

Encabezados MLPPPoA y MLPPPoFR

Una configuración típica de FRF.8 consiste en lo siguiente:

• Un punto final de Frame Relay

• Un punto final ATM

• Un dispositivo de interconexión (IWF)

Cada terminal encapsula paquetes de datos y voz en un encabezado de encapsulación de capa 2, que comunica el protocolo encapsulado y transportado en la trama o celda. Tanto Frame Relay como ATM admiten encabezados de encapsulación de ID de protocolo de capa de red (NLPID). El documento TR 9577 de la Comisión Electrotécnica Internacional (CEI)/ISO define valores NLPID conocidos para un número seleccionado de protocolos. Se asigna un valor de 0xCF a PPP.

RFC 1973 define PPP en Frame Relay y el encabezado MLPPPoFR, mientras que RFC 2364 define PPP sobre AAL5 y el encabezado MLPPPoA. Ambos encabezados utilizan un valor NLPID de 0xCF para identificar PPP como el protocolo encapsulado.

Cada uno de estos encabezados se ilustra en la Figura 1 a continuación.

Figura 1. Encabezado PPP sobre AAL5, encabezado MLPPPoA con encapsulación NLPID y encabezado MLPPPoA con multiplexación VC

Nota: El encabezado MLPPPoFR también incluye un campo de indicador de un byte de 0x7e, que no se muestra en la Figura 1. Después de los encabezados, el byte número 5 inicia los campos de protocolo PPP o MLPPP.

Tabla 1: FRF.8 Transparente frente a FRF.8 Traducción.

Figura 2 Cómo se fragmenta el paquete MLPPPoATM mediante NLPID.

Figura 3. Cómo se fragmenta el paquete MLPPPoATM mediante la multiplexación de VC.

A continuación se muestra el significado de los valores de bytes:

• 0xFEFE: identifica los puntos de acceso al servicio (SAP) de origen y destino en el encabezado Logical Link Control (LLC). Un valor de 0xFEFE indica que lo que sigue a continuación es un encabezado NLPID de forma corta, que se utiliza con protocolos que tienen un valor NLPID definido.

• 0x03 - Campo de control utilizado con muchas encapsulaciones, incluido High Level Data Link Control (HDLC). También indica que el contenido del paquete consiste en información no numerada.

• 0xCF: valor NLPID conocido para PPP.

Modo transparente FRF.8 versus modo de traducción

El acuerdo FRF.8 define dos modos operativos para el dispositivo IWF:

• Transparente - El dispositivo IWF reenvía los encabezados de encapsulación sin alteraciones. No realiza ningún mapeo de encabezado de protocolo, fragmentación o reensamblado.

• Traducción: el dispositivo IWF realiza la asignación de encabezado de protocolo entre los dos encabezados de encapsulación para tener en cuenta pequeñas diferencias entre los tipos de encapsulación.

El modo configurado en el dispositivo IWF, que puede ser un switch de campus ATM de Cisco o un router de la serie 7200 con un adaptador de puerto ATM PA-A3, cambia el número de bytes de encabezado de capa 2 en los segmentos ATM y Frame Relay del link de interconexión. Veamos esta sobrecarga con más detalle.

Las dos tablas siguientes muestran los bytes de tara de los paquetes de datos y los paquetes de voz sobre IP (VoIP).

Tabla 2: tara del link de datos en bytes para un paquete de datos sobre un link FRF.8.

Modo FRF.8			Transparente					Traducción
Dirección del tráfico			Frame Relay a ATM			ATM a Frame Relay		Frame Relay a ATM			ATM a Frame Relay
Frame Relay o tramo ATM del PVC			Frame Relay		ATM	ATM	Frame Relay	Frame Relay	ATM		ATM		Frame Relay
Indicador de Frame (0x7e)			1		0	0	1	1	0		1		0
Encabezado de Retransmisión de Tramas			2		0	0	2	2	0		0		2
LLC DSAP/SSAP (0xfefe)			0		0	2	2	0	2		2		0
Control LLC (0x03)			1		1	1	1	1	1		1		1
NLPID (Identificador de protocolo de capa de red) (0xcf para PPP)			1		1	1	1	1	1		1		1
ID de protocolo MLP (0x003d)			2		2	2	2	2	2		2		2
Número de secuencia MLP			4		4	4	4	4	4		4		4
ID del Protocolo PPP (Sólo primer fragmento)			2		2	2	2	2	2		2		2
Carga útil (Capa 3+)			0		0	0	0	0	0		0		0
Capa de adaptación (AAL)5 de ATM			0		8	8	0	0	8		8		0
Secuencia de verificación de tramas (FCS)			2		0	0	2	2	0		0		2
Tara total (bytes)			15		18	20	17	15	20		20		15

Tabla 3 - Sobrecarga de link de datos en bytes para un paquete VoIP sobre un link FRF.8.

Modo FRF.8	Transparente				Traducción				Frame Relay a Frame Relay
Dirección del tráfico	Frame Relay a ATM		ATM a Frame Relay		Frame Relay a ATM		ATM a Frame Relay
Frame Relay o tramo ATM del PVC	Frame Relay	ATM	ATM	Frame Relay	Frame Relay	ATM	ATM	Frame Relay
Indicador de Frame (0x7e)	1	0	0	1	1	0	0	1	1
Encabezado de Retransmisión de Tramas	2	0	0	2	2	0	0	2	2
LLC DSAP/SSAP (0xfefe)	0	0	2	2	0	2	2	0	0
Control LLC (0x03)	1	1	1	1	1	1	1	1	1
NLPID (Identificador de protocolo de capa de red) (0xcf para PPP)	1	1	1	1	1	1	1	1	1
PPP ID	2	2	2	2	2	2	2	2	0
Carga útil (IP+protocolo de datagrama de usuario (UDP)+RTP+voz)	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
Tara total (bytes)	9	12	14	11	9	14	14	9	7

Al revisar las tablas anteriores, tenga en cuenta lo siguiente:

• Los paquetes más pequeños que el tamaño de fragmentación especificado se encapsulan sólo en un encabezado PPP y no en un encabezado MLPPP. De manera similar, los paquetes mayores que el tamaño de fragmentación especificado se encapsulan tanto en un encabezado PPP como en un encabezado MLPPP. Por lo tanto, los paquetes VoIP tienen hasta ocho bytes menos de sobrecarga.

• Sólo el primer fragmento de Multilink PPP (MLP) incluye un campo de ID de protocolo PPP. Por lo tanto, el primer fragmento lleva dos bytes adicionales de sobrecosto.

• En el modo transparente, los encabezados de encapsulación se pasan sin cambios a través del dispositivo IWF. Por lo tanto, la sobrecarga varía en cada dirección y en cada segmento. Específicamente, un encabezado MLPPPoA comienza con un encabezado NLPID de forma corta de 0xFEFE. En el modo transparente, el dispositivo IWF pasa sin cambios este encabezado desde el segmento ATM al segmento Frame Relay. Sin embargo, en la dirección Frame Relay a ATM, no existe tal encabezado en el modo transparente en ninguno de los segmentos.

• En el modo de traducción, el dispositivo IWF cambia los encabezados de encapsulación. Por lo tanto, la sobrecarga es la misma en cada segmento en cualquier dirección. Específicamente, en la dirección ATM a Frame Relay, el extremo ATM encapsula el paquete en un encabezado MLPPPoA. El dispositivo IWF quita el encabezado NLPID antes de pasar la trama restante al segmento Frame Relay. En la dirección Frame Relay a ATM, el dispositivo IWF manipula nuevamente la trama y antepone un encabezado NLPID antes de pasar la trama segmentada al punto final ATM.

• Al diseñar links FRF con MLP, asegúrese de contar con el número correcto de bytes de tara de link de datos. Esta sobrecarga influye en la cantidad de ancho de banda consumido por cada llamada VoIP. Además participa en la determinación del tamaño óptimo del fragmento de MLP. Optimizar el tamaño del fragmento para que se ajuste a un número integral de celdas ATM es crítico, particularmente en PVC de baja velocidad donde se puede desperdiciar una cantidad significativa de ancho de banda al completar la última celda a un múltiplo par de 48 bytes.

Para mayor claridad, recorramos los pasos del proceso de encapsulación de paquetes cuando un paquete entra en la dirección Frame Relay a ATM con el modo transparente:

1. El extremo de Frame Relay encapsula el paquete en un encabezado MLPPPoFR.

2. El dispositivo IWF quita el encabezado Frame Relay de dos bytes con el identificador de conexión de enlace de datos (DLCI). Luego reenvía el paquete restante a la interfaz ATM de IWF, que segmenta el paquete en celdas y lo reenvía a través del segmento ATM.

3. El punto final ATM examina el encabezado del paquete recibido. Si los primeros dos bytes del paquete recibido son 0x03CF, el extremo ATM considera que el paquete es un paquete MLPPPoA válido.

4. Las funciones MLPPP en el punto final ATM realizan un procesamiento adicional.

Observe el proceso de encapsulación de paquetes cuando un paquete va en el ATM a la dirección Frame Relay con el modo transparente:

1. El extremo ATM encapsula el paquete en un encabezado MLPPPoA. Luego segmenta los paquetes en celdas y los reenvía fuera del segmento ATM.

2. El IWF recibe el paquete, lo reenvía a su interfaz de Frame Relay y antepone un encabezado de Frame Relay de dos bytes.

3. El punto final de Frame Relay examina el encabezado del paquete recibido. Si los primeros cuatro bytes después del encabezado Frame Relay de dos bytes son 0xfefe03cf, IWF trata el paquete como un paquete MLPPPoFR legal.

4. Las funciones MLPPP en el punto final de Frame Relay realizan un procesamiento adicional.

Las ilustraciones siguientes muestran el formato de los paquetes MLPPPoA y MLPPPoFR.

Figura 6. tara de MLPPPoA. Sólo el primer fragmento lleva un encabezado PPP.

Figura 7 tara de MLPPPoFR. Sólo el primer fragmento lleva un encabezado PPP.

Requisitos de ancho de banda para VoIP

Cuando se administra ancho de banda para VoIP, debe incluirse la tara del link de datos en los cálculos de ancho de banda. La tabla 4 muestra los requisitos de ancho de banda por llamada para VoIP en función del códec y del uso del protocolo de transporte en tiempo real (RTP) comprimido. Los cálculos de la tabla 4 asumen un escenario óptimo para la compresión del encabezado RTP (cRTP), en otras palabras, sin suma de comprobación UDP ni errores de transmisión. A continuación, los encabezados se comprimen de forma coherente de 40 bytes a dos bytes.

Tabla 4: Requisitos de ancho de banda de llamadas por VoIP (kbps).

Modo FRF.8	Transparente				Traducción				Frame Relay a Frame Relay
Dirección del tráfico	Frame Relay a ATM		ATM a Frame Relay		Frame Relay a ATM		ATM a Frame Relay
Frame Relay o tramo ATM del PVC	Frame Relay	ATM	ATM	Frame Relay	Frame Relay	ATM	ATM	Frame Relay
G729 - Muestras de 20 ms - Sin cRTP	27.6	42.4	42.4	28.4	27.6	42.4	42.4	27.6	26.8
G729 - Muestras de 20 ms - cRTP	12.4	21.2	21.2	13.2	12.4	21.2	21.2	12.4	11.6
G729 - Ejemplos de 30 ms - Sin cRTP	20.9	28.0	28.0	21.4	20.9	28.0	28.0	20.9	20.3
G729 - Ejemplos de 30 ms - cRTP	10.8	14.0	14.0	11.4	10.8	14.0	14.0	10.8	10.3
G711 - 20 ms Ejemplos - Sin cRTP	83.6	106.0	106.0	84.4	83.6	106.0	106.0	83.6	82.8
G711 - 20 ms Ejemplos - cRTP	68.4	84.8	84.8	69.2	68.4	84.8	84.8	68.4	67.6
G711 - 30 ms Ejemplos - Sin cRTP	76.3	97.9	97.9	76.8	76.3	97.9	97.9	76.3	75.8
G711 - Ejemplos de 30 ms - cRTP	66.3	84.0	84.0	66.8	66.3	84.0	84.0	66.3	65.7

Dado que la sobrecarga varía en cada tramo del PVC, recomendamos diseñar para el peor escenario posible. Por ejemplo, considere el caso de una llamada G.279 con muestreo de 20 mseg y cRTP a través de un PVC transparente. En el tramo Frame Relay, el requisito de ancho de banda es de 12,4 kbps en una dirección y 13,2 kbps en la otra. Por lo tanto, se recomienda un aprovisionamiento basado en 3,2 kbps por llamada.

Para fines de comparación, la tabla también muestra el requisito de ancho de banda de VoIP en un PVC de Frame Relay de extremo a extremo configurado con fragmentación FRF.12. Como se indica en la tabla, PPP consume entre 0.5 kbps y 0.8 kbps de ancho de banda adicional por llamada para soportar los bytes de encabezado de encapsulación adicionales. Por lo tanto, recomendamos utilizar FRF.12 con VC de Frame Relay de extremo a extremo.

El RTP comprimido (cRTP) sobre ATM requiere la versión 12.2(2)T del software Cisco IOS®. Cuando se habilita cRTP con MLPoFR y MLPoATM, la compresión de encabezado TCP/IP se habilita automáticamente y no se puede inhabilitar. Esta restricción es el resultado de RFC 2509, que no permite la negociación PPP de la compresión del encabezado RTP sin negociar también la compresión del encabezado TCP.

Traducción y soporte transparente en dispositivos de Cisco.

Originalmente, LFI requería que los dispositivos IWF usaran el modo transparente. Más recientemente, el Foro de Frame Relay introdujo FRF.8.1 para soportar el modo de traducción. Cisco introdujo el soporte para FRF.8.1 y el modo de traducción en las siguientes versiones de Cisco IOS Software:

• 12.0(18)W5(23) para LS1010 y Catalyst serie 8500 con un 4CE1 FR-PAM (CSCdt39211)

• 12.2(3)T y 12.2(2) en routers Cisco IOS con interfaces ATM, como PA-A3 (CSCdt70724)

Algunos proveedores de servicio aún no admiten la traducción PPP en sus dispositivos FRF.8. Siempre que este sea el caso, el proveedor debe configurar sus PVC para el modo transparente.

Hardware y software

Esta configuración utiliza el siguiente hardware y software:

• Punto final ATM: PA-A3-OC3 en un router de la serie 7200 que ejecuta la versión 12.2(8)T del software del IOS de Cisco. (Nota: LFI sólo es compatible con PA-A3-OC3 y PA-A3-T3. No es compatible con los adaptadores de puerto IMA y ATM OC-12.)

• Dispositivo IWF: LS1010 con módulo de adaptador de puerto T3 canalizado y Cisco IOS Software Release 12.1(8)EY.

• Punto final de Frame Relay: PA-MC-T3 en un router serie 7200 que ejecuta la versión 12.2(8)T del software del IOS de Cisco.

Diagrama de topología

Configuraciones

Esta sección muestra cómo configurar la función LFI sobre un link FRF.8 en modo transparente. Utiliza una plantilla virtual en los dos terminales del router, desde la que se clona la interfaz de acceso virtual del paquete MLP. LFI admite interfaces de marcador y plantillas virtuales para especificar los parámetros de la capa de protocolo de MLPPP. La versión 12.2(8)T del software del IOS de Cisco aumenta a 200 el número de plantillas virtuales únicas que se pueden configurar por router. Las versiones anteriores solo admitían hasta 25 plantillas virtuales por router. Esta limitación puede ser un problema de escalado en un router de distribución ATM si se requiere que cada PVC tenga una dirección IP única. Como solución alternativa, utilice IP como no numerado o reemplace las plantillas virtuales por interfaces de marcador en links numerados.

Cisco IOS Release 12.1(5)T introdujo el soporte para LFI sobre un solo link miembro por conjunto MLPPP. Por lo tanto, esta configuración utiliza solo un VC en cada punto final. Está previsto que se admitan varios VC por paquete para una próxima versión de Cisco IOS.

Punto final de retransmisión de tramas

El adaptador de puerto T3 canalizado requiere que cree un grupo de canal y especifique los intervalos de tiempo. De forma predeterminada, no existen interfaces. 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 Utilice el comando show diag para determinar el adaptador de puerto instalado. En este ejemplo, el PA T3 está en la ranura 3. Las versiones actuales de Cisco IOS ahora muestran el número de pieza reemplazable in situ (FRU) que se debe pedir en caso de que se produzca un fallo de 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 La ejecución del comando show controller t3 muestra las alarmas y estadísticas de la capa física. 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] Seleccione un T1 en el modo de configuración del controlador T3, cree un grupo de canal y asigne intervalos de tiempo al grupo. 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: Si la interfaz remota conectada no se configura de manera similar, la capa de link de la nueva interfaz canalizada se activa, pero el protocolo de línea permanece inactivo. La interfaz serial 3/0/1:1 identifica la nueva interfaz canalizada. Configure la interfaz para la encapsulación de Frame Relay y, a continuación, habilite el Modelado de tráfico de Frame Relay (FRTS) en la interfaz principal. 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. Configure una clase de mapa de retransmisión de tramas para aplicar parámetros de modelado de tráfico al VC de retransmisión de tramas (que se creará a continuación). 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 Cree una política de servicio de QoS. Utilice los mismos parámetros que el lado ATM. Consulte a continuación para ver las referencias. 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) Cree una interfaz de plantilla virtual y aplique los parámetros MLPPP. Aplique también la política de servicio de QoS al 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 Cree una subinterfaz y asigne el número de identificador de conexión de enlace de datos (DLCI) de Frame Relay. A continuación, aplique la encapsulación PPP, la plantilla virtual y la clase de mapa. 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 Utilice el comando show frame-relay pvc para confirmar los parámetros virtual-template y map-class en el 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 Use el comando show controller serial 3/0/1:1 para confirmar que el link Frame Relay está en estado activo y sin alarmas de capa física. A cada interfaz canalizada se le asigna un número "VC". En el siguiente resultado, al grupo de canales 1 (3/0/1:1) se le asigna un número de VC de 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.

Configuración LS1010

Utilice el comando show hardware para confirmar que el LS1010 está equipado con un módulo de adaptador de puerto (PAM) de Frame Relay canalizado. 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 Utilice el comando show ip int brief para identificar la interfaz del controlador. 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 Cree una interfaz canalizada y seleccione los mismos intervalos de tiempo que el adaptador de puerto serie (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 Configure la encapsulación de Frame Relay en la nueva interfaz serial. Además, cambie el tipo de interfaz de administración local (LMI) de 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 Utilice el comando show interface serial para confirmar la encapsulación de Frame Relay. 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 Antes de configurar el PVC, asegúrese de que la interfaz ATM esté activa/activa. 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 Además de las dos interfaces físicas, el LS1010 utiliza una interfaz lógica para vincular el lado ATM y el lado Frame Relay. La interfaz lógica se identifica como "atm-p1" en la pseudointerfaz 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 En el modo de configuración de interfaz serial, configure el PVC de interconexión. 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 Confirme su configuración con el 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

Punto de finalización ATM

Asegúrese de que está utilizando un ATM PA o PA-A3 mejorado. Utilice el comando show interface atm para confirmar. 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] Configure los parámetros de la capa ATM del circuito virtual permanente (PVC). En esta configuración, estamos utilizando una subinterfaz punto a punto con una velocidad de celda sostenida (SCR) de 150 kbps. Este valor fue seleccionado para ser aproximadamente un 15% más alto que la CIR de 128 kbps del punto final de Frame Relay. El 15% adicional ayuda a garantizar que el VC ofrezca un ancho de banda equivalente al tráfico de usuario real en ambos lados de la conexión, al tiempo que se acomoda la sobrecarga adicional del lado ATM. (Vea también Configuración del modelado de tráfico en PVC de Frame Relay a interconexión de servicios ATM (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. Confirme que su VC aparezca en la tabla de VC. Ejecute el comando show atm vc. Tenga en cuenta que el router asigna un tamaño de ráfaga máxima (MBS) predeterminado de 94, ya que no se ha introducido un valor explícito. 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 Cree una política de servicio de QoS. En la política que se muestra a continuación, creamos cuatro clases, incluida la clase class-default creada por el router. Cree un mapa de clase para los paquetes de voz sobre IP (VoIP). 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. Cree un mapa de clase para los paquetes de señalización de voz. Este ejemplo utiliza H.323 Fast Connect. (Vea también la sección "Lineamientos de configuración LLQ" de VoIP sobre links PPP con calidad de servicio (LLQ / prioridad IP RTP, 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 Cree un policy-map con nombre y asigne acciones de QoS a cada clase. Este ejemplo asigna la colocación en cola prioritaria a los paquetes de usuario VoIP con el comando priority y una garantía de ancho de banda mínimo a los paquetes de señalización de llamada con el comando bandwidth. El resto del tráfico va a la clase class-default, que separa el tráfico en flujos de capa IP y proporciona una colocación en cola justa entre los flujos. policy-map example class call-control bandwidth percent 10 class voice priority 110 class class-default fair-queue Confirme su configuración. ATMside#show policy-map example Policy Map example Class call-control bandwidth percent 10 Class voice priority 110 Class class-default fair-queue Cree una plantilla virtual y aplíquele la política de servicio de 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. Aplique la plantilla virtual y la encapsulación 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 Confirme la configuración en el 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 El router crea automáticamente una interfaz de acceso virtual. Si no tiene MLPPP configurado en el punto final de Frame Relay, el estado de la interfaz de acceso virtual es up/down. 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

comandos show y debug

Punto de finalización ATM

Utilice los siguientes comandos en el punto final ATM para confirmar que LFI funciona correctamente. Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

• show ppp multilink - LFI utiliza dos interfaces de acceso virtual — una para PPP y otra para el conjunto MLP. Utilice el show ppp multilink para diferenciar entre los dos.

  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 - Confirme que la interfaz de acceso virtual esté activa/activa e incrementando los contadores de paquetes de entrada y salida.

  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 int virtual-access 2 - Confirme que la política de servicio de QoS está vinculada a la interfaz de agrupamiento 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 y debug atm packet - Utilice estos comandos si todas las interfaces están up/up, pero no puede hacer ping de extremo a extremo. Además, puede utilizar estos comandos para capturar señales de mantenimiento PPP, como se ilustra a continuación.

  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.
  
  

Punto final de retransmisión de tramas

Utilice los siguientes comandos en el punto final de Frame Relay para confirmar que LFI funciona correctamente. Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

• show ppp multilink - LFI utiliza dos interfaces de acceso virtual — una para PPP y otra para el conjunto MLP. Utilice el show ppp multilink para diferenciar entre los dos.

  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 - Confirme que la política de servicio de QoS está vinculada a la interfaz de conjunto 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 y debug ppp packet: utilice estos comandos si todas las interfaces están activadas, pero no puede hacer ping de extremo a extremo.

  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
  
  

Almacenamiento en cola y LFI

MLPPPoA y MLPPPoFR clonan dos interfaces de acceso virtual desde la interfaz del marcador o la plantilla virtual. Una de estas interfaces representa el link PPP y la otra representa la interfaz de conjunto MLP. Utilice el comando show ppp multilink para determinar la interfaz específica utilizada para cada función. Al momento de escribir esto, sólo se soporta un VC por conjunto, y por lo tanto, sólo una interfaz de acceso virtual debería aparecer en la lista de miembros del conjunto en la salida show ppp multilink.

Además de las dos interfaces de acceso virtual, cada PVC está asociado con una interfaz principal y una subinterfaz. Cada una de estas interfaces proporciona algún tipo de colocación en cola. Sin embargo, sólo la interfaz de acceso virtual que representa la interfaz de agrupamiento admite la colocación en cola elaborada mediante una política de servicio de QoS aplicada. Las otras tres interfaces deben tener cola FIFO. Al aplicar una política de servicio a una plantilla virtual, el router muestra el siguiente mensaje:

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 soportado solamente en la interfaz de agrupamiento MLPPP.

Estos mensajes son normales. El primer mensaje está indicando que una política de servicio no es admitida en la interfaz de acceso virtual PPP. El segundo mensaje confirma que la política de servicio se aplica a la interfaz de acceso virtual del conjunto MLP. Para confirmar el mecanismo de colocación en cola en la interfaz de agrupamiento MLP, utilice los comandos show interface virtual-access, show queue virtual-access y show policy-map interface virtual-access.

MLPPPoFR requiere que el Modelado de tráfico de retransmisión de tramas (FRTS) esté habilitado en la interfaz física. FRTS activa las colas por VC. En plataformas como las series 7200, 3600 y 2600, FRTS se configura con los siguientes dos comandos:

• frame-relay traffic-shaping en la interfaz principal

• map-class con cualquier comando de modelado.

Las versiones actuales de Cisco IOS imprimen el siguiente mensaje de advertencia si MLPPoFR se aplica sin FRTS.

"MLPoFR not configured properly on Link x Bundle y"

Si ve este mensaje de advertencia, asegúrese de que se haya configurado FRTS en la interfaz física y de que la política de servicio de QoS se haya adjuntado a la plantilla virtual. Para verificar la configuración, utilice los comandos show running-config serial interface y show running-config virtual-template. Cuando MLPPPoFR está configurado, el mecanismo de colocación en cola de la interfaz cambia a FIFO dual, como se ilustra a continuación. La cola de alta prioridad gestiona paquetes de voz y paquetes de control, como la interfaz de administración local (LMI), y la cola de baja prioridad gestiona paquetes fragmentados, presumiblemente paquetes de datos o de no voz.

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 utiliza dos capas de colocación en cola: el nivel de agrupamiento MLPPP, que admite la colocación en cola elaborada, y el nivel PVC, que sólo admite la colocación en cola FIFO. La interfaz de agrupamiento mantiene su propia cola. Todos los paquetes MLP pasan por el conjunto MLP y las capas de acceso virtual primero antes que la capa Frame Relay o ATM. LFI monitorea el tamaño de las colas de hardware de los links miembros y quita de la cola los paquetes a las colas de hardware cuando caen por debajo de un umbral, que originalmente era un valor de dos. De lo contrario, los paquetes se colocan en cola en la cola de agrupamiento MLP.

Solución de problemas y problemas conocidos

La siguiente tabla enumera los problemas conocidos con LFI sobre links FRF y se centra en los pasos de troubleshooting a seguir para aislar sus síntomas en un bug resuelto.

Síntoma	Pasos para la resolución de problemas	Errores resueltos
Menor rendimiento en tramo ATM o tramo Frame Relay	Haga ping con paquetes de varios tamaños desde 100 bytes a la MTU Ethernet. ¿Los paquetes grandes experimentan tiempos de espera?	CSCdt59038 - Con los paquetes de 1500 bytes y la fragmentación establecida en 100 bytes, hay 15 paquetes fragmentados. El retraso fue causado por varios niveles de colocación en cola. CSCdu18344 - Con FRTS, los paquetes se quitan de la cola más lentamente de lo esperado. La función MLPPP bundle dequeue verifica el tamaño de cola de la cola del modelador de tráfico. FRTS tardó demasiado en borrar esta cola.
Paquetes fuera de servicio	Ejecute el comando show ppp multilink. Busque valores incrementales para los contadores de "fragmentos perdidos", "descartados" y "recibidos perdidos". 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 Habilite debug ppp multi events y busque los mensajes "Lost fragment" y "Out of sync with 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 - Cuando la interfaz ATM física está congestionada, los fragmentos MLP se descartan o reciben fuera de servicio en el extremo remoto. Este problema afecta solamente a los módulos de red ATM en las series 2600 y 3600. Es el resultado de cómo el controlador de interfaz estaba conmutando paquetes incorrectamente en el trayecto rápido (como con el fast switching o Cisco Express Forwarding). Específicamente, el segundo fragmento del paquete actual se envió después del primer fragmento del paquete siguiente
Pérdida de conectividad de extremo a extremo cuando la serie 3600 ejecuta IWF en modo transparente	Cambie el modo a translational y vuelva a realizar la prueba.	CSCdw11409 - Asegura que CEF busque en la ubicación de bytes correcta para comenzar a procesar los encabezados de encapsulación de los paquetes MLPPP

Información Relacionada

• Configuración de la fragmentación y el entrelazado de link para circuitos virtuales ATM y Frame Relay
• Diseño e implementación del PPP de link múltiple sobre Frame Relay y ATM
• RFC2364, PPP Over AAL5, julio de 1998
• RFC1973, PPP in Frame Relay, junio de 1996
• RFC1717, The PPP Multilink Protocol (MP), noviembre de 1994
• Acuerdo de Implementación de Interconexión de Servicio Frame Relay / ATM PVC FRF.8
• Más información sobre ATM
• Herramientas y recursos - Cisco Systems
• Soporte Técnico y Documentación - Cisco Systems