Calidad de servicio (QoS) en 6500 / 6800 supervisora 2T: Configuración y Troubleshooting.

Tabla de Contenidos 

Introducción

Habilitar QoS en Sup2T

Configuración y verificación

Policers

Policers distribuidos

Policers por VLAN

Marking

Queueing

Mensajes de error comunes

 

Introducción

El propósito de este documento es explicar las nuevas características de calidad de servicio (QoS) que ofrece la supervisora 2T en comparación con sus predecesoras, proporcionar algunos ejemplos de configuración donde puedan observarse estas nuevas capacidades aplicadas, así como estudiar los mensajes de error o problemas más comunes.

El motor de envío de paquetes PFC4 dentro de la supervisora 2T ofrece un número significativo de mejoras en el manejo de calidades de servicio (QoS). Dentro de estas mejoras, las siguientes resultan de mayor interés para nuestro estudio:

  • Mayor número de entradas en la TCAM de QoS. Lo cual se traduce en un mayor número de sentencias en los mapas de clases y por tanto también en más políticas posibles.

  • Clasificación de paquetes basada en dot1q tag y COS, pensado para transmisiones a través de EVC y Q-in-Q.

  • Clasificación de paquetes basada en TTL, Longitud del paquete y en el campo “Options” del paquete IP. En algunos casos, paquetes con TTL definido por el administrador (Como transmisiones de multicast) pueden ser asignadas a una queue prioritaria o en caso de la longitud, ciertos paquetes de longitud bien definida como o aquellos con ambientes que soportan jumbo frames para storage pueden aprovechar esta mejora en la clasificación.

  • La precisión de los Policers ha sido considerablemente mejorada incluso cuando la tasa de transmisión es muy baja. 

  • Los Policers ahora también pueden basarse en paquetes por segundo. PFC3 permitía solamente hacerlo en bits por segundo.

  • Ahora es posible tener policing distribuido. Los Policers establecen una tasa de tráfico que tiene que cumplirse, de lo contrario el tráfico es descartado. En la PFC3 la forma en que se medía esta tasa de tráfico era por linecard, es decir que si queríamos limitar transmisiones de un port-channel distribuido (con miembros en diferentes linecards) tendríamos que hacer el cálculo por cada linecard, pues no existía un mecanismo que llevara seguimiento de la tasa de transmisión de todos los miembros afectados por un Policer en todo el chassis. PFC4 nos da ahora la capacidad de aplicar un policer a un grupo de puertos distribuidos por todas las linecards y que estos puedan cumplir la tasa de transmisión establecida en la configuración de nuestro Policer.                                                      

Habilitar QoS en Sup2T

La supervisora 2T incorpora algunos cambios importantes en su comportamiento por defecto, la cual la vuelven más intuitiva en el manejo de calidades de servicio:

QoS se encuentra habilitado por defecto. No es necesario configurar nada.

Por defecto, los paquetes no son remarcados, o sufren ningún cambio en sus campos de DSCP, COS o EXP. Es decir, estos son enviados tal cual como se recibieron.

El estado “trust” del puerto no interfiere en las políticas de marcado. Es decir que si un puerto esta en trust COS nosotros podemos remarcar tráfico con DSCP.

[[{"type":"media","fid":"1425741","view_mode":"default","fields":{},"field_deltas":{"1":{}},"attributes":{"alt":"DSCP","title":"DSCP","height":"81","width":"300","class":"image-style-none media-element file-default","data-delta":"1"}}]]

 

Configuración y Verificación

Antes de proceder con la configuración de calidades de servicio, tenemos que revisar las capacidades generales de los puertos de la linecard sobre la que estamos trabajando:


S2T_core#show interface tengig 5/4 capabilities

TenGigabitEthernet5/4
Model: VS-SUP2T-10G

<snip>


QOS scheduling: rx-(8q4t), tx-(1p7q4t)

QOS queueing mode: rx-(cos,dscp), tx-(cos,dscp)

CoS rewrite: yes

ToS rewrite: yes

Ports-in-ASIC (Sub-port ASIC) : 1-5 (3-4)

<snip>


De particular interés es el output:

QOS scheduling:        rx-(8q4t), tx-(1p7q4t)    

QOS queueing mode:     rx-(cos,dscp), tx-(cos,dscp)

Este nos indica la cantidad de queues que soportan los puertos de esta linecard, en este caso para TX 1 queue de prioridad, 7 queues y 4 thresholds. Esto es importante pues algunas limitaciones en nuestras configuraciones de calidad de servicio se verán afectadas por esto.

El queueing mode nos indica la capacidad de la linecard para realizar acciones de queueing basado en DSCP o COS. En este caso, COS y DSCP son ambos soportados, sin embargo, la linecard en el output siguiente nos indica que solo soporta acciones basadas en COS:

