Qualidade de Serviço (QoS) : Mecanismos de eficiência de link QoS

Entendendo a qualidade do serviço dos switches da família Catalyst 6000

23 Março 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (30 Janeiro 2006) | Feedback


Índice


Introdução

Este documento explica os recursos de Quality of Service (QoS) disponíveis nos switches da família Catalyst 6000. Este documento abrange os recursos de configuração de QoS e fornece alguns exemplos de como a QoS pode ser implementada.

Este documento não consiste em um guia de configuração. Os exemplos de configuração são utilizados neste trabalho para dar suporte à explicação dos recursos de QoS de hardware e software da família Catalyst 6000. Para obter referência de sintaxe das estruturas de comando de QoS, consulte os seguintes guias de configuração e comandos da família Catalyst 6000:

Definindo QoS de Camada 2

Ainda que muitas pessoas possam pensar que a QoS de switches na Camada 2 (L2) esteja relacionada apenas à priorização de quadro de Ethernet, alguns percebem que isso envolve muito mais. A QoS de Camada 2 engloba os itens a seguir:

    1. Programação de Fila de Entrada: quando entra na porta, o quadro pode ser atribuído a uma das diversas filas baseadas em portas, antes de ser programado para comutação em uma porta de saída. Geralmente, várias filas são utilizadas em situações em que diversos tipos de tráfego exigem níveis de serviço diferentes ou quando a latência do switch deve ser mantida no valor mínimo. Por exemplo, os dados de voz e de vídeo baseados em IP exigem uma latência menor; portanto, pode haver a necessidade de priorizar o switching desses dados sobre o switching de outros dados, como File Transfer Protocol (FTP), Web, e-mail, Telnet, etc.

    2. Classificação: O processo de classificação envolve a inspeção de diversos campos no cabeçalho da Camada 2 da Ethernet, juntamente com campos no cabeçalho IP (Camada 3 (L3)) e o cabeçalho do Protocolo de Controle de Transmissão/Protocolo de Datagrama de Usuário (TCP/UDP) (Camada 4 (L4)), a fim de auxiliar a determinação do nível de serviço a ser atribuído ao quadro, à medida que este transita no switch.

    3. Vigilância: vigilância é o processo de inspeção de um quadro da Ethernet para verificar se este excedeu a taxa de tráfego predefinida, em um determinado período (geralmente, esse período corresponde a um número fixo interno do switch). Se esse quadro estiver fora do perfil (ou seja, se for parte de um fluxo de dados excedente do limite predefinido para a taxa), ele poderá ser descartado ou o valor de Classe do Serviço (CoS) poderá ser rebaixado.

    4. Reescrevendo: o processo de reescrita é a capacidade do switch de modificar a CoS no cabeçalho Ethernet ou os bits do Tipo de Serviço (ToS) no cabeçalho IPV4.

    5. Programação de Fila de Saída: após os processos de reescrita, o switch colocará o quadro de Ethernet em uma fila de saída apropriada para o switching. O switch executará o gerenciamento de buffer nessa fila, assegurando que o buffer não crie excessos. Geralmente, isso é feito com o algoritmo Random Early Discard (RED), em que quadros aleatórios são removidos (descartados) da fila. O RED ponderado (WRED) é um derivado do RED (utilizado por determinados módulos da família Catalyst 6000), pelo qual os valores de CoS são inspecionados para determinar quais quadros serão descartados. Quando os buffers atingem limites predefinidos, quadros com prioridade menor são descartados e quadros com prioridade maior são mantidos na fila.

Esse documento explica cada um dos mecanismos acima em detalhes, como também a maneira como se relacionam à família Catalyst 6000 nas seções a seguir.

A Necessidade de QoS em um Switch

Atualmente, backplanes de grande porte, milhões de pacotes comutados por segundo e switches não bloqueados são sinônimos de diversos switches. Por que um QoS é necessário? A resposta é devido a um congestionamento.

O switch pode ser o mais rápido do mundo, mas se um dos dois cenários exibidos na figura acima ocorrer, este apresentará um congestionamento. Em caso de congestionamento, se os recursos de gerenciamento de congestionamentos não estiverem presentes, os pacotes serão descartados. Quando os pacotes são descartados, as retransmissões ocorrem. Ao ocorrerem retransmissões, a carga da rede pode aumentar. Nas redes que já estão congestionadas, poderá haver um somatório de problemas de desempenho, o que degradará esse desempenho ainda mais.

Com redes convergentes, o gerenciamento do congestionamento é ainda mais crítico. O tráfego sensível à latência, tal como de voz e vídeo, pode sofrer um impacto severo se houver atrasos. O acréscimo de buffers a um switch não reduzirá, necessariamente, os problemas de congestionamento. O tráfego sensível à latência precisa ser comutado o mais rápido possível. Em primeiro lugar, é necessário identificar esse tráfego importante por meio de técnicas de classificação e, em seguida, implementar as técnicas de gerenciamento de buffer para impedir que o tráfego com prioridade mais alta seja descartado durante o congestionamento. Finalmente, é necessário incorporar as técnicas de programação para comutar os pacotes importantes das filas, o mais rápido possível. Conforme a leitura desse documento mostrará, a família Catalyst 6000 implementa todas essas técnicas, tornando o subsistema QoS um dos mais abrangentes na indústria atual.

As técnicas de QoS descritas na seção anterior serão exploradas com mais detalhes neste documento.

Suporte de Hardware para QoS na Família Catalyst 6000

Para dar suporte a QoS na família Catalyst 6000, será necessário algum suporte de hardware também. O hardware que dá suporte a QoS inclui Multilayer Switch Feature Card (MSFC), Policy Feature Card (PFC) e Port Application Specific Integrated Circuits (ASICs) nas próprias placas de linha. Este documento não abordará as capacidades de QoS do MSFC; por outro lado, este se concentrará nas capacidades de QoS do PFC e nos ASICs das placas de linha.

PFC

A versão 1 do PFC é uma placa secundária, acomodada no Supervisor I (SupI) e no Supervisor IA (SupIA) da família Catalyst 6000. O PFC2 consiste na repetição de um ciclo de PFC1 e acompanha o Supervisor II (SupII) novo e alguns ASICs integrados novos. Tanto o PFC1 quanto o PFC2 são conhecidos principalmente pela aceleração de hardware de switching de Camada 3, todavia, a QoS consiste em um dos outros objetivos. Os PFCs são exibidos a seguir.

Embora PFC 1 e PFC2 sejam essencialmente iguais, existem algumas diferenças na funcionalidade QoS. O PFC2 adiciona as capacidades a seguir:

    1. A capacidade de aplicar a política de QoS em uma Placa de Encaminhamento Distribuído (DFC).

    2. As decisões sobre vigilância são ligeiramente diferentes. O PFC1 e o PFC2 dão suporte à vigilância normal, de modo que os quadros serão descartados ou rebaixados, se uma política agregada ou de micro-fluxo retornar uma decisão fora de perfil. Entretanto, o PFC2 adiciona o suporte para uma taxa excedente, o que indica um segundo nível de vigilância a ser utilizado para ações de política.

Quando um vigilante de taxa excedente for definido, os pacotes poderão ser descartados ou reduzidos ao ultrapassarem essa taxa. Se um nível de vigilância em excesso for determinado, o mapeamento de DSCP com excesso é utilizado para substituir o valor original de DSCP por um valor reduzido. Se apenas um valor normal de vigilância for configurado, o mapeamento de DSCP normal será utilizado. O nível de vigilância em excesso terá prioridade na seleção de normas de mapeamento, quando os dois níveis forem configurados.

É importante observar que as funções de QoS descritas neste documento e executadas pelo ASICs mencionado resultam em altos níveis de desempenho. O desempenho de QoS em uma família Catalyst 6000 de base (sem módulo de estrutura de switch) produz 15 MPPS. É possível obter ganhos de desempenho adicionais de QoS, se forem utilizadas DFCs.

DFC

A DFC pode ser anexada à WS-X6516-GBIC como uma opção. Todavia, esta consiste em uma solução padrão na placa WS-X6816-GBIC. A DFC também poderá ser suportada em outras placas de linha de estrutura, como a placa 10/100 (WS-X6548-RJ45) lançada recentemente, a placa de linha de estrutura RJ21 (WS-X6548-RJ21) e a 100FX (WS-X6524-MM-FX). A DFC é mostrada a seguir.

A DFC permite que a placa de linha de estrutura (conectada por barra transversal) execute o switching local. Para tal, as políticas de QoS definidas para o switch também deverão ser suportadas. O administrador não pode configurar a DFC diretamente; em vez disso, esta deverá ser controlada pelo MSFC/PFC principal, no supervisor ativo. O PFC principal enviará uma tabela do Banco de Informações de Encaminhamento (FIB), que, por sua vez, fornecerá à DFC as tabelas de encaminhamento de Camada 2 e Camada 3. Este também enviará uma cópia das políticas de QoS, de forma que estas também estejam disponíveis a nível local para a placa de linha. Posteriormente, as decisões de switching local podem fazer referência à cópia local das políticas de QoS, promovendo a agilização do processamento de QoS do hardware e, ainda, garantindo altos níveis de desempenho com switching distribuído.

ASICs com base na porta

Para completar a imagem do hardware, cada uma das placas de linha implementa um número de ASICs. Esses ASICs implementam as filas, a colocação em buffer e os limiares utilizados para o armazenamento temporário de quadros, enquanto atravessam o switch. Nas placas 10/100, uma combinação de ASICs é utilizada para suprir as 48 portas 10/100.

Placas de Linha 10/100 Originais (WS-X6348-RJ45)

Os ASICs 10/100 fornecem uma série de filas de Recepção (Rx) e Transmissão (Tx) para cada porta 10/100. Os ASICs fornecem 128 K de buffer por porta 10/100. Consulte as Release Notes para obter detalhes sobre a colocação em buffer por porta disponível em cada placa de linha. Cada porta nessa placa de linha dá suporte a uma fila Rx e a duas TX, descritas como alta e baixas. Isso é mostrado no diagrama a seguir.

No diagrama acima, cada ASIC 10/100 fornece um breakout de 12 portas 10/100. Para cada porta 10/100, são fornecidos buffers de 128 K. Esses buffers são divididos entre as três filas. As figuras mostradas na fila acima não são o padrão, entretanto elas podem ser uma representação do que poderia ser configurado. A fila Rx única fica com 16 K e a memória restante (112 K) é dividida entre as duas filas Tx. Por padrão, em CatOS, a fila alta recebe 20% desse espaço e a fila baixa recebe 80%. No Catalyst IOS, o padrão é conceder 10% à fila alta e 90% à fila baixa.

A placa fornece buffer de estágio dual, porém, somente a colocação em buffer baseada no ASIC 10/100 está disponível para manipulação durante a configuração de QoS.

Placas de Linha de Estrutura 10/100 (WS-X6548-RJ45)

Os novos ASICs 10/100 fornecem uma série de filas Rx e TX para cada porta 10/100. Os ASICs fornecem um pool de memória compartilhada, disponível nas portas 10/100. Consulte as Release Notes para obter detalhes sobre a colocação em buffer por porta disponível em cada placa de linha. Cada porta nessa placa de linha dá suporte a duas filas Rx e a três filas TX. Uma fila Rx e uma TX são descritas como filas de prioridade absoluta. Elas agem como uma fila de latência baixa, que é ideal para o tráfego sensível à latência, como o tráfego de Voz sobre IP (VoIP).

Placas de linha GE (WS-X6408A, WS-X6516, WS-X6816)

Para as placas de linha GE, o ASIC fornece 512 K de colocação em buffer por porta. A representação da placa de linha GE de oito portas é exibida no diagrama a seguir.

Cada porta GE apresenta três filas, sendo uma Rx e duas TX, conforme ocorre com as portas 10/100. Este é o padrão da placa de linha WS-X6408-GBIC, e está mostrado no diagrama abaixo.

