terça-feira, 31 de janeiro de 2012

Device Mobility

Bom, chega de QoS (por enquanto). Hoje vou fazer um post sobre uma feature que dificilmente implantamos no dia-a-dia, mas pode ser testada na prova, que é o Device Mobility. Basicamente com essa funcionalidade, o CUCM identifica que o telefone foi mudado de localidade (através do IP), e aplica (ou não) configurações de um outro Device Pool.
Então vamos montar o nosso exemplo. Digamos que a nossa empresa tem três sites:
Site A: São Paulo, SP - Brasil - IP Subnet: 192.168.10.0/24 - Device Pool: DP_SPO
Site B: Curitiba, PR - Brasil - IP Subnet: 192.168.20.0/24 - Device Pool: DP_CBW
Site C: San Jose, CA - EUA - IP Subnet: 192.168.30.0/24 - Device Pool: DP_SJO

Para configurar o Device Mobility, trabalhamos com três entidades no CUCM: Device Mobility Group (DMG), Device Mobility Info (DMI) e Physical Location. Além, é claro, dos Device Pools.

Então primeiro vamos criar as Physical Locations, que são apenas "tags". Ou seja, elas sozinhas não fazem absolutamente nada:
PL_SPO, Physical Location - Sao Paulo
PL_CBW, Physical Location - Curitiba
PL_SJO, Physical Location - San Jose
E depois configuro elas nos Device Pools correspondentes.

Feito isso, vamos criar os DMIs, que são as nossas definições de Subnets. É aqui que vamos atrelar a subnet ao Device Pool.
DMI_SPO, 192.168.10.0/24, Roaming DP: DP_SPO
DMI_CBW, 192.168.20.0/24, Roaming DP: DP_CBW
DMI_SJO, 192.168.30.0/24, Roaming DP: DP_SJO
Obs: É possível associar mais de um device pool por DMI. Nesse caso o método de escolha do Device Pool durante o Roaming será via Round-Robin.


E agora vamos criar os DMGs, que também são apenas "tags". A idéia é tentarmos agrupar os devices que possuem o mesmo "numbering plan". Então eu criaria um DMG por pais, e depois entederemos o porque.
DMG-BRA, Device Mobility Group para o Brasil
DMG-EUA, Device Mobility Group para os EUA
E depois configuro eles nos Device Pools correspondentes.


Beleza, agora uma coisa importante. Precisamos habilitar o device mobility nos telefones. Isso pode ser feito no parâmetro Device Mobility Mode em cada device, ou no service parameter de mesmo nome, que por padrão é Off.


Agora vamos entender como isso funciona, e no que a feature pode nos ajudar.

Quando o telefone se registrar no CUCM, o fluxo será assim:
1. O endereço IP do telefone dá match com uma das Subnets configuradas no DMI? Se sim, vamos para o passo 2, se não, ele sobe com o "Home DP".

2. Comparo a Physical Location do Home DP com a do Roaming DP (que ele pegou lá ao dar o match em um DMI). Se for igual, o telefone sobe com o Home DP, porque ele pode por exemplo ter mudado de subnet dentro do mesmo prédio. Se for diferente, sigo para o passo 3.

3. Seleciono do Device Pool do DMI que ele deu match na subnet (Roaming DP).

4. Comparo do DMG do Roaming DP com o DMG do Home DP. E aqui que está o mais importante... Caso o DMG seja igual, ele só vai aplicar as configurações no quadro "Roaming Sensitive Settings" do Device Pool, que é o DTG, Region, MRGL, Location, Network Locale, SRST.
Caso o DMG seja diferente, ele vai aplicar também as configurações no quadro "Device Mobility Related Information", que contém a CSS, AAR, CgPTP, CdPTP.

