Calidad de servicio (QoS) : QoS Congestion Management (queueing)

Configurar el CBWFQ y el LLQ en el MLPPP y las interfaces del dialer

7 Septiembre 2014 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (23 Marzo 2008) | Inglés (12 Agosto 2014) | Comentarios


Contenido


Introducción

El comando service-policy generalmente aplica una correspondencia de política configurada con los comandos de modular QoS CLI (MQC) a una interfaz principal, subinterfaz o circuito virtual. También puede aplicar este comando a una interfaz de plantilla virtual, una interfaz de links múltiples y una interfaz de marcador configurada con encapsulación de Point-to-Point Protocol (PPP) y PPP Multilink (MLPPP). Dichas interfaces resultan en una interfaz de acceso virtual, donde, funcionalmente, se realiza la colación en cola. Este documento proporciona una referencia única para entender las configuraciones recomendadas y las advertencias relacionadas para aplicar colocación en cola equilibrada ponderada basada en la clase (CBWFQ) y colas de latencia baja (LLQ) a interfaces de paquete y a interfaces del dialer de MLPPP.

prerrequisitos

Requisitos

No hay requisitos previos específicos para este documento.

Componentes Utilizados

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

Convenciones

Consulte Convenciones de Consejos Técnicos de Cisco para obtener más información sobre las convenciones sobre documentos.

Aplique los Datos en espera a las interfaces con una variedad de anchos de banda

El RFC 1990leavingcisco.com define el Multilink PPP, que combina una o más interfaces físicas en una interfaz virtual del “conjunto”. El ancho de banda del bundle interface es igual a la suma del ancho de banda de los links componentes. Así, el bundle interface tiene un valor de ancho de banda máximo que varíe en un momento instantáneo a tiempo.

Originalmente, los comandos bandwidth y priority admitían sólo un valor absoluto kbps. Si aplicó una política de servicio con CBWFQ y LLQ a una interfaz de agrupamiento y la primera interfaz activa no admitió el valor kbps absoluto, la política de servicio fracasó en el control de admisión. El router quitó la política de servicio e imprimió los mensajes de error similares a esta salida:

May 18 17:32:34.766 MEST: CBWFQ: Not enough available bandwidth for all 
classes Available 48 (kbps) Needed 96 (kbps) 
May 18 17:32:34.766 MEST: CBWFQ: Removing service policy on Dialer100

A partir del Software Release 12.2T de Cisco IOS®, el router ahora intenta reaplicar la directiva cuando detecta que una interfaz adicional (tal como un segundo Canal B BRI) está agregada al conjunto. Un enfoque superior es para configurar la prioridad y los comandos del ancho de banda como un porcentaje del ancho de banda disponible. El uso de un valor del porcentaje configura al router para asignar una cantidad relativa de ancho de banda que ajuste mientras que el conjunto contiene uno o más links de miembro. La versión 12.2(2)T del IOS de Cisco introdujo la compatibilidad con el comando priority percentage en los routers de la serie 7500 de Cisco y otras plataformas. Para más información, refiera a los Datos en espera de la latencia baja con el soporte de porcentaje de prioridad.

CBWFQ y LLQ en interfaces de discado

El Dial-on-Demand Routing (DDR) se puede configurar de dos maneras:

  • DDR heredada - Aplica los parámetros de marcado y de protocolo directamente en la interfaz física.

  • Perfiles de marcado: aplica los parámetros de marcado y de protocolo dinámicamente en una interfaz de marcado, que a su vez se vincula con interfaces físicas. Por ejemplo, la interfaz del marcador incluye una o varias cadenas de marcado para alcanzar un sitio remoto, tipo de autenticación PPP y MLPPP.

