Minha jornada até o CCIE RS — QoS 1

E aí pessoal, tudo bem?

Estamos aqui mais uma vez percorrendo esta série de artigos onde compartilho centenas de páginas de anotações e informações acumuladas ao longo de 15 anos trabalhando com Routing and Switching. Continuo acreditando que estas informações possam ajudar no dia-a-dia de outros network engineers como eu. Portanto, vamos lá!

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” e “IPv6”.

Hoje exploraremos de forma geral Quality of Service, vulgo QoS!!! Então como diz o Rafael Bianco, pega seu café quentinho ou sua coca gelada e vamos nessa.

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

O principal motivo para QoS é a contenção de recursos, onde geralmente os recursos são a largura de banda. Essa contenção ocorre porque múltiplos fluxos de múltiplas aplicações compartilham o mesmo link e cada aplicação possui seus próprios requisitos (ex: delay, BW, etc).

O resultado dessa contenção é que os dispositivos na rede precisam enfileirar os diversos fluxos para encaminhá-los (“Queueing”). Este enfileiramento pode causar o atraso ou descarte de pacotes efetivamente diminuindo a vazão dos fluxos enfileirados além de aumento no delay ou jitter (variação do delay).

Obviamente a melhor solução seria evitar a contenção, não sobrecarregando os recursos de rede, de forma que o QoS não seria necessário. Como esta solução geralmente não é possível, QoS é a segunda melhor opção.

QoS é capaz de controlar congestionamento na rede, delay, jitter, descarte e vazão do link. Porém QoS se trata de uma solução temporária (um band-aid) para a contenção de recursos. Ou seja, se houver muita conteção, QoS não irá resolver.

Modelos de QoS — Definem como a conteção é gerenciada

Integrated Services (IntServ)

Define que todo fluxo tenha uma reserva explícita de recursos fim-a-fim. IntServ é um modelo orientado a conexão (connection-oriented) porque os aplicativos precisam conhecer os recursos de QoS e os dispositivos de rede precisam manter o estado para cada conexão (fluxo).

Como precisa manter múltiplos estados (para cada fluxo), IntServ não escala muito bem e é considerado uma solução legada.

OBS: IntServ ainda é utilizado em algumas soluções como MPLS-TE (Traffic Engineering) que usa RSVP para reservar recursos para cada tunel. Sobre este tópico, recomendo o artigo abaixo do Renato Antonio sobre Traffic Engineering em ISPs: https://medium.com/techrebels/mpls-core-traffic-engineering-e513490086ca

Differentiated Services (DiffServ)

Define que o comportamento QoS é definido pela classe de tráfego de modo hop-by-hop, também conhecido como QoS Per-Hop-Behaviour (PHB). Portanto DiffServ agrupa fluxos em classes definidas com requisitos comuns.

O processo de classificação dessas classes comuns é definido na borda da rede (cama de acesso) de forma manual ou pré-codificada dentro do pacote (“marking”).

QoS Marking

Define a classificação do pacote e pode ocorrer de diversas formas diferentes.

As marcações podem ocorrer em L3 ou L2:

• IPv4 e Ipv6 (Type of Service byte)
• — DSCP (6 bits)
• — IP Precedence (3 bits)
• Layer 2
• — Frelay DE bit (1)
• — MPLS EXP bits (3)
• — 802.1q/ISL CoS bits (3) -> Somente para interfaces trunk
• IP Prec geralmente é considerado um método legado porque DSCP permite maior granularidade. Pelo mesmo motivo marcação L3 tem preferência sobre marcação L2.
• Mesmo DSCP possuindo 6 bits não é interessante utilizar 64 classes diferentes porque se perde o controle da situação e dificulta gerenciamento.

DSCP

Possui 4 classes principais pré-definidas:

