Modo de transferencia asíncrona (ATM) : Administración de tráfico ATM

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

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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.

prerrequisitos

Requisitos

Este documento requiere una comprensión del siguiente:

Componentes Utilizados

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

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

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

La fragmentación es una técnica dominante para controlar el retraso de serialización y la variación de retraso en los links de baja velocidad que llevan el tráfico en tiempo real y no en tiempo real. El retraso de serialización es el retraso fijo requerido cronometrar una trama de voz o de datos sobre la interfaz de la red, y se relaciona directamente con la velocidad del reloj en el trunk. Un indicador adicional es necesario separar las tramas para las velocidades del reloj bajas y los pequeños tamaños de trama.

El LFI utiliza las capacidades de fragmentación incorporada de MLPPP de prevenir la fluctuación y retraso (variaciones en el retardo) causada por los paquetes grandes variable-clasificados que son hechos cola entre relativamente los paquetes de voz pequeños. Con el LFI, los paquetes más grandes que un tamaño del fragmento configurado se encapsulan en un encabezamiento MLPPP. El RFC 1990leavingcisco.com define el encabezamiento MLPPP así como el siguiente:

  • (B) el bit eginning del fragmento es un conjunto de un campo de bit a 1 en el primer fragmento derivado de un paquete PPP y conjunto a 0 para el resto de los fragmentos del mismo paquete PPP.

  • (E) el bit nding del fragmento es un conjunto de un campo de bit a 1 en el fragmento más reciente y conjunto a 0 para el resto de los fragmentos.

  • El campo sequence es un número 24-bit o 12-bit que se incremente para cada fragmento transmitido. Por abandono, el campo sequence es 24 bits de largo, pero se puede negociar para ser solamente 12 bits con la opción de configuración LCP descrita más abajo.

Además de la fragmentación, los paquetes sensibles al retraso se deben programar con la prioridad adecuada entre los fragmentos de un paquete grande. Con la fragmentación, la feria cargada que hace cola (WFQ) es “enterada” de si un paquete es parte de al fragmento o es unfragmented. El WFQ asigna un número de secuencia a cada paquete de llegada y después programa los paquetes basados en este número.

La fragmentación de la capa 2 proporciona una solución superior al resto de los acercamientos en solucionar el “problema del grande-paquete.” La tabla siguiente enumera las ventajas y desventajas de otras soluciones potenciales.

Solución potencial Ventajas Desventajas
Aborte la transmisión del paquete grande y hágala cola detrás del tráfico sensible al retraso.
  • Pospone solamente la transmisión de paquetes.
  • Cuando se retransmite el paquete, el mismo problema puede ocurrir. Si los paquetes se hacen cola continuamente e incluso se caen, la reducción de ancho de banda puede resultar.
  • Algunas interfaces físicas no soportan la transmisión abortada ni introducen una multa de rendimiento para hacer tan (por ejemplo el reajuste de la cola de transmisión entera).
Haga fragmentos del paquete grande usando las técnicas de fragmentación de la capa de red.
  • IP y fragmentación de soporte de CLNP en cualquier router, con el nuevo ensamble ocurriendo en la computadora principal de destino.
  • Puede evitar la necesidad de hacer fragmentos del paquete grande con la detección de MTU.
  • Utiliza un mecanismo global para superar cuál es esencialmente un problema local (del uno-salto) - todos los saltos rio abajo deben ocuparse de un número más grande de paquetes para conmutar, incluso si todos los links subsiguientes son rápidos.
  • Anula la opción de la compresión del encabezado TCP/IP.
  • Muchas aplicaciones no validan la fragmentación y fijar “no haga fragmentos” mordido en el encabezado IP. Estos paquetes serán caídos si están hechos fragmentos. Las aplicaciones que no son capaces de validar los paquetes fragmentados serán hechas inoperables en este entorno.
