Roteadores : Roteadores Cisco 12000 Series

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

12 Agosto 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Abril 2015) | Feedback


Índice


Introdução

Este documento explica como configurar uma placa de linha do Cisco 12000 Series para o Weighted Random Early Detection (WRED), descrita no RFC 2309leavingcisco.com , em um ambiente do multi-serviço.

Pré-requisitos

Requisitos

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

Componentes Utilizados

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

  • Algum software release de Cisco IOS� que apoiar o Cisco 12000 Series Internet Router. Normalmente são as versões 12.0S e 12.0ST.

  • Todas as plataformas Cisco 12000 são abordadas por este documento. Estes incluem os 12008, 12012, 12016, 12404, 12406, 12410, e os 12416.

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

Convenções

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

Informações de Apoio

O Cisco 12000 Series é uma da maioria de plataformas popular usadas para construir uma rede central IP da largura de banda elevada. Esta plataforma oferece a possibilidade exclusiva de configurar o Qualidade de Serviço (QoS).

Desde que é cada vez mais comum misturar tipos de tráfego IP diferentes (tais como a Voz sobre o IP - VoIP - e Multicast) na mesma rede, as exigências para a prioridade e um comportamento deixando cair controlado tornam-se extremamente importantes, e, em muitos casos, são-se a diferença entre sucesso e falha ao lançar um serviço novo tal como VoIP.

Os requisitos de rede para tipos de tráfego IP diferentes são além do alcance deste documento. Este documento centra-se sobre os testes de laboratório realizados para encontrar uma configuração que seja aplicável em placas de linha diferentes, incluindo o Cisco 12000 Series, placa de linha do Gigabit Ethernet 3-Port (3-Port GbE). Os resultados destes testes mostram que a placa de linha do Engine 2 3-Port GbE bem-está serida para um ambiente de rede que envolve uma mistura de Voz, de dados, e de tráfego multicast. Igualmente prova que aquele configurar QoS faz a uma diferença real em uma rede congestionada.

Classes de precedência usadas no teste

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

Classe Precedência Tráfego
Tráfego mau   Todos identificaram não fora do tráfego líquido (a fora-rede)
Na rede --- na rede 1 Trafique que estadas dentro da rede SP (on-net)
Serviços do provedor de serviço do Internet (ISP) 2 Tráfego ISP, S TP, POP, FTP, DNS, telnet, SSH, WWW, https
SME (pequena e média empresa) 3 Clientes de empreendimento, um serviço do ouro
Tempo real, não Voz 4 TV, jogo do tempo real
Voz 5 Tráfego voip RTP
Mensagens do controle de rede 6-7 Border Gateway Protocol (BGP) e outras mensagens do controle

Cores dos pacotes de IP

Se QoS deve ser executada no núcleo de uma rede, uma condição prévia é 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 isto é marcar todos os pacotes quando incorporam a rede, não fazendo nenhuma distinção se vêm do lado do cliente/utilizador final ou do Internet. Nenhuma marcação ou coloração devem ser feitas no núcleo.

Resultados esperados

O objetivo com este projeto é ter o comportamento verdadeiro WRED nas classes 0-3. Isto significa que nós gostaríamos de ter uma situação onde nós comecemos deixar cair a precedência 0 pacotes durante a congestão. Após isso, nós devemos igualmente começar deixar cair igualmente a precedência 1 se a congestão continua, e então a precedência 2 e 3. Isto é descrito toda no gráfico abaixo.

wred_behavior.gif

Você deve não ter a mais baixa latência possível para pacotes de voz, e nenhuma gota de todo para a Voz e o tráfego multicast.

Instalação de rede

Para testar e avaliar a configuração, nós usamos um Cisco 12410 junto com um gerador de pacote de Agilant. O Cisco 12000 Router está executando uma versão de engenharia baseada no Cisco IOS Software Release 12.0(21)S1.

/image/gif/paws/22561/network_setup.gif

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

Os cartões do Engine 2 têm normalmente oito filas do fromfab e uma fila de latência baixa, e oito filas do tofab pelo slot de destino. Há igualmente uma fila separada do Multicast do tofab. No cartão 3-Port GbE, há somente uma fila do fromfab pela porta física. No teste, a configuração que era aplicada especifica mais filas. Os resultados mostram que o cartão 3-Port GbE aceita esta configuração, e as filas são traçadas automaticamente às filas que estão disponíveis.

Algoritmo WRED do mecanismo 2 no Cisco IOS Software

