WAN QoS (Frame Relay) - AutoQoS

Estava devendo esse post já há uns meses. No post que fiz em Janeiro sobre WAN QoS, abordei o MQC-Based, onde colocávamos o Traffic Shapping dentro de uma Policy-Map que era chamada pelo map-class frame-relay e etc, etc, etc. Na verdade, você só vai precisar configurar aquela forma de QoS se no enunciado ele for claro quanto a isso, ou se ele disser que você não pode usar o AutoQoS. Caso contrário, o jeito mais fácil e rápido de configurar o QoS na WAN é usando o nosso bom e velho amigo AutoQoS.


Então vamos para a primeira regra. SEMPRE antes de configurar qualquer coisa do seu auto qos, defina a banda do link na sua interface física. É baseado nesse valor que ele vai definir os seus parâmetros do Frame-Relay e do Traffic Shapping. Se você não colocar nada, ele vai considerar que a sua banda é de 1544Kbps, e aí ele não vai configurar o Traffic Shapping, pois ele só configura para links menores que 768Kbps.
Uma vez definida a banda na interface, entre na configuração do seu dlci e aplique um dos comandos abaixo:

auto qos voip trust

auto qos voip trust fr-atm

auto qos voip

auto qos voip fr-atm

Quatro comandos? Sim, quatro tipos de AutoQoS, e temos que saber bem a diferença entre eles... Mas é bem fácil! Os comandos com fr-atm configuram o AutoQoS usando MLPPP e os comandos sem o fr-atm configuram usando o FRF.12. Basicamente são duas formas de se configurar o LFI (Link Fragmentation and Interleaving). Então se o enunciado pedir MLP, coloque o fr-atm. Se pedir FRF.12, não coloque o fr-atm. Simples assim... Eventualmente no mesmo enunciado ele pode pedir para você configurar o link HQ - BR1 com MLP e HQ - BR2 com FRF.12... isso é perfeitamente possível. Em uma interface você configura com o fr-atm e na outra não. Bom, e o trust tá na cara, né? Com o trust ele vai confiar na marcação, e as suas class-maps vão dar match apenas no DSCP. Sem o trust ele não vai confiar na marcação vinda do Switch, e as suas class-maps vão reclassificar os pacotes novamente através de access-lists.

Vamos ver um pouco de configuração... fica mais fácil explicar:


Aplicando o AutoQoS

interface Serial0/0.1 point-to-point

 bandwidth 384                     ! -- Primeiro definimos a banda

 frame-relay interface-dlci 101    ! -- Depois aplicamos um dos

  auto qos voip trust              ! -- comandos de AutoQoS


Com o trust ou sem o trust?
Se você aplicar o trust no seu comando de auto qos, independente de usar ou não o fr-atm, a sua class-map ficará assim:
class-map match-any AutoQoS-VoIP-RTP-Trust
 match ip dscp ef
class-map match-any AutoQoS-VoIP-Control-Trust
 match ip dscp cs3
 match ip dscp af31
Repare que ele apenas deu match no DSCP e boa.

Se você não aplicar o trust, fica assim:

class-map match-any AutoQoS-VoIP-Remark ! -- Pode ignorar essa
 match ip dscp ef
 match ip dscp cs3
 match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
 match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
 match protocol rtp audio
 match access-group name AutoQoS-VoIP-RTCP

ip access-list extended AutoQoS-VoIP-Control
 permit tcp any any eq 1720
 permit tcp any any range 11000 11999
 permit udp any any eq 2427
 permit tcp any any eq 2428
 permit tcp any any range 2000 2002
 permit udp any any eq 1719
 permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
 permit udp any any range 16384 32767
Repare que agora ele criou umas access lists para classificar o tráfego de RTP e Sinalização. Eventualmente o enunciado pode pedir para você não usar Access Lists. Nesse caso seria só remover tudo isso e configurar as class-maps com NBAR (match protocol XXX).


MLP 
Para os exemplos, vou considerar links menores que 768Kbps. Porque se for maior que isso, tanto faz porque o roteador não vai configurar LFI.
Quando configuramos MLPPP, o roteador cria uma interface virtual chamada Vitual-Template. Se o enunciado pedir para configurar MLP, nem pense em criar isso na mão porque vai dar um trabalhão!!! Deixe que o AutoQoS faça tudo por você. Detalhe que geralmente é necessário um reboot no router depois de aplicar essa config, senão você perde acesso a tudo... um bom motivo para nunca deixar QoS para o final da prova, porque se você quebrar a WAN nos 47 do segundo tempo, meu amigo...
Bom, a configuração usando MLPPP vai ficar assim:

policy-map AutoQoS-Policy-Trust
 class AutoQoS-VoIP-RTP-Trust
  priority percent 70        ! -- Essa é a sua LLQ, que provavel-

                             ! mente você tenha que modificar
                             ! depois. --

  compression header ip rtp  ! cRTP. Eu que adicionei essa linha

                             ! Por padrão o AutoQoS não habilita

                             ! o Class-Based cRTP. Se a prova 

                             ! pedir, é assim que faz. --
 class AutoQoS-VoIP-Control-Trust
  bandwidth percent 5
 class class-default
  fair-queue

interface Serial0/0.1 point-to-point
 description Connection to BranchOffice1
 bandwidth 384
 snmp trap link-status
 frame-relay interface-dlci 101 ppp Virtual-Template200
  class AutoQoS-FR-Se0/0-101
  auto qos voip trust fr-atm

interface Virtual-Template200  ! -- O AutoQoS que configurou isso
 bandwidth 384
 ip address 10.10.10.1 255.255.255.252
 ppp multilink
 ppp multilink interleave
 ppp multilink fragment delay 10

 service-policy output AutoQoS-Policy-Trust

map-class frame-relay AutoQoS-FR-Se0/0-101
 frame-relay cir 384000     ! -- Aqui um detalhe. O SRND diz que
 frame-relay bc 3840        ! esses valores devem ser 95% do CIR. 
 frame-relay be 0           ! ou seja, no caso, 36480. Então  
 frame-relay mincir 384000  ! teriamos que alterá-los na mão.
                            ! Mas se a prova não disser nada, deixe
                            ! assim ou confirme com o Proctor. --

FRF.12
Configuração de FRF.12 é bem mais tranquila. Da até para fazer na mão, se quiser. Tipo, você configura o HQ com auto qos, copia as configurações modificadas e cola na outra ponta da sua WAN. É uma boa tática para economizar um pouco de tempo.

policy-map AutoQoS-Policy-Trust ! -- Mesma coisa que lá em cima
 class AutoQoS-VoIP-RTP-Trust
  priority percent 70

 class AutoQoS-VoIP-Control-Trust
  bandwidth percent 5
 class class-default
  fair-queue

interface Serial0/0.1 point-to-point
 description Connection to HQ
 bandwidth 384
 ip address 10.10.10.6 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 203
  class AutoQoS-FR-Se0/0-203
  auto qos voip trust
 frame-relay ip rtp header-compression ! -- Remova isso se for 

                                       ! usar  class-based cRTP --

map-class frame-relay AutoQoS-FR-Se0/0-203
 frame-relay cir 384000    ! -- Mesma coisa. Confirme com o 
 frame-relay bc 3840       ! Proctor se tem que seguir o SRND e
 frame-relay be 0          ! mudar esses valores para 95% --
 frame-relay mincir 384000
 frame-relay fragment 480
 service-policy output AutoQoS-Policy-Trust

Cálculo da Banda
Pode ser que a prova peça para você permitir na LLQ x chamadas usando G.729 por exemplo. Nesse caso, usar MLPPP ou FRF.12 vai mudar as suas contas. Se você usar MLPPP, o seu overhead de Layer 2 será de 13 bytes. Se usar FRF.12, o overhead é de 6 bytes, de acordo com o SRND. Então atenção com isso na hora de fazer as suas contas.
Se você tiver que configurar FRF.12 e MLPPP no mesmo router, tipo um para a comunicação HQ-BR1 e outra para HQ-BR2, e tiver que configurar bandas diferentes nas suas LLQs, vc vai precisar criar uma segunda Policy-Map e mudar no Virtual-Template.
Para mais informações sobre a continha para fazer o cálculo da banda, veja o meu primeiro post, do dia 30/12.