O QoS por túnel não limita o uplink total do seu hub

A crença soa como aritmética: cinco spokes, cada um moldado a 5 Mbit/s, portanto o hub transporta 25 Mbit/s no máximo. A primeira metade é verdadeira e a conclusão não. Uma política por túnel é aplicada uma vez por túnel, não uma vez por hub, e o uplink compartilhado por onde passam os cinco túneis nunca aparece nesse cálculo. O congestionamento no uplink sobrevive exatamente como estava.

De onde vem a crença

A confusão é compreensível, porque as informações de grupo NHRP permitem que uma definição de política se aplique a todo um conjunto de spokes. Isso se lê como um orçamento compartilhado num arquivo de configuração. O que realmente significa é que cada spoke recebe a sua própria instância dessa definição.

Assim, 5 Mbit/s por spoke é um teto por túnel, e há tantos tetos quantos túneis.

O que uma instância de política controla

O guia da Cisco de QoS por túnel no DMVPN no IOS XE descreve uma política de saída do hub selecionada por informações de grupo NHRP e aplicada separadamente a cada spoke. Dessa frase decorrem dois limites, e ambos são ignorados. A taxa pertence a um único spoke e não a um balde compartilhado, e o recurso governa o tráfego do hub para o spoke, não o contrário.

Planeje a direção de envio do spoke de forma independente. Nada numa política de saída do hub limita o que uma filial envia.

Coloque o limite agregado no gargalo compartilhado

O agregado tem de ser moldado onde realmente compete: na interface física que todos os túneis compartilham. A Cisco documenta um shaper class-default na interface física como a política física concorrente suportada para este recurso, o que é uma afirmação mais estreita do que qualquer hierarquia que você possa digitar. Presuma que a segunda política física arbitrária que você inventou não é suportada até que alguém prove o contrário.

Depois decida o que acontece quando todos os spokes estão ocupados ao mesmo tempo. Que tráfego é admitido, que classe tem prioridade e que fila detém a contenção. Um teto por spoke não responde a nenhuma dessas perguntas, porque cada spoke é considerado isoladamente.

Ajuste as unidades de modelagem e a contabilização de overhead à entrega real. O overhead de encapsulamento que você deixa fora do cálculo da taxa aparece como um link que satura antes do número configurado.

Os contadores mentem de uma forma específica

Leia os contadores na camada que você está moldando. O mesmo guia da Cisco adverte que os contadores de política da interface principal podem ser imprecisos nesta disposição. É uma ressalva sobre o contador, não uma prova de que uma classe esteja correspondendo ou descartando. Mantenha isso separado do resultado da aplicação, que é a única coisa que o usuário experimenta.

Copiar um exemplo antigo de traffic-shape ao lado de um mapa de políticas não relacionado não prova que as duas taxas controlam os mesmos pacotes.

Teste o agregado, não apenas o teto

Comece com um spoke ocupado e confirme que ele atinge o seu teto. Depois ofereça tráfego de todos ao mesmo tempo sob um plano aprovado, e observe a interface física ao lado dos números por túnel. Se cada spoke permanece no seu teto enquanto o uplink está saturado e a latência sobe, a política por spoke está funcionando exatamente como projetada e o orçamento continua errado.

A correção nesse ponto é uma decisão de capacidade ou de admissão. Reajustar os números por spoke só muda qual filial reclama primeiro.