Este documento proporciona una configuración de muestra para el shaping del tráfico de Frame Relay.
No hay requisitos previos específicos para este documento.
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.
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
Las implementaciones comunes del modelado del tráfico de Frame Relay son:
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.
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.
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.
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
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.
En este documento, se utilizan estas configuraciones:
Hub
Remoto
Hub |
---|
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 ! |
Remoto |
---|
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.
En esta sección encontrará información que puede utilizar para confirmar que su configuración esté funcionando correctamente.
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
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:
Se reciben BECN y se ha configurado DLCI para que se modele a BECN.
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).
Se ha configurado la fragmentación FRF.12 y los paquetes están esperando a fragmentarse.
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.
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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
31-May-2005 |
Versión inicial |