La DDR heredada originalmente soportaba la formación en cola Primero en entrar, Primero en salir (FIFO) sólo cuando una interfaz serial o ISDN era configurada con MLPPP. Esta restricción aplicó incluso cuando los dos extremos de la conexión no negociaron el MLPPP y utilizó la interfaz física como interfaz del NON-conjunto que ejecuta la encapsulación PPP. Ahora se admite la Cola equilibrada tradicional (WFQ) mediante el comando fair-queue.

Si elige configurar los perfiles de marcación, tanto la interfaz del marcador como las interfaces físicas subyacentes admiten el comando service-policy. Si usted aplica una directiva en la interfaz física, publique el comando show policy-map interface serial o el comando del bri 0/0:1 (y bri0/0:2) del show policy-map interface de confirmar la configuración. El canal D, identificado en el IOS como BRI0/0, soporta la señalización y no el tráfico de datos. Si usted aplica una directiva a la interfaz del dialer, publique el comando del dial <0-255> de la interfaz de espera de la demostración de confirmar la configuración.

Los Cisco IOS Software Releases 12.2(4) y 12.2(4)T introdujeron el soporte para las políticas de servicio Datos en espera-basadas en las interfaces de acceso virtual creadas de una interfaz del dialer configurada con el MLPPP. En versiones anteriores, los parámetros de política de servicio no se copian en la interfaz de acceso virtual clonada, donde se lleva a cabo la colocación en cola. Esta salida ilustra estos síntomas:

Router#show policy interface dialer1
  Dialer1 
   Service-policy output: foo 

     Class-map: class-default (match-any) 
       0 packets, 0 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 

Router#show policy interface virtual-access 2
 Router#

Nota: El Cisco IOS Software Release 12.2(8) y 12.2(8)T se recomienda para evitar el Id. de bug Cisco CSCdu87408, que resuelve las recargas de router como a efecto colateral poco común de esta configuración.

Esta configuración de muestra muestra cómo aplicar el CBWFQ y el LLQ a una interfaz del dialer. Esta configuración da lugar a:

  • Utiliza una interfaz del marcador para aplicar dinámicamente los parámetros del protocolo de la conexión a las interfaces ISDN BRI. La interfaz del dialer reputa “limita” a las interfaces del ISDN BRI.

  • Coloque dos interfaces ISDN BRI en un paquete de links múltiples.

  • Utiliza el dialer load-threshold load [saliente | entrante | cualquier] comando de determinar cuando el router necesita activar los Canales B adicionales y aumentar el ancho de banda del bundle interface.

  • Crea una interfaz de acceso virtual con el comando ppp multilink.

  • Aplica una política de servicio con CBWFQ y LLQ a la interfaz de acceso virtual por medio de la interfaz del marcador.

Configuración de muestra:
access-list 101 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
access-list 102 permit tcp any any eq 23
! 
class-map voice
    match access-group 101

!--- Traffic that matches ACL 101 is classified as class voice.

class-map data
    match access-group 102

!--- Traffic that matches ACL 102 is classified as class data.

policy-map mlppp 
   class voice 
      priority percent 50 
   class data 
      bandwidth percent 25 
   class class-default 
     fair-queue 
!
interface BRI2/1  
  no ip address  
  encapsulation ppp  
  dialer pool-member 1  

!--- Member of dialer pool 1.

  isdn switch-type basic-net3  
  no cdp enable  
  ppp authentication chap  
! 
interface BRI2/2 
  no ip address  
  encapsulation ppp  
  dialer pool-member 1  

!--- Member of dialer pool 1.

  isdn switch-type basic-net3  
  no cdp enable  
  ppp authentication chap  
!  
interface Dialer2  
  ip unnumbered Loopback0  
  encapsulation ppp  
  dialer pool 1  
  dialer load-threshold 1 either  
  
!--- Load level (in either direction) for  
  !--- traffic at which additional connections  
  !--- are added to the MPPP bundle 
  !--- load level values that range from 1 (unloaded)  
  !--- to 255 (fully loaded).

  dialer string 6113 
  dialer string 6114  
  dialer-group 1  
  ppp authentication chap  
  ppp multilink  