S2T_core#show int gig 1/2 capabilities

GigabitEthernet1/2
Model: WS-X6724-SFP

<snip>

QOS scheduling: rx-(1q8t), tx-(1p3q8t) <<<<<<<

QOS queueing mode: rx-(cos), tx-(cos) <<<<<<<<

Ports-in-ASIC (Sub-port ASIC) : 1-24 (1-12)

<snip>

Policer

Para configurar un Policer necesitamos conocer la tasa de tráfico en bits por segundo o packets por segundo a la que queremos limitar el ingreso o el egreso a través de una interface.

En este ejemplo limitaremos la tasa de trafico marcado como DSCP 46 a 10 paquetes por segundo, las opciones que tenemos, así como los comandos para verificar que el Policer ha sido aplicado y está funcionando:

S2T_core #show class-map POLICER

Class Map match-all POLICER (id 42)

Match dscp ef (46)


S2T_core (config)#policy-map POLICER

S2T_core (config-pmap)#class POLICER

S2T_core (config-pmap-c)#police rate ?

WORD Rate value in the range 7-10,000,000,000

---- Primero establecemos un valor en decimal, posteriormente indicaremos si este valor define bits por segundo (bps) o paquetes por segundo (pps) -------

 
S2T_core (config-pmap-c)# police rate 10 ?

bps Treat 'rate' value in bits-per-second

burst Specify 'burst' parameter

conform-action action when rate is less than conform burst

peak-rate Specify peak rate or PCR for single-level ATM 4.0 policer

policies

pps Treat 'rate' value in packets-per-second

<cr>


S2T_core#show policy-map POLICER

Policy Map POLICER

Class POLICER

police rate 10 pps

conform-action transmit

exceed-action drop


S2T_core (config)#interface tengig 1/1/3

S2T_core (config-if)#service-policy input POLICER

S2T_core (config-if)# exit

Verificacion

Verificamos que la configuración se encuentra aplicada en la interface:

S2T_core #show running interface tengig 1/1/3

interface TenGigabitEthernet1/1/3

 switchport

 switchport mode trunk

 service-policy input POLICER

end

Para verificar que el Policer esta actuando podemos usar los comandos siguientes:

S2T_core #show policy-map interface tengig 1/1/3

TenGigabitEthernet1/1/3

Service-policy input: POLICER


class-map: POLICER (match-all)

Match: dscp ef (46)

police :

10 pps 2 limit 2 extended limit

Earl in switch 1, slot 1 :

124 packets

5 minute offered rate 2 pps

aggregate-forwarded 93 packets

action: transmit

exceeded 31 packets action: drop

aggregate-forward 3 pps exceed 1 pps

Class-map: class-default (match-any)

Match: any

De acuerdo al output del comando, 31 paquetes han excedido la tasa definida en el policer y han sido descartados

 Para verificar que el policer ha sido instalado en Hardware y se encuentra actuando podemos utilizar el siguiente comando:

S2T_core #show plat qos ip tenGigabitEthernet 1/1/3

[In] Policy map is POLICER [Out] Default.

QoS Summary [IPv4]: (* - shared aggregates, Mod - switch module, Sid - Switch Id, E - service instance)

(^ - class-copp keyword)



Int Sid Mod Dir Class-map DSCP Agg Trust Fl AgForward AgPoliced Id Id

-------------------------------------------------------------------------------

Te1/1/3 1 1 In POLICER 0 4096 dscp 0 526 175

Int: Interface donde esta aplicado el policer.

Dir: Direccion  (In: Ingress / Eg: Egress)

Class-map Id: Nombre del policer.

AgForward: Paquetes que no han excedido la tasa de transmisión y han sido recibidos satisfactoriamente.

AgPoliced: Paquetes que han excedido la tasa de transmisión definida en el policer y han sido descartados.

Policers Distribuidos

La supervisora Sup2T soporta policing distribuido como se explicó en la introducción. Esta opción se encuentra deshabilitada por defecto.

Para verificar si la opción está habilitada o deshabilitada corremos el siguiente comando:

S2T_core #show platform qos

QoS is enabled globally

Port QoS is disabled globally

QoS serial policing mode enabled globally

Distributed Policing is Disabled <<<<<<<<<< Deshabilitado

<snip>

Para habilitar la caracteristica de Policers Distrubuidos corremos el siguiente comando de configuracion global:

S2T_core (config)#platform qos police distributed ?

  loose       allocate policers in non-distributed region, if dist policers

              exhaust

  secondary-pups  enable secondary pups

  strict          allocate policers in distributed region only