Nas placas de linha GE de 16 portas mais recentes, nas portas GBIC em SupIA e SupII e na placa GE de 8 portas WS-X6408A-GBIC, são fornecidas duas filas extras de Prioridade Máxima (SP). Uma das filas SP é atribuída como uma fila Rx e a outra, como uma fila TX. Essa fila SP é utilizada principalmente para enfileirar o tráfego sensível à latência, tal como o de voz. Com a utilização da fila SP, os dados colocados nessa fila serão processados antes dos dados das filas alta e baixa. Somente quando a fila SP estiver vazia, as filas alta e baixa serão empregadas.

Placas de linha 10 GE (WS-X6502-10GE)

Na segunda metade de 2001, a Cisco apresentou uma série de placas de linha 10 GE, fornecendo uma porta de 10 GE por placa de linha. Esse módulo utiliza um slot do chassi 6000. A placa de linha 10 GE dá suporte a QoS. Ela fornece duas filas Rx e três TX para a porta 10 GE. Uma fila Rx e uma TX são designadas como fila SP. A colocação em buffer também é fornecida para a porta, disponibilizando um total de 256 K de buffer Rx e 64 MB de buffer TX. Esta porta implementa uma estrutura de fila de 1p1q8t para Rx e uma estrutura de fila de 1p2q1t para TX. As estruturas de fila são detalhadas adiante neste documento.

Sumário do Hardware de QoS na Família Catalyst 6000:

Os componentes de hardware que executam as funções de QoS acima na família Catalyst 6000 são detalhados na tabela a seguir.

Suporte de Software para QoS na Família Catalyst 6000

A família Catalyst 6000 dá suporte a dois sistemas operacionais. A plataforma do software original, CatOS, derivou-se da base de código usada na plataforma do Catalyst 5000. Mais recentemente, a Cisco lançou o Integrated Cisco IOS ® (Native Mode) (conhecido anteriormente como Native IOS), que utiliza uma base de código derivada do Cisco Router IOS. As duas plataformas OS (CatOS e Integrated Cisco IOS (Native Mode)) implementam o suporte de software, a fim de habilitar a QoS na plataforma da família de switches Catalyst 6000, utilizando o hardware descrito nas seções anteriores.

Observação: Esse documento utiliza exemplos de configuração das duas plataformas OS.

Mecanismos de Prioridade em IP e Ethernet

Para que os serviços de QoS sejam atribuídos aos dados, é necessário que haja um modo de classificar ou priorizar um pacote IP ou um quadro de Ethernet. Os campos de ToS e CoS são utilizados para esse fim.

ToS

ToS é um campo de um byte existente em um cabeçalho IPV4. O campo ToS consiste em oito bits, dos quais os três primeiros são utilizados para indicar a prioridade do pacote IP. Esses três primeiros bits são mencionados como os bits de precedência de IP. Eles podem ser configurados de zero até sete, sendo o zero a prioridade mais baixa e o sete a mais alta. O suporte está disponível para definir a precedência de IP no IOS por vários anos. O suporte à reconfiguração de precedência de IP pode ser proporcionado pelo MSFC ou pelo PFC (independente do MSFC). A mudança de configuração de confiável para não-confiável também pode apagar as definições de precedência de IP em um quadro recebido.

Os valores que podem ser definidos para precedência de IP são os seguintes:

O diagrama abaixo representa os bits de precedência de IP no cabeçalho de ToS. Os três Bits Mais Significativos (MSB) são interpretados como bits de precedência de IP.

Mais recentemente, a utilização do campo de ToS foi ampliada para englobar os seis MSBs, denominados DSCP. O DSCP resulta em 64 valores de prioridade (dois à potência seis), que podem ser atribuídos ao pacote IP.

A família Catalyst 6000 pode manipular o ToS. Isso pode ser alcançado por meio do PFC e do MSFC. Quando um quadro aparece no switch, um valor de DSCP é atribuído a ele. Este valor de DSCP é utilizado internamente no switch para atribuir níveis de serviço (políticas de QoS) definidos pelo administrador. Talvez o DSCP já exista em um quadro ou talvez seja derivado de um CoS existente, da precedência de IP ou do DSCP do quadro (a porta deve ser confiável). Um mapa é utilizado internamente no switch para originar o DSCP. Com oito valores possíveis de precedência de CoS/IP e 64 valores possíveis de DSCP, o mapa padrão irá mapear CoS/IPPrec 0 para DSCP 0, CoS/IPPrec 1 para DSCP 7, CoS/IPPrec 2 para DSCP 15 e assim por diante. Esses mapeamentos padrão podem ser substituídos pelo administrador. Quando o quadro estiver programado para uma porta de saída, o CoS poderá ser reescrito e o valor de DSCP será usado para derivar o novo CoS.

CoS

A CoS se refere aos três bits no cabeçalho ISL ou no cabeçalho 802.1Q, que são utilizados para indicar a prioridade do quadro de Ethernet, à medida que esta passa por uma rede comutada. Para os objetivos deste documento, exibiremos somente a utilização do cabeçalho 802.1Q. Os bits CoS do cabeçalho 802.1Q são comumente chamados de bits do 802.1p. Há três bits de CoS, que correspondem ao número de bits utilizados para a precedência de IP. Em muitas redes, a fim de manter a QoS de uma extremidade à outra, um pacote poderá atravessar os domínios de Camada 2 e Camada 3. Para manter a QoS, o ToS pode ser mapeado para CoS e vice-versa.

O diagrama abaixo é um quadro de Ethernet rotulado com um campo 802.1Q, que consiste em um Ethertype de dois bytes e em uma tag de dois bytes. Na tag de dois bytes, encontram-se os bits de prioridade do usuário (conhecidos como 802.1p).

Fluxo de QoS na família Catalyst 6000

QoS na família Catalyst 6000 é a implementação mais abrangente de QoS em todos os switches Cisco Catalyst atuais. As seções a seguir descrevem o modo como os diversos processos de QoS são atribuídos a um quadro à medida que atravessa o switch.

Observou-se anteriormente neste documento que há vários elementos de QOS a serem oferecidos por switches de Camada 2 e Camada 3. Esses elementos são: classificação, programação da fila de entrada, vigilância, reescrita e programação da fila de saída. A diferença em relação à família Catalyst 6000 é que esses elementos de QoS são aplicados por um engine da Camada 2 (L2), que tem um insight para os detalhes da Camada 3 (L3) e Camada 4 (L4) e também para as informações de cabeçalho da L2. O diagrama a seguir resume como a família Catalyst 6000 implementa estes elementos.

Um quadro é inserido no switch e é processado, inicialmente, pelo ASIC da porta que recebeu esse quadro. O ASIC posicionará o quadro em uma fila Rx. Dependendo da placa de linha da família Catalyst 6000, haverá uma ou duas filas Rx.

O ASIC da porta utilizará os bits CoS como indicador da fila que deverá receber o quadro (se existirem várias filas de entrada). Se a porta for classificada como não-confiável, o ASIC poderá substituir os bits CoS existentes, com base em um valor predefinido.

O quadro é então passado ao engine de encaminhamento de L2/L3 (PFC), que o classificará e, opcionalmente, o vigiará (limite de taxa). A classificação é o processo de atribuição de um valor de DSCP ao quadro. Esse valor é usado internamente pelo switch para o processamento do quadro. O DSCP será originado de um dos itens a seguir:

    1. Um valor DSCP existente, definido antes da inserção do quadro no switch.

    2. Bits de precedência do IP, já definidos no cabeçalho IPV4. Já que há 64 valores de DSCP e apenas oito valores de precedência de IP, o administrador irá configurar um mapeamento, utilizado pelo switch para originar o DSCP. Os mapeamentos padrão estarão disponíveis, caso o administrador não configure os mapas.

    3. Bits de CoS recebidos, já configurados anteriormente à inserção do quadro no switch. Assim como ocorre com a precedência IP, existe um máximo de oito valores CoS, sendo que cada um deve ser mapeado para um dos 64 valores de DSCP. Este mapa pode ser configurado ou o switch pode utilizar o mapa padrão.

    4. Defina o quadro utilizando um valor padrão de DSCP, normalmente atribuído por uma entrada de Access Control List (ACL).

Depois da atribuição de um valor de DSCP ao quadro, a vigilância (limite de taxa) é aplicada, caso haja uma configuração de vigilância. A vigilância limitará o fluxo de dados através do PFC, descartando ou diminuindo o tráfego que estiver fora de perfil. O termo “fora de perfil” é utilizado para indicar que o tráfego excedeu o limite de bits por segundo enviado pelo PFC, definido pelo administrador. O tráfego fora de perfil pode ser descartado ou o valor de CoS pode ser reduzido. No momento, PFC1 e PFC2 oferecem apenas o suporte à vigilância de entrada (limite de taxa). O suporte para a vigilância de entrada e de saída estará disponível com o lançamento de um novo PFC.

Posteriormente, o PFC passará o quadro à porta de saída para processamento. Neste ponto, o processo de reescrita será empregado para modificar os valores de CoS no quadro e o valor de ToS no cabeçalho IPV4. Este será derivado do DSCP interno. O quadro será colocado em uma fila de transmissão com base no valor de CoS, pronto para a transmissão. Enquanto o quadro estiver na fila, o ASIC da porta monitorará os buffers e implementará o WRED para evitar o excesso de buffers. O algoritmo de programação WRR será utilizado posteriormente para agendar e transmitir quadros da porta de saída.

As seções a seguir explorarão esse fluxo com mais detalhes, fornecendo exemplos de configuração para cada passo descrito acima.

Filas, Buffers, Limiares e Mapeamentos

Antes da configuração de QoS ser descrita com detalhes, determinados termos devem ser explanados para garantir o entendimento completo dos recursos dessa configuração no switch.

Filas

Cada porta do switch possui uma série de filas de entrada e saída, utilizadas como áreas de armazenamento de dados temporárias. As placas de linha da família Catalyst 6000 implementam números diferentes de filas para cada porta. Geralmente, as filas são implementadas nos ASICs do hardware para cada porta. Nas placas de linha de primeira geração da família Catalyst 6000, a configuração típica era uma fila de entrada e duas filas de saída. Nas placas de linha mais recentes (10/100 e GE), o ASIC implementa um conjunto extra de duas filas (uma de entrada e a outra de saída), resultando em duas filas de entrada e três de saída. Essas duas filas extras são filas SP especiais utilizadas para o tráfego sensível à latência, como VoIP. Estas são atendidas no modo SP. Ou seja, se um quadro chegar à fila SP, a programação de quadros nas filas mais baixas será interrompida para processar o quadro na fila SP. A programação dos pacotes da fila(s) inferior(es) será reiniciada somente quando a fila SP estiver vazia.

Quando um quadro chegar a uma porta (para entrada ou saída) em horários de congestionamento, ele será colocada em uma fila. A decisão sobre qual fila receberá o quadro geralmente se dá com base no valor de CoS no cabeçalho de Ethernet do quadro recebido.

Na saída, um algoritmo de programação será empregado para esvaziar a fila de TX (saída). WRR é a técnica utilizada para se alcançar isso. Para cada fila, é utilizada uma ponderação para determinar a quantidade de dados a ser esvaziada da desta, antes do deslocamento para a próxima fila. A ponderação atribuída pelo administrador corresponde a um número de 1 a 255 e este é atribuído a cada fila TX.

Buffers

Cada fila é atribuída a um determinado montante de espaço de buffer para armazenar os dados de trânsito. A memória é residente no ASIC de porta e é dividida e alocada por porta. Para cada porta GE, o ASIC GE fornece 512 K de espaço de buffer. Para as portas 10/100, o ASIC da porta reserva 64K ou 128K (dependendo da placa de linha) de colocação em buffer por porta. Esse espaço de buffer é então dividido entre a fila Rx (de entrada) e as filas TX (de saída).

Limiares

Um aspecto da transmissão de dados normal é que, se um pacote for descartado, ele acabará sendo retransmitido (fluxos de TCP). Em ocasiões de congestionamentos, isto poderá somar-se à carga na rede e causar uma sobrecarga maior dos buffers. Os switches da família Catalyst 6000 empregam diversas técnicas para evitar esse problema, garantindo assim que os buffers não sofram esse excesso.