Haga fragmentos del paquete usando las técnicas de la capa de link.
  • Soportado con cualquier paquete de capas de red o paquete Bridged.
  • Proporciona la fragmentación del por-link bastante que requiriendo los paquetes fragmentados ser de punta a punta transportado. Solamente el Routers asociado al link lento necesita acomodar la dirección y el nuevo ensamble de los paquetes adicionales.

El tamaño del fragmento ideal para el protocolo multilink point-to-point sobre la atmósfera (MLPPPoATM) debe permitir que los fragmentos quepan en un múltiplo exacto de las células ATM. Vea configurar la fragmentación de link y la interpolación para el Frame Relay y los circuitos virtuales ATM para la dirección en la selección de los valores de fragmentación.

Encabezados MLPPPoA y MLPPPoFR

Una configuración típica del FRF.8 consiste en el siguiente:

  • Un punto final de Frame Relay

  • Un punto final ATM

  • Un dispositivo que intertrabaja (IWF)

Cada punto final encapsula los paquetes de voz y datos en un encabezado de encapsulado de la capa 2, que comunica el protocolo encapsulado y transportado en la trama o la célula. El Frame Relay y las atmósferas soportan los encabezados de encapsulado del Network Layer Protocol ID (NLPID). El documento electrotécnico de la Comisión ISO/International (IEC) TR 9577 define los Valores conocidos de NLPID para un número selecto de protocolos. Un valor de 0xCF se asigna al PPP.

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

Cada uno de estas encabezados se ilustra en el cuadro 1 abajo.

/image/gif/paws/24041/mlpppoatm_encaps.gif

Cuadro 1. encabezado del PPP over AAL5, encabezado MLPPPoA con la encapsulación NLPID, y encabezado MLPPPoA con la multiplexión de VC

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

Cuadro 1 - FRF.8 transparente contra el FRF.8 de translación.

mlpppoatm_headers.gif

mlpppoatm_nlpid_frag_ex.gif

Figura 2 Cómo el paquete MLPPPoATM se hace fragmentos usando el NLPID.

mlpppoatm_vcmux_frag_ex.gif

Figura 3. Cómo el paquete MLPPPoATM se hace fragmentos usando la multiplexión de VC.

/image/gif/paws/24041/mlpofr_atm_header.gif

El significado de los valores de byte se muestra abajo:

  • 0xFEFE - Identifica el destino y los puntos de acceso de servicio de origen (savias) en la encabezado del Logical Link Control (LLC). Un valor de 0xFEFE indica que lo que sigue después es un encabezado de NLPID abreviado, que se utiliza con los protocolos que tienen un valor NLPID definido.

  • 0x03 - Campo de control usado con muchas encapsulaciones, incluyendo el High-Level Data Link Control (HDLC). También indica que el contenido del paquete consiste en la información sin numerar.

  • 0xCF - Valor conocido de NLPID para el PPP.

Modo transparente FRF.8 versus modo de traducción

El acuerdo FRF.8 define a dos modos de operación para el dispositivo IWF:

  • Transparente - Dispositivo IWF adelante los encabezados de encapsulado inalterados. No realiza ningún mapeo de encabezado de protocolos, fragmentación o nuevo ensamble.

  • Traducción - El dispositivo IWF realiza el mapeo de encabezado de protocolos entre los dos encabezados de encapsulado para explicar las pequeñas diferencias entre los tipos de encapsulación.

El modo configurado en el dispositivo IWF, que puede ser un switch de oficinas centrales Cisco ATM o un 7200 Series Router con un adaptador de puerto ATM PA-A3, cambia el número de bytes del encabezado de la capa 2 en la atmósfera y los segmentos de Frame Relay de intertrabajar conectan. Miremos estos gastos indirectos más detalladamente.

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

Cuadro 2 - Tara de link de datos en los 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

Cuadro 3 - Tara de link de datos en los bytes para un paquete de 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

