Compreendendo Como as Atualizações de Roteamento e os Pacotes de Controle do Layer 2 São Enfileirados em uma Interface Com Uma Política de Serviço de QoS

Introduction

Este documento explica como mensagens de protocolo de roteamento, como saudações e descritores de banco de dados, assim como outro tráfego de controle importante, são enfileirados quando uma interface de roteador de saída é configurada com uma política de serviço usando os comandos da interface de linha de comando (MQC) de qualidade de serviço modular.

Especificamente, este documento revisa esses dois mecanismos usados pelos roteadores Cisco IOS^® para priorizar pacotes de controle:

Campo	Local	Onde a Prioridade é Considerada
Bits de precedência de IP	Byte de TOS (tipo de serviço) no cabeçalho IP	Fornece prioridade por meio da rede
pak_priority	Rótulo de pacote interno dentro do roteador, atribuído pelo driver de interface	Fornece prioridade através do roteador (por salto)

Ambos os mecanismos foram projetados para garantir que os principais pacotes de informações de controle não sejam soltos ou sejam soltos por último pelo roteador e pelo sistema de fila quando uma interface externa estiver congestionada.

Prerequisites

Requirements

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

Componentes Utilizados

As informações neste documento se baseiam na Versão 12.2 do Software Cisco IOS.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Tags de priorização de pacote externo

O RFC 791 define o byte TOS no cabeçalho de um pacote IP. Embora RFC 2474 e RFC 2475 redefinam esse byte como valores de Ponto de Código de Serviços Diferenciados (DSCP - Differentiated Services Code Point), um roteador Cisco IOS ainda usa os bits originais de precedência de IP do byte TOS, conforme RFC 791. Observe como o RFC define o byte TOS:

O Tipo de Serviço fornece uma indicação dos parâmetros abstratos da qualidade do serviço desejado. Esses parâmetros devem ser utilizados para guiar a seleção dos parâmetros de serviço reais ao transmitir um datagrama por meio de uma rede específica. Várias redes oferecem precedência de serviço, que de alguma forma trata o tráfego de alta precedência como mais importante do que outro tráfego (geralmente ao aceitar somente tráfego acima de uma certa precedência em um determinado momento de carga alta).

Como ilustrado no diagrama, o campo de precedência de IP ocupa os três bits mais significativos do byte TOS. Somente os três bits precedentes do IP, e não o valor total do byte TOS, refletem a prioridade ou a importância do pacote.

Esta tabela lista os valores dos bits de precedência:

Número	Valor do bit	Nome
0	000	Rotina
1	001	Prioridade
2	010	Imediato
3	011	Flash
4	100	Substituição de Flash
5	101	CRÍTICO/ECP
6	110	Controle de Internetwork
7	111	Controle de rede

O Cisco IOS atribui uma precedência de IP de 6 aos pacotes do protocolo de roteamento no plano de controle. Conforme observado pelo RFC 791, "A designação de controle de internetwork destina-se ao uso somente por originadores de controle de gateway." Especificamente, o Cisco IOS marca estes pacotes de controle baseados em IP: Hellos e keepalives de Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP). O valor de precedência de IP de 6 também é atribuído a pacotes de Telnet enviados do roteador e dele recebidos. O valor atribuído permanece com os pacotes quando a interface de saída transmite-os na rede.

Caracteres de priorização de pacote interno

Embora o valor de precedência de IP especifique o tratamento de um datagrama em sua transmissão através da rede, o mecanismo pak_priority especifica o tratamento de um pacote durante sua transmissão dentro do roteador.

Além do núcleo de uma CPU de roteador, cada interface usa um controlador de rede ou uma CPU local, que executa uma parte especial de software chamada driver. O código do driver fornece instruções específicas da interface.

