WAN : Frame Relay

Configuración del modelado del tráfico de Frame Relay en routers 7200 y plataformas inferiores

16 Enero 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (13 Noviembre 2015) | Comentarios


Contenido


Introducción

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

prerrequisitos

Requisitos

No hay requisitos previos específicos para este documento.

Componentes Utilizados

El Frame-Relay Traffic Shaping se ha soportado desde el Software Release 11.2 de Cisco IOS�.

Se soporta en los Cisco 7200 Router y las plataformas inferiores. El Distributed Traffic Shaping se soporta en los Cisco 7500 Router, los 7600 Router, 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. Velocidad a las discordancías de poca velocidad del circuito: Existen dos posibilidades aquí:

    • El sitio del eje de conexión tiene una línea T1 en la nube, mientras que el sitio remoto tiene una menor velocidad (56 kbps). En este caso, usted necesita el tarifa-límite el sitio del eje de conexión de modo que no exceda la velocidad de acceso del lado 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. Oversubscription: Por ejemplo, si la tarifa garantizada en un circuito virtual permanente (PVC) es 64 kbps y la velocidad de acceso es el kbps 128 en los ambos extremos, es posible repartir sobre la tarifa garantizada cuando no hay congestión y caída de nuevo a la tarifa garantizada cuando hay congestión.

  3. Calidad de servicio: Para implementar la fragmentación FRF.12 o las características de cola de baja latencia para alcanzar la mejor calidad del servicio, vea el VoIP over Frame Relay con la calidad de servicio.

Nota: La velocidad de acceso es la velocidad de línea física de la interfaz que conecta con el Frame Relay. La tarifa garantizada es la Velocidad de información comprometida (CIR) que la compañía telefónica ha dado para el PVC. La determinación del CIR o del mincir a la velocidad de acceso se debe evitar, porque puede dar lugar a las caídas de resultados, haciendo el tráfico estrangular. La razón de esto es que la tarifa de la dimensión de una variable no tiene en cuenta los bytes de tara del indicador y de los campos de la verificación por redundancia cíclica (CRC). Así pues, el formar en la línea tarifa oversubscribing realmente, y causará la congestión de la interfaz. El formar a la velocidad de acceso no se recomienda. Usted debe formar siempre el tráfico en el 95 por ciento de la velocidad de acceso. Más generalmente, la tarifa formada global debe ser el no más que 95 por ciento de la velocidad de acceso.

Configurar

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

Nota: Para obtener información adicional sobre los comandos que se utilizan en este documento, use la herramienta IOS Command Lookup

Diagrama de la red

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

http://www.cisco.com/c/dam/en/us/support/docs/wan/frame-relay/6151-traffic-shaping-6151.gif

En el ejemplo antedicho, tenemos los valores siguientes:

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

  • Tarifa de acceso remoto = 64Kbps, tarifa garantizada = 32Kbps

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 Frame-Relay Traffic Shaping se habilita en la interfaz principal, y se aplica a todos los identificadores de conexión de link de datos (DLCI) bajo 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

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 es enviado router de eje de conexión de los:

http://www.cisco.com/c/dam/en/us/support/docs/wan/frame-relay/6151-traffic-shaping-6151a.gif

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 siete intervalos siguientes es solamente Bc = 8000 bits. Por lo tanto, la velocidad es 8000 / 125 mseg = 64 Kbps.

Por ejemplo, si recibimos una explosión de 88000 bits, no podemos enviar todo este tráfico en 8 Intervalos Tc. Los 8000 bits finales se enviarán en el 9º intervalo Tc. Así, este tráfico es retrasado 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

el formar inactivo/active

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 los BECN, y el DLCI se ha configurado para formar a los BECN.

  2. El número de bytes de datos a transmitir fuera de una interfaz es más que el 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 para ser hechos fragmentos.

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 salvan en la cola de modelado (afectada un aparato por el VC) y después se transmiten en los intervalos subsiguientes cuando hay bastante crédito disponible.

descensos 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. Por abandono, el tipo de cola es FCFS (First Come First Serve) o (Primero en Entrar, Primero en Salir FIFO), pero puede ser cambiado al WFQ, al PQ, al CQ, al CBWFQ, o al LLQ. Vea la sección de la “información relacionada” para los documentos en configurar los Mecanismos de envío a cola elaborados en el PVC de Frame Relay.

Parámetros configurables

frame relay cir