Os limiares são níveis imaginários atribuídos pelo switch (ou pelo administrador), que definem pontos de utilização, que servem de referência para que o algoritmo de gerenciamento de congestionamentos comece a descartar dados da fila. Nas portas da família Catalyst 6000, há normalmente quatro limiares associados às filas de entrada. Normalmente, há dois limiares associados às filas de saída.

Esses limiares também são distribuídos, no contexto de QoS, como um meio de atribuir a quadros diferentes prioridades para tais limiares. À medida que o buffer começa a ser preenchido e os limiares são rompidos, o administrador pode mapear prioridades diferentes para limiares diferentes, indicando para o switch os quadro a serem descartados quando um limiar for excedido.

Mapeamentos

Nas seções de filas e limiares acima, foi mencionado que o valor de CoS no quadro de Ethernet é utilizado para determinar qual fila receberá o quadro, como também o ponto de preenchimento do buffer, a partir do qual o quadro deverá ser descartado. Essa é a finalidade dos mapeamentos.

Quando a QoS está configurada na família Catalyst 6000, são habilitados mapeamentos padrão que definem o seguinte:

  • em quais limiares os quadros com valores de CoS específicos são elegíveis para serem descartadas;

  • em que fila o quadro deverá ser posicionado (com base em seu valor de CoS).

Enquanto os mapeamentos padrão existirem, eles poderão ser substituídos pelo administrador. Os mapeamentos existem para os propósitos a seguir:

  • Valores de CoS em um quadro recebido para um valor de DSCP

  • Valores de precedência de IP em um quadro recebido para um valor de DSCP

  • Valores de DSCP para um valor de CoS em um quadro enviado

  • Valores de CoS para descartar limiares nas filas de recepção

  • Valores de CoS para descartar limiares nas filas de transmissão

  • Valores de redução de DSCP para os quadros que excedam as instruções de vigilância

  • Valores de CoS para um quadro com um endereço MAC de um destino específico

WRED e WRR

WRED e WRR são dois algoritmos extremamente potentes que fazem parte da família Catalyst 6000. Tanto o WRED como o WRR utilizam a tag de prioridade (CoS) em um quadro de Ethernet para fornecer um gerenciamento de buffer aprimorado e a programação de saída. B

WRED

O WRED é um algoritmo de gerenciamento de buffer empregado pela família Catalyst 6000 para minimizar o impacto do descarte do tráfego de prioridade alta nos momentos de congestionamento. O WRED é baseado no algoritmo de RED.

Para entender RED e WRED, consulte o conceito de gerenciamento do fluxo de TCP. O gerenciamento de fluxo garante que o remetente de TCP não sobrecarregue a rede. O algoritmo de inicio lento de TCP é parte da solução para lidar com isso. Ele determina que no início do fluxo, um único pacote seja enviado antes de aguardar o reconhecimento. Dois pacotes são enviados antes de um ACK ser recebido, aumentando gradualmente o número de pacotes enviados antes do ACK (reconhecimento) ser recebido. Isto prosseguirá até que o fluxo alcance um nível de transmissão (ou seja, que envie um número x de pacotes) que a rede possa processar, sem que a carga acarrete um congestionamento. Se ocorrer um congestionamento, o algoritmo de início lento irá reduzir o tamanho da janela (isto é, o número de pacotes enviados antes do reconhecimento), reduzindo assim o desempenho geral dessa sessão (fluxo) de TCP.

O RED monitorará uma fila assim que ela começar a ser preenchida. Quando um determinado limiar é excedido, os pacotes começam a ser descartados aleatoriamente. Nenhuma referência será feita a pacotes específicos, os pacotes serão descartados aleatoriamente. Esses pacotes podem ser de fluxos de prioridade alta ou baixa. Os pacotes descartados podem fazer parte de um fluxo único ou de vários fluxos de TCP. Se diversos fluxos sofrerem impacto, conforme a descrição acima, isso poderá ter uma influência considerável no tamanho da janela de cada fluxo.

Diferentemente do RED, o WRED não é aleatório ao descartar quadros. O WRED leva em consideração a prioridade dos quadros (no caso da família Catalyst 6000, ele utiliza o valor de CoS). Com o WRED, o administrador atribui quadros com certos valores de CoS a limiares específicos. Quando esses limiares forem excedidos, os quadros com valores de CoS que estiverem mapeados para esses limiares estarão elegíveis para serem descartados. Outros quadros com valores de CoS atribuídos aos limiares mais altos são mantidos na fila. Esse processo permite que fluxos com prioridade mais alta permaneçam intactos, juntamente com suas janelas maiores, minimizando assim a latência envolvida na obtenção de pacotes do remetente para o receptor.

Como saber se a placa de linha suporta o WRED? Execute o comando a seguir. Na saída, verifique a seção que indica o suporte para WRED nesta porta.


Console> show qos info config 2/1 

Configuração de QoS em NVRAM: 

A QoS está habilitada. 

A porta 2/1 possui duas filas de transmissão com dois limiares de descarte (2q2t). 

A porta 2/1 possui uma fila de recepção com quatro limiares de descarte (1q4t). 

Tipo de interface: baseada em vlan 

ACL anexada: 

O tipo de QoS de confiança é definido como não-confiável. 

O CoS padrão = 0 

Mapeamento de Fila e de Limiar: 

CoS de Limiar de Fila 

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

1     1         0 1 

1     2         2 3 

2     1         4 5 

2     2         6 7 

Limiares de descarte de Rx: 

Os limiares de descarte de Rx foram desabilitados para as portas não confiáveis. 

Fila # Limiares – porcentagem (valores abs) 

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

1        50% 60% 80% 100% 

Limiares de descarte de Tx: 

Fila # Limiares – porcentagem (valores abs) 

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

1        40% 100% 

2        40% 100% 

Limiares de descarte de WRED TX: 

O recurso WRED não é suportado para este tipo de_porta.

!Buscar os seguintes itens.

Tamanhos de fila: 

Fila # Tamanhos – porcentagem (valores abs) 

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

1        80% 

2        20% 

Configuração WRR de portas com a velocidade 1000MBPS: 

Fila # Proporções (valores abs) 

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

1        100 

2        255 

Console> (habilitar)

Se o WRED não estiver disponível em uma porta, esta utilizará um método de descarte traseiro do gerenciamento de buffer. O descarte traseiro, como o nome indica, simplesmente descarta os quadros recebidos quando os buffers são completamente utilizados.

WRR

O WRR é utilizado para agendar o tráfego de saída das filas TX. O algoritmo round-robin alternará entre as filas TX enviando o mesmo número de pacotes de cada fila, antes de passar à próxima fila. O aspecto ponderado do WRR permite que o algoritmo de programação inspecione um peso que foi atribuído à fila. Isso permite o acesso a filas definidas para uma fração maior de largura de banda. O algoritmo de programação WRR eliminará uma quantidade maior de dados das filas identificadas do que de outras filas, garantindo assim um bias para as filas designadas.

A configuração de WRR e outros aspectos descritos acima serão explanados nas seções a seguir.

Configurando o ASIC de Porta com Base em QoS na Família Catalyst 6000.

A configuração de QoS instrui o ASIC da porta ou o PFC para executar uma ação de QoS. As seções a seguir examinarão a configuração de QoS para estes dois processos. No ASIC da porta, a configuração QoS afeta os fluxos de tráfego de entrada e saída.

No diagrama acima, pode-se observar que os processos de configuração de QoS a seguir se aplicam a:

    1. estados confiáveis de portas

    2. aplicação de CoS baseado em porta

    3. atribuição de limiar para descarte de RX

    4. CoS para mapas de limiares de descarte de Rx

Quando um quadro é processado por MSFC ou PFC, é passado para o ASIC da porta de saída para processamento posterior. Os quadros processados pelo MSFC terão seus valores de CoS redefinidos como zero. Isso deve ser levado em consideração para o processamento de QoS nas portas externas.

O diagrama acima exibe o processamento de QoS, executado pelo ASIC da porta, para o tráfego de saída. Alguns dos processos acionados no processamento de saída QoS incluem o seguinte:

    1. Atribuições de descarte traseiro de TX e limiar de WRED

    2. CoS para descarte traseiro de TX e mapas de WRED

Além disso, embora não exibido no diagrama acima, há o processo de reatribuição de CoS ao quadro de saída, utilizando um DSCP para o mapa de CoS.

As seções a seguir abordam as capacidades da configuração de QoS do ASIC baseado em porta, com mais detalhes.

Observação: Um ponto importante a considerar é que quando os comandos de QoS são empregados com a utilização de CatOS, eles se aplicam a todas as portas com o tipo de fila especificado. Por exemplo, se um limiar de descarte WRED for atribuído a portas com o tipo de fila 1p2q2t, este limiar será também atribuído a todas as portas nas placas de linha com suporte a este tipo de fila. Com o Cat IOS, os comandos do QoS são geralmente aplicados no nível da interface.

Habilitando QoS

Antes que a configuração de QOS seja efetuada na família Catalyst 6000, ela deve estar habilitada no switch. Para fazer isso, entre o seguinte comando:

CatOS


Console> (enable) set qos enable

!-- A QoS está habilitada.

Console> (habilitar)

Cisco IOS integrado (Modo Nativo)


Cat6500(config)# mls qos

Quando a QoS estiver habilitada na família Catalyst 6000, o switch definirá uma série de padrões de QoS. Esses padrões incluem as configurações a seguir:

Portas confiáveis e não confiáveis

Qualquer porta na família Catalyst 6000 pode ser configurada como confiável ou não-confiável. O estado de confiança da porta determina o modo como ela marca, classifica e agenda o quadro, à medida que ele transita pelo switch. Por padrão, todas as portas estarão no estado não-confiável.

Portas Não-Confiáveis (Configuração Padrão de Portas)

Caso a porta seja configurada como não confiável, um quadro, depois de entrar inicialmente na porta, terá seus valores CoS e ToS zerados pelo ASIC da porta. Isso significa que o quadro receberá o serviço de menor prioridade no caminho pelo switch.

Alternativamente, o administrador poderá redefinir o valor de CoS de um quadro de Ethernet inserido em uma porta não-confiável como um valor predefinido. Essa configuração será discutida em uma seção posterior.

Definir a porta como não-confiável instruirá o switch a não realizar nenhuma fuga de congestionamento. A fuga de congestionamento é o método utilizado para descartar quadros, com base nos seus valores de CoS, quando estes excedem os limiares definidos para essa fila. Todos os quadros inseridos na porta estarão qualificados a serem descartadas quando os buffers atingirem o limiar de 100%.

Em CatOS, uma porta 10/100 ou GE pode ser configurada como não-confiável, entrando o seguinte comando:

CatOS


Console> (enable) set port qos 3/16 trust untrusted

!-- Porta 3/16 qos definida como não-confiável. 

Console> (habilitar)

Esse comando configura a porta 16 do módulo 3 como não confiável.

Observação: Para o Cisco IOS Integrado (Modo Nativo), atualmente, o software dá suporte apenas à configuração confiável de portas GE.

Cisco IOS integrado (Modo Nativo)


Cat6500(config)# interface gigabitethernet 1/1 

Cat6500(config-if)# no mls qos trust

No exemplo acima, entramos na configuração da interface e aplicamos forma no do comando para definir a porta como não-confiável, já que se trata do IOS.

Portas Confiáveis

Às vezes, os quadros de Ethernet inseridos no switch apresentam uma configuração de CoS ou ToS que o administrador deseja manter à medida que o quadro passa pelo switch. Neste caso, o administrador pode definir o estado de confiança de uma porta em que o tráfego entra no switch como confiável.

Conforme mencionado anteriormente, o switch utiliza um valor de DSCP interno para atribuir um nível de serviço predeterminado ao quadro. Quando o quadro é inserido na porta confiável, o administrador pode configurar a porta para observar a CoS, a precedência de IP ou o valor de DSCP existentes, a fim de definir o valor de DSCP interno. Alternativamente, o administrador pode configurar um valor de DSCP predefinido para cada pacote que entrar na porta.

A configuração do estado de confiança de uma porta como confiável pode ser alcançada emitindo o seguinte comando:

CatOS


Console> (enable) set port qos 3/16 trust trust-cos

!-- Porta 3/16 qos definida como trust-COs

