Como compreender as políticas de QoS e a marcação no Catalyst 3550

Introdução

A função de vigilância determina se o nível de tráfego está dentro do perfil ou contrato especificado e permite que você remova o tráfego fora do perfil ou marque-o para um valor diferente de DSCP (Differential Services Code Point, Ponto de código de serviços diferenciais). Isto reforça um nível de serviço contratado.

O DSCP é uma medida do nível de Qualidade de Serviço (QoS) do pacote. Juntamente com o DSCP, a precedência de IP e a Classe de Serviço (CoS) também são usadas para transmitir o nível de QoS do pacote.

O policiamento não deve ser confundido com a modelagem de tráfego, embora ambos assegurem que o tráfego permaneça dentro do perfil ou do contrato.

A vigilância não armazena o tráfego em buffer, portanto, a vigilância não afeta o atraso de transmissão. Em vez de armazenar pacotes fora do perfil, a vigilância os descarta ou os marca com diferentes níveis de QoS (redução de DSCP).

A modelagem de tráfego coloca em buffer o tráfego fora do perfil e suaviza as intermitências de tráfego, mas afeta o atraso e a variação do atraso. A modelagem só pode ser aplicada na interface de saída, enquanto a vigilância pode ser aplicada na interface de entrada e de saída.

O Catalyst 3550 suporta policiamento para direções de entrada e saída. Não há suporte para modelagem de tráfego.

A marcação altera o nível de QoS do pacote de acordo com uma política.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Versões de hardware e software

A vigilância e a marcação no Catalyst 3550 são suportadas com todas as versões de software. O guia de configuração mais recente está listado aqui. Consulte esta documentação para todos os recursos suportados.

• Configurando QoS

Vigilância de QoS e parâmetros de marcação

Para configurar a vigilância, você deve definir os mapas de política de QoS e aplicá-los às portas. Isso também é conhecido como QoS baseado em porta.

Note:  O QoS baseado em VLAN não é suportado atualmente pelo Catalyst 3550.

O vigilante é definido pelos parâmetros de taxa e intermitência, bem como pela ação para tráfego fora de perfil.

Há suporte para estes dois tipos de vigilantes:

• Agregar

• Indivíduo

O vigilante agregado atua sobre o tráfego em todas as instâncias onde ele é aplicado. O vigilante individual atua separadamente no tráfego em cada instância onde ele é aplicado.

Observação: no Catalyst 3550, o vigilante agregado só pode ser aplicado a diferentes classes da mesma política. Não há suporte para a política agregada em várias interfaces ou políticas.

Por exemplo, aplique o vigilante agregado para limitar o tráfego de classe customer1 e classe customer2 no mesmo mapa de política a 1 Mbps. Tal vigilante permite 1 Mbps de tráfego na classe customer1 e customer2 juntos. Se você aplicar o vigilante individual, o vigilante limitará o tráfego para a classe customer1 a 1 Mbps e para a classe customer2 a 1 Mbps. Portanto, cada instância do vigilante é separada.

Esta tabela resume a ação de QoS no pacote quando tratado pelas políticas de entrada e saída:

Observação: é possível marcar e marcar dentro da mesma classe de tráfego da mesma política. Nesse caso, todo o tráfego para a classe específica é marcado primeiro. A vigilância e a redução ocorrem no tráfego já marcado.

A vigilância de QoS no Catalyst 3550 está em conformidade com este conceito de vazamento de bucket:

O número de tokens proporcionais aos tamanhos dos pacotes de tráfego de entrada são colocados em um token bucket; o número de tokens é igual ao tamanho do pacote. Em um intervalo regular, um número definido de tokens derivados da taxa configurada é removido do bucket. Se não houver lugar no bucket para acomodar um pacote recebido, o pacote será considerado fora de perfil e será descartado ou marcado de acordo com a ação de vigilância configurada.

Este conceito é mostrado neste exemplo:

Observação: o tráfego não é colocado em buffer no bucket, como pode ser visto neste exemplo. O tráfego real não flui pelo bucket; o bucket é usado somente para decidir se o pacote está no perfil ou fora de perfil.

Observação: a implementação de hardware da vigilância pode variar, mas funcionalmente ainda está em conformidade com esse modelo.

Estes parâmetros controlam a operação de vigilância:

• Taxa — define quantos tokens são removidos em cada intervalo. Isso define efetivamente a taxa de vigilância. Todo o tráfego abaixo da taxa é considerado no perfil. As taxas suportadas variam de 8 Kbps a 2 Gbps e aumentam em 8 Kbps.