!--- Allow MLPPP for the four BRI channels.

  service-policy output mlppp 
  
!--- Apply the service policy to the dialer interface.

LLQ y CBWFQ con MLPPP distribuido

La serie 7500 de Cisco utiliza una arquitectura distribuida que asegura la velocidad alta de transmisión de paquetes al mover las decisiones de reenvío de paquetes desde el Procesador del switch de la ruta (RSP) a los Procesadores de interfaz versátil (VIP). Esta arquitectura también habilita el despliegue de los servicios en grande del IP mejorado, tales como QoS, separando la carga de procesamiento a través de los procesadores múltiples independientes de los VIP.

De acuerdo con el hardware de la interfaz, las Cisco 7500 Series soportan dos formas de QoS:

QoS Cómo se habilitó Donde se admite Donde se procesan
Basado en RSP Automáticamente en procesadores de interfaz heredada Procesadores de interfaz heredada No se puede habilitar más en VIP. RSP CPU
Basado en VIP (distribuido) Automáticamente cuando se configuran estos dos comandos: VIP CPU VIP

Los mecanismos de Calidad de servicio (QoS) VIP basados aplicados vía el Modular QoS CLI (MQC) se introducen en estos tres trenes de versión del Cisco IOS Software:

  • Cisco IOS Software Release 12.0(XE), que se convirtió en Cisco IOS Software Release 12.1(E)

  • Cisco IOS Software Release 12.0(9)S

  • Cisco IOS Software Release 12.1(5)T, que se convirtió en mainline y Cisco IOS Software Release 12.2T del Cisco IOS Software Release 12.2

La función de MLPP le permite combinar el ancho de banda de múltiples interfaces T1/E1 de un VIP en una interfaz de agrupamiento. Para más información, refiera al protocolo multilink point-to-point distribuido para los Cisco 7500 Series Router. El Cisco IOS Software Release 12.2(13)T introduce el soporte para el MLPPP distribuido (dMLPPP) en los adaptadores de puerto no separados, tales como el PA-4T+ y el PA-8T.

La versión 12.2(8)T del software Cisco IOS incorpora el soporte para LLQ y CBWFQ distribuidas en las interfaces de agrupamiento de los adaptadores de puertos canalizados como PA-MC-xT1/E1 y PA-MC-xT3/E3. Como la versión no distribuida de esta función, dMLPPP usa una interfaz de links múltiples para crear una interfaz de acceso virtual donde ocurre el envío a cola. Refiera a nuevo y a la información cambiada para el Cisco IOS Software Release 12.2T. Cuando usted aplica los Datos en espera distribuidos con el dMLPPP, el Cisco IOS Software Release 12.2(10)T o Posterior se recomienda para evitar el Id. de bug Cisco CSCdw47678.

Sólo CBWFQ y LLQ tal como se aplican con el comando service-policy, están admitidos con dMLPPP/dLFI. Las características de colocación en cola de la herencia, tales como colas justas con el comando fair-queue, cola prioritaria con el comando priority-group, y el formar la cola a medida con el comando queue-list, no se soportan.

El FlexWan para las Cisco 7600 Series soporta el dLLQ en las interfaces del NON-conjunto. No soporta dLLQ en interfaces de agrupamiento MLPPP. Este soporte está disponible con el Cisco IOS Software Release 12.2S.

Esta configuración de muestra aplica el dLLQ en un multilink de la interfaz:

Configuración de muestra del dLLQ en un bundle interface MLPPP
Interface 
! 
access-list 100 permit udp any any range 16384 32000
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
access-list 102 permit tcp any any eq 23
!
class-map voip 
   match access-group 100
class-map data1
    match access-group 101
class-map data2 
    match access-group 102
!
policy-map llq-policy
    class voip 
     bandwidth 40 
    class data1 
     bandwidth 15 
    class data2 
     bandwidth 15
    class class-default 
     fair-queue
