WRED e MDRR no Cisco 12000 Series Internet Router com uma combinação de exemplo de configuração de tráfego de voz, multicast e unicast

Introduction

Este documento explica como configurar uma placa de linha Cisco 12000 Series para WRED (Weighted Random Early Detection), descrita em RFC 2309 , em um ambiente multisserviço.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes da seguinte informação:

• Compreendendo e configurando MDRR e WRED no Cisco 12000 Series Internet Router

• Como ler a saída do comando show controller frfab | Comandos tofab queue em um Cisco 12000 Series Internet Router

• Tipo de serviço no Internet Protocol Suite, precedência (RFC-1349)

• Detecção antecipada aleatória ponderada

Componentes Utilizados

As informações neste documento são baseadas nas versões de software e hardware abaixo:

• Qualquer Cisco IOS® Software Release que suporte o roteador de Internet do Cisco 12000 Series. Normalmente são as versões 12.0S e 12.0ST.

• Todas as plataformas Cisco 12000 são abordadas por este documento. Entre eles estão 12008, 12012, 12016, 12404, 12406, 12410 e 12416.

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

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

A série Cisco 12000 é uma das plataformas mais populares usadas para construir uma rede de núcleo IP de alta largura de banda. Essa plataforma oferece a possibilidade exclusiva de configurar a Qualidade de Serviço (QoS).

Como é cada vez mais comum combinar diferentes tipos de tráfego IP (como Voz sobre IP - VoIP - e multicast) na mesma rede, os requisitos para priorização e um comportamento de descarte controlado tornam-se extremamente importantes e, em muitos casos, são a diferença entre sucesso e falha ao iniciar um novo serviço como VoIP.

Os requisitos de rede para diferentes tipos de tráfego IP estão além do escopo deste documento. Este documento enfatiza os testes de laboratório realizados para encontrar uma configuração aplicável em diferentes placas de linha, incluindo a placa de linha Cisco 12000 Series, Gigabit Ethernet de 3 portas (GbE de 3 portas). Os resultados desses testes mostram que a placa de linha do GbE Engine 2 de 3 portas é adequada para um ambiente de rede que envolve uma combinação de tráfego de voz, dados e multicast. Também prova que a configuração da QoS faz uma diferença real em uma rede congestionada.

Classes de precedência usadas no teste

Os valores de precedência atribuídos a diferentes classes precisam ser os mesmos em toda a rede. Você precisa determinar uma política genérica.

Classe	Precedência	Tráfego
Tráfego mal-intencionado		Todo o tráfego não identificado fora da rede (fora da rede)
Na rede — na rede	1	Tráfego que permanece na rede da controladora de armazenamento (na rede)
Serviços de provedor de serviços de Internet (ISP)	2	Tráfego de ISP, SMTP, POP, FTP, DNS, Telnet, SSH, www, https
PME (pequenas e médias empresas)	3	Clientes corporativos, um serviço ouro
Tempo real, sem voz	4	TV, jogos em tempo real
Voz	5	tráfego de RTP VOIP
Mensagens de controle de rede	6-7	Border Gateway Protocol (BGP) e outras mensagens de controle

Cores dos pacotes de IP

Se a QoS for implementada no núcleo de uma rede, um pré-requisito é que o provedor de serviços esteja no controle total do valor de precedência de todos os pacotes IP transportados na rede. A única maneira de fazer isso é marcar todos os pacotes quando eles entrarem na rede, sem distinção se eles vêm do lado do cliente/usuário final ou da Internet. Nenhuma marcação ou coloração deve ser feita no núcleo.

Resultados esperados

O objetivo deste projeto é ter um comportamento WRED real nas classes 0 a 3. Isso significa que gostaríamos de ter uma situação em que começássemos a descartar pacotes de precedência 0 durante o congestionamento. Depois disso, deveríamos também começar a perder a precedência 1 se o congestionamento continuar, e depois também a precedência 2 e 3. Tudo isso está descrito no gráfico abaixo.

Você deve ter a menor latência possível para pacotes de voz e nenhuma perda para tráfego de voz e multicast.

Configuração da rede