Você deve inteiramente compreender o algoritmo usado para o WRED na placa de linha do Engine 2 ao configurar o mínimo e os valores do Maximum Queue Depth. O código não se importa com o valor mínimo configurado; em lugar de, usa sua própria fórmula (baseada no valor máximo configurado) para ajustar o valor mínimo.

Fórmula:

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

Os valores usados neste teste conduziram aos seguintes valores mínimos programados aos circuitos integrados do aplicativo específicos (ASIC):

Precedência Mínimo configurado Máxima configurada A potência a mais alta de 2 Valor mínimo no 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 terminar acima com o pacote incorreto que segura o comportamento se você não toma este na consideração ao configurar seus parâmetros de WRED. Isso é mostrado no seguinte exemplo:

Precedência Mínimo configurado Máxima configurada A potência a mais alta de 2 Valor mínimo no 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

Isto significa que, mesmo que os valores é configurado para começar deixar cair de acordo com a regra 0 primeiramente, a seguir 1, 2 e ultimamente 3 (acima), quando os valores são escritos ao ASIC, você começa realmente deixar cair a precedência 0, então a precedência 2, então a precedência 1, e ultimamente a precedência 3. Não há nenhuma maneira de ver que valores foram configurados no ASIC em um cartão do Engine 2. Se você aplica a configuração em um cartão do Engine 3, os valores que aparecem na configuração serão os valores reais (o valor mínimo voltado a calcular).

Configuração de QoS

Para mais detalhes sobre a configuração de QoS, leia por favor a compreensão e configurar do MDRR e do WRED no 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, nós tivemos alguns cartões que não apoiaram o enfileiramento tofab, assim que nós não poderíamos sempre usar o comando rx-cos-slot all. Em lugar de, nós atribuímos nossa entalhe-tabela à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 seus qos TX, tais como o “cos-queue-group B2".

Cada valor de precedência que você quer configurar um comportamento da gota para que as necessidades estejam traçadas a um Random-detect-label 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 o Modified Deficit Round Robin (MDRR), trace cada precedência a uma fila MDRR. Em nosso exemplo, nós traçamos a precedência 0-3 à mesma fila MDRR a fim reservar a largura de banda de 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 é identificada por meio de precedência 5, que é porque a precedência 5 é traçada à fila de latência baixa.

precedence 5 queue low-latency  

precedence 6 queue 6  

precedence 7 queue 6  

Agora você tem que configurar o comportamento deixando cair para cada um do Random-detect-labels. Durante testes, estes números foram mudados até que os valores estiveram encontrados que deram o teste padrão desejado da gota. Para detalhes, veja a seção dos resultados esperados. A profundidade de fila é medida na fila física, e não no MDRR ou na fila da Vermelho-etiqueta.

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 com base na classe, comportamento do Weighted Fair Queuing (CBWFQ), dando à fila diferente MDRR um o peso. O peso padrão é 10 pela fila. O número de bytes transmitiu cada ciclo MDRR é uma função do valor do peso. Um valor de 1 significa 1500 bytes cada ciclo. Um valor do 10 significa 1500+(9*512) bytes pelo ciclo.”

queue 0 20  

queue 4 20  

queue 6 20  

!  

Mapeamento de interfaces

Cada relação precisa de ser configurada para o WRED. Isto é feito usando os comandos:

  • configure terminal

  • conecte a atuação 6/0

  • TX-cos B2

Iniciando com nenhuma queda

O fluxo gerado usa os seguintes valores a menos que algo for indicado mais:

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

126Mb MC, 114Mb voip

Isto conduz a um fluxo de background de 240Mb (VoIP e Multicast).

Nós adicionamos então quatro fluxos de dados do mesmo tamanho, mas com precedência 0-3 (um valor de precedência pelo córrego).

Quatro fluxos de dados com 151 Mb cada

Esta configuração dá uma largura de banda total de 844Mb. O gráfico abaixo mostra que há as quedas de pacote de informação 0, e muito uma latência baixa (sobre 50 pés nós - microssegundos - para cada córrego, incluindo a Voz).

151mb.gif

Quatro fluxos de dados de 160 Mb cada

Esta configuração dá uma largura de banda total de 880Mb. O gráfico abaixo mostra que os pacotes começam deixar cair da precedência 0 classes, e a latência para a Voz aumentou à Senhora 6 - milissegundos.

/image/gif/paws/22561/160mb.gif

Quatro fluxos de dados de 167 Mb cada

Esta configuração dá uma largura de banda total de 908Mb. As gotas estão começando agora para a precedência 1 classe também. A latência do tráfego de voz é ainda a mesma.