Isso significa que se um telefone de São Paulo se registrar pela subnet de Curitiba, o device vai pegar as configurações apenas relativas a codec, media resources, data/hora, SRST... ou seja, não vai mudar nada para o usuário em questão de roteamento de chamadas. Ele vai continuar fazendo as chamadas da forma que ele está acostumado a fazer em São Paulo, e as chamadas continuarão saindo por SP.
Agora, se esse mesmo telefone se registrar em San Jose, ele vai alterar a CSS e os transformation patterns (Calling e Called). Ou seja, todo o seu dial plan vai ser alterado para esse phone! Ele terá outra CSS no device level (útil se usarmos o Device-Line approach), e terá todas as transformations alteradas... não vou entrar a fundo nisso porque envolveria a questão do dial plan, e aí poderia ficar horas e horas falando sobre isso. Mas para quem já tem uma noção de dial plan, já deu pra sacar o estrago que pode essa feature pode fazer, né? Um prato cheio para cair na prova e nos deixar mais loucos ainda com o Dial Plan...

quarta-feira, 18 de janeiro de 2012

WAN QoS (Frame Relay) - MQC-Based

Agora que já abordamos o QoS na LAN, é hora de falar sobre o QoS na WAN. O post é mais voltado para a prova, então estou considerando um link Frame Relay inferior a 768kbps. E nesse post usarei o "Class Based Shaping", que não é o que o AutoQoS configura... Num post futuro eu falarei mais sobre o FRTS antigo.
A primeira coisa a se fazer ao configurar o QoS é classificar os pacotes. E o jeito mais prático de se fazer isso é usando NBAR. Com essa feature é possível dizer para o roteador inspecionar o pacote e determinar se este é algum que estamos procurando para marcação:

class-map match-any RTP
 match protocol RTP
class-map match-any SIG
 match protocol SIP
 match protocol H323
 match protocol Skinny

Com essas regras já definimos class-maps que classificam pacotes de voz (RTP) e de sinalização.
Pelo NBAR também é possível criar uma regra customizada. Por exemplo, se eu quiser pegar tráfego de JTAPI, posso criar a regra:
ip nbar port-map custom-01 tcp 2748
E aplicar no meu class-map SIG: match protocol custom-01

Depois de criadas as regras de classificação, colocamos dentro de um Policy Map:

policy-map LLQ
 class SIG
  bandwidth percent 5
 class RTP
  priority percent 40
 class class-default
  fair-queue

O que estamos fazendo aqui é alocar 5% da banda para sinalização, e 40% para voz, colocando o tráfego RTP em uma LLQ (Low Latency Queue). Essas percentagens são relativas ao bandwidth da interface física ou ao traffic shapper, como veremos a diante. Atenção: Como em links Frame Relay criamos sub-interfaces, não adianta colocar o bandwidth na sub-interface que esse percent vai ser calculado em cima do bandwidth da interface física!

Criada a policy-map, vamos aplicá-la em uma outra policy-map que fará o traffic shape. A policy se chamará GTS (Generic Traffic Shape). Assim:

policy-map GTS
 class class-default
   shape average 364800 3648 0
  service-policy LLQ

Aqui estou considerando um link de 384kbps. De acordo com o SRND de QoS da Cisco, o shape deve ser feito em 95% do seu CIR, por isso configurei o valor em 364800 (bps), e bc (commited burst) deve ser o valor divido por 100. E o excess burst (be) vou deixar em 0. Com o shape configurado, aquelas percentagens la na policy-map LLQ agora vão ser referentes aos valores configurados no shape.

Agora eu vou aplicar essa policy-map em uma map-class:
map-class frame-relay FR-MC
 service policy output GTS
 frame-relay fragment 480

Dentro da map class eu configuro o link fragmentation, que a Cisco recomenda para links menores do que 768kbps. O tamanho do fragmento pode ser calculado assim (de acordo com o SRND):
Fragment_size = (PVC Speed * 10) / 8

Agora sim, finalmente, eu aplico o map-class na minha sub-interface do Frame Relay:
interface s0/0/0:0.1 point-to-point
 frame-relay interface-dlci 101
  class FR-MC

Resumindo, temos a seguinte hierarquia:
Interface --> Map-Class --> GTS Policy --> Policy-Map --> Class-Map

quinta-feira, 5 de janeiro de 2012

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! =)

segunda-feira, 2 de janeiro de 2012

LAN QoS, parte 1