Para testar e avaliar a configuração, usamos um Cisco 12410 junto com um gerador de pacotes da Agilant. O roteador Cisco 12000 está executando uma versão de engenharia com base no Cisco IOS Software Release 12.0(21)S1.

Implementação de enfileiramento GbE Engine 2 de 3 portas

As placas Engine 2 normalmente têm oito filas fab e uma fila de baixa latência e oito filas tofab por slot de destino. Há também uma fila tofab multicast separada. Na placa GbE de 3 portas, há apenas uma fila de formatação por porta física. No teste, a configuração que foi aplicada especifica mais filas. Os resultados mostram que a placa GbE de 3 portas aceita essa configuração e que as filas são mapeadas automaticamente para as filas disponíveis.

Algoritmo WRED do mecanismo 2 no Cisco IOS Software

Você deve entender completamente o algoritmo usado para WRED na placa de linha Engine 2 ao configurar os valores mínimo e máximo de profundidade de fila. O código não se preocupa com o valor mínimo configurado; em vez disso, usa sua própria fórmula (com base no valor máximo configurado) para definir o valor mínimo.

Fórmula:

Valor mínimo = Valor máximo - (a potência mais alta de 2 que não gera um resultado negativo)

Os valores usados neste teste resultaram nos seguintes valores mínimos programados para o ASIC (Application-Specific Integrated Circuit Circuito Integrado Específico de Aplicativo):

Precedência	Mínimo configurado	Máximo configurado	Maior potência de 2	Valor mínimo em ASIC
0	50	5000	4096	5000-4096=904
1	60	6000	4096	6000-4096=1904
2	70	7000	4096	7000-4096=2904
3	80	8000	4096	8000-4096=3904

Usar esta fórmula para calcular o valor mínimo significa que você pode acabar com o comportamento incorreto de tratamento de pacotes se não levar isso em consideração ao configurar seus parâmetros WRED. Isso é mostrado no seguinte exemplo:

Precedência	Mínimo configurado	Máximo configurado	Maior potência de 2	Valor mínimo em ASIC
0	50	150	128	150-128=22
1	75	225	128	225-128=97
2	100	300	256	300-256=44
3	125	375	256	375-256=119

Isso significa que, mesmo que os valores estejam configurados para começar a cair de acordo com a regra 0 primeiro, depois 1, 2 e por último 3 (acima), quando os valores são gravados no ASIC, você realmente começa a descartar a precedência 0, depois a precedência 2, depois a precedência 1 e, por último, a precedência 3. Não há como ver quais valores foram configurados no ASIC em uma placa Engine 2. Se você aplicar a configuração em uma placa Engine 3, os valores mostrados na configuração serão os valores reais (o valor mínimo recalculado).

Configuração de QoS

Para obter mais detalhes sobre a configuração de QoS, leia Understanding and Configuring MDRR and WRED on the Cisco 12000 Series Internet Router.

Rx CoS

rx-cos-slot 2 B2-Table
rx-cos-slot 3 B2-Table
rx-cos-slot 6 B2-Table

Na maioria dos casos, você pode usar o comando rx-cos-slot all. Em nosso caso de teste, tínhamos alguns cartões que não suportavam enfileiramento tofab, então nem sempre poderíamos usar o comando rx-cos-slot all. Em vez disso, atribuímos nossa tabela de slots às placas de linha que estão sendo usadas no teste.

!   
slot-table-cos B2-Table  
destination-slot all B2  
multicast B2  
!--- If you don't fulfill the steps above, you will not be able to reach the goal of 0 drops for Multicast traffic. With no rx-cos configured, multicast will be treated in the default queue, meaning it will drop as soon as there is congestion.

!

QoS de transmissão

Agora você pode configurar seu tx-cos. Escolha um nome para suas tx qos, como "cos-queue-group B2".

Cada valor de precedência para o qual você deseja configurar um comportamento de queda precisa ser mapeado para um rótulo de detecção aleatório separado.

precedence 0 random-detect-label 0  

precedence 1 random-detect-label 1  

precedence 2 random-detect-label 2  

precedence 3 random-detect-label 3

Para Rodízio de Déficit Modificado (MDRR - Modified Deficit Round Robin), mapeie cada precedência para uma fila MDRR. Em nosso exemplo, mapeamos a precedência 0-3 para a mesma fila MDRR para reservar largura de banda para vídeo (tráfego multicast). Este mapeamento fornece o comportamento solicitado.