La velocidad media a la que desea enviar el tráfico en un PVC determinado en bps. Generalmente, ésta es mayor que la velocidad garantizada pero menor que la velocidad de acceso (AR). Esto equivale a la velocidad garantizada únicamente si:

  1. El proveedor del servicio no le permite realizar envíos que exceden la tarifa garantizada.

  2. La velocidad de línea física en la interfaz es la misma que la velocidad garantizada.

  3. En este PVC, existen paquetes de Voz (voz sobre IP [VOIP] o voz sobre Frame Relay [VOFR]); por lo tanto, no puede permitirse paquetes perdidos por calidad o servicio.

El valor del CIR es 56000 BPS está por abandono.

frame relay mincir

La velocidad garantizada real obtenida del proveedor de servicio en bps. Este valor debería ser la velocidad mínima que tiene que tirar en caso de congestión (tirar por debajo de esta velocidad implica que no obtiene el ancho de banda por el que está pagando). En algunos casos (que se mencionan arriba), los valores mincir y cir deben ser iguales. El valor de mincir es la mitad del valor CIR en bps en forma predeterminada.

Frame Relay a.C.

La cantidad de datos que deben enviarse por cada intervalo Tc en bits. Idealmente, para PVC Bc de datos = CIR/8 de modo que Tc = 125mseg. El Cisco IOS recalcula el parámetro FRTS cuando el Bc es mayor de 10,000 bytes. Si estamos haciendo la Voz en el PVC, después el Bc = el CIR/100 es preferibles, de modo que Intervalo Tc = 10msec (como paquetes de voz no puede tolerar un retardo más largo). El valor del Bc por abandono se muestra como el CIR en los bits en la salida del comando show traffic-shape. Sin embargo, internamente, un diverso valor se asigna para asegurar el rendimiento óptimo. Este valor se muestra en “la columna de los bytes del incremento” en la salida de la tráfico-dimensión de una variable de la demostración. Un valor del bc=CIR compara a un Tc de 1 segundo. Dependiendo de cómo el tráfico llega el shaper, el router tendría que parar la transmisión para cerca de 1 segundo si la explosión fue agotada inmediatamente al inicio del intervalo. Así, el shaper asigna un diverso valor interno que todavía permita el Bc configurado sobre el Tc original, sólo lo haremos en varias pequeñas explosiones en vez de una explosión grande.

el Frame Relay sea

La cantidad de datos en exceso que puede enviarse durante el intervalo Tc en bits una vez que se ha creado el crédito. Configure Be sólo si el valor CIR de Frame Relay es menor que el AR. Para los PVC que llevan los paquetes de voz, el se debe fijar a cero para asegurar la Calidad de voz mejor. El router sólo emite ráfagas de datos adicionales (Be) cuando hay fichas en la cubeta con fichas. El token bucket no acrecienta los tokens a menos que la cantidad de tráfico que es enviada sea menos que el CIR. El router puede repartir solamente para el primer Tc, después de lo cual el token bucket está vacío. El valor de Be está predeterminado en cero bits.

BECN de modelado de adaptación de Frame Relay

Implica que el PVC adapta la velocidad de transmisión en respuesta a las BECN recibidas. El comportamiento está como abajo:

  • Si el PVC recibe algunos BECN durante el intervalo de hora actual (no importa si éste es uno o 1000) que la tarifa del transmitir es disminuida por el 25 por ciento o al mincir y para si es el valor configurado del mincir más el de 75% del valor círculo.

  • Continúa cayendo con cada BECN (límite de una caída por intervalo de tiempo) hasta que la velocidad del tráfico llega al mincir (velocidad garantizada) donde se detiene.

  • Una vez que la velocidad del tráfico haya disminuido, debe permitir 16 intervalos de tiempo de no recibir BECN, antes de comenzar a incrementar el tráfico nuevamente. El periodo que aumenta en es el límite de bytes que aparece en la salida del show frame pvc x dividida por 16. Este aumento ocurre solamente si el modelado de tráfico es activo. Así, dura mucho para volver al CIR que hizo para caer al mincir.

Parámetros no configurables

intervalo (Tc)

El intervalo durante el cual usted envía los bits del Bc para mantener la tasa promedio del CIR en los segundos.

Tc = Bc/CIR in seconds

El rango para Tc es de 10 a 125 ms. El router internamente calcula este valor basado en el CIR y los valores del Bc en el map class. Si Bc/CIR es mayor o igual a 125 mseg, usa el valor Tc interno. Si el valor de Bc/CIR es menor a 125 ms, utiliza el Tc que se calcula a partir de esa ecuación.

aumento de bytes

La cantidad de bytes comprometidos enviada por el Tc. Podemos calcular esto mediante la siguiente fórmula:

Cir * Tc / 8

límite de bytes

La cantidad de bytes real enviada en el primer Tc. Podemos calcular esto mediante la siguiente fórmula:

byte increment + Be/8 (measured in bytes)

Troubleshooting

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 6151