Console> (habilitar)

Esse comando é aplicável na placa WS-X6548-RJ45 e define o estado de confiança da porta 3/16 como confiável. O switch utilizará o valor CoS definido no quadro recebido para configurar o DSCP interno. O DSCP é derivado de um mapa padrão criado quando a QoS foi habilitada no switch ou, alternativamente, de um mapa definido pelo administrador. Em vez da palavra-chave trust-CoS, o administrador também pode utilizar as palavras-chave trust-dscp ou trust-ipprec.

Em placas de linha 10/100 anteriores (WS-X6348-RJ45 e WS-X6248-RJ45), a confiança de portas precisa ser definida por meio do comando set qos acl. Neste comando, o estado de confiança pode ser atribuído por um sub-parâmetro do comando set qos acl. A configuração de trust CoS não é suportada para portas dessas placas de linha, conforme descrito abaixo.


Console> (enable) set port qos 4/1 trust trust-COs

O tipo de confiança trust-COs não é suportado nesta porta.

!-- Trust-COs não suportado, utilizar acl.

Os limiares de Rx são habilitados na porta 4/1. 

!-- É necessário ativar a programação da fila de entrada.

Porta 4/1 qos definida como não-confiável. 

!-- Trust-COs não suportado, então a porta é configurada para não-confiável.

O comando acima indica que é necessário habilitar a programação da fila de entrada. Portanto, para portas 10/100 em placas de linha WS-X6248-RJ45 e WS-X6348-RJ45, o comando set port qos x/y trust trust-COsdeve estar ainda configurado, apesar de que o ACL deve ser utilizado para configurar estados de confiança.

Com o Cisco IOS Integrado (Modo Nativo), a configuração de confiança pode ser efetuada em uma interface GE e nas portas 10/100 da placa de linha WS-X6548-RJ45.

Cisco IOS integrado (Modo Nativo)


Cat6500(config)# interface gigabitethernet 5/4 

Cat6500(config-if)# mls qos trust ip-precedence 

Cat6500(config-if)#

Este exemplo configura o estado de confiança da porta GE 5/4 como confiável. O valor de precedência de IP do quadro será utilizado para derivar o valor do DSCP.

Classificação de Entrada e Configuração de CoS Baseada em Porta

Na entrada em uma porta do switch, o quadro de Ethernet pode ter sua CoS alterada, se esta atender a um dos critérios a seguir:

    1. a porta está configurada como não confiável, ou

    2. o quadro de Ethernet não tem um valor COS existente já configurado.

Para reconfigurar o valor de CoS de um quadro de entrada de Ethernet, é necessário executar o comando a seguir:

CatOS


Console> (enable) set port qos 3/16 cos 3

!-- Porta 3/16 qos definida como 3. 

Console> (habilitar)

Esse comando configura os COs de quadros Ethernet de entrada na porta 16 do módulo 3 para um valor de 3 quando um quadro não marcado chega ou quando a porta está configurada como não confiável.

Cisco IOS Integrado (Modo Nativo)


Cat6500(config)# interface fastethernet 5/13 

Cat6500(config-if)# mls qos COs 4

Cat6500(config-if)#

Esse comando configura os COs de quadros Ethernet de entrada na porta 13 do módulo 5 para um valor de 4 quando um quadro não marcado chega ou quando a porta está configurada como não confiável.

Configurar Limiares de Descarte de Rx

Ao entrar na porta do switch, o quadro será colocado em uma fila Rx. Para evitar o excesso de buffers, o ASIC da porta implementa quatro limiares em cada fila Rx e usa esses limiares para identificar quadros que podem ser descartados, uma vez que esses limiares são excedidos. O ASIC de porta irá utilizar o valor de COs dos quadros para identificar os que podem ser descartados quando o limiar for excedido. Esse recurso permite que os quadros com prioridade mais elevada permaneçam no buffer por mais tempo quando ocorre congestionamento.

Conforme exibido no diagrama acima, os quadros chegam e são posicionadas na fila. À medida que a fila começa a ser preenchida, os limiares são monitorados pelo ASIC da porta. Quando um limiar é rompido, os quadros com valores de CO identificados pelo administrador são descartados aleatoriamente da fila. Os mapeamentos de limiar padrão para uma fila 1q4t (encontrados nas placas de linha WS-X6248-RJ45 e WS-X6348-RJ45) são os seguintes:

  • o limiar 1 é definido para 50% e os valores de COs 0 e 1 são mapeados para esse limiar.
  • o limiar 2 é definido para 60% e os valores de COs 2 e 3 são mapeados para esse limiar.
  • o limiar 3 é definido para 80% e os valores de COs 4 e 5 são mapeados para esse limiar.
  • o limiar 4 é definido para 100% e os valores de COs 6 e 7 são mapeados para esse limiar.

Os mapeamentos padrão para uma fila 1P1q4t (encontrados nas portas GE) são os seguintes:

  • o limiar 1 é definido para 50% e os valores de COs 0 e 1 são mapeados para esse limiar.
  • o limiar 2 é definido para 60% e os valores de COs 2 e 3 são mapeados para esse limiar.
  • o limiar 3 é definido para 80% e os valores de COs 4 são mapeados para esse limiar.
  • o limiar 4 é definido para 100% e os valores de COs 6 e 7 são mapeados para esse limiar.
  • O valor de CoS 5 é mapeado para a fila de prioridade estrita.

Os mapeamentos padrão para uma fila 1p1q0t (encontrados nas portas 10/100 da placa de linha WS-X6548-RJ45) são os seguintes:

  • Os quadros com valor de COs 5 são direcionados para a fila Rx SP (fila 2), onde o switch descarta os quadros recebidos, apenas quando o buffer da fila de recepção SP está 100% ocupado.
  • Os quadros com valores de COs 0, 1, 2, 3, 4, 6, ou 7 se direcionam para a fila Rx padrão. O switch descarta os quadros recebidos quando o buffer da fila Rx está 100% ocupado.

Esses limiares de descarte podem ser alterados pelo administrador. Além disso, os valores de COs padrão mapeados para cada limiar também podem ser alterados. Placas de linha diferentes executam implementações de filas Rx diferentes. A seguir, será exibido um sumário dos tipos de fila.

CatOS


Console> (enable) set qos drop-threshold 1q4t rx queue 1 20 40 75 100

!-- Limiares de descarte de Rx par a fila 1 definidos como 20%, 40%, 75%, e 100%.

Console> (habilitar)

Esse comando define os limites de descarte de recebimento de todas as portas de entrada com uma fila e quatro limiares (significa 1q4t) para 20%, 40%, 75% e 100%.

O comando executado no Cisco IOS Integrado (Modo Nativo) é mostrado a seguir.

Cisco IOS Integrado (Modo Nativo)


Cat6500(config-if)# wrr-queue threshold 1 40 50 

Cat6500(config-if)# wrr-queue threshold 2 60 100 



!-- Configura os 4 limiares para uma fila Rx 1q4t e



Cat6500(config-if)# rcv-queue threshold 1 60 75 85 100



!-- Configura a fila Rx 1p1q4t, que se aplica a  

!-- nova placa de linha 10/100 WS-X6548-RJ45.

Os limiares de descarte de Rx devem ser habilitados pelo administrador. Atualmente, o comando set port qos x/y trust trust-COs deve ser utilizado para ativar os limiares de descarte de Rx (onde x é o número do módulo e y é a porta neste módulo).

Configuração de limiares de descarte de TX

Em uma porta de saída, essa porta terá dois limites TX usados como parte do mecanismo de evasão de congestionamento, fila 1 e fila 2. A fila 1 é representada como a fila padrão de baixa prioridade e a fila 2 é representada como a fila padrão de alta prioridade. Dependendo das placas de linha utilizadas, elas empregarão um descarte traseiro ou um algoritmo de gerenciamento de limiar de WRED. Os dois algoritmos utilizam limiares para cada fila de TX.

O administrador pode configurar manualmente os limiares da seguinte maneira:

CatOS


Console> (enable) set qos drop-threshold 2q2t TX queue 1 40 100

!-- Limiares de descarte de Tx para a fila 1 definidos como 40% e 100%.

Console> (habilitar)

Esse comando configura os limiares de descarte de Tx para a fila 1 para todas as portas de saída com duas filas e dois limiares (indica 2q2t) para 40% e 100%.


Console> (enable) set qos wred 1p2q2t TX queue 1  60 100

!-- Os limiares de WRED da fila 1 são definidos como 60% e 100% em todas as portas 1p2q2t com o recurso WRED.

Console> (habilitar)

Esse comando configura os limiares de descarte do WRED para fila 1, para todas as portas de saída com uma fila SP, duas filas normais e dois limiares (indica 1p2q2t) para 60% e 100%. A fila 1 é definida como a fila de prioridade normal baixa e apresenta a prioridade mais baixa. A fila 2 é a fila normal de prioridade alta e apresenta uma prioridade mais elevada que a fila 1. A fila 3 é a fila SP, que é utilizada antes de todas as outras filas nesta porta.

O comando equivalente executado no Cisco IOS Integrado (Modo Nativo) é mostrado a seguir.

Cisco IOS Integrado (Modo Nativo)


Cat6500(config-if)# wrr-queue random-detect max-threshold  1 40 100

Cat6500(config-if)#

Isto define os limiares de descarte WRED de uma porta 1p2q2t para a fila 1 em 40% do limiar 1 (TX) e 100% do limiar 2 (TX).

O WRED também poderá ser desabilitado, se necessário, no Cisco IOS Integrado (Modo Nativo). O método utilizado para isso é a entrada da forma n" do comando. Um exemplo de como desabilitar o WRED é exibido a seguir:

Cisco IOS Integrado (Modo Nativo)


Cat6500(config-if)# no wrr-queue random-detect queue_id

Mapeando o endereço MAC para valores de CoS.

Além de configurar o COs com base em uma definição de porta global, o switch permite que o administrador defina valores de COs com base no endereço MAC de destino e na ID da VLAN. Isso permite que os quadros destinados para objetivos específicos sejam rotulados com um valor de COs predeterminado. Esta configuração pode ser feita emitindo o comando a seguir:

CatOS


Console> (enable) set qos Mac-COs 00-00-0c-33-2a-4e 200 5

!-- O COs 5 é atribuído a 00-00-0c-33-2a-4e VLAN 200.

Console> (habilitar)

Este comando configura um COs de 5 para qualquer quadro cujo endereço MAC de destino seja 00-00-0c-33-2a-4e, que tenha vindo da VLAN 200.

Não há um comando equivalente no Cisco IOS Integrado (Modo Nativo). Isso ocorre porque este comando é suportado apenas quando não há uma PFC presente e o Cisco IOS Integrado (Modo Nativo) requer uma PFC para funcionar.

Mapeamento de COs para Limiares

Depois de configurar os limiares, o administrador pode atribuir os valores de COs a esses limiares, de modo que, quando estes forem excedidos, os quadros com valores de COs específicos possam ser descartados. Normalmente, o administrador atribuirá quadros de prioridade inferior aos limiares inferiores, mantendo assim o tráfego de prioridade superior na fila, caso ocorra congestionamento.

A figura acima mostra uma fila de entrada com quatro limiares e a maneira como os valores de COs foram atribuídos a cada limiar.

A seguinte saída apresenta o modo como os valores de COs podem ser mapeados para limiares:

CatOS


Console> (enable) set qos map 2q2t 1 1 COs 0 1 

!-- A fila de prioridade TX de QoS e o limiar foram mapeados para COs com êxito.

Console> (habilitar)

Esse comando atribui os valores 0 e 1 de CoS para a fila 1, com o limiar 1. O comando equivalente no Cisco IOS Integrado (Modo Nativo) será exibido a seguir.

Cisco IOS Integrado (Modo Nativo)


Cat6500(config-if)# wrr-queue COs-map  1  1  0  1 

Cat6500(config-if)#

Configuração da largura de banda em filas TX

Se um quadro for colocado em uma fila de saída, ele será transmitido com o uso de um algoritmo de programação de emissor. O processo do programador de saída utiliza o WRR para transmitir quadros a partir das filas de saída. Dependendo do hardware da placa de linha utilizada, pode haver duas, três ou quatro filas de transmissão por porta.