!
policy-map set-policy
    class voip 
     bandwidth 40 
    class data1 
     bandwidth 15
    class data2 
     bandwidth 15 
    class class-default 
     fair-queue
!
interface Serial5/0/0:0 
   no ip address 
   encapsulation ppp 
   keepalive 10 
   ppp chap hostname G2 
   ppp multilink 
   multilink-group 2 
!  
interface Serial5/1/0:0 
  no ip address 
  encapsulation ppp 
  keepalive 10 
  ppp chap hostname G2 
  ppp multilink 
  multilink-group 2 
!  
interface Multilink2 
  ip address 106.0.0.2 255.0.0.0 
  ppp multilink 
  service-policy output llq-policy 
  service-policy input set-policy 
  multilink-group 2

El Link Fragmentation and Interleaving (LFI) agrega el ppp multilink fragment-delay y los comandos ppp multilink interleave a una virtual-plantilla de la interfaz configurada con el MLPPP y una política de servicio. Esta configuración reduce el retardo en links más despacio rompiendo para arriba los datagramas grandes e interpolando los paquetes de tráfico con bajo retraso con los paquetes más pequeños que resultan del datagrama fragmentado. Para más información, refiera a configurar la fragmentación de link y a interpolación para el Frame Relay y los circuitos virtuales ATM.

El soporte introducido Cisco IOS Software Release 12.2(8)T para LFI distribuido (dlfi) sobre-canalizó las líneas seriales en las Cisco 7500 Series con los VIP. Esta característica está también disponible con los Catalyst 6500 Series Switch y los Cisco 7600 Series Router. Para la información sobre las versiones que soportan el dlfi, refiera a la herramienta Feature Navigator (clientes registrados solamente) y a los Release Note para los productos respectivos. Para más información sobre esta característica, refiera a la fragmentación de link distribuida y a la interpolación sobre las líneas arrendadas.

El FlexWan para las Cisco 7600 Series con el tren de versión del Cisco IOS Software 12.1E no soporta el dlfi.

Después de que usted configure el retraso del fragmento máximo con el comando ppp multilink fragment-delay <msec>, la característica del dlfi calcula los tamaños del fragmento reales en las interfaces seriales canalizadas con el uso de esta fórmula (donde está el ancho de banda en el kbps):

fragment size = bandwidth x fragment-delay  / 8

Además, los tamaños del fragmento se calculan sobre la base del link de miembro con la cantidad más pequeña del ancho de banda. Por ejemplo, en una configuración con links miembro de 64 K y 128 K, el tamaño del fragmento se calcula en función del link de 64 K.

CBWFQ y LLQ con PPPoA y MLPPPoA

La versión 12.2(8) de software del IOS de Cisco fue la primera en admitir el almacenamiento en cola por VC en circuitos virtuales ATM configurados con PPP genérico sobre encapsulación ATM (PPPoA). Estas subdivisiones le dan los ejemplos de configuración del Marcado basado en clases, del policing, y de los Datos en espera.

1. Marcación basada en la clase

El comando service-policy puede ser asociado a la interfaz de plantilla virtual o a la atmósfera PVC para el Marcado basado en clases.

En este ejemplo, se define la correspondencia PEER2PEER de la clase, se crea la correspondencia de políticas MARK_PEER2PEER, y el valor por defecto del dscp se configura para la clase PEER2PEER; entonces la servicio-directiva se asocia a la plantilla virtual o a la atmósfera PVC.

Router(config)#class-map PEER2PEER
Router(config-cmap)#match access-group 100
Router(config-cmap)#exit

Router(config)#policy-map MARK_PEER2PEER
Router(config-pmap)#class PEER2PEER
Router(config-pmap-c)#set dscp default
Router(config-pmap-c)#end


Attaching Service-policy to Virtual Template


Router(config-subif)#int atm1/0.1 point-to-point
Router(config-subif)#ip address 10.10.10.1 255.255.255.0
Router(config-subif)#pvc 1/50
Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 1