precedence 0 queue 0  

precedence 1 queue 0  

precedence 2 queue 0  

precedence 3 queue 0  

precedence 4 queue 4 

A voz é marcada com a precedência 5, por isso a precedência 5 é mapeada para a fila de baixa latência.

precedence 5 queue low-latency  

precedence 6 queue 6  

precedence 7 queue 6  

Agora você precisa configurar o comportamento de descarte para cada um dos rótulos de detecção aleatória. Durante o teste, esses números foram alterados até que foram encontrados valores que deram o padrão de queda desejado. Para obter detalhes, consulte a seção Resultados esperados. A profundidade da fila é medida na fila física, e não no MDRR ou na fila RED-Label.

random-detect-label 0 50 5000 1  

random-detect-label 1 60 6000 1  

random-detect-label 2 70 7000 1  

random-detect-label 3 80 8000 1 

No Cisco 12000, é possível criar comportamento CBWFQ (Class-Based, Weighted Fair Queuing), dando um peso à fila MDRR diferente. O peso padrão é 10 por fila. O número de bytes transmitidos a cada ciclo MDRR é uma função do valor de peso. Um valor de 1 significa 1500 bytes cada ciclo. Um valor de 10 significa 1500+(9*512) bytes por ciclo."

queue 0 20  

queue 4 20  

queue 6 20  

!  

Mapeamento de interfaces

Cada interface precisa ser configurada para WRED. Isso é feito usando os comandos:

• configure terminal

• interface gig 6/0

• tx-cos B2

Iniciando com nenhuma queda

O fluxo gerado usa os seguintes valores, a menos que outra coisa seja informada:

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb voip

Isso resulta em um fluxo de segundo plano de 240 Mb (VoIP e multicast).

Em seguida, adicionamos quatro fluxos de dados do mesmo tamanho, mas com precedência de 0 a 3 (um valor de precedência por fluxo).

Quatro fluxos de dados com 151 Mb cada

Essa configuração fornece uma largura de banda total de 844Mb. O gráfico abaixo mostra que há 0 quedas de pacote e uma latência muito baixa (cerca de 50 us - microssegundos - para cada fluxo, incluindo Voz).

Quatro fluxos de dados de 160 Mb cada

Essa configuração fornece uma largura de banda total de 880 Mb. O gráfico abaixo mostra que os pacotes começam a cair da classe de precedência 0 e a latência para Voz aumentou para 6 ms - milissegundos.

Quatro fluxos de dados de 167 Mb cada

Essa configuração fornece uma largura de banda total de 908 Mb. As quedas também começam para a classe de precedência 1. A latência do tráfego de voz ainda é a mesma.

Observação: o fluxo não foi interrompido antes de ser aumentado, portanto a diferença entre o número de gotas no fluxo 0 e 1 é cumulativa.

Quatro fluxos de dados de 191Mb cada

Quando a largura de banda total aumenta, os pacotes também começam a sair da fila de precedência 2. A largura de banda total que estamos tentando alcançar para a interface Gigabit Ethernet agora é de 1004Mb. Isso é ilustrado nos contadores de erro de sequência no gráfico abaixo.

Quatro fluxos de dados de 244 Mb cada

Os erros de sequência para a precedência 3 também estão começando a aumentar. Este é o primeiro sinal que as quedas começarão nessa fila. A quantidade total de largura de banda que estamos tentando enviar para a interface GbE agora é de 1216 Mb. Observe que as quedas no multicast (MC) e na fila de voz ainda são zero e a latência da fila de voz não aumentou.

Parando e iniciando

Todos os fluxos foram parados e começaram a gerar um gráfico que limpou os contadores. Isso mostra como ele ficará durante o congestionamento pesado. Como você pode ver abaixo, o comportamento é o desejado.

Todas as QoS removidas

Para provar que a QoS realmente melhora o desempenho durante o congestionamento, a QoS foi removida e a interface ficou congestionada. Os resultados estão abaixo (o fluxo gerado usa os seguintes valores, a menos que algo mais seja informado).

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb VoIP

Isso resulta em um fluxo de segundo plano de 240 Mb (VoIP e multicast).