Loose: Si se excede el número de policers distribuidos soportados (4000) el switch permitirá configurar un nuevo policer sin embargo, empezara a comportarse en modo PFC3, es decir, sin llevar una cuenta global de la tasa de tráfico en todas las PFC4s en el chassis.

Strict:  Si se excede el número de policers distribuidos soportados, el switch rechazara cualquier policer nuevo que vaya a ser configurado.

En caso de que se desee deshabilitar esta caracteristica, se debe configurar el comando con su forma "no":

S2T_core (config)#no platform qos police distributed

Policers por VLAN

La supervisora 2T soporta policers por VLAN, de tal forma que el trafico pueda ser limitado para el trafico que sea transmitido a traves de la VLAN completa, esto en combinación con policers distribuidos nos otorga una excelente herramienta para limitar la tasa de tráfico por VLAN definida protegiendo así recursos importantes de ancho de banda:

S2T_core (config)#interface vlan 1
S2T_core (config-if)#service-policy input POLICER
S2T_core (config-if)#exit
 
interface Vlan1
 ip address 10.1.1.1 255.255.255.0
 service-policy input POLICER

end

El policer es el mismo que en el ejemplo anterior, sin embargo, esta vez se ha aplicado en la SVI. Por último, se tiene que definir las interfaces en las que esperamos recibir el tráfico que el policer estará evaluando por VLAN y configurar el comando "platform qos vlan-based":

S2T_core (config)#interface tengig 1/1/3
S2T_core (config-if)#platform qos vlan-based

interface TenGigabitEthernet1/1/3
 switchport
 switchport mode access
switchport access vlan 1
 platform qos vlan-based

La verificacion de la aplicacion del policer es la misma que en el ejemplo anterior.

Marking

Basado en las capacidades de queueing de la linecard

QOS queueing mode:     rx-(cos,dscp), tx-(cos,dscp)

QOS queueing mode:     rx-(cos), tx-(cos)

La marcación basada en COS hacia DSCP no está soportada. En este ejemplo, recibimos paquetes marcados con COS5 y DSCP 46, se planea remarcarlo a DSCP AF11:

Class Map match-all MARK (id 39)

   Match cos  5

  Policy Map MARK

    Class MARK

      set dscp af11

En Arquitecturas que soportan queueing DSCP y COS, el DSCP se mantendrá como fue recibido y no será remarcado. En estel ejemplo, un paquete ingresando con DSCP 46 y COS 5 no sera marcada como AF11 a pesar de que eso indique la política de marking, sin embargo, su marcación DSCP 46 permanecerá.

En Arquitecturas que soportan COS solamente, el DSCP no solo no será marcado como AF11 sin no que además será remarcado a default (DSCP 0).

La marcación basada en DSCP hacia DSCP esta soportada en arquitecturas queueing COS y DSCP solamente. Para arquitecturas que soportan COS queueing únicamente, el DSCP se mantiene, pero no se remarca hacia el valor deseado. 

En este ejemplo, recibiremos un paquete marcado como DSCP 46 y planeamos remarcarlo a DSCP AF11:

Class Map match-all MARK (id 39)

   Match dscp 46

  Policy Map MARK

    Class MARK

      set dscp af11      

En arquitecturas con capacidad de COS queueing solamente, el valor permanecera como DSCP 46 y no cambiara a AF11.

Una de las nuevas capacidades de la supervisora 2T es la de clasificar el tráfico en base a TTL, Longitud del paquete y el campo de Options en el paquete de IP:

S2T_core (config)#ip access-list extended PKT_LEN
S2T_core (config-ext-nacl)#permit ip any any ?

dscp Match packets with given dscp value
fragments Check non-initial fragments
log Log matches against this entry
log-input Log matches against this entry, including input interface
option Match packets with given IP Options value
pak-len Match only packets on given pak-len operator
precedence Match packets with given precedence value
reflect Create reflexive access list entry
time-range Specify a time-range
tos Match packets with given TOS value
ttl Match packets with given TTL value
<cr>


S2T_core #show access-lists PKT_LEN
Extended IP access list PKT_LEN
10 permit ip any any pak-len gt 1600
20 permit ip any any

S2T_core #show class-map PKT_LEN
Class Map match-all PKT_LEN (id 38)
Match access-group name PKT_LEN

En este ejemplo, la policy PKT_LEN aplicada en la interface clasificara el tráfico que sea mayor a 1600 bytes.

Queueing

Una vez más, la capacidad para clasificar el tráfico se verá determinada por la arquitectura de QoS que tenga la linecard:

QOS queueing mode:     rx-(cos,dscp), tx-(cos,dscp)

QOS queueing mode:     rx-(cos), tx-(cos)