Quando recebe um pacote, o driver da interface copia o pacote de um pequeno buffer FIFO (first-in, first-out, primeiro a entrar, primeiro a sair) para um buffer de dados na memória de entrada/saída (I/O). Em seguida, ele conecta um pequeno cabeçalho de pacote ao buffer. O cabeçalho do pacote, mencionado na terminologia do Cisco IOS como a estrutura paktype, contém informações importantes sobre o bloco de dados no buffer. Dependendo do conteúdo do pacote, o cabeçalho do pacote pode apontar para o endereço na memória onde o cabeçalho de encapsulamento Ethernet, o cabeçalho de Protocolo Internet (IP) e o cabeçalho de Protocolo de Controle de Transmissão (TCP - Transmission Control Protocol) são iniciados.

O Cisco IOS Software usa os campos do cabeçalho do pacote para controlar o tratamento do pacote nas filas da interface. O cabeçalho de pacote inclui o flag pak_priority, que indica a importância relativa de pacotes marcados no sistema de enfileiramento.

Os processos de roteamento RIP e OSPF executados na CPU central de um roteador marcam todo o tráfego que originam com a precedência 6 de IP e a prioridade_pak. Em contraste, o BGP (Border Gateway Protocol) instrui o TCP a marcar seu tráfego com a precedência de IP 6, mas não define pak_priority.

O Cisco IOS também deve garantir uma baixa probabilidade de queda para vários tipos de pacotes de controle não-IP. Esses tipos de pacote incluem:

• Mensagens do protocolo de roteamento IS-IS (Intermediate System-to-Intermediate System)

• Mensagens do Enhanced Interior Gateway Routing Protocol (EIGRP)

• PPP (Protocolo ponto a ponto) e manutenções de atividades do HDLC (Controle de enlace de dados de alto nível) em interfaces seriais e POS (Pacote sobre SONET)

• Operações, administração e células de manutenção (OAM) e mensagens de protocolo de resolução de endereço (ARP) em interfaces ATM

Como esse tráfego não é IP, o Cisco IOS não pode fazer a correspondência com o valor de precedência do IP para priorização. Em vez disso, ele usa apenas o valor de pak_priority interno no cabeçalho do buffer de pacotes.

Observação: o Cisco Catalyst 6000 / Cisco 7600 Series inicialmente suportava o mecanismo pak_priority somente no FlexWAN. Os aprimoramentos na priorização de pacotes de controle IP e não IP foram implementados posteriormente.

Marcas e enfileiramento de priorização de pacotes

Os roteadores como o Cisco 7500 Route/Switch Processor (RSP) e os roteadores de extremidade inferior (como os Cisco 7200 e 3600 Series) usam um mecanismo diferente para rotear e controlar o tráfego que o Cisco 7500 Versatile Interface Processor (VIP). Esta tabela resume as duas abordagens e presume que uma política de serviço configurada com o MQC é aplicada à interface de saída.

Platform	Enfileiramento de Mensgens pak_priority
Cisco 7500 Series (com QoS e VIPs distribuídos)	Coloca o tráfego pak_priority na fila de classes de padrão classe, ou em uma fila especificamente configurada (separada). Quando enfileirados para class-default, os pacotes vão para a extremidade traseira da fila. O flag de pak_priority é usado para evitar o descarte dos pacotes de alta prioridade.
QoS baseada em RSP e outras plataformas, que incluem as séries Cisco 7200, 3600, 2600	Coloca o tráfego de pak_priority em um conjunto separado de filas diferente de class-default. (Consulte a seção Compreender filas especiais com plataformas não RSP.) Marca essas mensagens com um valor de peso especial (atualmente 1024).

Em outras palavras, na série Cisco 7500, se uma política de serviço de saída estiver conectada à interface, os pacotes serão classificados em relação às classes nessa política, e o pacote pak_priority será colocado no final da fila de classe escolhida. Se o pacote pak_priority não corresponder a nenhuma classe definida pelo usuário, ele será colocado no fim da fila padrão da classe.