Em seguida, adicionamos quatro fluxos de dados do mesmo tamanho, mas com precedência de 0 a 3 (um valor de precedência por fluxo).

Quatro fluxos de dados de 153 Mb cada

Isso dá um total de 852 Mb. Há 0 gotas e uma latência menor que 50 nós.

Quatro fluxos de dados com 158 Mb cada

Começamos a diminuir na mesma utilização que quando o WRED é aplicado (872Mb ). A diferença agora é que há uma latência de pacotes de voz de 14 ms (mais que o dobro do teste WRED) e que quedas ocorrem igualmente de todas as classes, incluindo VoIP e multicast.

Adicionando carga de ingresso

Até o momento, todos os testes incluíram apenas transmissão através das interfaces Gigabit Ethernet. Para verificar como a interface reage em uma situação em que também congestionamos a interface na outra direção, foram feitos os seguintes testes.

Para este teste, carregamos a interface Gigabit Ethernet com uma quantidade total de 1056 Mb. Isso resultou em quedas na precedência de 0 a 2, sem quedas no tráfego de precedência 3. (MC e VOIP permaneceram os mesmos, ou seja, sem quedas). Em seguida, adicionamos tráfego na outra direção, tanto tráfego quanto o gerador de pacotes foi capaz de enviar através da interface Gigabit Ethernet. O resultado é bastante impressionante: o congestionamento de recebimento não interfere de todo com a fila de transmissão, e a latência para o tráfego de recebimento é extremamente baixa, menos de 13 us para Voz.

12-RP#show interfaces g 6/0

Você pode monitorar a carga no link Gigabit usando o comando show interfaces:

Router#show interfaces gig 6/0
GigabitEthernet6/0 is up, line protocol is up
  Hardware is GigMac 3 Port GigabitEthernet, address is 0004.de56.c264 
  (bia 0004.de56.c264)
  Internet address is 178.6.0.1/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 232/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX 
  output flow-control is unsupported, input flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 08:52:40
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 2174119522 drops; input queue 0/75, 0 drops
  30 second input rate 838969000 bits/sec, 792079 packets/sec
  30 second output rate 910819000 bits/sec, 464704 packets/sec
    7584351146 packets input, 1003461987270 bytes, 0 no buffer
	Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
	0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
	0 watchdog, 514 multicast, 0 pause input
	11167110605 packets output, 2241229569668 bytes, 0 underruns
	0 output errors, 0 collisions, 0 interface resets
	0 babbles, 0 late collision, 0 deferred
	0 lost carrier, 0 no carrier, 0 pause output
	0 output buffer failures, 0 output buffers swapped out

Alterando o tamanho dos fluxos

Para verificar se os resultados do teste não são devido à largura de banda ser a mesma para todos os fluxos, nós mudamos os fluxos de modo que eles estivessem transmitindo diferentes quantidades de dados. Também tentamos alterar a MTU (Maximum Transmission Unit, unidade de transmissão máxima), de modo que ela fosse diferente para cada fluxo. Com os valores de fila configurados, o resultado ainda era o mesmo, deixando a precedência 0 primeiro, depois 1, depois 2 e, por último, a precedência 3.

Verificando uma placa de linha de 10 portas Gigabit Ethernet Engine 4

Como a latência da fila VoIP (a fila de baixa latência) no teste foi relativamente alta, realizamos o mesmo teste com a placa de linha 10-Port Gigabit Ethernet Engine 4. Como esperado, o resultado com essa placa de linha foi muito melhor em relação à latência na fila de baixa latência (LLQ). Os resultados foram os mesmos em relação à forma como a queda ocorreu. A latência para o LLQ era de cerca de 10us, que é 1:1000 da latência na placa de linha do Gigabit Ethernet Engine 2 de 3 portas.

Informações Relacionadas

• Compreendendo e configurando MDRR e WRED no Cisco 12000 Series Internet Router
• Como ler a saída do comando show controller frfab | Comandos tofab queue em um Cisco 12000 Series Internet Router
• Tipo de serviço no Internet Protocol Suite, precedência (RFC-1349)
• Detecção antecipada aleatória ponderada
• Suporte Técnico e Documentação - Cisco Systems