Nota: O córrego não foi parado antes de ser aumentado, assim que a diferença entre o número de gotas no córrego 0 e 1 é cumulativa.

/image/gif/paws/22561/167mb.gif

Quatro fluxos de dados de 191Mb cada

Quando a largura de banda total aumenta, os pacotes estão começando deixar cair também da fila da precedência 2. A largura de banda total que nós estamos tentando alcançar para a interface Gigabit Ethernet é agora 1004Mb. Isto é ilustrado nos contadores de erro de sequência no gráfico abaixo.

191mb.gif

Quatro fluxos de dados de 244 Mb cada

Os erros de sequência para a precedência 3 estão começando aumentar também. Este é o primeiro sinal que as gotas começarão dessa fila. A quantidade total de largura de banda que nós estamos tentando mandar a relação GbE é agora 1216 Mb. Note que as gotas no Multicast (MC) e a fila da Voz é ainda zero, e a latência da fila da Voz não aumentou.

/image/gif/paws/22561/244mb.gif

Parada e começar

Todos os córregos foram parados e começados gerar um gráfico que cancelasse contadores. Isto mostra como olhará durante a congestão pesada. Como você pode ver abaixo, o comportamento é desejado.

/image/gif/paws/22561/stop_start.gif

Todas as QoS removidas

Para mostrar que QoS melhora realmente o desempenho durante a congestão, QoS tem sido removido agora e a relação foi congestionada. Os resultados estão abaixo (o fluxo gerado usa os seguintes valores a menos que algo for indicado mais).

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

126Mb MC, 114Mb VoIP

Isto conduz a um fluxo de background de 240Mb (VoIP e Multicast).

Nós adicionamos então quatro fluxos de dados do mesmo tamanho, mas com precedência 0-3 (um valor de precedência pelo córrego).

Quatro fluxos de dados de 153 Mb cada

Isto dá um total de 852Mb. Há as gotas 0, e uma latência de menos então 50 pés nós.

/image/gif/paws/22561/153mb.gif

Quatro fluxos de dados com 158 Mb cada

Nós começamos deixar cair na utilização mais ou menos idêntica como quando o WRED é aplicado (872Mb). A diferença é agora que há uma latência dos pacotes de voz da Senhora 14 (mais de duas vezes tanto quanto no teste WRED), e que as gotas estão ocorrendo ingualmente de todas as classes, incluindo VoIP e o Multicast.

/image/gif/paws/22561/158mb.gif

Adicionando carga de ingresso

Até agora, todos os testes incluíram somente transmitir através das interfaces Gigabit Ethernet. Para verificar como a relação reage em uma situação onde nós igualmente congestionássemos a relação no outro sentido, os seguintes testes foram feitos.

Para este teste, nós carregamos a interface Gigabit Ethernet com uma quantidade total de 1056 Mb. Isto conduziu às gotas na precedência 0-2, nenhumas gotas no tráfego da precedência 3. (o MC e VOIP permaneceram o mesmo, isto é, nenhumas gotas). Nós adicionamos então o tráfego no outro sentido, tanto tráfego como o gerador de pacote podia mandar através da interface Gigabit Ethernet. O resultado é consideravelmente impressionante: a congestão de recepção não interfere de todo com a fila transmissora, e a latência para o tráfego de recepção é extremamente - baixa, menos de 13 nós para a Voz.

ingress_load1.gif

12-RP#show interfaces g 6/0

Você pode monitorar a carga no enlace de 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 que os resultados de teste não são devido à largura de banda que é os mesmos para todos os córregos, nós mudamos os córregos de modo que transmitissem quantidades diferentes de dados. Nós igualmente tentamos mudar a unidade de transmissão máxima (MTU) assim que era diferente para cada córrego. Com os valores de fila configurados, o resultado era ainda o mesmo, deixando cair a precedência 0 primeiramente, então 1, então 2, e ultimamente precedência 3.

stream_size.gif

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

Desde que a latência da fila de VoIP (a fila de latência baixa) no teste era razoavelmente alta, nós executamos o mesmo teste com 10-Port a placa de linha do Gigabit Ethernet Engine 4. Como esperado, o resultado com esta placa de linha era muito melhor em relação à latência na fila de latência baixa (LLQ). Os resultados eram os mesmos a propósito de como deixar cair ocorreu. A latência para o LLQ era em torno de 10us, que é 1:1000 da latência 3-Port na placa de linha do Gigabit Ethernet Engine 2.

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.


Informações Relacionadas


Document ID: 22561