Nas placas de linha WS-X6248 e WS-X6348 (com estruturas de fila 2q2t), duas filas TX são usadas pelo mecanismo WRR para programação. Nas placas de entrada WS-X6548 (com estrutura de fila 1p3q1t), há quatro filas TX. Dessas quatro filas, três filas TX são utilizadas pelo algoritmo WRR (a última fila TX é uma fila SP). Nas placas de linha GE, há três filas TX (com a estrutura de fila 1p2q2t), sendo que uma dessas é a fila SP; portanto, o algoritmo WRR utiliza somente duas filas TX.

Normalmente, o administrador atribuirá uma ponderação à fila TX. O WRR funciona verificando a ponderação atribuída à fila de portas, que é usada internamente pelo switch para determinar a quantidade de tráfego a ser transmitida, antes de passar para a próxima fila. Pode-se atribuir um valor de ponderação de 1 a 255 para cada fila de porta.

CatOS


Console> (enable) set qos wrr 2q2t 40 80 

!-- Proporção WRR de QoS configurada com êxito.

Console> (habilitar)

Esse comando atribui uma ponderação de 40 para a fila 1 e 80 para a fila 2. Isso significa uma proporção de dois para um (80 para 40 = 2 para 1) de largura de banda atribuída entre as duas filas. Este comando tem efeito em todas as portas com duas filas e dois limiares.

O comando equivalente executado no Cisco IOS Integrado (Modo Nativo) é mostrado a seguir.

Cisco IOS Integrado (Modo Nativo)


Cat6500(config-if)# wrr-queue bandwidth 1 3

Cat6500(config-if)#

Os dados acima representam uma proporção de três para um entre as duas filas. É possível observar que a versão Cat IOS desse comando se aplica apenas a uma determinada interface.

Mapeamento de DSCP para COs

Depois de posicionar o quadro na porta de saída, o ASIC da porta usará os COs atribuídos para executar fuga de congestionamento (ou seja, WRED) e também utilizará os COs para determinar a programação do quadro (ou seja, sua transmissão). Nesse ponto, o switch utilizará o mapa padrão para resgatar o DSCP atribuído e mapeá-lo de volta para um valor de COs. Esse mapa padrão é exibido nesta tabela.

Alternativamente, o administrador pode criar um mapa para ser utilizado pelo switch para resgatar o valor interno de DSCP atribuído e também criar um valor de COs novo para o quadro. A seguir, é possível observar exemplos de utilização de CatOS e Cisco IOS Integrado (Modo Nativo) para tal.

CatOS


Console> (enable) set qos dscp-cos--map 20-30:5 10-15:3 45-52:7 

!-- Mapa dscp-cos de QoS configurado com êxito.

Console> (habilitar)

O comando acima mapeia os valores de DSCP de 20 a 30 para um valor de COs igual a 5, valores de DSCP de 10 a 15 para um valor de COs igual a 3 e valores de DSCP de 45a 52 para um valor de COs igual a 7. Todos os outros valores de DSCP utilizam o mapa padrão, criado quando a QoS é habilitada no switch.

O comando equivalente executado no Cisco IOS Integrado (Modo Nativo) é mostrado a seguir.

Cisco IOS Integrado (Modo Nativo)


Cat6500(config)# mls qos map dscp-cos 20 30 40 50 52 10 1 to 3

Cat6500(config)#

Configura os valores DSCP de 20, 30, 40, 50, 52, 10 e 1 para um valor de 3 de COs.

Classificação e Vigilância com o PFC

O PFC dá suporte à classificação e à vigilância de quadros. A classificação pode utilizar uma ACL para atribuir (marcar) um quadro recebido com uma prioridade (DSCP). A vigilância permite que um fluxo de tráfego seja limitado a uma determinada largura de banda.

As seções a seguir descreverão esses recursos no PFC, do ponto de vista das plataformas OS de CatOS e do Cisco IOS Integrado (Modo Nativo). Os processos atribuídos pelo PFC são exibidos no diagrama seguir:

Configurar a Vigilância na Família Catalyst 6000 com CatOS.

A função de vigilância é dividida em duas seções, uma para CatOS e uma para o Cisco IOS Integrado (Modo Nativo). As duas obtêm resultados finais iguais, embora sejam configuradas e implementadas de forma diferente.

Vigilância

O PFC suporta a capacidade de estabelecer um limite de taxa (ou vigilância) do tráfego recebido no switch e reduzir o fluxo desse tráfego para um limite predefinido. O tráfego excedente a esse limite pode ser descartado ou ter o valor DSCP diminuído no quadro.

A limitação da taxa de saída não é suportada atualmente no PFC1e nem no PFC2. Esta será acrescentada em uma nova revisão programada do PFC, que suportará a vigilância de saída.

A vigilância é suportada em CatOS e no novo Cisco IOS Integrado (Modo Nativo), embora a configuração desses recursos seja bastante diferente. As seguintes seções descreverão a configuração de vigilância nas duas plataformas de OS.

Agregados e Microfluxos (CatOS)

Os termos Agregados e Microfluxos são utilizados para definir o âmbito da vigilância executada pelo PFC.

Microfluxo se refere à vigilância de um único fluxo. Um fluxo é definido por uma sessão com um endereço SA/DA MAC único, endereço IP SA/DA e números de porta TCP/UDP. Para cada fluxo novo iniciado por meio de uma porta de VLAN, o microfluxo pode ser utilizado para limitar a quantidade de dados recebidos nesse fluxo pelo switch. Na definição de microfluxo, os pacotes que excedem o limite de taxa prescrito podem ser descartados ou ter seus valores de DSCP reduzidos.

De maneira similar ao microfluxo, um agregado pode ser usado para limitar a taxa de tráfego. Contudo, a taxa agregada se aplica a todo o tráfego de entrada em uma porta ou VLAN, que corresponda a uma ACL de QoS especificada. É possível exibir o agregado como a vigilância de tráfego cumulativo que corresponde ao perfil da Entrada de Controle de Acesso (ACE).

Tanto o agregado quanto o microfluxo definem a quantidade de tráfego aceito no switch. Tanto o agregado quanto o microfluxo podem ser atribuídos ao mesmo tempo para uma porta ou VLAN.

Pode-se definir uma quantidade de até 63 microfluxos e de até 1023 agregados.

Entradas de Controle de Acesso e ACLs de QoS (CatOS)

Uma ACL de QoS consiste em uma lista de ACEs que definem um conjunto de regras de QoS utilizadas pelo PFC para processar os quadros recebidos. As ACEs se assemelham à Lista de Controle de Acesso do Roteador (RACL). A ACE define critérios de classificação, marcação e vigilância para um quadro recebido. Se um quadro recebido corresponder aos critérios definidos na ACE, o engine de QoS processará o quadro (indicado pela ACE).

Todo o processamento de QoS é realizado no hardware, permitindo que a política de QoS não cause impacto no desempenho do switch.

O PFC2 atualmente suporta até 500 ACLs, que podem consistir em até 32.000 ACEs (no total). Os números reais de ACE dependerão de outros serviços definidos e da memória disponível no PFC.

Existem três tipos de ACEs que podem ser definidas. São elas: IP, IPX e MAC. As ACEs IP e IPX inspecionam as informações de cabeçalho da Camada 3, já as ACEs baseadas em MAC inspecionam apenas as de Camada 2. Deve-se observar também que as ACEs MAC só podem ser aplicadas aos tráfegos não-IP e não-IPX.

Criando Regras de Vigilância

O processo de criação de regras de vigilância envolve a criação de um agregado (ou microfluxo) e, posteriormente, o mapeamento deste para uma ACE.

Se, por exemplo, o requisito for a limitação de todo o tráfego IP recebido na porta 5/3 para um valor máximo de 20 MB, os dois passos mencionados acima devem ser configurados.

Primeiro, o exemplo solicita que todo o tráfego IP recebido seja limitado. Isso implica que um vigilante agregado deve ser definido. Observar um exemplo disso a seguir:


Console> (enable) set qos policer aggregate test-flow rate 20000 burst 13 policed-dscp  

!-- Programação do hardware em processamento...

!-- Vigilante de QoS para o fluxo de teste agregado criado com êxito.

Console> (habilitar)

Criamos um agregado chamado de fluxo de teste. Ele define uma taxa de 20.000 KBPS (20MBPS) e uma intermitência de 13. A palavra-chave policed-dscp indica que os dados que excederem essa política terão seu valor de DSCP diminuído, conforme especificado no mapa de redução de DSCP (pode ser o mapa padrão ou um modificado pelo administrador). Uma alternativa para a utilização dessa palavra-chave é a palavra-chave drop. A palavra-chave drop simplesmente descartará todo o tráfego fora de perfil (tráfego que fica fora do valor de intermitência distribuído).

A facilidade de vigilância funciona em um esquema de vazamento de token bucket, no sentido de que você define uma intermitência (quantidade de dados em bits por segundo que você aceitará em um dado intervalo (fixo) de tempo) e, depois, a taxa (definida como a quantidade de dados que você retirará do bucket em um único segundo). Os dados que ultrapassarem esse bucket serão descartados ou terão seus valores de DSCP diminuídos. O período de tempo (ou intervalo) especificado, mencionado acima, é de 0,00025 segundos (ou 1/4000 segundo) e é fixo (isto é, não é possível utilizar nenhum comando de configuração para alterar esse número).

O número 13 no exemplo acima representa um bucket que aceitará até 13.000 bits de dados a cada 1/4000 segundo. Isso se refere a 52 MB por segundo (13K * (1 / 0,00025) ou 13K * 4000). Deve-se verificar sempre se a intermitência está configurada para ser igual ou superior à taxa na qual se deseja enviar dados. Em outras palavras, a intermitência deve ser maior que ou igual ao montante mínimo de dados, a serem transmitidos por um determinado período. Se a intermitência resultar em um número menor do que o especificado como taxa, o limite da taxa será igualado à intermitência. Ou seja, se a taxa de 20 MBPS for definida e a intermitência for calculada em 15MBPS, a taxa também só chegará a 15MBPS. A próxima pergunta poderá ser por que 13? É necessário lembrar que a intermitência define a profundidade do token bucket, ou, em outras palavras, a profundidade do bucket utilizado para receber os dados que chegam a cada 1/4000 de segundo. Assim, a intermitência pode ser um número qualquer suportado quando a taxa de dados na chegada for maior que ou igual a 20 MB por segundo. A intermitência mínima que poderia ser usada para um limite de taxa de 20 MB é 20.000/4.000 = 5.

Durante o processamento do vigilante, o algoritmo de vigilância começa preenchendo o token bucket com um complemento completo de tokens. O número de tokens é igual ao valor da intermitência. Portanto, se o valor da intermitência for 13, o número de tokens no bucket será igual a 13.000. Para cada 1/4.000 de segundo, o algoritmo de vigilância enviará um montante de dados igual à taxa definida, dividida por 4000. Para cada bit (dígito binário) de dados enviados, ele consome um token do bucket. Ao final do intervalo, o bucket será preenchido com um novo conjunto de tokens. O número de tokens substituído será definido pela taxa / 4.000. Observar o exemplo acima para entender esse procedimento:

Console> (enable) set qos policer aggregate test-flow rate 20000 burst 13

Suponha que essa porta seja de 100 MBPS e que haja um fluxo constante de 100 MBPS para essa porta. Sabe-se que isso equacionará uma taxa de entrada de 100.000.000 de bits por segundo. Os parâmetros são uma taxa de 20.000 e uma intermitência de 13. No intervalo t0, há um complemento integral de tokens no bucket (que corresponde a 13.000). No intervalo t0, o primeiro conjunto de dados chegará à porta. Para esse intervalo de tempo, a taxa de chegada será de 100.000.000 / 4.000 = 25.000 bits por segundo. Como nosso token bucket apresenta apenas uma profundidade de 13.000 tokens, somente 13.000 bits dos 25.000 bits que chegam à porta podem ser enviados e 12.000 serão descartados.