Observação: com métodos de enfileiramento legado como enfileiramento de prioridade e enfileiramento personalizado ou com uma fila FIFO de interface padrão, os roteadores não-RSP enfileiram mensagens pak_priority para o cabeçalho da fila para garantir latência mínima e probabilidade mínima de descarte.

Entender as filas especiais com plataformas não RSP

Conforme observado na tabela Packet Prioritization Tags and Queuing, as plataformas de roteador da Cisco como as séries Cisco 7200, 3600 e 2600 colocam as mensagens pak_priority em um conjunto separado de filas e não no conjunto de filas padrão da classe.

Há três conjuntos de filas em uma interface:

• 2^n conjunto de filas baseadas em fluxo que consideram valores de cabeçalho como os endereços IP origem e destino. O número real de filas baseia-se na largura de banda da interface ou circuito virtual. Consulte a descrição do comando fair-queue na Referência de Comandos do Cisco IOS.

• Filas para classes criadas por usuários.

• As filas acessadas com base em um hash do tipo de link. Por exemplo, os microfluxos IP são classificados pelo sistema de enfileiramento justo em filas com base em um hash dos endereços de origem e destino e das portas, bits TOS e número do protocolo IP. As mensagens da interface de gerenciamento local (LMI) do Frame Relay são enfileiradas com base em um hash do número mágico que indica que a mensagem é LMI. As mensagens com o sinalizador pak_priority vão para essas filas de tipo de link separadas.

Esta tabela lista as várias filas e suas IDs de conversação (conforme visto na saída dos comandos show policy-map interface ou show queue) para uma interface com largura de banda superior a 512 Kbps.

Conversa / Número da fila	Tipo de tráfego
1 - 256	Filas de tráfego baseadas em fluxo geral. O tráfego que não corresponde a uma classe criada pelo usuário corresponde ao padrão de classe e a uma das filas baseadas em fluxo.
257 - 263	Reservado para o Cisco Discovery Protocol e para pacotes marcados com um flag interno de alta prioridade.
264	Fila reservada para a classe de prioridade (classes configuradas com o comando priority). Procure o valor "Strict Priority" para a classe na saída show policy-map interface. A fila de prioridade usa uma ID de conversação igual ao número de filas dinâmicas mais 8.
265 e superior	Filas para classes criadas por usuários.

Observação: os valores nesta tabela dependem da implementação e estão sujeitos a alterações.

Priorizar pacotes IS-IS

Os pacotes de controle de roteamento do Intermediate System to Intermediate System (IS-IS) são um caso especial em relação ao enfileiramento e à priorização de pacotes.

O IS-IS é o protocolo de roteamento do Protocolo de Rede Sem Conexão (CLNP - Connectionless Network Protocol) da Organização Internacional de Padronização (ISO - International Organization for Standardization). Os desenvolvedores de CLNP viram o TCP/IP como um conjunto de protocolo temporário que o conjunto OSI (Interconexão de sistemas abertos) acabaria por substituir. Para suportar essa transição prevista, o IS-IS integrado (ou IS-IS duplo) foi criado como uma extensão do IS-IS para fornecer um único protocolo de roteamento capaz de rotear o CLNS (Connectionless-mode Network Service) e o IP. O protocolo foi projetado para operar em um ambiente CLNS puro, ambiente IP puro ou em ambiente duplo CLNS/IP.

Mesmo quando o IS-IS é usado para rotear somente TCP/IP, o IS-IS ainda é um protocolo CLNP ISO. Os pacotes pelos quais o IS-IS se comunica com seus pares são unidades de dados de protocolo (PDUs) CLNS, o que por sua vez significa que mesmo em um ambiente somente IP, o sistema de enfileiramento e o Cisco IOS não podem usar precedência de IP para priorizar mensagens de controle CLNS. Em vez disso, os pacotes IS-IS recebem prioridade através do mecanismo pak_priority dentro do roteador.

Configurar uma estratégia de enfileiramento para rotear pacotes