Bom, QoS na LAN todo mundo sabe configurar, né? "auto qos voip cisco-phone" e boa, o Switch faz tudinho pra você, seguindo as melhores práticas da Cisco. Inclui um monte de configurações automaticamente e tudo funciona perfeitamente bem. Mas para a prova, não basta saber só isso... temos que entender exatamente o que o Switch configura para você com o auto qos, para podermos modificá-lo do jeito que o enunciado pedir.
Para esse post, utilizarei como base um 3750, que é o que teremos na prova. Para outros modelos de switch, algumas coisas podem ser diferentes.
Quando aplicamos o auto qos, o switch inclui as seguintes configurações (dentre outras, que mostrarei em outro post):

mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue input bandwidth 90 10
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66
mls qos srr-queue input buffers 67 33
mls qos srr-queue input cos-map queue 1 threshold 2 1
mls qos srr-queue input cos-map queue 1 threshold 3 0
mls qos srr-queue input cos-map queue 2 threshold 1 2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3 3 5
mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue input dscp-map queue 1 threshold 3 32
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61

Vamos tentar entender o que é tudo isso...
Primeiramente é preciso saber que o 3750 trabalha com 2 filas de entrada e 4 filas de saída por porta. Vamos pensar primeiro na entrada, ou seja, quando o pacote chega no switch. Nesse momento ele pode ser colocado em uma das duas filas de entrada (ingress). Os parâmetros dessas filas são definidas nos comandos (obs: L1, L2, L3 e L4 não fazem parte do comando. É só para identificar a linha):
L1. mls qos srr-queue input bandwidth 90 10
L2. mls qos srr-queue input threshold 1 8 16
L3. mls qos srr-queue input threshold 2 34 66
L4. mls qos srr-queue input buffers 67 33
Com isso estamos dizendo que vamos alocar 90% da banda para a fila 1 e 10% da banda para a fila 2 (L1), e dividiremos o buffer de memória em 67% para a fila 1 e 33% para a fila 2 (L4). Com isso determinamos o quanto de dados podem ser armazenados na fila antes que os pacotes comecem a ser droppados na interface. Além disso, definimos também alguns thresholds para cada fila (L2 e L3): para a fila 1, temos o primeiro threshold em 8% e o segundo em 16%; e para a fila 2 temos o primeiro threshold em 34% e o segundo em 66%. Para as duas filas existe também um terceiro threshold em 100% (não configurável). Isso quer dizer que se colocarmos um tráfego na fila 1, threshold 1, por exemplo, quando ele atingir os 8% da fila, começará a ser droppado (WTD - Weighted Tail Drop). Mas para isso, precisamos separar os pacotes nas filas/threshold, de acordo com a sua marcação de CoS e DSCP. Esse mapeamento é feito pelos comandos:  
L1. mls qos srr-queue input cos-map queue 1 threshold 2 1
L2. mls qos srr-queue input cos-map queue 1 threshold 3 0
L3. mls qos srr-queue input cos-map queue 2 threshold 1 2
L4. mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
L5. mls qos srr-queue input cos-map queue 2 threshold 3 3 5
L6. mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
L7. mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
L8. mls qos srr-queue input dscp-map queue 1 threshold 3 32
L9. mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
L10. mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
L11. mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
L12. mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
L13. mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
L14. mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
De L1 a L5, fazemos o mapeamento baseado no CoS. Tipo, Cos 1 vai para a fila 1, threshold 2; Cos 0 vai para fila 1, threshold 3; CoS 3 e 5 vão para a fila 2 threshold 3... E de L6 a L14 fazemos o mapeamento baseado no DSCP. Tipo, DSCP 46 está na fila 2, threshold 3. (obs:Quando muitos DSCPs estão mapeados na mesma fila e threshold, o switch quebra a config em várias linhas, mas é como se estivesse tudo numa linha só. Ex: L13 e L14 são mapeamentos da fila 2, threshold 3).
Beleza, agora vamos ver as filas de saída (egress). O 3750 trabalha com 4 filas de saída para cada interface, que vamos chamar de Q1, Q2, Q3 e Q4. E para cada fila podemos configurar também 2 thresholds (e existe mais um terceiro fixo nos 100%). A diferença é que nas filas de saída os thresholds podem ficar acima dos 100%, pois ele usará a memória do switch alocada para a interface.  As filas e thresholds são configuradas por esses comandos:  
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242
Queue-sets são como se fossem templates. O 3750 deixa você configurar 2 templates, e a Cisco recomenda que você mexa apenas no template 2. Isso porque se você fizer alguma cagada, pode simplesmente voltar para o template 1 e tudo estará bem. Para aplicar um queue-set em uma interface, basta entrar na config dela e aplicar queue-set 1 ou queue-set 2. Nos queue-sets definimos os thresholds de cada fila. Mas nos comandos podemos ver que na frente do ID da fila temos 4 parâmetros. Se eu disse que só configuramos 2 Thresholds, o que são os outros dois? A sintaxe do comando é a seguinte:
mls qos queue-set output <queue-set id> threshold <queue-id> <T1> <T2> <Reserved> <Maximum>