• Intervalo — define com que frequência os tokens são removidos do bucket. O intervalo é fixado em 0,125 milissegundos (ou 8000 vezes por segundo). Este intervalo não pode ser alterado.

• Intermitência — define a quantidade máxima de tokens que o bucket pode conter a qualquer momento. As intermitências suportadas variam de 8000 bytes a 2000000 bytes e aumentam em 64 bytes.

Observação: embora as strings de ajuda da linha de comando mostrem um grande intervalo de valores, a opção rate-bps não pode exceder a velocidade de porta configurada e a opção burst-byte não pode exceder 2000000 bytes. Se você inserir um valor maior, o switch rejeitará o mapa de política quando você o conectar a uma interface.

Para manter a taxa de tráfego especificada, a intermitência não deve ser inferior à soma desta equação:

Burstmin (bits) = Rate (bps) / 8000 (1/sec) 

Por exemplo, calcule o valor mínimo de intermitência para sustentar uma taxa de 1 Mbps. A taxa é definida como 1000 Kbps, portanto, o burst mínimo necessário é a soma desta equação:

1000 (Kbps) / 8000 (1/sec) =125 (bits) 

O tamanho mínimo de intermitência suportado é 8000 bytes, que é mais do que o mínimo calculado de intermitência.

Observação: devido à granularidade da vigilância de hardware, a taxa exata e a intermitência são arredondadas para o valor suportado mais próximo.

Ao configurar a taxa de intermitência, você deve levar em conta que alguns protocolos implementam mecanismos que reagem à perda de pacotes. Por exemplo, o Transmission Control Protocol (TCP) reduz a janela pela metade para cada pacote perdido. Isso causa um efeito de "dente de serra" no tráfego TCP quando o TCP tenta acelerar até a taxa de linha e é acelerado pelo vigilante. Se a taxa média do tráfego de dentes de serra for calculada, essa taxa será muito menor que a taxa policiada. No entanto, você pode aumentar a intermitência para obter uma melhor utilização. Um bom começo é definir a intermitência igual ao dobro da quantidade de tráfego enviado com a taxa desejada durante o Round-Trip Time (TCP RTT). Se RTT não for conhecido, você pode dobrar o valor do parâmetro de intermitência.

Pelo mesmo motivo, não é recomendável fazer referência à operação do vigilante pelo tráfego orientado a conexão. Esse cenário geralmente mostra um desempenho inferior ao permitido pelo vigilante.

O tráfego sem conexão também pode reagir ao policiamento de forma diferente. Por exemplo, o NFS (Network File System) usa blocos, que podem consistir em mais de um pacote UDP (User Datagram Protocol). Um pacote descartado pode disparar muitos pacotes, até mesmo o bloco inteiro, para serem retransmitidos.

Este exemplo calcula o burst para uma sessão TCP com uma taxa de vigilância de 64 Kbps e, dado que o TCP RTT é de 0,05 segundos:

<burst> = 2*  *  = 2 * 0.05 [sec] * 64000/8 [bytes/sec] = 800    [bytes] 

Neste exemplo, <burst> é para uma sessão TCP. Dimensione este número para a média do número esperado de sessões que trafegam pelo vigilante.

Observação: Este é apenas um exemplo, em cada caso você precisa avaliar os requisitos de tráfego e de aplicativo e o comportamento em relação aos recursos disponíveis para escolher os parâmetros de vigilância.

A ação de vigilância pode ser descartar o pacote ou alterar o DSCP do pacote (markdown). Para reduzir o pacote, um mapa de DSCP policiado deve ser modificado. Um mapa DSCP policiado padrão comenta o pacote com o mesmo DSCP. Portanto, não ocorrerá nenhuma redução.

Os pacotes podem ser enviados fora de ordem quando um pacote fora de perfil é marcado para baixo em um DSCP mapeado em uma fila de saída diferente do DSCP original. Se a ordem dos pacotes for importante, reduza os pacotes fora de perfil para o DSCP mapeado para a mesma fila de saída que os pacotes dentro do perfil.

Vigiando e marcando recursos suportados pelo Catalyst 3550

Esta tabela fornece um resumo dos recursos relacionados à vigilância e marcação suportados pelo Catalyst 3550, divididos por direção:

Há suporte para uma instrução de correspondência por mapa de classe. Estas são instruções de correspondência válidas para a política de entrada:

• match access-group

• match ip dscp

• precedência compatível de ip