A taxa especificada define uma taxa de encaminhamento de 20.000.000 de bits por segundo, o que equivale a 5.000 bits enviados no intervalo de 1/4.000 de segundo. A cada 5.000 bits enviados, há um consumo de 5.000 tokens. No intervalo T1, chegam mais 25.000 bits de dados, mas o bucket descarta 12.000 bits. O bucket é preenchido de novo com tokens definidos como a taxa / 4.000 (que equivale a 5.000 novos tokens). O algoritmo emite, em seguida, o próximo complemento de dados, que se iguala a outros 5.000 bits de dados (isso consome outros 5.000 tokens), e assim por diante, em cada intervalo.

Resumindo, os dados excedentes da profundidade do bucket (intermitência definida) são descartados. Os dados remanescentes do envio (correspondentes à taxa determinada) também são descartados, liberando espaço para a chegada do próximo conjunto de dados. Um pacote incompleto é aquele que não foi recebido totalmente no intervalo de tempo e não é descartado, e sim mantido até ser completamente recebido na porta.

Esse número de intermitências supõe um fluxo constante de tráfego. Todavia, nas redes reais, os dados não são constantes e seu fluxo é determinado pelo tamanho das janelas TCP, que incorporam os reconhecimentos TCP na seqüência de transmissão. Para levar em consideração os problemas de tamanhos de janela de TCP, é recomendável dobrar o valor de intermitência. No exemplo acima, o valor sugerido de 13 seria configurado, na realidade, como 26.

Outro aspecto importante é que no intervalo de tempo 0, ou seja, no início do ciclo de vigilância, o token bucket estará repleto de tokens.

Essa política de agregação agora deve ser incorporada a uma ACE de QoS. A ACE é o local de especificação de critérios a serem obedecidos para um quadro recebido. Considere o seguinte exemplo. É necessário aplicar o agregado definido acima para todo o tráfego IP, mas, especificamente para o tráfego com origem da sub-rede 10.5.x.x e com destino para a sub-rede 203.100.45.x. A ACE teria a aparência a seguir:


Console> (enable) set qos acl ip test-acl trust-dscp aggregate test-flow tcp 10.5.0.0 203.100.45.0  

!-- Editbuffer test-acl modificado. Execute o comando commit para aplicar as alterações.

Console> (habilitar)

O comando acima criou uma ACE IP (pelo uso do comando set qos acl ip), que agora está associada a uma ACL de QoS chamada test-acl. ACEs subseqüentes criadas e associadas à ACL test-acl são incluídas ao final da lista ACE. A entrada ACE tem o fluxo de teste agregado associado. Os fluxos TCP com a sub-rede de origem 10.5.0.0 e a de destino 203.100.45.0 serão atribuídos a essa política.

As ACLs (e ACEs associadas) fornecem um nível de flexibilidade de configuração bastante granular, que pode ser utilizado pelos administradores. Uma ACL pode consistir em uma ou várias Aces e os endereços de origem ou destino podem ser usados, como também os valores de porta da Camada 4 para identificar determinados fluxos que devam ser vigiados.

Todavia, antes de a vigilância ocorrer efetivamente, a ACL deve ser mapeada para uma porta física ou uma VLAN.

Decisões de Vigilância de PFC2

Para o PFC2, foi realizada uma modificação no CatOS 7.1 e CatOS 7.2, que introduziu um algoritmo de vazamento de bucket dual para vigilância. Com esse novo algoritmo, os dois níveis a seguir são adicionados:

    1. Nível de Vigilância Normal: é igual ao primeiro bucket e define os parâmetros, especificando a profundidade deste (intermitência) e a taxa com a qual os dados devem ser enviados do bucket (taxa).
    2. Nível de Vigilância em Excesso: é igual ao segundo bucket e define os parâmetros, especificando a profundidade deste (eburst) e a taxa com a qual os dados devem ser enviados do bucket (erate).

A forma como esse processo funciona é com os dados começando a preencher o primeiro bucket. O PFC2 aceita um fluxo de entrada de dados menor que ou igual à profundidade (valor de intermitência) do primeiro bucket. Os dados que excederem o primeiro bucket podem ser reduzidos e passados ao segundo bucket. O segundo bucket pode aceitar uma taxa de entrada de dados vindos do primeiro em um valor menor ou igual ao valor eburst. Os dados do segundo bucket são enviados com uma taxa definida pelo parâmetro erate, subtraído do parâmetro de taxa. Os dados que excederem o segundo bucket também podem ser diminuídos ou descartados.

Este é um exemplo de vigilante de vazamento de bucket dual:

Console> (enable) set qos policer aggregate AGG1 rate 10000 policed-dscp erate 12000 drop burst 13 eburst 13

Esse exemplo posiciona um agregado chamado AGG1 com uma taxa de excesso de tráfego de 10 MPBS e será marcado com um valor inferior, de acordo com o mapa de vigilância de DSCP. O tráfego em excesso do erate (definido em 12 MBPS) será descartado de acordo com a palavra-chave drop.

Aplicando Vigilantes Agregados aos Módulos Habilitados por DFC

Deve-se observar que a aplicação de vigilantes agregados a placas de linha não-DFC pode ser realizada devido ao modo como o Catalyst 6000 utiliza um engine de encaminhamento centralizado (PFC) para encaminhar o tráfego. A implementação de um engine de encaminhamento central permite rastrear as estatísticas de tráfego para uma determinada VLAN. Esse processo pode ser utilizado para atribuir um vigilante agregado a uma VLAN.

Em uma placa de linha habilitada por DFC, contudo, as decisões de encaminhamento são distribuídas para a placa. O DFC só toma ciência das portas na placa de linha imediata e desconhece o movimento de tráfego nas outras placas de linha. Por esse motivo, se um vigilante agregado for atribuído a uma VLAN com portas-membro em diversos módulos DFC, o vigilante pode produzir resultados inconsistentes. Isso ocorre porque o DFC só pode rastrear estatísticas de porta locais e não considera as estatísticas de porta de outras placas de linha. Assim, um vigilante agregado atribuído a uma VLAN com portas-membro em uma placa de linha habilitada por DFC fará com que o DFC efetue a vigilância do tráfego com o limite de taxa para as portas da VLAN residentes apenas na placa de linha de DFC.

Mapas de Redução de DSCP (CatOS)

Esses mapas são utilizados quando se define o vigilante para reduzir o tráfego fora de perfil, em vez de descartá-lo. O tráfego fora de perfil é definido como o tráfego que excede a configuração de intermitência.

Um mapa de redução de DSCP é definido quando a QoS é desabilitada. Esse mapa de redução padrão está relacionado nesta tabela, anteriormente neste documento. A Command Line Interface (CLI) permite que um administrador modifique o mapa padrão de redução, entrando o comando set qos policed-dscp-map. Um exemplo disso é mostrado a seguir.

Cat6500(config)# set qos policed-dscp-map 20-25:7 33-38:3

Esse exemplo modifica o mapa DSCP vigiado, de modo que esse reflita que os valores de DSCP de 20 a 25 serão diminuídos para um valor de DSCP igual a 7 e que os valores de 33 a 38 serão diminuídos para um valor de DSCP igual a 3.

Políticas de mapeamento para VLANs e Portas (CatOS)

Após a criação de uma ACL, ela deve ser mapeada para uma porta ou uma VLAN para poder ser efetivada.

Um comando interessante, que pode confundir os mais desatentos, é o utilizado na configuração padrão de QoS, que define todo o QoS como baseado em porta. Se um agregado (ou microfluxo) for aplicado a uma VLAN, este não surtirá efeito em uma porta, se esta porta não tiver sido configurada para QoS baseada em VLAN.


Console> (enable) set port qos 2/5-10 vlan-based  

!-- Programação do hardware em processamento...

!-- Interface QoS definida para portas baseadas em vlan 2/5-10.

Console> (habilitar)

A alteração de QoS baseada em porta para QoS baseada em VLAN separa imediatamente todas as ACLs atribuídas a essa porta e atribui ACLs baseadas em VLAN à mesma.

O mapeamento da ACL para uma porta (ou VLAN) é realizado com a entrada do comando:


Console> (enable) set qos acl map test-acl 3/5  

!-- Programação do hardware em processamento...

!-- A ACL test-acl é anexada à porta 3/5.

Console> (habilitar)



Console> (enable) set qos acl map test-acl 18  

!-- Programação do hardware em processamento...

!-- A ACL test-acl é anexada à VLAN 18.

Console> (habilitar)

Mesmo após o mapeamento da ACL para uma porta (ou VLAN), a ACL ainda não tem efeito, até que esta seja vinculada ao hardware. Isso está descrito na seção seguinte. Nesse ponto, a ACL permanece em um buffer de edição temporário na memória. Enquanto estiver nesse buffer, a ACL poderá ser modificada.

Para remover ACLs não vinculadas que estejam no buffer de edição, execute o comando rollback. Esse comando exclui a ACL do buffer de edição.


Console> (enable) rollback qos acl test-acl 

!-- Reversão da ACL de QoS test-acl com êxito.

Console> (habilitar)

Vinculando ACLs (CatOS)

Para aplicar a ACL QoS definida (acima), a ACL deve estar comprometida com o hardware. O processo de comprometimento copia a ACL do buffer temporário para o hardware de PFC. Uma vez residindo na memória de PFC, a política definida na ACL de QoS pode ser aplicada a todo o tráfego que corresponda às ACEs.

Para facilitar a configuração, a maioria dos administradores executa o comando commit all. Entretanto, é possível vincular uma ACL específica (dentre várias), que podem residir atualmente no buffer de edição. Um exemplo do uso do comando commit é fornecido abaixo.


Console> (enable) commit qos acl test-acl 

!-- Programação do hardware em processamento...

!-- A ACL test-acl é vinculada ao hardware.  

Console> (habilitar)

Para remover uma ACL de uma porta (ou VLAN), é necessário limpar o mapa que associa essa ACL à porta (ou VLAN), entrando o comando a seguir:


Console> (enable) clear qos acl map test-acl 3/5  

!-- Programação do hardware em processamento...

!-- A ACL test-acl é separada da porta 3/5.

Console>(habilitar)

Configurar a Vigilância na Família Catalyst 6000 com o Cisco IOS Integrado (Modo Nativo)

A vigilância é suportada com o Cisco IOS Integrado (Modo Nativo). Todavia, a configuração e a implementação dessa função de vigilância é obtida por meio de mapas de política. Cada mapa utiliza múltiplas classes de política para o compor e estas classes podem ser definidas para tipos de fluxos de tráfego diferentes.

Na filtragem, as classes de mapas de política usam ACLs com base em IOS e instruções de correspondência de classe para identificar o tráfego a ser vigiado. Depois que o tráfego é identificado, as classes de política podem usar os vigilantes agregados e de microfluxo para aplicar as políticas de vigilância àquele tráfego correspondente.

As seções seguintes explicam a configuração de vigilância para o Cisco IOS Integrado (Modo Nativo) com mais detalhes.

Agregados e Microfluxos (Cisco IOS Integrado (Modo Nativo))

Os termos agregados e microfluxos são utilizados para definir o âmbito da vigilância executada pelo PFC. Igualmente ao CatOS, os agregados e os microfluxos também são usados com o Cisco IOS Integrado (Modo Nativo).

Microfluxo se refere à vigilância de um único fluxo. Um fluxo é definido por uma sessão com um endereço SA/DA MAC único, endereço IP SA/DA e números de porta TCP/UDP. Para cada fluxo novo iniciado por meio de uma porta de VLAN, o microfluxo pode ser utilizado para limitar a quantidade de dados recebidos nesse fluxo pelo switch. Na definição de microfluxo, os pacotes que excedem o limite de taxa prescrito podem ser descartados ou ter seus valores de DSCP diminuídos. Os microfluxos são aplicados com a utilização do comando police flow, que faz parte de uma classe de mapa de política.

Para habilitar a vigilância de microfluxo no Cisco IOS Integrado (Modo Nativo), habilite-a globalmente no switch. Isto pode ser feito por meio da entrada do comando a seguir:

Cat6500(config)# mls qos flow-policing

A vigilância de microfluxo também pode ser aplicada ao tráfego interligado, ou seja, o tráfego não comutado na Camada 3. Execute o comando a seguir para habilitar o switch a oferecer suporte à vigilância de microfluxo no tráfego interligado:


Cat6500(config)# mls qos bridged

Esse comando também habilita a vigilância de microfluxo para o tráfego multicast. Se o tráfego multicast precisar ser atribuído a um vigilante de microfluxo, habilitar o comando (mls qos bridged).

De maneira similar ao microfluxo, um agregado pode ser usado para limitar a taxa de tráfego. Contudo, a taxa agregada se aplica a todo o tráfego de entrada em uma porta ou VLAN, que corresponda a uma ACL de QoS especificada. É possível exibir o agregado como a vigilância de tráfego cumulativo que corresponde a um perfil de tráfego definido.

Existem duas formas de agregados que podem ser definidas no Cisco IOS Integrado (Modo Nativo), como a seguir:

  • por vigilantes agregados de interface

  • vigilantes agregados nomeados

Os agregados por interface são aplicados a uma interface individual, através da entrada do comando police em uma classe de mapa de política. Essas classes de mapa podem ser aplicadas a várias interfaces, mas o vigilante policia cada interface separadamente. Agregados nomeados são aplicados a um grupo de portas e vigiam o tráfego de todas as interfaces cumulativamente. Os agregados nomeados são aplicados pela entrada do comando mls qos aggregate policer.

Pode-se definir uma quantidade de até 63 microfluxos e de até 1.023 agregados.

Criando Regras de Vigilância (Cisco IOS Integrado (Modo Nativo))

O processo de criação de regras de vigilância envolve a criação de um agregado (ou microfluxo) por meio de um mapa de política e, posteriormente, a inserção desse mapa em uma interface.

Considere o mesmo exemplo criado para CatOS. O requisito era limitar todo o tráfego IP recebido na porta 5/3 a um valor máximo de 20 MBPS.

É necessário criar um mapa de política primeiro. Criar um mapa de política denominado tráfego-limite. Isto pode ser feito da seguinte maneira:


Cat6500(config)# policy-map limit-traffic

Cat6500(config-pmap)#

Será possível observar de imediato que o prompt do switch se altera para mostrar o modo de configuração para criação de uma classe de mapa. Lembre-se de que um mapa de políticas pode conter múltiplas classes. Cada classe contém um conjunto de ações de política separado, que pode ser aplicado a diversos fluxos de tráfego.

Devemos criar uma classe de tráfego para limitar especificamente o tráfego recebido a 20 MBPS. Esse limite de classe deve ser chamado de limite-20. Isto será ilustrado a seguir.


Cat6500(config)# policy-map limit-traffic

Cat6500(config-pmap)# class limit-to-20

Cat6500(config-pmap-c)#

O prompt se altera novamente para refletir que agora você está na configuração de classe de mapa (mostrado com o -c no fim do prompt). Para aplicar o limite de taxa, de forma que este corresponda ao tráfego recebido específico, configure uma ACL e aplique-a ao nome da classe. Para atribuir um limite de 20 MBPS ao tráfego originado na rede 10.10.1.x, execute a seguinte ACL:

Cat6500(config)# access-list 101 permit ip 10.10.1.0  0.0.0.255 any

Essa ACL pode ser adicionada ao nome da classe, como a seguir:


Cat6500(config)# policy-map limit-traffic

Cat6500(config-pmap)# class limit-to-20 access-group 101

Cat6500(config-pmap-c)#

Depois que o mapa da classe estiver definido, pode-se definir os vigilantes individuais para essa classe. É possível criar agregados (usando a palavra-chave "vigia") ou microfluxos (usando a palavra-chave "fluxo de vigias"). Criar o agregado, conforme exibido a seguir.


Cat6500(config)# policy-map limit-traffic

Cat6500(config-pmap)# class limit-to-20 access-group 101

Cat6500(config-pmap-c)# police 20000000 13000 confirm-action transmit exceed-action drop

Cat6500(config-pmap-c)# exit

Cat6500(config-pmap)# exit

Cat6500(config)#

A instrução de classe acima (comando police) configura um limite de taxa de 20.000 k (20 Mbps), com uma intermitência de 52 Mbps (13.000 x 4.000 = 52 MB). Se o tráfego corresponder ao perfil e estiver dentro do limite de taxa, a ação a executar será definir a transmissão do tráfego dentro do perfil, por meio da instrução de confirmação da ação. Caso o tráfego esteja fora de perfil (isto é, acima do limite de 20 MB estabelecido em nosso exemplo), a instrução de ação em excesso será configurada para descartar o tráfego (todo o tráfego acima do limite será descartado).

Na configuração de um microfluxo, uma ação semelhante é executada. Para limitar todos os fluxos que correspondam a um determinado mapa de classe em uma porta para até 200 K cada, a configuração deste fluxo seria similar ao exemplo a seguir:


Cat6500(config)# mls qos flow-policing

Cat6500(config)# policy-map limit-each-flow

Cat6500(config-pmap)# class limit-to-200 

Cat6500(config-pmap-c)# police flow 200000 13000 confirm-action transmit exceed-action drop

Cat6500(config-pmap-c)# exit

Cat6500(config-pmap)# exit

Mapas de Redução de DSCP

Esses mapas são utilizados quando se define o vigilante para reduzir o tráfego fora de perfil, em vez de descartá-lo. O tráfego fora de perfil é definido como o tráfego que excede a configuração de intermitência.

Um mapa de redução de DSCP padrão é definido quando a QoS é habilitada. Esse mapa de redução padrão está relacionado nesta tabela. A CLI permite que um administrador modifique o mapa padrão de redução, entrando o comando set qos policed-dscp-map. Um exemplo disso é mostrado a seguir.


Cat6500(config)# mls qos map policed-dscp normal-burst 32 to 16

Esse exemplo define uma alteração no mapa padrão de vigilância de DSCP, que é a redução do valor de DSCP de 32 para 16. Em uma porta com definição de vigilância, os dados recebidos com esse valor de DSCP, que forem parte de um bloqueio de dados que excederam a intermitência definida, terão seu valor de DSCP diminuído para 16.

Mapeando Políticas para VLANS e Portas (Cisco IOS Integrado (Modo Nativo))

Após a criação de uma política, ela deve ser mapeada para uma porta ou uma VLAN para poder ser efetivada. Ao contrário do processo de vinculação em CatOS, aqui não há um equivalente no Cisco IOS Integrado (Modo Nativo). Quando uma política é mapeada para uma interface, essa política está em efeito. Para mapear a política acima para uma interface, execute o comando a seguir:


Cat6500(config)# interface fastethernet 3/5

Cat6500(config-if)# service-policy input limit-traffic

Se uma política for mapeada para uma VLAN, deve-se informar a interface onde a QoS é baseda em VLAN para cada porta na VLAN à qual a política deva ser atribuída, entrando o comando mls qos vlan-based.


Cat6500(config)# interface fastethernet 3/5

Cat6500(config-if)# mls qos vlan-based

Cat6500(config-if)# exit

Cat6500(config)# interface vlan 100

Cat6500(config-if)# service-policy input limit-traffic

Supondo que a interface 3/5 fazia parte da VLAN 100, a política chamada tráfego-limite aplicada à VLAN 100 também seria aplicada à interface 3/5.

Configurar a Classificação na Família Catalyst 6000 com CatOS

A PFC introduz o suporte para a classificação de dados, usando ACLs que podem visualizar informações de cabeçalhos de Camada 2, Camada 3 e Camada 4. Para um SupI ou IA (sem PFC), a classificação é limitada à utilização das palavras-chave de confiabilidade nas portas.

A seção a seguir descreve os componentes de configuração QoS usados pelo PFC para Classificação no CatOS.

COs para Mapeamento de DSCP (CatOS)

Quando entram no switch, os quadros têm seus valores de DSCP definidos pelo switch. Se a porta estiver no estado confiável e o administrador tiver utilizado as palavras-chave trust-COs, o valor de COs definido no quadro será utilizado para determinar o valor de DSCP configurado para ele. Conforme mencionado anteriormente, o switch pode atribuir níveis de serviço para um quadro com base no valor de DSCP interno à medida que transita pelo switch.

Essa palavra-chave não é suportada nos módulos 10/100 mais antigos (WS-X6248 e WS-X6348). Nesses módulos, é recomendado utilizar ACLs para atribuir configurações de COs aos dados recebidos.

Quando a QoS é habilitada, o switch cria um mapa padrão. Esse mapa é utilizado para identificar o valor de DSCP a ser definido, com base no valor de COs. Esses mapas são relacionados nesta tabela, anteriormente neste documento. Alternativamente, o administrador pode definir um único mapa. Um exemplo disso é mostrado a seguir.


Console> (enable) set qos cos-dscp-map 20 30 1 43 63 12 13 8 

!-- Mapa cos-dscp de QoS configurado com êxito.

Console> (habilitar)

O comando acima define o mapa a seguir:

COs 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Embora improvável que esse mapa seja utilizado em uma rede na realidade, ele auxilia o entendimento do que pode ser realizado por meio desse comando.

Precedência de IP para Mapeamento de DSCP (CatOS)

De modo semelhante ao ocorrido na definição de COs para o mapa de DSCP, um quadro pode ter um valor de DSCP determinado pela configuração da precedência de IP dos pacotes recebidos. Isso ocorrerá somente se a porta for definida como confiável pelo administrador e este tiver usado a palavra-chave trust-ipprec.

Quando a QoS é habilitada, o switch cria um mapa padrão. Esses mapas são relacionados nesta tabela, anteriormente neste documento. Esse mapa é utilizado para identificar o valor de DSCP a ser definido, com base no valor de precedência de IP. Alternativamente, o administrador pode definir um único mapa. Um exemplo disso é mostrado a seguir:


Console> (enable) set qos ipprec-dscp-map 20 30 1 43 63 12 13 8 

!-- Mapa ipprec-dscp de QoS configurado com êxito.

Console> (habilitar)

O comando acima define o mapa a seguir:

Precedência de IP 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Embora improvável que esse mapa seja utilizado em uma rede na realidade, ele auxilia o entendimento do que pode ser realizado por meio desse comando.

Classificação (CatOS)