Para entender isso é preciso saber que o 3750 reserva um buffer de memória para cada fila de cada interface (reserved buffer pool). Quando a fila não usa essa memória, ela vai pro common buffer pool, e fica disponível para outras filas. Meio complicado mesmo, faz parte da arquitetura do switch. Mas o importante é saber que depois de definir os thresholds (T1 e T2), definimos quantos % da memória reservada para a fila eu vou garantir para ela. É a memória que vou deixar reservada para ela. Já o outro parâmetro, Maximum, é o máximo de memória que eu vou poder alocar para essa fila, usando o common buffer pool. E finalmente, esses comandos dividem o buffer da porta entre as 4 filas (a soma da 100%):
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61
Bom, mas agora falta jogarmos os tráfegos classificados dentro das filas e thresholds. Lembrando que para o Switch 3750, a fila de maior prioridade (PQ) é a fila 1! Mas isso muda de switch pra switch, já vi alguns que a Priority Queue é a 4. Vai saber pq a Cisco faz isso... Para mapear o tráfego nas filas é igual fizemos nas de entrada:
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7

Eu sei, esse post ficou enorme, cansativo e dificil! Vou tentar fazer um exemplo... Digamos que a gente tenha esse mapeamento:
mls qos srr-queue output cos-map queue 2 threshold 1  3
mls qos srr-queue output cos-map queue 2 threshold 2  4 5


E configuramos esses thresholds para a fila 2:
mls qos queue-set output 1 threshold 2 40 70 90 400

Quer dizer que quando o buffer da fila 2 estiver em 40% (T1), ela vai começar a droppar o tráfego marcado com CoS 3, mas não o tráfego marcado com CoS 4 e 5, porque estes estão mapeados no T2, que está em 70%.
Digamos agora que a gente tenha o seguinte buffer configurado:
mls qos queue-set output 1 buffers 15 45 20 20
Para a fila 2, configuramos 90% de reserved e 400 de maximum. Isso significa que reservaremos 90% do buffer da fila 2 (isto é, 45% da memória da porta). Então teremos garantido para essa fila 90% dos 45% de memória da porta. Os outros 10% ficarão no common buffer pool e poderá ser usado pelas filas 1, 3 e 4. Assim como as outras filas também podem ter deixado uma sobrinha no common buffer pool.

Agora só ficou faltando falar sobre esse comando:
mls qos map cos-dscp 0 8 16 24 32 46 48 56  
Esse é fácil. É simplesmente como o switch vai fazer o mapeamento de CoS para DSCP, como expliquei no post passado. Nesse caso o switch vai mapear CoS 0 com DSCP 0, CoS 1 com DSCP 8, CoS 2 com DSCP 16, CoS 3 com DSCP 24 (Voice Signaling!), CoS 4 com DSCP 32, CoS 5 com DSCP 46 (RTP!), CoS 6 com DSCP 48 e CoS 7 com DSCP 56.  

Caraca, esse post ficou todo confuso... mas espero que tenha ajudado!

Fundamentos de QoS - Marcação de pacotes (parte 1)

QoS para mim é um dos temas mais complicados da prova, porque hoje em dia, na vida real, o Auto QoS já resolve todos os nossos problemas na LAN (geralmente), e a WAN acaba ficando sob responsabilidade da operadora, por não termos acesso ao roteador de borda da MPLS. Então acabo não exercitando tanto assim o QoS no dia-a-dia. Esse tópico abordará conceitos bem básicos sobre marcação de pacotes em Layer 2 e Layer 3.