Router(config)#interface Virtual-Template1
Router(config-if)#ip address negotiated
Router(config-if)#service-policy output MARK_PEER2PEER 


Attaching Service-policy to ATM pvc

Router(config)#int atm1/0.1 point-to-point
Router(config-subif)#ip address 10.10.10.1 255.255.255.0
Router(config-subif)#pvc 1/50
Router(config-if-atm-vc)#service-policy output MARK_PEER2PEER

2. Class-based policing:

El comando service-policy puede ser asociado a la interfaz de plantilla virtual o al pvc atmósfera para el class-based policing.

Router(config)#policy-map POLICE_PEER2PEER
Router(config-pmap)#class PEER2PEERRouter(config-pmap-c)#police 8000 conform-action transmit exceed-action drop

Attaching Service-policy to Virtual Template

Router(config-subif)#int atm1/0.2 multipoint
Router(config-subif)#no ip address
Router(config-subif)#pvc 1/100
Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 2

Router(config)#interface Virtual-Template2
Router(config-if)#ip address negotiated
Router(config-if)#service-policy output POLICE_PEER2PEER 



Attaching Service-policy to ATM pvc

Router(config)#int atm1/0.2 multipoint
Router(config-subif)#no ip address
Router(config-subif)#pvc 1/100
Router(config-if-atm-vc)#service-policy output POLICE_PEER2PEER

3. Datos en espera basados en la clase:

Para los Datos en espera basados en la clase, es decir, el ancho de banda, dimensión de una variable, prioridad, y al azar-detecta, el comando service-policy puede ser asociado a la plantilla virtual o a la atmósfera PVC.

Router(config)#policy-map QUEUE_PEER2PEER
 Router(config-pmap)#class PEER2PEER
 Router(config-pmap-c)#bandwidth 768

Attaching Service-policy to Virtual Template

Router(config-subif)#int atm1/0
Router(config-subif)#no atm ilmi-keepalive
Router(config-subif)#pvc 1/150
Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 3

Router(config)#interface Virtual-Template3
Router(config-if)#ip address negotiated
Router(config-if)#service-policy output QUEUE_PEER2PEER

Attaching Service-policy to ATM pvc 

Router(config)#int atm1/0
Router(config-subif)#no atm ilmi-keepalive
Router(config-subif)#pvc 1/150
Router(config-if-atm-vc)#service-policy output QUEUE_PEER2PEER

Nota: Cuando usted utiliza una combinación de Marcado basado en clases o class-based policing y los Datos en espera basados en la clase, la orden de funcionamiento es ésta:

  1. El comando service-policy configurado en la interfaz de plantilla virtual marca o limpia los paquetes.

  2. El comando service-policy en la atmósfera PVC hace cola los paquetes.

Refiera a este ejemplo:

policy-map MARK_PEER2PEER
  class PEER2PEER
   set dscp default
! 
 interface ATM0/0
 no ip address
 no atm ilmi-keepalive
 pvc 1/100
  encapsulation aal5mux ppp Virtual-Template1
  service-policy output QUEUE_PEER2PEER
!
interface Virtual-Template1 
ip address negotiate
service-policy output MARK_PEER2PEER

Si usted funciona con una versión de Cisco IOS Software anterior, usted puede configurar en el VC atmósfera con la encapsulación MLPPPoA y aplicar una política de servicio Datos en espera-basada a la interfaz de plantilla virtual. Para más información, refiera a la fragmentación de link e interpolación para el Frame Relay y los circuitos virtuales ATM y la descripción de los Link Efficiency Mechanism.

El Cisco IOS Software Release 12.2(4)T3 introduce una versión distribuida de esta característica para las Cisco 7500 Series. Para más información sobre esta característica, refiera a la fragmentación de link distribuida y a la interpolación para la atmósfera y el Frame Relay.

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: 10102