Configuración del modelado del tráfico de retransmisión de tramas en routers 7200 y plataformas inferiores

Introducción

Este documento proporciona una configuración de muestra para el shaping del tráfico de Frame Relay.

Prerequisites

Requirements

No hay requisitos previos específicos para este documento.

Componentes Utilizados

El modelado de tráfico de Frame Relay ha sido soportado desde la versión 11.2 del software Cisco IOS®.

Es compatible con los routers Cisco 7200 y las plataformas inferiores. El modelado de tráfico distribuido es compatible con los routers Cisco 7500, los routers 7600 y el módulo FlexWAN.

Convenciones

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

Antecedentes

Las implementaciones comunes del modelado del tráfico de Frame Relay son:

1. Discordancias del circuito de alta velocidad a baja velocidad: Existen dos posibilidades aquí:

   • El sitio del hub tiene una línea T1 en la nube, mientras que el sitio remoto tiene una velocidad inferior (56 Kbps). En este caso, debe limitar la velocidad del sitio del hub para que no exceda la velocidad de acceso lateral remoto.

   • El sitio del hub tiene una sola línea T1 en la nube, mientras que los sitios remotos también tienen una línea totalmente T1 en la nube con conexión al mismo sitio del hub. En este caso, debe limitar la velocidad de los sitios remotos para no saturar el concentrador.

2. Sobresuscripción: Por ejemplo, si la velocidad garantizada en un circuito virtual permanente (PVC) es de 64 Kbps y la velocidad de acceso es de 128 Kbps en ambos extremos, es posible que se produzca una ráfaga por encima de la velocidad garantizada cuando no hay congestión y vuelva a la velocidad garantizada cuando hay congestión.

3. Calidad del servicio: Para implementar las funciones de fragmentación FRF.12 o de colocación en cola de baja latencia para lograr una mejor calidad de servicio, vea VoIP sobre Frame Relay con Calidad de Servicio.

Nota: La velocidad de acceso es la velocidad de línea física de la interfaz que se conecta a Frame Relay. La velocidad garantizada es la velocidad de información comprometida (CIR) que la compañía telefónica ha dado para el PVC. Debe evitarse establecer la CIR o minCIR a la velocidad de acceso, ya que puede dar lugar a caídas de salida, provocando que el tráfico se congele. La razón de esto es que la velocidad de la forma no tiene en cuenta los bytes de tara de los campos Indicador y Verificación por Redundancia Cíclica (CRC). Por lo tanto, el modelado a velocidad de línea en realidad está sobresuscribiéndose y causará congestión en la interfaz. No se recomienda modelar a la velocidad de acceso. Siempre debe modelar el tráfico al 95% de la velocidad de acceso. En términos más generales, la tasa de forma agregada no debe ser superior al 95% de la tasa de acceso.

Configurar

En esta sección encontrará la información para configurar las funciones descritas en este documento.

Nota: Para encontrar información adicional sobre los comandos usados en este documento, utilice la herramienta de búsqueda de comandos de IOS

Diagrama de la red

En este documento, se utiliza esta configuración de red:

En el ejemplo anterior, tenemos los siguientes valores:

• HUB - velocidad de acceso = 192 kbps, velocidad garantizada = 32Kbps

• REMOTO: velocidad de acceso = 64 Kbps, velocidad garantizada = 32 Kbps

Aquí, estamos implementando la modelación de tráfico en ambos extremos para que la velocidad de transmisión promedio sea 64 Kbps. Si es necesario, el hub puede precipitarse más allá de esto. En caso de congestión, puede caer a 32Kbps como mínimo. La notificación de congestión desde la nube se realiza a través de la Notificación explícita de la congestión retrospectiva (BECN). Por lo tanto, la modelación se configura para que se adapte a BECN.

Nota: El modelado de tráfico Frame Relay está habilitado en la interfaz principal y se aplica a todos los identificadores de conexión de link de datos (DLCI) de esa interfaz. No podemos habilitar el modelado del tráfico únicamente para un DLCI determinado o para una subinterfaz bajo la interfaz principal. Si un DLCI determinado no tiene una clase de correspondencia asociada a él y el modelado de tráfico está habilitado en la interfaz principal, al DLCI se le asignará una clase de correspondencia predeterminada con CIR = 56000.

Configuraciones

En este documento, se utilizan estas configuraciones:

• Hub

• Remoto

