Introdução
A taxa de encaminhamento e largura de banda são métricas distintas e complementares que definem o comportamento de equipamentos de rede em aplicações industriais e corporativas. Neste artigo, dirigido a engenheiros eletricistas, de automação, projetistas OEM, integradores e gerentes de manutenção, explico com rigor técnico o que cada termo significa, como medí-los, por que são críticos para SLAs e como projetar redes que alcancem metas reais de desempenho. Usarei conceitos como pps, bps, MTU, PFC e MTBF, além de normas e referências técnicas aplicáveis (IEEE 802.3, RFCs relevantes e normas de produto como IEC/EN 62368-1 e IEC 60601-1 onde aplicável a equipamentos com requisitos de segurança).
A distinção entre plano de controle e plano de encaminhamento será enfatizada: enquanto o primeiro lida com assincronias, tabelas e sessões, o segundo refere-se ao processamento de pacotes em escala (pps/bps). Vou também indicar ferramentas práticas (iperf3, TRex, pktgen, perf counters, SmartNICs/DPDK) e metodologias replicáveis para medir ambos os parâmetros em laboratório e em produção. Para mais artigos técnicos consulte: https://blog.ird.net.br/.
Este guia é prático e orientado a decisões de projeto: ao final terá checklists de teste, recomendações de QoS, ajustes de MTU e observabilidade L2–L7 para que sua arquitetura entregue as métricas contratadas sem surpresas operacionais.
1) O que são taxa de encaminhamento e largura de banda
Definição técnica de taxa de encaminhamento (forwarding rate)
A taxa de encaminhamento mede quantos pacotes um equipamento consegue processar por segundo — normalmente expressa em pps (packets per second). Essa métrica descreve a capacidade do data plane e é influenciada por MTU, tamanho de cabeçalhos, complexidade das regras (ACLs, NAT, inspeção) e arquitetura de hardware (ASIC, NPU, CPU). Em aplicações com muitos pacotes pequenos, o pps é quase sempre o limitador real.
Definição técnica de largura de banda (throughput)
A largura de banda refere-se à taxa de bits efetivamente transmitida/recebida por segundo — em bps (bits per second). É uma métrica de uso do enlace físico e de capacidade de encaminhamento quando o tráfego é composto por pacotes maiores. A conversão entre pps e bps depende do tamanho do pacote "on-wire" (incluindo preâmbulo, IFG, cabeçalhos e FCS): bps ≈ pps × (bytes_on_wire) × 8.
Planos de controle vs. planos de encaminhamento e impacto do MTU
É crucial separar plano de controle (BGP, OSPF, TACACS, tabelas de sessão) do plano de encaminhamento (comutação/encaminhamento de pacotes). O MTU altera a relação pps/bps: aumentar MTU (jumbo frames) reduz pps para mesma bps, aliviando CPU/ASIC em cenários de fluxos grandes mas introduzindo trade-offs em interoperabilidade e latência. Normas como IEEE 802.3 definem limites de frames e overheads físicos que influenciam cálculos.
2) Por que taxa de encaminhamento e largura de banda importam
Impacto em latência, jitter e perda
Confundir pps com bps pode levar a projetos que colapsam sob tráfego de pequenos pacotes: um firewall com 10 Gbps declarado pode não suportar milhões de pps de pacotes de 64 bytes, resultando em aumento de latência, jitter e drops. Em aplicações de automação e controle em tempo real, onde jitter e latência determinística são críticas, a escolha correta do equipamento e do dimensionamento é mandatória.
Capacidade, custo e granularidade do SLA
A métrica correta influencia CAPEX e OPEX. Dimensionar só por bps pode levar a pagar portas 100G quando o gargalo é pps (por exemplo, em cenários com muito small-packet telemetry, IoT ou sondas). Calcular custo por porta/pps é tão importante quanto custo por Gbps. Além disso, SLAs relacionados a tempo de recuperação e MTBF do hardware (e conformidade a IEC/EN 62368-1 para segurança de produto) devem ser considerados ao definir garantias contratuais.
Riscos operacionais ao confundir as duas métricas
Erros comuns: confiar apenas em bps para dimensionar firewalls, não contabilizar overhead de encapsulação (GRE, VXLAN) que diminui efetiva largura de banda, ou assumir que NIC com offloads eliminará necessidade de testes de pps. Há riscos adicionais quando funções L4–L7 (inspeção, TLS) tornam o encaminhamento CPU-bound; nesses casos, pps pode cair dramaticamente apesar de sobra de bps.
3) Como medir e diagnosticar taxa de encaminhamento e largura de banda
Metodologia de laboratório: isolamento e ambiente controlado
Monte um cenário isolado (VLAN de teste) com tráfego gerado por equipamentos que suportem repetibilidade (TRex, IXIA, Spirent, pktgen). Defina: pacote base (payload), presença de tags 802.1Q, MTU, offloads de NIC (TSO/GSO/GRO) desabilitados, e monitore counters SFP/QSFP por porta. Garanta aquecimento (warm-up) e runs múltiplos para média estatística.
Ferramentas e métricas práticas
- Para bps: iperf3 (TCP/UDP) é prático; use UDP para saturar links e medir perda.
- Para pps e perfis de tráfego realísticos: TRex, pktgen-DPDK, Scapy, Ostinato.
- Para counters e telemetria: ethtool, ifconfig/ss, SNMP (ifHCInOctets, ifHCInUcastPkts), sFlow/NetFlow, telemetry gNMI/gRPC.
Interprete também CPU, interrupções por segundo, e counters ASIC (drop by queue, policer drops).
Procedimento passo a passo para testes reproduzíveis
- Configure fluxo (tamanho do frame, taxa pps alvo ou bps alvo).
- Desabilite features que mascaram: checksum offload, LRO/GRO.
- Execute com aumento incremental (ramp-up) até drops; registre pps, bps, CPU e counters ASIC.
- Repita com variações de MTU e com/sem encapsulamento.
- Correlacione com monitoramento em produção (telemetria contínua) para validar comportamento sob carga real.
4) Como otimizar e projetar redes com foco em taxa de encaminhamento e largura de banda
Configurações de QoS: shaping vs policing e filas
Escolha shaping quando for necessário suavizar bursts e evitar perda upstream; use policing para aplicação de limites rígidos no perímetro. Configure filas com tamanhos adequados ao perfil (small-packet bias exige filas poucos pacotes mas alta taxa de processamentos por segundo). Técnicas como Class-Based WFQ, RED/CoDel e priorização por DSCP auxiliam a controlar latência e drops.
Ajuste de buffers, MTU e offloads de NIC/SmartNIC
Aumentar buffers de porta/ASIC pode absorver bursts mas introduz latência (bufferbloat). Use jumbo frames (MTU 9000) em redes DC para reduzir pps quando tráfego é predominantemente grande, mas avalie interoperabilidade. Considere offloads e aceleradores: SmartNICs, P4-programáveis e DPDK aliviam CPU; porém, valide compatibilidade com features de switch/firewall (ex.: offload de checksum e segmentação altera comportamento do teste).
Arquiteturas e engenharia de tráfego
Arquiteturas que usam balanceamento por fluxo (ECMP) tendem a preservar pps por sessão; balanceamento por pacote pode causar reordenação. Em ambientes com muitos micro-flows, use split de fluxos, hashing por 5-tuple e sticky flows. Para firewalling/IDS, dimensione para pps máximos esperados e prefira modelos com aceleração por ASIC/NPU para manter desempenho sem comprometer inspeção profunda.
CTA: Para aplicações que exigem alta taxa de encaminhamento e largura de banda com aceleração por hardware, a linha de switches e routers de alto desempenho da IRD.Net está preparada para testes em laboratório e produção: https://www.ird.net.br/produtos/switches
5) Comparações avançadas e erros comuns envolvendo taxa de encaminhamento e largura de banda
Diferenças entre ASICs, CPUs de encaminhamento e aceleradores
ASICs entregam baixa latência e alta bps/pps em pipeline fixo; NPUs/SmartNICs oferecem flexibilidade com aceleração; CPUs de encaminhamento (software) são versáteis mas frequentemente limitadas por pps. Implementações L7 (inspeção, TLS) tipicamente migram carga para CPU/NPU, reduzindo pps apesar de sobra de bps.
Casos práticos: muitos pequenos pacotes e impacto do cabeçalho
Cenário: telemetria de IoT com milhões de pacotes de 64 bytes. O overhead on-wire (preamble + IFG + cabeçalho + FCS) faz com que pps necessários aumentem e possam saturar TCAMs/ACLs. Exemplo prático: para calcular bps necessário use bps = pps × (bytes_on_wire) × 8; incluir VLAN e encapsulamento (GRE/VXLAN) aumenta bytes_on_wire e reduz throughput efetivo.
Erros recorrentes e validação em laboratório
Erros comuns:
- Usar apenas testes TCP (iperf) quando a carga real é UDP small-packet.
- Não isolar offloads ao medir pps.
- Confiar em números “line-rate” do datasheet sem testar com tráfego real e com regras ativadas (ACLs, NAT, QoS).
Checklist de validação: perf run, counters ASIC, teste com variação de MTU, simulação de bursts e teste de degradação (graceful failure).
CTA: Para testar e validar em laboratório com equipamentos certificados, consulte a plataforma de appliances e serviços de testes da IRD.Net: https://www.ird.net.br/produtos/firewalls
6) Resumo estratégico e próximos passos para dominar taxa de encaminhamento e largura de banda
Decisões-chave: quando priorizar pps vs bps
Priorize pps quando houver grande quantidade de pacotes pequenos (telemetria, VoIP, sensores). Priorize bps quando o tráfego é dominado por grandes fluxos (backup, storage, vídeo). Sempre avalie encapsulações e interrupções do plano de controle que possam afetar ambas as métricas.
Checklist de ação imediata (Medir, Validar, Otimizar, Monitorar)
- Medir: estabelecer cenários reais e sintéticos com TRex/iperf.
- Validar: executar testes com regras reais (ACL/NAT/QoS) e com offloads desabilitados.
- Otimizar: ajustar MTU, filas, QoS e considerar SmartNIC/P4.
- Monitorar: habilitar telemetria (sFlow, NetFlow, gNMI) e alertas para pps spikes e drops.
Tendências e governança para manter métricas alinhadas a SLAs
Acompanhe 400G/800G, SmartNICs e programação P4, além de evolução de observabilidade L2–L7. Defina governança: periodicidade de testes, thresholds, e revisão de MTBF e conformidade (IEC/EN 62368-1 para segurança; IEC 60601-1 quando aplicável a equipamentos médicos). Inclua métricas pps em seus SLAs e crie playbooks de mitigação para cenários de crise.
Conclusão
Taxa de encaminhamento (pps) e largura de banda (bps) são métricas essenciais porém distintas; confundí‑las pode levar a falhas operacionais e custos desnecessários. Medir de forma controlada, validar com tráfego realístico, e otimizar tanto a camada física quanto o plano de dados (filas, QoS, offloads) são práticas indispensáveis para projetos industriais robustos.
Interaja: comente abaixo seus desafios práticos — que equipamento apresentou gargalo em pps? Que ferramentas você prefere para testes? Suas perguntas ajudam a enriquecer este guia técnico.
Para mais artigos técnicos consulte: https://blog.ird.net.br/
