Configurar a prioridade de QoS em roteadores baseados em ASR 920 e RSP2

Introduction

Este documento descreve como os roteadores ASR920/RSP2 lidam com prioridades de QoS e como configurá-las.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Roteadores ASR série 920
• Políticas de QoS

Componentes Utilizados

As informações neste documento são baseadas em um ASR 9xx com roteador RSP2 que executa a versão de software 16.x a 17.x.
Um gerador de tráfego é usado para testar as funções que manipulam pacotes de prioridade.

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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Problemas

Este documento aborda estes problemas específicos dos roteadores baseados em ASR 920 e RSP2:

• Pacotes de prioridade descartados na vantagem de pacotes de melhor esforço devido à limitação do ASIC em RSP2
• Como calcular o percentual de largura de banda a ser oferecido em uma classe

Pacotes de prioridade descartados com a vantagem dos pacotes de melhor esforço

Durante um teste, foi determinado que o pacote de prioridade pode ser descartado com a vantagem de um pacote de melhor esforço. Isso é aparente quando o tráfego de entrada chega por uma interface com velocidade mais alta do que a interface de saída e causa excesso de assinaturas na direção de saída. Por exemplo, quando 5 Gbps de tráfego são recebidos e precisam ser encaminhados através de uma interface de 1 Gbps.
Isso é igualmente verdadeiro para interfaces de saída configuradas com um modelador. Caso a velocidade de entrada seja maior que a CIR configurada na prioridade de saída, um pacote ainda poderá ser descartado com a vantagem de um pacote de melhor esforço.

Observação: há uma limitação de ASIC para a qual não podemos ter um filho prioritário para um pai não prioritário.

Se uma fila estiver configurada como expedita e seu sub-canal pai não estiver, haverá tremulação na fila de prioridade devido às latências de arbitragem no nível do sub-canal.

Solução

1. Configurar EFP
2. Aplicar um modelador no físico
3. Aplique o QoS desejado no EFP
4. Aplicar a conectividade IP na interface BDI

Exemplo:

configuration with issue 
-------------------------
interface GigabitEthernet0/0/0
description this is my egress interface 
service-policy output PM-1G-Out

configuration without issue 
---------------------------
interface GigabitEthernet0/0/0
description this is  egress interface
service-policy output POL-PRIO-MAIN-1G ==> shaper, useful to allow internal priority like BDF
service instance 200 ethernet
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
service-policy output PM-1G-Out ==> the original QoS previously applied in the physical interface
bridge-domain 200
!
interface BDI200 ==> BDI must match the bridge-domain defined under the service-instance
description this is  L3 egress
ip address 10.20.2.45 255.255.255.0 
ip mtu 9000
==> no QoS applied under the BDI, all QoS are in the service-instance with a backpressure of the shaper in the physical

Com essa configuração, todos os pacotes de prioridade foram priorizados corretamente e nenhum foi descartado com a vantagem de um pacote de melhor esforço, ainda assim você precisa calcular a largura de banda alocada corretamente.

Como calcular o percentual da largura de banda a ser oferecido em uma aula

A alocação de largura de banda na plataforma RSP2 também tem um comportamento específico. Muitas vezes, as quedas são vistas enquanto a QoS é configurada como em outras plataformas.

Por exemplo, se você configurar o QoS com um modelador de 2 Mbps em um roteador ASR1K, ele não cairá antes de 2 Mbps serem atingidos, nem enfileirará pacotes na classe. No entanto, isso acontece com RSP2.

Em muitos casos, a velocidade oferecida nem chega ao máximo permitido quando quedas já são vistas.

Este é um exemplo típico do que pode ser visto em um RSP2, enquanto os mesmos valores para o mesmo tráfego exato aplicado a outra plataforma não mostrariam nenhuma queda:

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    58803127 packets, 5488269944 bytes
    5 minute offered rate 279000 bps, drop rate 35000 bps

    Match: mpls experimental topmost 5
    Priority: 3% (297 kbps), burst bytes 37000, b/w exceed drops: 60373

    Priority Level: 1

O problema é devido à maneira como o tráfego é tratado no hardware. Basicamente, a implementação de hardware RSP2 não considera apenas a camada 3, mas todo o quadro, o que significa que todos os cabeçalhos são levados em conta.

RSP2 QoS Priority Test (Teste de prioridade de QoS RSP2)

Nesse caso, o tráfego CEM é usado para testar o comportamento de prioridade.

Este é um exemplo que mostra como configurar a prioridade para evitar quedas na vantagem do melhor esforço e ajustar a alocação de largura de banda.

Configuração

policy-map POL-PRIO-MAIN-1G
class class-default
shape average 8650000
!
policy-map PM-MPLS-1G-Out
class EXP-5
priority level 1 percent 4
class EXP-4
priority level 2 percent 24
class EXP-6
bandwidth percent 2
queue-limit 25000 us
class EXP-3
bandwidth percent 2
queue-limit 10000 us
class EXP-2
bandwidth percent 2
queue-limit 50000 us
class EXP-1
bandwidth percent 2
queue-limit 20000 us
class class-default
bandwidth percent 1
queue-limit 40000 us
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
service-policy output POL-PRIO-MAIN-1G
service instance 200 ethernet
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
service-policy output PM-MPLS-1G-Out
bridge-domain 200
!
interface CEM0/1/8
no ip address
cem 0
service-policy input PM-CEM-in
payload-size 128
dejitter-buffer 20
!
interface CEM0/1/9
no ip address
cem 0
service-policy input PM-CEM-in
payload-size 64
dejitter-buffer 16
!
interface BDI200
description path for qos stress
ip address 10.20.2.45 255.255.255.0
ip mtu 9000
ip router isis
carrier-delay msec 0
cdp enable
mpls traffic-eng tunnels
bfd template BFD-1hop-5ms
isis circuit-type level-2-only
isis network point-to-point
isis metric 15 level-1
isis metric 15 level-2
ip rsvp bandwidth percent 90
ip rsvp signalling hello graceful-restart