En el repaso de las tablas arriba, observe el siguiente:

  • Los paquetes más pequeños que el tamaño de fragmentación especificado se encapsulan solamente en un encabezado PPP y no en un encabezamiento MLPPP. Semejantemente, los paquetes más grandes que el tamaño de fragmentación especificado se encapsulan en un encabezado PPP y un encabezamiento MLPPP. Así, los paquetes de VoIP tienen hasta ocho bytes menos de los gastos indirectos.

  • Solamente el primer fragmento del Multilink PPP (MLP) incluye un campo del protocolo PPP ID. Así, el primer fragmento lleva dos byes adicionales de los gastos indirectos.

  • En el modo transparente, los encabezados de encapsulado se pasan sin cambiar a través del dispositivo IWF. Así, los gastos indirectos varían en cada dirección y en cada segmento. Específicamente, un encabezado MLPPPoA comienza con un encabezado de NLPID abreviado de 0xFEFE. En el modo transparente, esta encabezado es pasada sin cambiar por el dispositivo IWF del segmento atmósfera al segmento de Frame Relay. Sin embargo, en el Frame Relay a la Dirección de ATM, ninguna tal encabezado existe en el modo transparente en cualquier segmento.

  • En el modo de traducción, el dispositivo IWF cambia los encabezados de encapsulado. Así, los gastos indirectos son lo mismo en cada segmento en cualquier dirección. Específicamente, en la dirección del ATM a Frame Relay, el punto final ATM encapsula el paquete en un encabezado MLPPPoA. El dispositivo IWF quita el encabezado de NLPID antes de pasar la trama restante al segmento de Frame Relay. En el Frame Relay a la Dirección de ATM, el dispositivo IWF manipula la trama y prepends otra vez un encabezado de NLPID antes de pasar la trama dividida en segmentos al punto final ATM.

  • Cuando el diseño del FRF conecta al MLP, esté seguro de explicar el número correcto de bytes de la tara de link de datos. Tales gastos indirectos influencian la cantidad de ancho de banda consumida por cada llamada VoIP. Además participa en la determinación del tamaño óptimo del fragmento de MLP. La optimización del tamaño del fragmento para caber a un número entero de células ATM es crítica, determinado en los PVC despacio donde una cantidad significativa de ancho de banda se puede perder en completar la célula más reciente a un incluso múltiple de 48 bytes.

Para mayor clareza los propósitos, nos dejan recorrer con los pasos del proceso de encapsulación de paquete cuando un paquete entra en el Frame Relay a la Dirección de ATM con el modo transparente:

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

  2. El dispositivo IWF quita el encabezador de Frame Relay de dos bytes con el identificador de conexión de link de datos (DLCI). Él entonces adelante el paquete restante a la interfaz ATM IWF, que divide el paquete en las células y adelante lo en segmentos a través del segmento atmósfera.

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

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

Mire el proceso de encapsulación de paquete cuando un paquete entra en la atmósfera a la dirección de Frame Relay con el modo transparente:

  1. El punto final ATM encapsula el paquete en un encabezado MLPPPoA. Entonces divide los paquetes en segmentos en las células y adelante ellas hacia fuera el segmento atmósfera.

  2. El IWF recibe el paquete, adelante él a su interfaz de Frame Relay, y prepends un encabezador de Frame Relay de dos bytes.

  3. El punto final de Frame Relay examina la encabezado del paquete recibido. Si los primeros cuatro bytes después de que el encabezador de Frame Relay de dos bytes sea 0xfefe03cf, el IWF tratan el paquete como paquete legal MLPPPoFR.

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

Los ejemplos siguientes muestran el formato de MLPPPoA y de los paquetes MLPPPoFR.

/image/gif/paws/24041/mlpppoa-overhead.gif

Cuadro 6. tara de MLPPPoA. Solamente el primer fragmento lleva un encabezado PPP.

mlpppofr-overhead.gif

