Introdução
A taxa de encaminhamento de pacotes é um dos indicadores centrais para engenheiros eletricistas, de automação, projetistas de produtos (OEMs), integradores de sistemas e gestores de manutenção industrial que operam redes determinísticas e IP. Neste artigo técnico completo vamos definir precisamente a taxa de encaminhamento de pacotes, distinguir pps vs bps vs throughput, e fornecer procedimentos práticos para medir, monitorar e diagnosticar problemas ligados a essa métrica. Desde contadores SNMP (ifInUcastPkts, ifOutUcastPkts) até telemetria baseada em gNMI/OpenConfig, cobriremos as normas relevantes (RFCs, IEEE 802.3, IEC/EN quando aplicável) e como relacionar resultados a CPU/ASIC, MTBF e PFC.
O objetivo é que você, profissional de campo ou projeto, saia com um playbook operacional: como coletar contadores, configurar NetFlow/sFlow, executar testes ativos (TRex, iPerf), montar dashboards (Prometheus/Grafana) e criar runbooks de resposta. Usaremos analogias técnicas para tornar conceitos como microbursts e oversubscription intuitivos, mantendo rigor técnico e referências de padrões (por exemplo, RFC 7011 IPFIX, RFC 3176 sFlow, RFC 1213 MIB‑II). Para mais artigos técnicos consulte: https://blog.ird.net.br/.
Interaja: ao final incentivo perguntas e comentários técnicos para debater casos específicos de rede, topologias e equipamentos. Agora vamos começar pela definição.
Entenda o que é taxa de encaminhamento de pacotes: definição, métricas e sinais básicos
Definição e distinções fundamentais
A taxa de encaminhamento de pacotes é a velocidade na qual um equipamento de rede (roteador, switch, firewall, appliance) processa e encaminha pacotes em termos de pacotes por segundo (pps). Isso difere de bits por segundo (bps), que mede largura de banda, e de throughput, que normalmente refere-se a dados úteis transferidos por unidade de tempo levando em conta overheads. Em dispositivos com ASICs específicos, o limite em pps pode ser independente do limite em bps — por exemplo, 10 Gbps pode admitir muitos pps pequenos ou menos pps se os pacotes forem grandes.
Métricas primárias e sinais que observar
As métricas primárias incluem: pacotes encaminhados, pacotes descartados (drops), reencaminhados, latência e microbursts (curtos picos de pps que podem não ser vistos por amostragem grosseira). Counters relevantes (MIB‑II) são: ifInUcastPkts, ifOutUcastPkts, ifInNUcastPkts, ifOutDiscards, ifInDiscards, ifHCInOctets, ifHCOutOctets. Para correlacionar: delta(ifHCOutPkts)/delta(t) = pps observado; delta(ifHCOutOctets)*8/delta(t) = bps.
Exemplo numérico prático
Considere um interface com ifHCOutPkts = 1.200.000 no tempo T0 e 1.560.000 no tempo T1, 60 segundos depois. Delta = 360.000 pacotes / 60 s = 6.000 pps. Se ifHCOutOctets delta = 360.000.000 bytes no mesmo intervalo → 360.000.000*8/60 ≈ 48 Mbps. Uso de pps é crítico quando pacotes são pequenos (VoIP, telemetria industrial) pois bps pode subestimar a carga de CPU/ASIC.
Avalie por que monitorar taxa de encaminhamento de pacotes importa: riscos, SLAs e benefícios operacionais
Impacto operacional e econômico
A falha em manter a taxa de encaminhamento esperada pode degradar SLAs, aumentar latência de aplicações e gerar falhas intermitentes em sistemas industriais. Em ambientes que exigem conformidade e segurança (por exemplo, dispositivos médicos ou painéis integrados) normas como IEC/EN 62368-1 e IEC 60601-1 podem não tratar diretamente de pps, mas influenciam requisitos de certificação e confiabilidade elétrica dos equipamentos que contêm a função de rede. Além disso, o Fator de Potência (PFC) e MTBF entram em consideração ao dimensionar fontes de alimentação para appliances que suportem picos sostenidos de processamento.
Indicadores de risco e cenários reais
Indicadores críticos são drops, backpressure em filas, e oversubscription em agregação de links. Cenários reais: manutenção com buffers cheios, DDoS volumétrico ou por pps, e atualizações de firmware que alteram o path de forwarding (p.ex. modo de software vs. hardware). Detectar aumento súbito de pps, drop rate crescente (>0.01% para ambientes sensíveis) ou aumento de microbursts são sinais de intervenção imediata.
Benefícios tangíveis ao monitorar
Monitoramento robusto permite detecção precoce, planejamento de capacidade e otimização de custo (ex.: evitar upgrades caros de chassis ao detectar que o gargalo é CPU e não link). Critérios para priorizar dispositivos a monitorar: pontos de agregação, borda de datacenter, links com SLAs estritos e equipamentos com histórico de high CPU/ASIC utilization. Priorize interfaces com alta variação de pps e serviços críticos (SCADA, VoIP).
Links úteis: veja também nosso artigo sobre monitoramento de rede em ambientes industriais e sobre telemetria moderna.
Meça taxa de encaminhamento de pacotes na prática: métodos, ferramentas e procedimentos passo a passo
Coletando counters relevantes (SNMP e CLI)
Procedimento prático: use SNMP para ifTable (RFC 1213). OIDs principais: ifInUcastPkts (.1.3.6.1.2.1.2.2.1.11), ifOutUcastPkts (.1.3.6.1.2.1.2.2.1.17), ifHCInOctets (.1.3.6.1.2.1.31.1.1.1.6), ifHCOutOctets (.1.3.6.1.2.1.31.1.1.1.10), ifInDiscards, ifOutDiscards. Exemplo de comando CLI: em Cisco, show interfaces | include packets; em Juniper, show interfaces extensive. Em Linux: cat /proc/net/dev e ethtool -S eth0.
Configurando NetFlow/sFlow e interpretando amostras
Configure NetFlow v9 / IPFIX (RFC 7011) para exportar templates e registros que representam fluxos agregados; use sFlow (RFC 3176) para amostragem estatística com menor overhead. Interpretação: NetFlow dá contagem por fluxo (pps, bytes) — importante para correlacionar hot‑flows; sFlow é útil para detectar microbursts se a amostragem for ajustada (ex.: 1:1000 vs 1:100). Exemplos de configuração mínimos: Cisco ASA/IOS: ip flow-export destination X.Y.Z.W 2055; Juniper: set services flow-monitoring version9.
Testes ativos: TRex, iPerf e scripts de medição
Para medir pps máximos e microbursts, use TRex (trafic generator) para gerar tráfego com perfil realista em pps; iPerf3 para throughput/UDP com controle de datagrama. Exemplos:
- iPerf server: iperf3 -s
- iPerf client: iperf3 -c -u -b 100M -l 256
- TRex: use profiles para gerar pps desejados e variar tamanho de pacote.
Para medições repetíveis, capture deltas de counters via SNMP em intervalos curtos (ex.: 1s ou 5s) e armazene num CSV. Scripts reutilizáveis podem usar rrdtool, collecte, ou Python (pysnmp) para automação.
Exemplo de snippet SNMP com snmpwalk:
snmpwalk -v2c -c public .1.3.6.1.2.1.31.1.1.1.6 # ifHCInOctetssnmpwalk -v2c -c public .1.3.6.1.2.1.2.2.1.11 # ifInUcastPktsExemplo Linux:
cat /proc/net/devethtool -S eth0tcpdump -n -i eth0 -c 1000 -w capture.pcapPara aplicações que exigem robustez em coleta contínua, a plataforma de appliances de monitoramento da IRD.Net oferece sondas com captura e exportação de telemetria em tempo real: https://www.ird.net.br/produtos/monitor-de-rede.
Implemente monitoramento contínuo de taxa de encaminhamento de pacotes: dashboards, alertas e runbooks
Arquitetura recomendada
Arquitetura típica: telemetry → time-series DB → painel → alertas. Recomendação prática: exportar SNMP/flow/streaming telemetry para Prometheus (metrics exporters) ou InfluxDB (dados de alta cardinalidade), visualizar em Grafana e acionar alertas via Alertmanager ou sistema de ITSM. Para telemetria em escala, prefira gNMI/OpenConfig ou streaming sobre gRPC para reduzir overhead e coletar métricas de sub‑segundo.
KPIs, SLIs e estratégias de threshold
Defina KPIs como:
- pps 95/99 percentil por interface
- taxa de drops (%) por interface
- número de microbursts por janela de 100 ms
Strategy: thresholds estáticos para SLAs críticos e thresholds adaptativos (baseline) para detecção de anomalias. Ex.: alertar quando pps > baseline + 4σ ou drop rate > 0.01% por 5 minutos.
Dashboards e modelos de alerta com runbook
Exemplo de dashboard: painel com pps (1s/1m), bps (1s/1m), drop rate, CPU/ASIC utilization, buffer occupancy. Alertas: níveis para triagem (P1: perda de forwarding em produção; P2: aumento de drop rate; P3: variação de baseline). Runbook reduzido:
- Detecção → coletar counters e capture de 30s → triagem (isolar porta/slot) → mitigação (rate‑limit, reroute, ACLs, aumentar buffer) → post‑mortem.
Para acelerar implantação de runbooks e sondas, conheça soluções de appliances e serviços da IRD.Net: https://www.ird.net.br/produtos/rdm-3000.
Evite erros e otimize: comparações de métodos, armadilhas comuns e diagnóstico avançado de taxa de encaminhamento de pacotes
Erros frequentes a evitar
Principais armadilhas: amostragem enviesada (sFlow com amostragem muito alta perde microbursts), wrap de counters (32‑bit) e offloads de NIC (GRO/LSO/TSO) que mascaram pps reais no host. Métricas agregadas podem esconder microbursts em uma única fila. Sempre prefira ifHC counters e intervais curtos quando precisar de precisão em pps.
Comparação entre SNMP, NetFlow, sFlow e telemetry
- SNMP: baixo custo, boa para trends, problemas em resolução temporal fina (coleta típica 30s-5min).
- NetFlow/IPFIX: bom para visibilidade por fluxo, estado médio/granularidade.
- sFlow: eficiente para visibilidade estatística, útil em ambientes de alta velocidade com sampling.
- Streaming telemetry (gNMI/OpenConfig): maior fidelidade, menor overhead para dados em sub‑segundo; recomendado para deteção de microbursts e correlação com ASIC counters.
Matriz de escolha: SNMP para capacidade e trending; NetFlow para troubleshooting de fluxos; sFlow para visibilidade em escala; telemetry para SLAs e detecção em tempo real.
Técnicas avançadas de diagnóstico
Use packet captures com timestamping de hardware, eBPF para contadores por aplicação/processo no Linux, P4/INT para telemetria in-band em plataformas compatíveis e ferramentas de benchmark (TRex/IXIA) calibradas. Checklist rápido: desative offloads no host ao medir pps, confirme que counters são de 64 bits (ifHC), sincronize clocks (PTP/NTP) para correlacionar captures, e compare múltiplas fontes (SNMP vs NetFlow vs telemetry) para identificar discrepâncias.
Planeje o futuro e formalize ações: playbook, KPIs permanentes e tendências para taxa de encaminhamento de pacotes
Sumário estratégico e checklist de implantação
Plano mínimo: inventário (dispositivos/ports), baseline inicial de pps e drops, configuração de coleta (SNMP + NetFlow + telemetry), dashboards e runbooks, testes de carga controlados. Checklist prático:
- Ativar counters ifHC e flow exports
- Definir janelas de amostragem (1s/5s)
- Implementar captura de pacotes com timestamping
- Validar com TRex/IXIA
KPIs permanentes e templates de SLA/alerta
Recomendações de KPIs operacionais: pps 95/99 percentil, drop rate tolerável (ex.: 0.05% por 1 min.
Roadmap tecnológico e vendors recomendados
Tendências: in‑band telemetry (INT), programação de dataplane com P4, e AI/ML para detecção de anomalias em pps e microbursts. Vendors a considerar: infra de coleta (Prometheus, InfluxDB), visualização (Grafana), geração de tráfego (TRex/IXIA). Para soluções turnkey em monitorização de redes industriais e instrumentação, consulte as soluções e consultoria da IRD.Net em https://www.ird.net.br/produtos.
Encaminhamento prático: links recomendados para scripts, dashboards e laboratórios de teste para começar imediatamente estão disponíveis no blog técnico da IRD.Net — consulte https://blog.ird.net.br/ para guias, exemplos de dashboards e repositórios.
Conclusão
Medir e operar a taxa de encaminhamento de pacotes é atividade crítica para manter SLAs, segurança e custo‑efetividade em redes industriais e de datacenter. Neste guia você encontrou definições claras (pps vs bps), procedimentos práticos (SNMP OIDs, NetFlow/sFlow, TRex/iPerf), arquitetura de monitoramento (telemetry → TSDB → Grafana) e técnicas avançadas (eBPF, P4, INT). A aplicação correta desses conceitos reduz risco operacional, facilita planejamento e fornece indicadores objetivos para decisões de compra e manutenção.
Pergunte e comente: quais equipamentos, topologias ou ferramentas você usa hoje? Compartilhe um contador ou um resultado de teste e nós podemos ajudar a interpretar e sugerir ajustes. Para mais artigos técnicos consulte: https://blog.ird.net.br/.