Esta seção considera as três abordagens gerais para projetar uma estratégia de enfileiramento especificamente para minimizar as chances de pacotes de controle descartados em condições de congestionamento pesado nas séries Cisco 7500 e VIPs. (Lembre-se de que as plataformas não RSP colocam pacotes de controle em filas separadas por padrão.)

Estratégia	Quando usar	Descrição de como configurar
Faça a correspondência com uma fila separada.	A estratégia mais conservadora. Garante pouca ou nenhuma queda.	Utilize a CLI QoS modular para configurar uma classe separada e utilize o comando bandwidth para atribuir uma alocação de largura de banda mínima para o tráfego correspondente durante os períodos de congestionamento. Uma classe configurada com o comando bandwidth usa um "peso" de programação com base na largura de banda e não na precedência de IP. Consulte Entendendo o Enfileiramento Moderado Ponderado Baseado em Classe em ATM.
Faça a correspondência com class-default com fair queuing.	Suficiente para a maioria das configurações. Alguns pacotes de controle podem ser descartados na presença de congestionamento.	Use a precedência 6 do IP atribuída automaticamente pelo Cisco IOS ao pacote, para influenciar o peso e também o compartilhamento respectivos da largura de banda. Consulte O que é enfileiramento adequado ponderado em ATM.
Faça a correspondência com class-default com o enfileiramento FIFO.	Não recomendado para links congestionados. Alguns pacotes de controle podem ser descartados na presença de congestionamento.	Essa abordagem não leva em conta a precedência de IP. Com o QoS baseado em VIP, as mensagens pak_priority são enfileiradas no final da fila de FIFO.

Este é um exemplo de como criar uma fila separada para pacotes de controle RIP.

 class-map match-all rp 
   match access-group 104 
! 
 access-list 104 permit udp any eq rip any eq rip 

!--- Create a class-map that matches an ACL permitting RIP. 

! 
 policy-map bandwidth 
   class voip 
     priority 64 
   class bus 
    bandwidth 184 
   class RP 
    bandwidth 8 

!--- Create a policy-map (named "bandwidth") and specify !--- class RP. 
! 
interface Serial1/0:0.1 point-to-point 
  bandwidth 256 
  ip unnumbered Loopback0 
  ip accounting precedence input 
  no cdp enable 
  frame-relay class sample 
  frame-relay interface-dlci 100 IETF 

!--- Apply the map-class named "sample" to the PVC. 

! 
map-class frame-relay sample 
  frame-relay cir 256000 
  frame-relay bc 2560 
  frame-relay mincir 256000 
  no frame-relay adaptive-shaping 
  service-policy output bandwidth 
  frame-relay fragment 160 

!--- Create a frame relay map-class and apply the service !--- policy inside the map-class.

Considere estes fatores ao escolher uma destas abordagens:

• O protocolo de roteamento específico usado e os valores de temporizador configurados para saudações e atualização do banco de dados

• O tamanho do banco de dados que precisa ser trocado e se apenas atualizações/alterações ou tabelas completas são atualizadas periodicamente

• A quantidade de congestionamento esperada na interface ou no circuito virtual

Em outras palavras, considere as chances de enfileiramento de pacotes de alta prioridade na presença de congestionamento.

QoS e pacotes gerados localmente

O tráfego gerado pelo roteador representa um caso especial para políticas de serviço de QoS de saída. Alguns tráfegos gerados localmente devem ser tratados como qualquer outro tráfego de usuário, e o sistema de QoS deve aplicar os mecanismos de QoS configurados a esse tráfego. Um exemplo desse tráfego são as sondas de desempenho que são projetadas para medir o comportamento incorrido por pacotes de uma determinada classe. Outro tráfego gerado localmente, particularmente keepalives de Camada 2 e mensagens de protocolo de roteamento, é vital para o funcionamento básico do roteador e não deve estar sujeito a alguns recursos de QoS. Por exemplo, a detecção antecipada aleatória ponderada (WRED - Weighted Random Early Detection) não deve descartar keepalives da Camada 2 quando a profundidade média da fila atinge uma marca d'água alta

