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.
No hay requisitos previos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Consulte Convenciones de Consejos Técnicos de Cisco para obtener más información sobre las convenciones sobre documentos.
El RFC 1990 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.
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 marcado, 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 para colocación en cola 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. |
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 el tamaño del fragmento real 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, el tamaño del fragmento se calcula 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.
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:
El comando service-policy configurado en la interfaz de plantilla virtual marca o limpia los paquetes.
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.