Para la configuración de políticas para Queueing donde podremos reservar un porcentaje del ancho de banda de la interface a  flujos de tráfico de diferentes características se requiere el uso de políticas de tipo “Queueing”:

 

S2T_core(config)#class-map type lan-queuing QUEUEING

S2T_core(config-cmap)#match dscp 46

S2T_core(config)#policy-map type lan-queuing QUEUEING

S2T_core(config-pmap)#class QUEUEING

S2T_core(config-pmap-c)#bandwidth percent 50

S2T_core(config-pmap-c)#end

 

Entre las opciones que tenemos para la clasificación de tráfico para queueing tenemos COS, DSCP o PRECEDENCE.

Las linecards con arquitecturas de queueing COS y DSCP serán capaces de clasificar y asignar buffers entre las queues disponibles en base a COS o a DSCP. A diferencia de las arquitecturas que soportan COS solamente, estas solo podrán realizar acciones de queueing basadas en valores de COS.

Al intentar clasificar trafico marcado con DSCP para acciones de queueing en arquitecturas que solo soportan COS el switch nos arrojara un error y sera imposible configurar la politica en la interface.

Mensajes de error comunes:

En ocasiones, no seremos capaces de visualizar los mansajes de error y nos encontraremos en una situación donde intentamos configurar nuestra política en la interface y simplemente no es aplicada en la configuración esto es debido al bug CSCur92556 donde los mensajes de error no son visualizados si estamos conectados al switch vía Telnet o SSH, sin embargo, estos son perfectamente visibles a través de consola.

Bandwidth can not be configured on default class: Default class gets assigned remaining bandwidth not used by other queues

HWIF QOS:Policy attach Failed

El mensaje especifica que la configuración de “bandwidth” en la clase default no esta soportado. Remover la configuración de la política resolvería este mensaje de error.

S2T_core#show policy-map type lan-queuing QUEUEING

  Policy Map QUEUEING

    Class class-default

      bandwidth 50 (%)  <<< Remover

 

Priority percent/absolute command is not supported

Use 'priority level [1-2] percent <val>/<abs value>' instead

HWIF QOS:Policy attach Failed

El mensaje especifica que se ha configurado una queue de prioridad en la política de queueing sin especificar su nivel de prioridad específico:

S2T_core #show policy-map type lan-queueing PRIORITY

  Policy Map type lan-queuing PRIORITY

    Class QUEUEING

      priority 50000 (kbps) 

Reemplazar con:

Class PRIORITY

priority level [1/2] 50000

HWIF QOS: Match dscp not supported on the interface 

Propagating [remove] lan queueing policy "QUEUEING" to Gi1/1 Gi1/3 Gi1/4 Gi1/5 Gi1/6 Gi1/7 Gi1/8 Gi1/9 Gi1/10 Gi1/11 Gi1/12

El mensaje especifica que la clasificación basada en DSCP no está soportada en la interface, esto normalmente ocurre cuando la linecard no soporta queueing en DSCP debido a su arquitectura. El Queueing basado en DSCP esta únicamente soportando en puertos con arquitectura 8q4t, 1p7q2t y 1p7q4t.

S2T_core#show int gig 1/1 capabilities | inc QOS

  QOS scheduling:        rx-(1q8t), tx-(1p3q8t)  <<<

  QOS queueing mode:     rx-(cos), tx-(cos)

Bandwidth in Kbps not supported

HWIF QOS:Policy attach Failed

bandwidth kbps/percent command cannot co-exist with strict priority in the same policy-map

Una vez que exista una queue de prioridad definida en una política, es necesario que las demás queues no prioritarias usen un porcentaje del bandwidth restante con la configuracion “bandwidth remain percent {dec}”:

 

S2T_core #show policy-map type lan-queueing QUEUEING

  Policy Map type lan-queuing QUEUEING

    Class QUEUEING

      priority 1 50000 (kbps)

    Class QUEUEING_2

      bandwidth 20000

 Reemplazar con:

S2T_core #show policy-map type lan-queueing QUEUEING

  Policy Map type lan-queuing QUEUEING

    Class QUEUEING

      priority 1 50000 (kbps)

    Class QUEUEING_2

      bandwidth remaining percent 20

 

Comentarios
New Member

Excelente Documento, muy completo y exactamente lo que estaba buscando!
Muchas gracias por tu aportación :)

De casualidad no tendrás unos links de donde pueda ver el tema un poco más a fondo?
Saludos!

Cisco Employee

Hola vicanky,

Claro, puedes encontrar informacion respecto a las capacidades de QoS de las linecards y mas en los siguientes enlaces:

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-652042.html

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11_538840.html

Saludos!

New Member

Perfecto, Muchas gracias por la información!! :)

Saludos!

127
Visitas
10
ÚTIL
3
Comentarios