Quando um quadro é passado para o PFC para processamento, o processo de classificação é realizado na estrutura. O PFC utilizará uma ACL pré-configurada (ou uma ACL padrão) para atribuir um DSCP ao quadro. Na ACE, uma das quatro palavras-chaves é usada para atribuir um valor de DSCP. Elas são exibidas a seguir:

    1. TRUST-DSCP (somente ACLs IP)
    2. TRUST-IPPREC (IP ACL'=s only)
    3. TRUST-COS (todas as ACLs, exceto IPX e MAC em uma PFC2)
    4. DSCP

A palavra-chave TRUS-DSCP parte do princípio que o quadro recebido no PFC já possui um valor de DSCP, definido antes da entrada no switch. O switch irá manter esse valor de DSCP.

Com TRUST-IPPREC, o PFC derivará um valor DSCP do valor de precedência de IP existente, residente no campo ToS. O PFC utilizará a precedência IP para mapas de DSCP, a fim de atribuir o DSCP correto. Quando a QoS é habilitada no switch, o mapa padrão é criado. Alternativamente, o mapa criado pelo administrador pode ser utilizado para originar o valor de DSCP.

Similarmente à TRUST-IPPREC, a palavra-chave TRUS-COS avisa o PFC para derivar um valor DSCP a partir dos COs no cabeçalho do quadro. Também haverá um COs para o mapa de DSCP (padrão ou atribuído pelo administrador) para auxiliar o PFC a derivar o DSCP.

A palavra-chave DSCP é usada quando um quadro recebido é originado em uma porta não-confiável. Isso é uma situação interessante para a derivação do DSCP. Nesse momento, o DSCP configurado na instrução set qos acl é utilizado para derivar este DSCP. Todavia, é nesse ponto que as ACLs podem ser utilizadas para derivar um DSCP para o tráfego, com base nos critérios de classificação definidos na ACE. Isso significa que em uma ACE, pode-se usar os critérios de classificação, tais como endereço IP de origem e de destino, números de portas TCP/UDP, códigos ICMP, tipo de IGMP, números de rede e de protocolo IPX, endereços MAC de origem e de destino e Ethertypes (somente para tráfego não-IP e não-IPX) para identificar o tráfego. Assim, uma ACE poderia ser configurada para atribuir um valor de DSCP específico, que defina o tráfego HTTP over FTP.

Considere o seguinte exemplo:


Console> (enable) set port qos 3/5 trust untrusted

A definição de uma porta como não confiável instruirá o PCF a usar uma ACE para derivar o DSCP do quadro. Se a ACE for configurada com critérios de classificação, os fluxos individuais dessa porta podem ser classificados com prioridades diferentes. As Aces a seguir ilustram isso:


Console> (enable) set qos acl ip abc dscp 32 tcp any any eq http 

Console> (enable) set qos acl ip ABC dscp 16 tcp any any eq ftp

Nesse exemplo, há duas instruções ACE. A primeira identifica um fluxo TCP (a palavra-chave any é utilizada para identificar o tráfego de origem e destino), cujo número da porta é 80 (80 = HTTP) e será atribuído a um valor de DSCP igual a 32. A segunda ACE identifica o tráfego originado de um host e destinado a qualquer host com o número de porta de TCP igual a 21 (FTP), que será atribuído a um valor de DSCP de 16.

Configurar a Classificação na família Catalyst 6000 com o Cisco IOS Integrado (Modo Nativo)

A seção a seguir descreve os componentes de configuração QoS usados para dar suporte à classificação no PFC, utilizando o Cisco IOS Integrado (Modo Nativo).

COs para Mapeamento de DSCP (Cisco IOS Integrado (Modo Nativo))

Ao entrar no switch, o quadro terá seu valor de DSCP definido por ele. Se a porta estiver no estado confiável e o administrador tiver utilizado a palavra-chave mls qos trust-COs (nas portas GE ou 10/100 das placas de linha WS-X6548), o valor de COs definido no quadro será utilizado para determinar o valor de DSCP configurado para ele. Conforme mencionado anteriormente, o switch pode atribuir níveis de serviço a um quadro, à medida que ele transita pelo switch com base no valor de DSCP interno.

Quando a QoS é habilitada, o switch cria um mapa padrão. Consultar esta tabela para visualizar as configurações padrão. Esse mapa é utilizado para identificar o valor de DSCP a ser definido, com base no valor de COs. Alternativamente, o administrador pode definir um único mapa. Um exemplo disso é mostrado a seguir.


Cat6500(config)# mls qos map cos-dscp 20 30 1 43 63 12 13 8

Cat6500(config)#

O comando acima define o mapa a seguir:

COs 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Embora improvável que esse mapa seja utilizado em uma rede na realidade, ele auxilia o entendimento do que pode ser realizado por meio desse comando.

Precedência de IP para Mapeamento de DSCP (Cisco IOS Integrado (Modo Nativo))

De modo semelhante ao ocorrido na definição de COs para o mapa de DSCP, um quadro pode ter um valor de DSCP determinado pela configuração da precedência de IP dos pacotes recebidos. Isso ocorrerá somente se a porta for definida como confiável pelo administrador e este tiver usado a palavra-chave mls qos trust-ipprec. A palavra-chave é suportada apenas em portas GE e 10/100 em placas de linha WS-X6548. Nas portas 10/100 das placas de linha WS-X6348 e WS-X6248, as ACLs devem ser utilizadas para atribuir a precedência de IP aos dados recebidos.

Quando a QoS é habilitada, o switch cria um mapa padrão. Consultar esta tabela para visualizar as configurações padrão. Esse mapa é utilizado para identificar o valor de DSCP a ser definido, com base no valor de precedência de IP. Alternativamente, o administrador pode definir um único mapa. Um exemplo disso é mostrado a seguir.


Cat6500(config)# mls qos map ip-prec-dscp 20 30 1 43 63 12 13 8

Cat6500(config)#

O comando acima define o mapa a seguir:

Precedência de IP 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Embora improvável que esse mapa seja utilizado em uma rede na realidade, ele auxilia o entendimento do que pode ser realizado por meio desse comando.

Classificação (Cisco IOS Integrado (Modo Nativo))

Quando um quadro é passado à PFC, o processo de classificação pode ser executado para atribuir uma nova prioridade ao quadro recebido. A advertência nesse caso é que essa atribuição só poderá ser feita quando o quadro for originado em uma porta não confiável ou quando tiver sido classificado como não confiável.

Uma ação de classe do mapa de política pode ser utilizada para:

    1. TRUST COs
    2. TRUST IP-PRECEDENCE
    3. TRUST DSCP
    4. NO TRUST

A palavra-chave TRUS-DSCP parte do princípio que o quadro recebido no PFC já possui um valor de DSCP, definido antes da entrada no switch. O switch irá manter esse valor de DSCP.

Com TRUST IP-PRECEDENCE, o PFC derivará um valor DSCP do valor de precedência de IP existente, residente no campo ToS. O PFC utilizará uma precedência de IP para o mapa de DSCP, a fim de atribuir o DSCP correto. Quando a QoS é habilitada no switch, o mapa padrão é criado. Alternativamente, o mapa criado pelo administrador pode ser utilizado para originar o valor de DSCP.

De modo semelhante à TRUST IP-PRECEDENCE, a palavra-chave TRUS-COS avisa o PFC para derivar um valor DSCP, a partir dos COs no cabeçalho do quadro. Também haverá um COs para o mapa de DSCP (padrão ou atribuído pelo administrador) para auxiliar o PFC a derivar o DSCP.

Um exemplo de derivação de DSCP de uma prioridade existente (DSCP, precedência de IP ou COs) é exibido a seguir.


Cat6500(config)# policy-map assign-dscp-value

Cat6500(config-pmap)# class test 

Cat6500(config-pmap-c)# trust COs

Cat6500(config-pmap-c)# exit

Cat6500(config-pmap)# exit

Cat6500(config)#

O mapa de classe acima será derivado do valor de DSCP de COs no cabeçalho da Ethernet.

A forma NO-TRUST da palavra-chave é usada quando um quadro é recebido de uma porta não-confiável. Isso permite que o quadro tenha um valor de DSCP atribuído durante o processo de vigilância.

Considere o exemplo de como uma prioridade nova (DSCP) pode ser atribuída a diversos fluxos que chegam ao PFC, por meio da definição de política a seguir.


Cat6500(config)# access-list 102 permit tcp any any eq http

Cat6500(config)# policy-map new-dscp-for-flow

Cat6500(config-pmap)# class test access-group 102 

Cat6500(config-pmap-c)# no trust 

Cat6500(config-pmap-c)# police 1000 1 confirm-action set-dscp-transmit 24  Cat6500(config-pmap-c)# exit

Cat6500(config-pmap)# exit

Cat6500(config)#

O exemplo acima mostra o seguinte:

    1. Criação de uma ACL para identificar os fluxos de http que chegam à porta.
    2. Um mapa de política chamado new-dscp-for-flow.
    3. Um mapa de classe (teste de nomes) que utiliza a lista de acesso 102, a fim de identificar o tráfego para o qual a ação desse mapa será executada.
    4. O teste de mapa de classe define o estado de confiabilidade do quadro recebido como não-confiável e atribui um DSCP de 24 para o fluxo.
    5. Esse mapa de classe também limitará o agregado de todos os fluxos de http a um máximo de 1MB.

COPS (Common Open Policy Server)

O COPS é um protocolo que habilita a família Catalyst 6000 para a configuração de QoS de um host remoto. Atualmente, o COPS é suportado apenas com CatOS e faz parte da arquitetura Intserv para QoS. Atualmente, não há suporte (na data deste documento) para COPS com a utilização do Cisco IOS Integrado (Modo Nativo). Mesmo que o protocolo COPS leve as informações de configuração de QoS para o switch, ele não será a origem dessas informações. A utilização do protocolo COPS requer um gerenciador de QoS externo para hospedar as configurações de QoS para o switch. O gerenciador de QoS externo iniciará a ação de descarregamento dessas configurações para o switch, utilizando o protocolo COPS. O Cisco QoS Policy Manager (QPM) é um exemplo de gerenciador de QoS externo.

Esse documento não visa explicar o funcionamento de QPM, mas sim a configuração necessária no switch para suportar as configurações externas de QoS, empregadas na utilização de QPM.

Configuração do COPS

Por padrão, o suporte ao COPS é desabilitado. Para utilizar o COPS no switch, este deve estar habilitado. Isto pode ser feito por meio da entrada do comando a seguir:


Console> (enable) set qos policy-source cops   

!-- Origem da política de QoS do switch definida como COPS.

Console> (habilitar)

Quando este comando é iniciado, determinados valores de configuração de QoS padrão serão originados no servidor COPS. Esses valores de configuração incluem:

    1. COs para mapeamentos de fila
    2. Atribuições de limiares das filas de entrada e saída
    3. Atribuições de largura de banda de WRR
    4. Políticas de agregado e microfluxo
    5. DSCP para mapas de COs do tráfego de saída
    6. ACLs
    7. Atribuições de COs para a porta padrão

Quando as configurações de QoS forem realizadas usando COPS, é importante compreender que a aplicação dessas configurações é realizada de uma forma diferente. Em vez de configurar diretamente as portas, o COPS é utilizado para configurar o ASIC da porta. Geralmente, o ASIC da porta controla um grupo de portas; portanto a configuração de COPS é aplicada a várias portas ao mesmo tempo.

O ASIC da porta configurado é o GE ASIC. Nas placas de linha GE, há quatro portas por GE (portas 1-4, 5-8, 9-12, 13-16). Nessas placas de linha, a configuração COPS afeta cada grupo de portas. Nas placas de linha 10/100 (conforme discutido anteriormente neste documento), há dois grupos de ASICs, o GE e o 10/100. Há um ASIC GE para quatro ASICs 10/100. Cada ASIC 10/100 suporta 12 portas 10/100. O COPS configura o ASIC GE. Portanto, ao aplicar a configuração de QoS às placas de linha 10/100 por meio do COPS, essa será aplicada a todas as 48 portas 10/100.

Ao habilitar o suporte COPS por meio da entrada do comando set qos policy-source cops, a configuração de QoS via COPS será aplicada em todos os ASICs do chassi do switch. É possível aplicar a configuração COPS a ASICs específicos. Isto pode ser feito por meio do comando a seguir:


Console> (enable) set port qos 5/4 policy-source cops

!-- Origem da política de QoS definida como COPS para porta(s) 5/1-4.

Console> (habilitar)

No aplicativo, você pode ver que o comando acima foi executado em um módulo GE, uma vez que quatro portas foram afetadas por ele.

Policy Decision Point Servers e Domain Names

Policy Decision Point Servers (PDPS) são gerenciadores externos de políticas utilizados para armazenar detalhes de configuração de QoS enviados para o switch. Se o COPS estiver habilitado no switch, este deve ser configurado com o endereço IP do gerenciador externo, que fornecerá os detalhes da configuração de QoS para o switch. Isso é similar ao que ocorre quando o SNMP é habilitado e o endereço IP do gerenciador de SNMP é definido.

O comando para identificar o PDPS externo é efetuado com o uso de:


Console> (enable) set cops server 192.168.1.1 primary

!-- O 192.168.1.1 é adicionado à tabela diff-serv server do COPS como servidor primário.

!-- O 192.168.1.1 é adicionado à tabela rsvp server do COPS como servidor primário.

Console> (habilitar)

O comando acima identifica o dispositivo 192.168.1.1 como servidor de ponto de decisão principal.

Quando o switch se comunica com o PDPS, ele precisa fazer parte de um domínio definido no PDPS. O PDPS só falará com os switches que fazem parte de seu domínio definido, portanto o switch deverá estar configurado para identificar o domínio COPS ao qual ele pertence. Para fazer isso, entrar o seguinte comando:


Console> (enable) set cops domain name remote-cat6k

!-- Nome do domínio definido como remote-cat6k.

Console> (habilitar)

O comando acima mostra o switch sendo configurado para ser parte de um domínio chamado remote-cat6k. Esse domínio deve ser definido em QPM e o switch deve ser adicionado àquele domínio.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 24906