Além disso, os pacotes destinados ao roteador devem ser tratados com cuidado. Por exemplo, lembre-se de que uma política de serviço que aplique vigilância baseada em classe não deve se aplicar aos pacotes destinados ao roteador para evitar descartar mensagens de controle importantes.

Observação: conforme o projeto, os pacotes gerados pelo RP não são considerados nos contadores CLI de QoS modular, mesmo que esses pacotes sejam classificados/enfileirados corretamente. Esses pacotes não são considerados na saída do comando show policy-map interface.

Esta tabela lista como os pacotes destinados ao roteador e do roteador interagem atualmente com os principais recursos de QoS.

Recurso de QoS	Descrição
Marcação com base na classe	Originalmente, funcionava somente nos pacotes comutados pelo CEF. Suporte para os métodos de switching de processo e switching rápida foi introduzido Cisco IOS Software Versão 12.2(5) (CSCdt74738).
Vigilância	Entrada - Limite de taxa pode ser aplicado. A interface de entrada deve ser configurada com CEF se a Taxa de Acesso Confirmada (CAR - Committed Access Rate) (e não a vigilância baseada em classe) for usada. Em um roteador da série Cisco 7500, a vigilância de tráfego pode monitorar somente caminhos de switching CEF. Saída - Limitação de taxa com CAR ou trabalhos de vigilância baseados em classe.

Priorizar pacotes no Catalyst 6000

Quando você executa o Cisco IOS no supervisor e na MSFC (MultiLayer Switch Feature Card) no Catalyst 6000, o RP marca os pacotes de controle de roteamento com precedência IP 6. Esse valor remarcado pode ser utilizado com a programação de saída para mapear os pacotes de controle de roteamento para fila e limiar superiores no Weighted Round Robin (WRR) System. Esse mapeamento de pacotes de controle de roteamento originados pela MSFC acontece automaticamente, desde que a QoS seja habilitada globalmente com o comando mls qos. Se você habilitar a QoS, isso fará com que o sistema configure todos os parâmetros de enfileiramento, como limiares de queda WRED, larguras de banda WRR e limites de fila. Com a QoS desabilitada globalmente, todos os pacotes são mapeados para a fila baixa, limite baixo para programação de saída, WRR.

Conforme observado no capítulo Configurando QoS do Guia de Configuração do Catalyst 6000, a QoS suporta classificação, marcação, programação e prevenção de congestionamento usando valores de Classe de Serviço (CoS - Class of Service) de Camada 2 em portas de entrada Ethernet. Classificação, marcação, programação e prevenção de congestionamento nas portas de entrada Ethernet não usam nem definem os valores de precedência IP ou DSCP da Camada 3. Além disso, com qualquer mecanismo de comutação, a QoS suporta o agendamento de portas de saída Ethernet e a prevenção de congestionamento com valores de CoS da camada 2. Como resultado, os pacotes IP e não IP cruciais devem ser mapeados para um valor de CoS, mesmo que esses valores sejam usados apenas internamente como parte do cabeçalho do barramento de dados. Os pacotes IP cruciais têm seu valor de precedência de IP de 6 mapeados para um valor de CoS equivalente de 6. Pacotes não IP cruciais, que incluem pacotes IS-IS originados do MSFC, são marcados com o flag pak_priority e, em seguida, esses pacotes sinalizados são mapeados para um valor de CoS 6. Esse mapeamento acontece automaticamente em versões atuais do Cisco IOS.

Nem os vigilantes de entrada nem os vigilantes de saída marcam pacotes originados pelo MSFC e destinados à transmissão através de uma interface Ethernet física.

A configuração de QoS no Catalyst 6000 está fora do escopo deste documento. Consulte Configurando o QoS e a página de suporte dos Switches LAN e ATM Catalyst para obter mais informações.

Informações Relacionadas

• Páginas de suporte de QoS
• Suporte Técnico e Documentação - Cisco Systems