interface Serial0/0 
 no ip address 
 encapsulation frame-relay 
 no fair-queue 
 frame-relay traffic-shaping 

!--- Apply traffic shaping to main interface (step 3).
 
interface Serial0/0.1 point-to-point 
 ip address 10.1.1.1 255.255.255.0 
 frame-relay interface-dlci 16  
 frame-relay class cisco 

!--- Apply map class to the DLCI / subinterface (step 2).
 
! 
! 

!--- Configure map class parameters (step 1).
 
map-class frame-relay cisco 
 frame-relay cir 64000  
 frame-relay mincir 32000 
 frame-relay adaptive-shaping becn 
 frame-relay bc 8000 
 frame-relay be 16000 
!

interface Serial0/0 
no ip address 
encapsulation frame-relay 
no fair-queue 
frame-relay traffic-shaping 
! 
interface Serial0/0.1 point-to-point 
ip address 10.1.1.2 255.255.255.0 
frame-relay interface-dlci 16                            
frame-relay class cisco 
! 
map-class frame-relay cisco 
frame-relay cir 64000 
frame-relay mincir 32000 
frame-relay adaptive-shaping becn 
frame-relay bc 8000 
!

Este diagrama muestra el tráfico que se envía fuera del router HUB:

Suponiendo que el tráfico se envía con una ráfaga de 80000 bits, se envía fuera del PVC en intervalos de 8 Tc (125 msec cada uno). Podemos alcanzar esto porque, en el primer intervalo, el crédito disponible es Bc + Be = 8000 + 16000 = 24000 bits. Esto significa que la velocidad es de 24000 bits / 125 mseg = 192 Kbps.

En los siguientes siete intervalos, es sólo Bc = 8000 bits. Por lo tanto, la velocidad es 8000 / 125 mseg = 64 Kbps.

Por ejemplo, si recibimos una ráfaga de 88000 bits, no podemos enviar todo este tráfico en intervalos de 8 Tc. Los 8000 bits finales se enviarán en el 9º intervalo Tc. Por lo tanto, este tráfico se demora por el mecanismo de modelado del tráfico.

Verificación

En esta sección encontrará información que puede utilizar para confirmar que su configuración esté funcionando correctamente.

Comandos show

La herramienta Output Interpreter (sólo para clientes registrados) permite utilizar algunos comandos “show” y ver un análisis del resultado de estos comandos.

Utilice el comando show frame relay pvc <dlci> para ver los detalles de la configuración:

Hub#show frame relay pvc 16
     PVC Statistics for interface Serial0/0 (Frame Relay DTE)
     DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
       input pkts 8743          output pkts 5            in bytes 2548330
       out bytes 520            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
       Shaping adapts to BECN
       pvc create time 6d01h, last time pvc status changed 6d01h
       
cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 
      mincir 56000 byte increment 1000 Adaptive Shaping BECN 
      pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 
      shaping inactive 
      traffic shaping drops 0
 
       Queueing strategy: fifo 
       Output queue 0/40, 0 drop, 0 dequeued

modelado inactivo / activo

Este comando muestra, en tiempo real, si se activó o no el mecanismo de modelado del tráfico. El modelado del tráfico está activo en los siguientes escenarios:

1. Se reciben BECN y se ha configurado DLCI para que se modele a BECN.

2. El número de bytes de datos que se transmitirán desde una interfaz es superior al crédito disponible (límite de bytes) en un intervalo determinado (Tc).

3. Se ha configurado la fragmentación FRF.12 y los paquetes están esperando a fragmentarse.

paquetes demorados/bytes demorados

Muestra el número de paquetes y bytes que se han demorado debido a la activación del mecanismo de modelado de tráfico. Esto se aplica principalmente si el número de bits que van a transmitirse excede el crédito disponible por cada intervalo, o si los paquetes necesitan fragmentarse (FRF.12). Estos paquetes y bytes se almacenan en la cola de modelado (asignada por VC) y luego se transmiten en intervalos posteriores cuando hay suficiente crédito disponible.

Descarte del modelado de tráfico

Esto muestra el número de caídas que se producen en la cola de modelación. Los bytes primero se retrasan por el mecanismo de modelado y se almacenan en esta cola. Si se llena la cola, se descartan los paquetes. De forma predeterminada, el tipo de cola es FCFS (First Come First Server) o FIFO, pero se puede cambiar a WFQ, PQ, CQ, CBWFQ o LLQ. Consulte Información relacionada.