Cuadro 7. tara MLPPPoFR. Solamente 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. El cuadro 4 muestra los requisitos del ancho de banda de por llamada para el VoIP dependiendo del codificador-decodificador y del uso del (RTP) del protocolo compressed real-time transport. Los cálculos en el cuadro 4 asumen un mejor de los casos para la Compresión de cabecera RTP (cRTP), es decir ningún checksum de UDP o errores de transmisión. Las encabezados entonces se comprimen constantemente a partir 40 bytes a dos bytes.

Cuadro 4 - Por los requerimientos de ancho de banda de la llamada 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 - 20 ms muestras - ningún cRTP 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G729 - 20 ms muestras - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G729 - 30 ms muestras - ningún cRTP 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G729 - 30 ms muestras - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G711 - 20 ms muestras - ningún 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 - muestras 30ms - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

Puesto que los gastos indirectos varían en cada pierna del PVC, recomendamos el diseñar para un escenario de caso peor. Por ejemplo, considere el caso de una llamada G.279 con el muestreo 20 milisegundos y del cRTP a través de un PVC transparente. En el tramo Frame Relay, los requerimientos de ancho de banda son 12.4 kbps en una dirección y 13.2 kbps en la otra. Así, recomendamos la disposición basada en 3.2 kbps por la llamada.

A efectos de comparación, la tabla también muestra los requisitos de ancho de banda para VoIP en un Frame Relay de extremo a extremo PVC configurado con la fragmentación FRF.12. Como se apunta en la tabla, el PPP consume entre 0.5 kbps y 0.8 kbps del ancho de banda adicional por la llamada para soportar los bytes adicionales del encabezado de encapsulado. Así, recomendamos usando el FRF.12 con el Frame Relay de extremo a extremo VCs.

El Compressed RTP (cRTP) sobre la atmósfera requiere el Software Release 12.2(2)T del ½ del ¿Â de Cisco IOSïÂ. Cuando el cRTP se habilita con el MLPoFR y el MLPoATM, la compresión del encabezado TCP/IP se habilita y no puede automáticamente ser inhabilitada. Esta restricción resulta del RFC 2509, que no permite la negociación PPP de la Compresión de cabecera RTP sin la Compresión de cabecera TCP también de negociación.

Traducción y soporte transparente en dispositivos de Cisco.

Originalmente, el LFI requirió que los dispositivos IWF utilicen al modo transparente. Más recientemente, el foro de Frame Relay introdujo el FRF.8.1 para apoyar al modo de traducción. Cisco presentó al soporte para el FRF.8.1 y al modo de traducción en las versiones del Cisco IOS Software siguientes:

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

  • 12.2(3)T y 12.2(2) en el Routers del Cisco IOS con las interfaces ATM, tales como el PA-A3 (CSCdt70724)

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

Hardware y software

El capítulo de descripción general de los Link Efficiency Mechanism enumera el hardware admitido para la característica LFI. Esta configuración utiliza el hardware y software siguiente:

  • Punto final ATM - PA-A3-OC3 en un Cisco IOS Software Release 12.2(8)T corriente del 7200 Series Router. (Nota: El LFI se soporta en el PA-A3-OC3 y el PA-A3-T3 solamente. No se soporta en los adaptadores de puerto IMA y atmósfera OC-12.)

  • Dispositivo IWF - LS1010 con puerto T3 canalizado el módulo adapter y el Cisco IOS Software Release 12.1(8)EY.

  • Punto final de Frame Relay - PA-MC-T3 en un Cisco IOS Software Release 12.2(8)T corriente del 7200 Series Router.

Diagrama de topología

/image/gif/paws/24041/lfi-topology.gif

Configuraciones