Observação: no Catalyst 3550, o comando match interface não é suportado e somente um comando match é permitido em um mapa de classe. Portanto, é complicado classificar todo o tráfego que chega através de uma interface e policiar todo o tráfego com um único vigilante. Consulte a seção Como classificar todo o tráfego de interface com um único vigilante deste documento.

Esta é a instrução de correspondência válida para a política de saída:

• match ip dscp

Estas são ações de política válidas para a política de entrada:

• polícia

• set ip dscp (marcação)

• set ip precedence (marking)

• trust dscp

• trust ip-precedence

• trust cos

Esta tabela mostra a matriz de políticas de QoS de entrada suportada:

1. Essa opção também aborda a precedência de IP de correspondência.

2. Essa opção abrange o CoS confiável, a precedência de IP e o DSCP.

3. Essa opção também aborda a definição da precedência de IP.

Esta é a ação de política válida para a política de saída:

• polícia

Esta tabela mostra a matriz de políticas de QoS de saída suportadas:

A marcação permite que o nível de QoS do pacote seja alterado com base na classificação ou na vigilância. A classificação divide o tráfego em diferentes classes para o processamento de QoS com base nos critérios definidos.

O processamento de QoS é baseado no DSCP interno; a medida do nível de QoS do pacote. O DSCP interno é derivado de acordo com a configuração de confiança. O sistema oferece suporte a CoS confiável, DSCP, precedência de IP e interfaces não confiáveis. A relação de confiança especifica o campo a partir do qual o DSCP interno é derivado para cada pacote, da seguinte maneira:

• Ao confiar em CoS, o nível de QoS é derivado do cabeçalho da Camada 2 (L2) do Inter-Switch Link Protocol (ISL) ou do pacote encapsulado 802.1Q.

• Ao confiar na precedência de DSCP ou IP, o sistema deriva o nível de QoS do campo de precedência de DSCP ou IP do pacote de acordo.

Confiar no CoS só é significativo em interfaces de entroncamento, e confiar no DSCP (ou precedência de IP) faz sentido apenas para pacotes IP.

Quando uma interface não é confiável, o DSCP interno é derivado do CoS padrão configurável para a interface correspondente. Este é o estado padrão quando a QoS está habilitada. Se nenhum CoS padrão estiver configurado, o valor padrão será zero.

Uma vez determinado o DSCP interno, ele pode ser alterado por marcação e vigilância ou retido.

Depois que o pacote passa pelo processamento de QoS, seus campos de nível de QoS (no campo IP/DSCP para IP e no cabeçalho ISL/802.1Q, se houver) são atualizados a partir do DSCP interno. Há estes mapas de QoS especiais relevantes para vigilância:

• DSCP para DSCP vigiado — usado para derivar o DSCP vigiado quando você faz markdown do pacote.

• DSCP-to-CoS — usado para derivar o nível de CoS do DSCP interno para atualizar o cabeçalho do pacote de saída ISL/802.1Q.

• CoS-to-DSCP — usado para derivar o DSCP interno do CoS de entrada (cabeçalho ISL/802.1Q) quando a interface está no modo CoS de confiança.

Estas são considerações importantes específicas da implementação:

• A política de serviço de ingresso não pode ser anexada à interface quando ela está configurada para confiar em qualquer métrica de QoS, como CoS/DSCP ou precedência de IP. Para corresponder à precedência de DSCP/IP e à vigilância no ingresso, você deve configurar a confiança para a classe específica dentro da política, não na interface. Para marcar com base na precedência de DSCP/IP, nenhuma confiança deve ser configurada.

• Somente o tráfego IPv4 sem opções de IP e o encapsulamento ARPA (Advanced Research Projects Agency) da Ethernet II são considerados tráfego IP do ponto de vista do hardware e da QoS. Todo o tráfego restante é considerado não IP, incluindo IP com opções, como SNAP (SubNetwork Access Protocol), IP encapsulado e IPv6.

• Para pacotes não-IP, o "grupo de acesso de correspondência" é o único método de classificação, pois você não pode corresponder o DSCP para tráfego não-IP. Uma lista de acesso (ACL) de controle de acesso ao meio (MAC - Media Access Control) é usada para essa finalidade; os pacotes podem ser combinados com base no endereço MAC origem, no endereço MAC destino e no EtherType. Não é possível fazer a correspondência entre o tráfego IP e a ACL MAC, já que o switch faz uma distinção entre o tráfego IP e não IP.

Configurar e monitorar a vigilância

Estas etapas são necessárias para configurar a vigilância no Cisco IOS:

1. Definir um vigilante (para vigilantes agregados)

2. Definir critérios para selecionar tráfego para vigilância