A marcação em Layer 2 chama-se CoS (Class of Service), e ela utiliza campos do cabeçalho Ethernet quando o 802.1Q está habilitado. O campo TPID do 802.1Q possui 2 bytes (16 bits), e os 3 primeiros (chamados de user-priority) são os que usamos para a marcação do CoS. Dessa forma, com esses 3 bits, é possível definir 8 valores para o CoS:

000: Best Effort (CoS 0)
001: Bulk Data (CoS 1)
010: Critical Data (CoS 2)
011: Call Signaling (CoS 3)
100: Video (CoS 4)
101: Voice (CoS 5)
110: Routing (CoS 6)
111: Reserved (CoS 7)

Desses, o importante é sabermos que o CoS 3 é usado para sinalização e o CoS 5 para voz (RTP). É assim que o telefone IP marca os seus pacotes por default, por exemplo.

A marcação em Layer 3 chama-se ToS (Type of Service), e utiliza 8 bits do cabeçalho IP. Desses 8 bits, os 3 primeiros são chamados de IP Precedence. E com os 6 primeiros bits (utilizando também os 3 bits do IP Precendence), formamos os DSCPs. Os outros dois bits são usados para ECN (Explicit Congestion Notification).

O interessante dessa marcação é que o IP Precedence é compatível com os 3 bits do CoS. Então quando no CoS está marcado 101 por exemplo (CoS 5), o IP Precedence também será 101 no cabeçalho IP (Precedence 5). Dessa forma, é possível estabelecer uma relação entre as marcações de L2 e L3. Cos 0 = Precedence 0, CoS 1 = Precedence 1, CoS 2 = Precedence 2, e assim por diante.

Agora juntando os DSCPs na jogada, vamos começar a utilizar os outros 3 bits. Quando os 3 bits seguintes são 000, formamos a classe CSx do DSCP:
CS1 = Precedence 1 = 001000 = DSCP 8
CS2 = Precedence 2 = 010000 = DSCP 16
CS3 = Precedence 3 = 011000 = DSCP 24
CS4 = Precedence 4 = 100000 = DSCP 32
CS5 = Precedence 5 = 101000 = DSCP 40
CS6 = Precedence 6 = 110000 = DSCP 48
CS7 = Precedence 7 = 111000 = DSCP 56

Agora, mexendo com os valores dos 3 bits à direta, formamos a classe AFxy (Assured Forwarding), onde x é o IP Precedence e y é a preferência no descarte de pacotes em caso de congestionamento (utilizado em algoritmos de Congestion Avoidance como o WRED). Quanto maior o y, maior a preferência de descarte desse pacote.
O precedence (x) varia de 1 a 4, e drop preference (y) de 1 a 3. Assim, temos os seguintes valores possíveis:
AF11 = 001010 = DSCP 10
AF12 = 001100 = DSCP 12
AF13 = 001110 = DSCP 14
AF21 = 010010 = DSCP 18
AF22 = 010100 = DSCP 20
AF23 = 010110 = DSCP 22
AF31 = 011010 = DSCP 26
AF32 = 011100 = DSCP 28
AF33 = 011110 = DSCP 30
AF41 = 100010 = DSCP 34
AF42 = 100100 = DSCP 36
AF43 = 100110 = DSCP 38

Dica: Uma maneira rápida de calcular o valor do DSCP é fazer 8x + 2y!

Bom, mas se no AF o IP Precedence varia de 1 a 4, o que acontece quando o precedence for 5, que é justamente como os pacotes de voz são marcados? Aí temos a classe EF (Expedited Forwarding), DSCP 46, 101110. Por padrão os telefones marcam os seus pacotes de voz como ef (DSCP 46). Inclusive, quando você configura um auto qos no switch, pode reparar que ele faz o mapeamento do cos-dscp colocando o cos 5 como dscp 46 ao invés de 40.

Além desses, temos também o DSCP 0, que é o BE (Best Effort).

Mas lembre-se que isso é só marcação de pacote. Num adianta nada você marcar tudo e não aplicar as regras (policy) devidas para cada classe de tráfego. Mas isso é assunto para um outro post.