Esta sección muestra cómo configurar la característica LFI sobre un link FRF.8 en el modo transparente. Utiliza una plantilla virtual en los dos puntos finales del router, de los cuales se reproduce la interfaz de acceso virtual del paquete de MLP. El LFI soporta las interfaces del dialer y las plantillas virtuales para especificar los parámetros de la capa del protocolo del MLPPP. El Cisco IOS Software Release 12.2(8)T aumenta a 200 el número de plantillas virtuales únicas que se puedan configurar por el router. Las versiones anteriores soportan solamente hasta 25 plantillas virtuales por el router. Esta limitación puede ser un problema de ampliación en un router de distribución atmósfera si cada PVC se requiere para tener un IP Address único. Como solución alternativa, utilice el IP como innumerable o substituya las plantillas virtuales por las interfaces del dialer en los links numerados.

El Cisco IOS Release 12.1(5)T introdujo el soporte para el LFI sobre solamente un link de miembro por el conjunto MLPPP. Así, esta configuración utiliza solamente un solo VC en cada punto final. El soporte para VCs múltiple por el conjunto se planea para una próxima versión del Cisco IOS.

Punto final de retransmisión de tramas
  1. Puerto T3 canalizado el adaptador requiere que usted cree a un canal-grupo y especifique los intervalos de tiempo. Por abandono, ningunas interfaces existen.
    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 de determinar el adaptador de puerto instalado. En este ejemplo, el T3 PA está en las versiones actuales del slot 3. del Cisco IOS ahora visualiza el numero de parte reemplazable en el terreno (FRU) para ordenar en caso de una falla 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 visualiza las alarmas de capa física y las estadísticas.
    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 dentro del modo de configuración de controlador T3, cree a un canal-grupo, y asigne los 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 asociada no se configura semejantemente, la capa de link de la nueva interfaz canalizada sube, pero el Line Protocol permanece abajo.

  5. El serial 3/0/1:1 de la interfaz identifica la nueva interfaz canalizada. Configure la interfaz para la Encapsulación de Frame Relay y después habilite el Control 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 correspondencia de Frame Relay para aplicar los parámetros de modelado del tráfico al VC de Frame Relay (que serán creados abajo).
    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ósfera. Vea abajo para la referencia.
    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. También aplique la servicio-directiva 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 del identificador de la conexión de link de datos de Frame Relay (DLCI). Entonces aplique la encapsulación PPP, la plantilla virtual, y el map-class.
    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 de confirmar su virtual-plantilla y parámetros del 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. Utilice el serial 3/0/1:1 del regulador de la demostración para confirmar que el link de Frame Relay está en un estatus y un claro ascendentes de las alarmas de capa física. Cada interfaz canalizada se asigna un número del “VC”. En el producto siguiente, el canal-grupo 1 (3/0/1:1) se asigna un número del 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 de confirmar que su LS1010 está equipado de un módulo canalizado del adaptador de puerto de Frame Relay (PAM).
    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 de identificar la interfaz del regulador.
    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 serial (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) del NNI al 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 de 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 que usted configure el PVC, asegúrese de que la interfaz ATM sea up/up.
    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 conectar el lado atmósfera y al lado de Frame Relay. La interfaz lógica se identifica como "atm-p1" en el seudo interfaz atmósfera.
    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 la configuración de la interfaz serial, configure el PVC que intertrabaja.
    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 usted esté utilizando un ATM PA mejorado o un PA-A3. Utilice el comando show interface atm de 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 continua de celda (SCR) de 150 kbps. Este valor fue seleccionado para ser el cerca de 15% más alto que el CIR del punto final de Frame Relay del kbps 128. Las ayudas adicionales del 15% para asegurarse de que el VC entregue un ancho de banda equivalente al tráfico del usuario real a ambos lados de la conexión mientras que acomode los gastos indirectos adicionales del lado atmósfera. (Véase también configurar el modelado de tráfico en el Frame Relay al ATM Service Interworking (FRF.8) los PVC.)
    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 aparece en la tabla del VC. Ejecute el comando show atm vc. Observe que el router asigna un máximo predeterminado del tamaño de ráfaga (MBS) de 94 puesto que no ingresamos 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 directiva mostrada abajo, creamos cuatro clases, incluyendo el clase class-default router-creado.
    1. Cree un clase-mapa para los paquetes de la 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 clase-mapa para los paquetes de la señalización de voz. Este ejemplo utiliza H.323 rápidamente conecta. (Véase también el sección “Instrucciones para la configuración de LLQ” del VoIP sobre los links PPP con la calidad de servicio (prioridad de RTP LLQ/IP, LFI, el 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 una asignación de políticas denominada y asigne las acciones de QoS a cada clase. Este ejemplo asigna la prioridad que hace cola a los paquetes del usuario de VoIP con el comando priority y una garantía mínima del ancho de banda a los paquetes de la señalización de llamada con el comando bandwidth. El resto del tráfico va al clase class-default, que separa el tráfico en los flujos de la capa IP y proporciona la justo-espera 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 aplique la política de servicio de QoS a ella.
    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 encapsulación de la plantilla virtual y del Multilink PPP a la atmósfera PVC.
    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 sus configuraciones en la atmósfera PVC.
    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 una interfaz de acceso virtual automáticamente. Si usted no tiene MLPPP configurado en el punto final de Frame Relay, el estatus de la interfaz de acceso virtual es arriba/abajo.
    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 de confirmar que el LFI está trabajando correctamente. Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

  • muestre el multilink ppp - El LFI utiliza dos interfaces de acceso virtual -- uno para el PPP y uno para el paquete de MLP. Utilice el multilink ppp de la demostración para distinguir 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 es up/up y incrementar los contadores de los paquetes de entrada y de 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á limitada al bundle interface 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
    
  • haga el debug del paquete ppp y haga el debug del paquete ATM - utilice estos comandos si todas las interfaces son up/up, pero usted no puede hacer ping el End to End. Además, usted puede utilizar estos comandos de capturar las señales de mantenimiento de PPP, según lo ilustrado abajo.

    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 de confirmar que el LFI está trabajando correctamente. Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

  • muestre el multilink ppp - El LFI utiliza dos interfaces de acceso virtual -- uno para el PPP y uno para el paquete de MLP. Utilice el multilink ppp de la demostración para distinguir 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 
    
  • acceso virtual del show policy-map interface - Confirme que la política de servicio de QoS está limitada al bundle interface 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 
    
    
  • haga el debug del paquete de trama y haga el debug del paquete ppp - Utilice estos comandos si todas las interfaces son up/up, pero usted no puede hacer ping de punta a punta.

    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 reproducen dos interfaces de acceso virtual de la interfaz del dialer o de la plantilla virtual. Una tal interfaz representa el link PPP, y la otra representa la interfaz del paquete de MLP. Utilice el comando show ppp multilink de determinar la interfaz específica usada para cada función. A partir de esta escritura, solamente un VC por el conjunto se soporta, y solamente una interfaz de acceso virtual debe aparecer así en la lista de los miembros del agrupamiento en la salida del multilink ppp de la demostración.

Además de las dos interfaces de acceso virtual, cada PVC se asocia a una interfaz principal y a una subinterfaz. Cada uno de estas interfaces proporciona una cierta forma de espera. Sin embargo, solamente la interfaz de acceso virtual que representa el bundle interface soporta la espera de lujo vía una política de servicio aplicada de QoS. Las otras tres interfaces deben tener espera (Primero en Entrar, Primero en Salir FIFO). Al aplicar una servicio-directiva a una virtual-plantilla, el router visualiza 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 en el bundle interface MLPPP solamente.

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 servicio-directiva está aplicada a la interfaz de acceso virtual del paquete de MLP. Para confirmar el Mecanismo para formar la cola en la interfaz del paquete de MLP, utilice los comandos show interface virtual-access, show queue virtual-access, y show policy-map interface virtual-access.

MLPPPoFR requiere ese Control de tráfico de Frame Relay (FRTS) se habilite en la interfaz física. El FRTS activa las colas de administración del tráfico por VC. En las Plataformas tales como los 7200, los 3600, y las 2600 Series, el FRTS se configura con los dos comandos siguientes:

  • formar EL tráfico del Frame Relay en la interfaz principal

  • map-class con cualquier comandos shaping.

Las versiones actuales del Cisco IOS imprimen el mensaje de advertencia siguiente si MLPPoFR es aplicado sin el FRTS.

"MLPoFR not configured properly on Link x Bundle y"

Si usted ve este mensaje de advertencia, asegúrese de que el FRTS se haya configurado en la interfaz física y de que la política de servicio de QoS se ha asociado a la plantilla virtual. Para verificar la configuración, utilice los comandos show running-config serial interface y show running-config virtual-template. Cuando se configura MLPPPoFR, el Mecanismo para formar la cola de la interfaz cambia para doblarse (Primero en Entrar, Primero en Salir FIFO), según lo ilustrado abajo. La cola de alta prioridad maneja los paquetes de voz y los paquetes de control, tales como Interfaz de administración local (LMI), y la cola de baja prioridad maneja los paquetes fragmentados, probablemente los datos o los paquetes sin 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

El LFI utiliza dos capas de espera -- Nivel del conjunto MLPPP, que soporta la espera de lujo, y nivel PVC, que soporta solamente la espera (Primero en Entrar, Primero en Salir FIFO). El bundle interface mantiene su propia cola. Todos los paquetes MLP pasan con las capas del paquete de MLP y del acceso virtual primero antes del Frame Relay o de la capa ATM. El LFI monitorea el tamaño de las colas de hardware de los links de miembro y dequeues los paquetes a las colas de hardware cuando caen debajo de un umbral, que era originalmente un valor de dos. Si no, los paquetes se hacen cola en la cola del paquete de MLP.

Solución de problemas y problemas conocidos

Los problemas conocidos de las listas de la tabla siguiente con los links del LFI over FRF y focos en los pasos de Troubleshooting a tomar para aislar sus síntomas a un bug resuelto.

Síntoma Pasos para la resolución de problemas Bug resueltos
Rendimiento de procesamiento reducido en el tramo ATM o el tramo Frame Relay
  • Haga ping con los paquetes diverso-clasificados a partir de 100 bytes a los Ethernetes MTU.
  • ¿Los paquetes grandes experimentan los descansos?
CSCdt59038 - Con los paquetes 1500-byte y la fragmentación fijados a 100 bytes, hay 15 paquetes fragmentados. El retardo fue causado por los niveles múltiples de espera. CSCdu18344 - Con el FRTS, los paquetes dequeued más lentamente que esperados. El conjunto MLPPP dequeue los controles de funcionamiento el tamaño de la cola de la cola del modelador de tráfico. El FRTS era demasiado lento en borrar esta cola.
Paquetes defectuosos
  • Ejecute el comando show ppp multilink. Busque incrementar los valores para “perdió los fragmentos”, “desechado”, y “perdió” los contadores recibidos.
    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 los eventos multi ppp del debug y busque “perdió el fragmento” y “fuera de sincronice con los mensajes del par”.
    *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 se congestiona la interfaz ATM física, se caen los fragmentos MLP o fuera de servicio recibida en el extremo remoto. Este problema afecta solamente a los módulos de red ATM en las 2600 y 3600 Series. Resulta de cómo el driver de la interfaz conmutaba incorrectamente los paquetes en el trayecto rápido (por ejemplo con la transferencia rápida o el Cisco Express Forwarding). Específicamente, el segundo fragmento del paquete actual fue enviado después del primer fragmento del próximo paquete
Pérdida de conectividad de extremo a extremo cuando las 3600 Series realizan el IWF en el modo transparente
  • Cambie el modo a de translación y a la prueba otra vez.
CSCdw11409 - Se asegura de que las miradas CEF en la ubicación del byte correcta para comenzar a procesar los encabezados de encapsulado de los paquetes MLPPP


Información Relacionada


Document ID: 24041