• Default-class utiliza DSCP 0, reservada para tráfego best-effort que não é tratado por nenhuma outra classe (conhecida como Scavenger Class).
• Expedited Forwarding (EF) utiliza DSCP 46 (101110), geralmente reservada para tráfego prioritário (geralmente VOIP). EF é a best class, oposto da default-class.
• Assured-Forwarding (AF) é geralmente utilizada para aplicações com bandwidth garantida (web, ftp, DB, etc…). AF define 4 tipos de classes e 3 precedências de descarte, no formato AF XY onde:
• — Classe: X entre 1–4 (maior tem preferência).
• — Descarte: Y entre 1–3 (maior tem mais chance de ser descartado).
• — AF utiliza formato DSCP binário (XXXYY0), sendo valores XXX entre 1–4 e YY entre 1–3.
• Class Selector (CS) é a classe que oferece compatibilidade com IP Prec, definindo 7 classes CSX onde X entre 1–7. CS5 é geralmente utilizado para tráfego Crítico e CS6 e 7 são utilizados para tráfego de Control Plane.

QoS tools (ferramenta) confiam cegamente na marcação e portanto ela deve ser realizada de forma padronizada na borda da rede (geralmente em SW L2). São usadas diferentes tools para CORE e EDGE.

OBS: A difícil tarefa no QoS é entender o porquê de usar uma determinada ferramenta para determinado cenário.

Queuing

Ocorre quando os pacotes são retardados pelo roteador tanto inbound quanto outbound. Queuing pode apresentar múltiplos níveis de hierarquia. Ex:

• PVC-QUEUE (Frelay)
• -> Interface-queue (software queue) ou Output Queue
• — -> Hardware-queue (TX-ring)
• Catalyst Switches realizam QoS somente usando hardware-queue.

A grande maioria dos mecanismos de QoS manipulam a software-queue, também conhecidos como fancy queueing, enquanto esperam enfileiramento na hardware-queue (se a TX-ring está cheia).

A TX-ring (hardware-queue) é a última parada antes dos pacotes serem serializados na interface (link) e nela não há muita (ou nenhuma) manipulação de QoS que se possa fazer. Switches realizam QoS somente na hardware-queue e, portanto, possuem muito menos mecanismos de QoS.

Modular QoS CLI-MQC

• MQC permite implementação de múltiplos mecanismos de QoS por interface por direção.
• Alternativa para métodos legados de QoS (ex: custom queue, priority queue, GTS, …)
• Antiga versão é chamada CBWFQ (class based weighted fair queueing).
• Nova versão é chamada HQF (Hierarchical Queueing Framework) a partir do IOS 12.4(20)T (já velhinho) padronizada na maioria dos routers (lembrando que switches realizam QoS em hardware).

OBS: Este White Paper sobre HQF mostra o que mudou no QoS a partir da versão 12.4(20)T e alterações na sintaxe.

MQC possui 3 passos básicos de configuração para Routers e Switches:

1. Definir as classes de tráfego através de critérios de match (class-map);
2. Definir a política de tráfego através de ações (policy-map) ;
3. Aplicar a política em uma interface IN ou OUT.

OBS: Não confundir class-map com map-class (antigo mecanismo de Frelay para QoS).

OBS: A partir da versão 12.4(20)T não há métodos para verificar antigos mecanismos de QoS (APENAS <sh policy-map> 😞 ). Portanto não há nem motivos para implementá-los.

Opções de Classificação de MQC

• match-all vs match-any (default é match-all)
• ACLs
• DSCP/IP Prec
• NBAR (Application Based)
• Source Interface
• Source/Destination MAC
• *Combinação de múltiplos matches

Policy-map é processado de forma top-down portanto as classes devem ser referenciadas do match mais específico para o match menos específico (class-default).

OBS: Quanto mais nova a versão, mais opções de classificação (principalmente para NBAR).

OBS: Basicamente tudo que realiza match através de ACL pode ser classificado via QoS (incluindo time-based ACLs).

OBS: Importante lembrar que TOS byte são 8 bits, que o IP Prec usa os 3 bits mais significativos enquanto DSCP usa 6 bits mais significativos (o TOS precisa ser completado por 0s).

Queueing é geralmente relacionado com mecanismos outbound enquanto Classification é relacionado com termos inbound.

OBS: Comparando com switches, roteadores possuem toneladas de opções de QoS.

No próximo artigo iremos explorar os principais mecanismos de QoS. 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