Minha jornada até o CCIE RS — QoS 2
E aí galera, belezinha?
Voltamos aqui mais uma vez para continuar esta jornada de artigos onde eu compartilho centenas de páginas de anotações e informações acumuladas ao longo de 15 anos trabalhando com Routing and Switching. Como sempre digo, acredito que estas informações possam ajudar não somente para seus estudos para certificações, mas no dia-a-dia de outros network engineers que lidam com topologias de redes Cisco.
Para quem não leu os artigos anteriores dessa jornada, seguem os links: “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP”, “OSPF”, “BGP” e “Redistribuição”, “MPLS”, “DMVPN — Parte 1”, “DMVPN — Parte 2”, “DMVPN — Parte 3”, “DMVPN — Parte 4”, “IPv6” e “QoS — Parte 1”.
No artigo anterior exploramos de forma geral Quality of Service. Hoje vamos explorar os principais mecanismos de QoS!!! Então traga seu cafézinho e bora começar.
Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a dar “claps” aí do lado esquerdo do artigo e compartilhar nos seus grupos. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)
QoS Tools
FIFO
É o método mais simples e mais fácil de implementar onde o único parâmetro é queue-depth, que define o tail drop. FIFO geralmente é utilizado como parte de outras soluções (ex: HQF).
OBS: Clock-rate é uma função física da interface e define a velocidade que o tx-ring opera serializando os pacotes.
Queueing é responsável por atrasar os pacotes e somente é utilizado se o TX-ring está cheio (contenção de link). Se o TX-ring não está ocupado, o pacote é encaminhado diretamente para ele, sem passar pela Output Queue.
Fair-Queueing (ou max-min scheduling)
Opera de modo que múltiplos fluxos compartilhem o link igualmente. Os fluxos que necessitam mais BW dividem a que não foi utilizada pelos fluxos menores sucessivamente.
Ex: O bolo de chocolate é dividido igualmente entre os irmãos e se algum deles não quiser, o pedaço dele é dividido entre os que querem.
Weighted Fair Queue (WFQ)
- Utiliza max-min scheduling, mas de forma desigual alocando BW para os fluxos proporcionalmente ao peso deles, determinado pelo DSCP/IP Prec.
- WFQ define os fluxos dinamicamente usando:
- Source-Destination IP + Source-Destination Port + ToS Byte
- Peso é definido como IP Prec+1.
- Se o número de fluxos for maior que o número de queues definidas, as queues são compartilhadas.
Ex: O bolo de chocolate é dividido entre os irmãos e os pedaços são diretamente proporcionais a idade.
Class-Based Weighted Fair Queue (CBWFQ ou HQF)
Permite a definição de fluxos através de classes usando MQC e o peso da classe através de parâmetro bandwidth (absoluto kbps ou relativo %).
- Bandwidth configurada para cada classe é chamada Reservation.
- Toda BW não reservada para alguma classe é reservada para a Class-Default.
- O router calcula a soma de reservas definidas para cada classe de modo que não exceda 100% da BW da interface.
- Class-default tem garantido pelo menos 1% da BW da interface.
- Cada class no HQF é tratada como FIFO por default, mas pode ser alterado para WFQ compartilhando a BW proporcionalmente ao peso do fluxo (DSCP).
- Daí o termo HQF (Hierarchical Queueing Framework), permitindo mecanismos de queuing em hierarquia um dentro do outro.
- A reserva configurada para cada classe significa uma garantia mínima de BW (não confundir com policing).
- Toda BW não utilizada por uma classe é compartilhada pelas outras.
Low-latency Queueing (LLQ)
Reoderna a output queue e encaminha o tráfego definido para a TX-ring através de uma Priority Queue. A Priority Queue sempre é esvaziada primeiro e tipicamente utilizada para tráfego low-BW (geralmente VOIP).
- LLQ é derivado do legado mecanismo Priority Queueing que também fornecia prioridade a uma determinada classe de tráfego e através de reordenação constante poderia causar starvation das outras classes.
- LLQ é implementado com Policing que é utilizado em momentos de contenção da TX-Ring. Se a taxa configurada no Policing é ultrapassada mas não há contenção, o tráfego é encaminhado através da Output Queue (mas sem prioridade); se houver contenção, o tráfego excedente é descartado.
- OBS: Também existe opção de implementação sem Policing, mas dificilmente é usado porque pode causar starvation das outras classes.
Classes diferentes podem ser declaradas com LLQ onde o único propósito é utilizar Policing com taxas diferentes. Ambas utilizarão a mesma Priority Queue da interface e nenhuma receberá prioridade sobre as outras, porém serão limitadas às suas respectivas taxas.
Remaining Bandwidth é geralmente utilizado com LLQ, considerando a BW restante após alocação da LLQ: Remaining = Inteface BW — LLQ BW.
OBS: Se uma Policy possuir uma classe configurada com strict priority (sem policing definido) as outras classes só poderão especificar reservas através de <remaining bandwidth> (parâmetro <bandwidth> sozinho nem é aceito).
Bandwidth-Remaining é calculada sobre a BW configurada (e não clock) na interface. Portanto, tomar cuidado neste aspecto quando a BW garantida for diferente da BW da interface.
DOC: “QoS: Congestion Management Configuration Guide” -> Multi-Level Priority Queues
Weighted Random Early Detection (WRED)
- WRED é um mecanismo de congestion avoidance e não de congestion management (queueing).
- Derivado do antigo mecanismo RED.
- A função do WRED é descartar pacotes randomicamente da Output Queue antes dela encher, prevenindo contra sincronização do TCP ou Global Synchronization (problema que ocorre com tail drop).
WRED monitora a profundidade da queue (tamanho da fila). avg=(old_avg*(1–1/2^n))+(q_size*1/2^n)
- Pacotes são descartados baseados no Mark Probability Denominator (MPD) onde: Probabilidade = 1/MPD
- Probabilidade de descarte aumenta conforme o tamanho da fila cresce. Se a fila atingir seu limite ocorre tail drop.
- Quanto maior a marcação do pacote menor é a probabilidade de ser descartado porque usa um min-threshold mais alto.
OBS: CS6 e CS7 são geralmente utilizados para tráfego de Control Plane e portanto possuem menor probabilidade de descarte.
DOC: “Understanding How Routing Updates and Layer 2 Control Packets Are Queued on an Interface with a QoS Service Policy”. Explica como o Control Plane é processado de forma diferente do Data Plane, através de tags como pak_priority.
WRED confia no processo de janela deslizante do TCP para evitar o problema de Sincronização Global. Por isso, WRED não surte efeito (melhoria) em ambientes com maior parte do tráfego UDP.
OBS: Teste prático para checar classificação é disparar pings com TOS (especificado em decimal, não em HEX)
Traffic Shaping
Objetivo do Shaping é normalizar o tráfego outbound atrasando e enfileirando o tráfego que exceder uma taxa definida, diminuindo a velocidade de transferência Output Queue -> TX-Ring.
Traffic Shaping é necessário quando a taxa de serialização da TX-Ring outbound (clock rate) de um lado é maior que a taxa de policing inbound do outro lado (ex: Foi contratado link de 15 Mb servido através de um link fast-ethernet. Neste caso pode ter até 85 Mb descartados constantemente… gerando enorme taxa de retransmissão desnecessária).
IOS mede a taxa de tráfego contra o valor pré-definido e atrasa somente o tráfego definido. Obviamente, se o buffer encher o excedente é descartado.
Time Committed (Tc)
Controla a frequência com que o shaping ocorre a cada segundo. Intervalo de tempo em ms que é permitido envio de bursts usando sempre Access Rate (AR) (clock rate).
Burst Committed (Bc)
Total de tráfego que poderia ser enviado a cada Tc para alcançar a taxa média/segundo: Taxa/1 seg = Bc/Tc
Burst Excessive (Be)
Total de tráfego além do Bc que pode ser enviado durante Tc se houver crédito acumulado.
OBS: Importante ponto sobre Traffic Shaping é que, não importa quanto tráfego seja enviado por Tc (burst), nunca se pode exceder a taxa/seg.
Fórmulas de Shaping
- AIR = Access Information Rate (clock rate)
- CIR = Committed Information Rate (CIR)
- — CIR = Bc/Tc = taxa média (velocidade do link)
- EIR = Excess Information Rate
- — EIR = AIR — CIR = taxa excessiva (esporádica)
- Be — EIR x Tc = burst excessivo (pode ser desabilitado com Be = 0)
- — Obviamente Be só pode ser utilizado se AIR > CIR.
Dentro do shaper a queue default é FIFO, mas pode ser configurada como HQF especificando uma child policy (ou nested policy) na classe de shapping.
Traffic Policing
- Policing é utilizado para medir a taxa de fluxo, tipicamente inbound.
- Pacotes que excederem a taxa especificada sofrem alguma marcação (ex: alteração do DSCP/IP Prec, descarte,etc) (tecnicamente, descarte também é um tipo de marcação).
- Policing só possui parâmetros:
- — CIR — taxa média
- — Tc — frequência do policing
- Quanto maior o Tc, maior será o Bc, porque Bc = CIR * Tc.
- Novamente, Be é o total de bytes permitidos além do Bc durante Tc.
Shaping and Policing
Tipicamente Policing e Shaping são utilizados juntos onde um lado utiliza Shaping Outbound enquanto o outro usa Policing Inbound. Neste caso os parâmetros devem bater e o Shaping deve ser ajustado de acordo com o Policing (CIR, Bc e Be). Tecnicamente os valores do Policing podem ser mais altos.
Ao se basear em segundos, Shaping oferece menos vazão ao tráfego. Mas a longo prazo oferece um melhor aproveitamento do link diminuindo a frequência de TCP Slow-Start e consequentemente oferece melhor vazão.
Policing possui 3 ações para o tráfego: Conform, Exceed, Violate.
- Conform: X =< Bc
- Exceed: Bc < X < (Bc + Be)
- Violate: (Bc + Be) < X
Single-rate Policing
Mede apenas o CIR e possui 2 opções:
- Conform — abaixo do CIR
- Exceed — acima do CIR
Dual-Rate Policing
- Mede contra duas taxas — CIR e PIR (Bc + Be)
- Possui 3 ações
- — Conform: abaixo do CIR
- — Exceed: entre CIR e PIR
- — Violate: acima do PIR
- Normalmente utilizado para implementar acesso com 2 taxas onde o cliente tem garantia até o CIR, permissão para enviar até o PIR e tráfego entre CIR e PIR é remarcado (geralmente com DSCP mais baixo) sem garantia.
OBS: Lembrando que Policing pode ser IN ou OUT, enquanto Shaping só pode ser OUT porque se trata de um mecanismo de queueing.
Frame-Relay Traffic Shaping (FRTS) (nostálgico né???)
- Similar ao Traffic Shaping padrão, com a diferença que permite taxas de shaping diferentes por PVC (afinal PVCs diferentes tem BWs diferentes).
- Utilizado em cenários onde uma interface física agrega múltiplos PVCs.
- Ponto negativo de FRTS é que não há como informar sobre a utilização de um PVC para outro PVC, portanto a BW não utilizada de um PVC não pode ser compartilhada por outros.
- Neste cenário existem 2 opções:
- — Implementar FRTS e nenhum PVC ultrapassa o limite definido.
- — Não aplicar nenhum shaping e deixar que os PVCs enviem a taxa máxima permitida pela serialização (clock-rate) sujeitando o tráfego a contenção do TX-Ring e possível policing do PVC.
- FRTS pode utilizar HFQ -> Shaping do PVC + Shaping da Interface.
Legacy FRTS
- Aplicado diretamente na interface principal. Se o CIR não for especificado força todos os PVCs para 56k.
- As taxas dos PVCs devem ser aplicadas via map-class na Subinterface ou DLCI (PVC). Se as taxas entre os PVCs forem diferentes é necessário aplicar diretamente nos PVCs.
- — OBS: Não confundir map-class com class-map de MQC.
Legacy FRTS + HFQ
Shaping é definido dentro da map-class juntamente com uma service-policy. A service-policy define as diferentes queues, permitindo utilizar praticamente todas as tools HFQ juntamente com Legacy FRTS (não permite uso de shaping dentro da service-policy).
Um ponto chave é que a BW máxima que pode ser reservada (comando priority ou bandwidth) será determinada agora pelo Frelay minCIR (CIR/2). O minCIR é o valor garantido do PVC, ou seja, minCIR da Cisco = CIR do ISP.
OBS: Termos utilizados entre Cisco e ISPs podem diferir.
Ao habilitar legacy FRTS + HFQ na interface Frelay, ela passa a utilizar DUAL-FIFO queueing para permitir o uso de Fragmentation e Interleaving. Este mecanismo define que os pacotes sejam fragmentados diretamente na L2 e uma vez que isto ocorre, os pacotes com prioridade são enviados entre os pacotes sem prioridade.
Fragmentation e Interleaving foram desenvolvidos para circuitos de baixa velocidade devido a demora na serialização e o objetivo é evitar que os pacotes de voz esperem mais de um Tc para serem encaminhados.
MQC FRTS
O Shaping é definido na policy que é referenciada pela map-class. A map-class ainda é utilizada mas basicamente para mapear o FRTS (policy) para os PVCs.
OBS: A diferença entre os métodos é onde configurar o shaping (direto na map-class ou através de policy)
OBS: Assim como no Traffic-Shaping, o Tc é implicitamente calculado baseado no CIR e Bc.
OBS: Os valores de Bc e Be podem ser qualquer um mas não faz sentido definir valores mais altos que o clock-rate porque haverá contenção na TX-Ring (realmente sem sentido). Geralmente Bc representa o CIR e o Be é a diferença entre o clock-rate e o CIR, durante um Tc.
OBS: Se a implementação do FRTS deve ser realizada diretamente na interface ou por PVC, depende diretamente de como o ISP estabelece o Policing (por link ou por PVC). Outbound Shaping -> Inbound Policing.
RSVP
Desenvolvido para ser utilizado com o modelo IntServ onde a aplicação solicita reserva de recursos na rede (aplicação deve suportar RSVP) através de solicitações de reserva (PATH e RESV).
Aplicação transmite uma mensagem PATH até o destino de forma hop-by-hop. Se a aplicação de destino e os dispositivos concordarem com a reserva, a aplicação destino responde com mensagem RESV de forma hop-by-hop até a origem.
- Uma vez que as aplicações realizem a reserva através do Control Plane, os roteadores realizam a reserva no Data Plane através de WFQ (Portanto RSVP requer WFQ ou CBWFQ).
- Todo fluxo possui um policer associado e uma queue WFQ dedicada.
- Através do RSVP o router realiza controle de admissão e caso não possua mais BW disponível, responde para o Source com deny.
- RSVP é considerado um mecanismo legado porque todos os routers no caminho precisam manter o estado de todos os fluxos (esse troço não escala).
- Atualmente RSVP é utilizado somente para MPLS-TE em túneis.
- Como o RSVP necessita de WFQ ele não funciona com outros mecanismos HFQ.
- Suporta usos de queues per-VC através de Legacy FRTS, porém PVCs devem ser configurados com WFQ para suportar reservas com diferentes pesos.
OBS: Roteadores podem ser configurados para iniciar a solicitação ou confirmação de reserva, mas na prática quem faz isso é a aplicação.
No próximo artigo vamos explorar mecanismos de QoS em uma plataforma de Switches Catalyst. Portanto continue com a gente :)
O que achou desse artigo? Vai te ajudar no dia-a-dia? Fala pra gente nos comentários?
Se gostou do conteúdo, dê “clap” para o artigo aí do lado esquerdo e compartilhe nos seus grupos. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Giuliano Barros é Network Engineer & Founder da Control Plane — Network Services.
Graduado em Ciência da Computação, certificado CCIE RS e Cisco Champion pela Cisco Systems, trabalha há 15 anos como Network Engineer em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros
