Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

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

Encabezados MLPPPoA y MLPPPoFR

Modo transparente FRF.8 versus modo de traducción

Requisitos de ancho de banda para VoIP

Traducción y soporte transparente en dispositivos de Cisco.

Hardware y software

Diagrama de topología

Configuraciones

comandos show y debug

Punto de finalización ATM

Punto final de retransmisión de tramas

Almacenamiento en cola y LFI

Solución de problemas y problemas conocidos

Información Relacionada

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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