Tráfego

2 fluxos de tráfego são criados por CEM0/1/8 em vermelho e CEM0/1/9 em verde:

Podemos ver o comportamento com tamanhos de pacotes diferentes, CEM0/1/9 envia duas vezes mais pacotes que CEM0/1/8, que está configurado para 128 bytes.

Normalmente, uma configuração de QoS no RP considera somente o payload do CEM, enquanto o RSP2 considera todo o quadro.

Exemplo de quadro

Você pode ver 30 bytes a mais para o payload original configurado no CEM. Isso pode ser explicado como:

Ethernet header = 14 Bytes
Dot1q header    = 4 Bytes
Mpls header     = 4 Bytes
PW   Header     = 4 Bytes
CEM trailer     = 4 Bytes
Total           = 30 Bytes

Cálculo da largura de banda necessária no hardware, lembre que o quadro precisa ser considerado:

CEM 0/1/8 125 Packet/sec, size 128bytes ==> 125*128*8 = 128000 bps
CEM 0/1/9 250 Packet/sec, size 64bytes  ==> 250*64*8  = 128000 bps
on each frame we need an extra 30bytes  ==> 375*30*8  = 90000 bps
Total                                                 = 346000 bps

Para verificar o comportamento e a precisão do modelador na interface em que ele foi configurado para 8650000 bps, isso é feito para ter um valor exato de 4% para a classe de prioridade.

Cálculo: 346000,0000/8650000,0000 = 0,04 = 4%.

Isso é o que é visto na configuração acima. Os resultados confirmam que a configuração e o cálculo são precisos.

Saída da política:

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    3063745 packets, 285949512 bytes
    5 minute offered rate 279000 bps, drop rate 0000 bps
    Match: mpls experimental topmost 5
    Priority: 4% (346 kbps), burst bytes 8650, b/w exceed drops: 0

    Priority Level: 1

346 Kbps aplicados independentemente da plataforma são muito mais do que L3, mas são exatamente o tráfego L2.

Teste com gerador de tráfego

Gerador de tráfego —> interface TenGig —> Asr9xx RSP2 —> saída 1G onde a política é aplicada.

ASR903#show clock
22:54:40.976 CET Wed Nov 30 2022
ASR903#show ethernet service instance policy-map | inc Class-map:|drop rate
  Class-map: EXP-5 (match-all)
    5 minute offered rate 279000 bps, drop rate 0000 bps
  Class-map: EXP-4 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-6 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-3 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-2 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-1 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: class-default (match-any)
    5 minute offered rate 762348000 bps, drop rate 756024000 bps

ASR903#show clock
17:41:16.110 CET Thu Dec 1 2022
ASR903#show ethernet service instance policy-map | inc Class-map:|drop rate
  Class-map: EXP-5 (match-all)
    5 minute offered rate 279000 bps, drop rate 0000 bps
  Class-map: EXP-4 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-6 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-3 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-2 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-1 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: class-default (match-any)
    5 minute offered rate 762400000 bps, drop rate 756077000 bps

Após aproximadamente 18 horas, não houve uma única queda na prioridade, embora na interface haja muitas quedas, como visto na taxa de queda do padrão de classe, devido à CIR do limite do modelador.

Observe que o limite de fila padrão foi usado: para ajustar a largura de banda para suportar todo o tamanho do quadro l2, não é necessário ajustar as filas.

Teste negativo

            

Outro teste para verificar a boa precisão é omitir os 4 bytes do trailer CEM e ver se ocorrem pequenas quedas:

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    352466 packets, 32896848 bytes
    5 minute offered rate 279000 bps, drop rate 5000 bps
    Match: mpls experimental topmost 5
    Priority: 4% (334 kbps), burst bytes 8350, b/w exceed drops: 271

    Priority Level: 1

Como você pode ver, se você omitir uma parte desse quadro, ela causará quedas.

Conclusões

Esse teste com o tráfego CEM confirma que todo o quadro L2 precisa ser levado em consideração para o cálculo da largura de banda.

Um artifício é aumentar o limite de fila, mas claramente um cálculo correto do quadro L2 coloca menos estresse nos recursos de memória usados pela plataforma.

É óbvio que nem todo o tráfego pode ser previsto em cada ponto no tempo, como na transferência com tamanho de pacote variável. Para ter uma configuração precisa, você precisa levar em consideração os cabeçalhos de Ethernet, dot1q(s), tag(s) MPLS para o tamanho médio do pacote e também a taxa de pacotes.

Para qualquer tráfego que atravessa o ASIC de um RSP2, você precisa estar ciente de cada byte único contido em um quadro enviado para fora da plataforma (CRC não incluído).