3. Definir um mapa de classes para selecionar o tráfego usando critérios definidos

4. Definir uma política de serviço usando classe e aplicando um vigilante à classe especificada

5. Aplicar uma política de serviço a uma porta

Há suporte para estes dois tipos de vigilantes:

• Agregação nomeada

• Indivíduo

O vigilante agregado nomeado policia o tráfego combinado de todas as classes dentro da mesma política para onde ele é aplicado. Não há suporte para a política agregada em diferentes interfaces.

Observação: o vigilante agregado não pode ser aplicado a mais de uma política. Se for, esta mensagem de erro será exibida:

QoS: Cannot allocate policer for policy map <policy name>

Considere este exemplo:

Há um gerador de tráfego conectado à porta GigabitEthernet0/3 que envia aproximadamente 17 Mbps de tráfego UDP com a porta de destino 111. Há também o tráfego TCP da porta 20. Você deseja que esses dois fluxos de tráfego sejam vigiados em 1 Mbps, e o tráfego excessivo deve ser descartado. Este exemplo mostra como isso é feito:

!--- Globally enables QoS.

mls qos

!--- Defines the QoS policer, sets the burst !--- to 16000 for better TCP performance.

mls qos aggregate-policer pol_1mbps 1000000 16000 exceed-action drop

!--- Defines the ACLs to select traffic.

access-list 123 permit udp any any eq 111
access-list 145 permit tcp any eq 20 any

!--- Defines the traffic classes to be policed.

class-map match-all cl_udp111
  match access-group 123
class-map match-all cl_tcp20
  match access-group 145

!--- Defines the QoS policy, and attaches !--- the policer to the traffic classes.

policy-map po_test
  class cl_udp111	
    police aggregate pol_1mbps 
  class cl_tcp20
    police aggregate pol_1mbps 

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test
!

O primeiro exemplo usou o vigilante agregado nomeado. O vigilante individual, ao contrário do vigilante nomeado, policia o tráfego separadamente em cada classe onde é aplicado. O vigilante individual é definido na configuração do mapa de política. Neste exemplo, duas classes de tráfego são vigiadas por dois vigilantes individuais; cl_udp111 é policiado para 1 Mbps por intermitência de 8K e cl_tcp20 é policiado para 512 Kbps por intermitência de 32K:

!--- Globally enables QoS.

mls qos

!--- Defines the ACLs to select traffic.

access-list 123 permit udp any any eq 111
access-list 145 permit tcp any eq 20 any

!--- Defines the traffic classes to be policed.

class-map match-all cl_udp111
  match access-group 123
class-map match-all cl_tcp20
  match access-group 145

!--- Defines QoS policy, and creates and attaches !--- the policers to the traffic classes.

policy-map po_test2
  class cl_udp111	
    police 1000000 8000 exceed-action drop
  class cl_tcp20
    police 512000 32000 exceed-action drop

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test2

Este comando é usado para monitorar a operação de vigilância:

cat3550#show mls qos interface g0/3 statistics 
GigabitEthernet0/3
Ingress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
Others: 267718     0          267717     0          0         
Egress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
Others: 590877        n/a       n/a      266303     0         

WRED drop counts:
  qid  thresh1    thresh2   FreeQ
   1 : 0          0         1024      
   2 : 0          0         1024      
   3 : 0          0         8         
   4 : 0          0         1024

Observação: Por padrão, não há estatísticas por DSCP. O Catalyst 3550 suporta uma coleta de estatísticas por interface e por direção para até oito valores diferentes de DSCP. Isso é configurado quando você executa o comando mls qos monitor. Para monitorar estatísticas para DSCPs 8, 16, 24 e 32, você deve emitir este comando per-interface:

cat3550(config-if)#mls qos monitor dscp 8 16 24 32

Observação: o comando mls qos monitor dscp 8 16 24 32 altera a saída do comando show mls qos int g0/3 statistics para:

cat3550#show mls qos interface g0/3 statistics
GigabitEthernet0/3
Ingress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
    8 : 0          0          675053785  0          0         
    16: 1811748    0          0          0          0         ? per DSCP statistics 
    24: 1227820404 15241073   0          0          0         
    32: 0          0          539337294  0          0         
Others: 1658208    0          1658208    0          0         
Egress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
    8 : 675425886     n/a       n/a      0          0         
    16: 0             n/a       n/a      0          0         ? per DSCP statistics
    24: 15239542      n/a       n/a      0          0         
    32: 539289117     n/a       n/a      536486430  0         
