LAN QoS, parte 2

Continuando com a segunda parte de QoS na LAN, além das linhas mostradas no post anterior, o Auto QoS também adiciona os seguintes comandos:

mls qos map policed-dscp 24 26 46 to 0

class-map match-all AutoQoS-VoIP-RTP-Trust
 match ip dscp ef
class-map match-all AutoQoS-VoIP-Control-Trust
 match ip dscp cs3 af31

policy-map AutoQoS-Police-CiscoPhone
 class AutoQoS-VoIP-RTP-Trust
  set dscp ef
  police 320000 8000 exceed-action policed-dscp-transmit
 class AutoQoS-VoIP-Control-Trust
  set dscp cs3
  police 32000 8000 exceed-action policed-dscp-transmit

interface FastEthernet 0/1
 srr-queue bandwidth share 10 10 60 20
 priority-queue out
 mls qos trust device cisco-phone
 mls qos trust cos
 auto qos voip cisco-phone
 service-policy input AutoQoS-Police-CiscoPhone

Vamos começar pela interface. Existe um "erro" aqui que confunte as pessoas. Após colocarmos o comando de Auto QoS (auto qos voip cisco-phone), que dá origem a todas essas linhas de configuração mostradas nesse tópico e no anterior, a interface ficará com esses dois comandos:
mls qos trust device cisco-phone
mls qos trust cos
Isso é um trust condicional. Ou seja, a primeira linha diz que eu vou confiar no device conectado a esta porta apenas se ele for um Cisco Phone (o switch descobre isso através do CDP). Aí caso o device seja mesmo um telefone, o switch aplica a regra da segunda linha (mls qos trust cos). Então o que essas duas linhas querem dizer é que o switch vai confiar no CoS de tráfegos vindos de Telefones apenas. É possível mudar esse comportamento para o switch confiar no DSCP ao invés do CoS, basta alterar esse comando para mls qos trust dscp. E lembrando que por padrão, tudo o que estiver vindo de trás do telefone (PC Port), o switch remarcará como CoS 0. Isso pode ser alterado através do switchport priority extend cos X.
PORÉM, quando você tem um service-policy aplicado na interface, como é o caso aqui, isso não funciona. O service policy tem prioridade sobre o trust. Então é um ou outro... ou você deixa a porta como trust, ou você aplica um service policy.


Uma outra linha que o switch coloca na interface é o priority-queue out. Isso é para ativar uma das filas como PQ, para comportar tráfegos real time, como o de voz. No 3750, como falei anteriormente, a PQ é a fila 1. Mas isso muda de switch para switch... Se esse comando não for colocado na interface, o switch vai considerar a fila 1 como uma fila normal.

A linha srr-queue bandwidth share 10 10 60 20 já é um pouco mais complexa. O switch pode alocar a banda nas filas de duas formas: shared ou shaped. No auto qos ele configurou como shared.
A alocação "shared" é uma alocação relativa. Por exemplo, se a gente configurar os valores como 10 10 60 20 (como o auto qos faz), temos a soma 10+10+60+20 = 100 (é mais fácil fazer com a soma dando 100, mas não é obrigatório, pois esses valores são pesos e não percentuais). Então temos os seguintes pesos para cada fila dessa interface: 10/100, 10/100, 60/100 e 20/100. Multiplicando esse valor pelo speed da porta, obtemos a banda "GARANTIDA" para cada fila. Por exemplo, nesse caso a fila 1 teria 10/100 * 100Mbps (considerando a porta como 100Mbps) = 10Mbps garantidos numa situação de congestionamento.
Obs: Se a priority-queue estiver habilitada na interface, a primeira fila não entra na soma. Portanto as alocações nesse caso ficariam 10/90 para a segunda fila, 60/90 para a terceira e 20/90 para a quarta.
Ja o modo "shaped", ao invés de fazer garantia de banda, faz restrição de banda (policing), e o cálculo é feito com o inverso do valor configurado. Por exemplo, se configurarmos srr-queue bandwidth shape 30 0 0 0, estamos restringindo a banda da Fila 1 para 1/30 da banda da porta. No caso de uma porta 100Mbps, seria 1/30 * 100 = 3,33Mbps. Quando o valor está em 0 quer dizer que o shape não será aplicado.
Se utilizamos os dois modos simultaneamente, o shape toma precedencia caso configurado. Por exemplo:
srr-queue bandwidth share 100 100 40 20
srr-queue bandwidth shape 50 50 0 0
A fila 1 e 2 terão o shape ativo, e numa interface 100Mbps, receberão 2Mbps de banda cada. E as filas 3 e 4, como não possuem o shape ativo, farão o cálculo do share na proporção 2:1 (sem considerar as filas 1 e 2) utilizando o restante da banda da porta (100 - 2 - 2 = 96Mbps).

Bom, e por fim a linha  service-policy input AutoQoS-Police-CiscoPhone habilita nesta interface o Policy-Map criado no AutoQoS:
policy-map AutoQoS-Police-CiscoPhone
 class AutoQoS-VoIP-RTP-Trust
  set dscp ef
  police 320000 8000 exceed-action policed-dscp-transmit
 class AutoQoS-VoIP-Control-Trust
  set dscp cs3
  police 32000 8000 exceed-action policed-dscp-transmit
O que esse Policy-Map faz é pegar todo o tráfego de voz (classificado no class-map AutoQoS-Police-CiscoPhone) e forçar a marcação deles como ef (que na prática não fez nada, porque os pacotes já estavam marcados como ef), e fazer um Police de 320kbps com 8kbps de burst. O que exceder, ele vai passar para frente, mas remarcando o dscp, como veremos daqui a pouco.
E para o tráfego de sinalização (classificado no class-map AutoQoS-VoIP-Control-Trus), ele vai forçar a marcação cs3 (porque pelo class-map, ele dá match tanto em cs3 como em af31), e fazer o mesmo police, mas de 32kbps e 8kbps de burst. E o que passar, ele vai passar para frente remarcando o DSCP.

E o que faz a classificação dos pacotes são os Class-Maps:
class-map match-all AutoQoS-VoIP-RTP-Trust
 match ip dscp ef
class-map match-all AutoQoS-VoIP-Control-Trust
 match ip dscp cs3 af31
Tudo que for DSCP ef ele classifica como RTP (voz) e tudo que for cs3 ou af31 ele classifica como sinalização.

Bom, voltando uns parágrafos, quando eu falei que o que passasse da regra do Police ele passaria para frente remarcado o DSCP, isso é porque no exceed-action ele configurou a regra policed-dscp-transmit. O policed-dscp é uma linha que foi definida lá em cima, junto com aqueles comandos de mls qos do post anterior:

mls qos map policed-dscp 24 26 46 to 0

Essa regra está dizendo que ele vai verificar os pacotes com DSCP 24, 26 ou 46 e remarcá-los para 0, em caso de o policy-map fazer o police. Ou seja, no caso dos pacotes de voz, se passar os 320kbps, ele não vai droppar... vai passar para frente, mas com DSCP 0, e logo recebendo tratamento de best effort, indo lá pra fila 4.

E é isso aí, destrinchamos as configurações do Auto Qos! =)