Others: 1983055       n/a       n/a      1649446    0         

WRED drop counts:
  qid  thresh1    thresh2   FreeQ
   1 : 0          0         1024      
   2 : 0          0         1024      
   3 : 0          0         6         
   4 : 0          0         1024

Esta é uma descrição dos campos no exemplo:

• Entrada — mostra quantos pacotes chegam de cada direção

• NO_change — mostra quantos pacotes foram confiáveis (como o nível de QoS não alterado)

• Classificado — mostra quantos pacotes foram atribuídos a esse DSCP interno após a classificação

• Policed — mostra quantos pacotes foram marcados como inativos pela vigilância; DSCP mostrado antes do markdown.

• Descartado — mostra quantos pacotes foram descartados pela vigilância

Esteja ciente destas considerações específicas de implementação:

• Se oito valores de DSCP forem configurados quando você executar o comando mls qos monitor, os outros contadores vistos quando você executar o comando show mls qos int statistics poderão exibir informações inadequadas.

• Não há nenhum comando específico para verificar a taxa de tráfego oferecida ou de saída por vigilante.

• Como os contadores são recuperados do hardware sequencialmente, é possível que eles não sejam adicionados corretamente. Por exemplo, a quantidade de pacotes policiados, classificados ou descartados pode ser ligeiramente diferente do número de pacotes de entrada.

Configurar e monitorar a marcação

Estas etapas são necessárias para configurar a marcação:

1. Definir os critérios para classificar o tráfego

2. Definir classes de tráfego a serem classificadas com os critérios definidos anteriormente

3. Criar um mapa de políticas que anexe ações de marcação e ações de vigilância às classes definidas

4. Configure as interfaces correspondentes para modo confiável

5. Aplique o mapa de política a uma interface

Neste exemplo, você deseja que o tráfego IP de entrada para o host 192.168.192.168 seja marcado com precedência de IP 6 e policiado para 1 Mbps; o tráfego em excesso deve ser marcado para a precedência 2 do IP:

!--- Globally enables QoS.

mls qos

!--- Defines the ACLs to select traffic.

access-list 167 permit ip any host 192.168.192.168

!--- Defines the traffic class.

class-map match-all cl_2host
  match access-group 167

!--- Defines QoS policy, and creates and attaches !--- the policers to the traffic classes.

policy-map po_test3
  class cl_2host

!--- Marks all the class traffic with the IP precedence 6.

    set ip precedence 6

!--- Polices down to 1 Mbps and marks down according to the QoS map.

    police 1000000 8000 exceed-action policed-dscp-transmit

!--- Modifies the policed DSCP QoS map, so the !--- traffic is marked down from IP precedence 6 to 2. !--- In terms of DSCP, this is from 48 to 16 (DSCP=IPprec x8).

mls qos map policed-dscp  48 to 16

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test3

O mesmo comando show mls qos interface statistics é emitido para monitorar a marcação. Exemplos de resultados e implicações estão documentados na seção deste documento.

Como classificar todo o tráfego de interface com um único vigilante

No Catalyst 3550, o comando match interface não é suportado, e somente um comando match é permitido por class-map. Além disso, o Catalyst 3550 não permite que o tráfego IP seja correspondido pelas ACLs MAC. Assim, o tráfego IP e não IP deve ser classificado com dois mapas de classe separados. Isso dificulta a classificação de todo o tráfego que entra em uma interface e o policiamento de todo o tráfego com um único vigilante. O exemplo de configuração aqui permite que você faça isso. Nessa configuração, o tráfego IP e não IP é combinado com dois mapas de classe diferentes. No entanto, cada um usa um vigilante comum para o tráfego.

access-list 100 permit ip any any

class-map ip
match access-group 100

!--- This class-map classifies all IP traffic.


mac access-list extended non-ip-acl
permit any any

class-map non-ip
match access-group name non-ip-acl

!--- Class-map classifies all non-IP traffic only. 


mls qos aggregate-policer all-traffic 8000 8000 exceed-action drop

!--- This command configures a common policer that is applied for both IP and non-IP traffic.


policy-map police-all-traffic
class non-ip
police aggregate all-traffic
class ip
police aggregate all-traffic

interface gigabitEthernet 0/7
service-policy input police-all-traffic

!--- This command applies the policy map to the physical interface.

 

Informações Relacionadas

• Configurando QoS no Catalyst 3550
• Páginas de Suporte da Qualidade de Serviço
• Página de suporte da switching de LAN
• Páginas de Suporte de Produtos de LAN
• Suporte Técnico e Documentação - Cisco Systems