Protocolo sFlow: o que é, como funciona e diferença para NetFlow

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado dez/2015Atualizado set/2026

O protocolo sFlow resolve um problema prático de monitoramento de redes de alta velocidade: como coletar informações de tráfego suficientes para tomar decisões operacionais sem sobrecarregar os próprios dispositivos que você está tentando monitorar?

Sua resposta é a amostragem estatística. Em vez de capturar cada pacote que atravessa uma interface, o protocolo coleta uma amostra representativa e a envia para análise.

Desenvolvido pela InMon Corporation e introduzido comercialmente pela HP em 2001, o sFlow surgiu como alternativa ao NetFlow da Cisco para ambientes com switches de alta densidade e orçamento de CPU limitado. Hoje é suportado por fabricantes como HP Aruba, Brocade, Huawei, Dell, Alcatel e D-Link, tornando-se um padrão de fato para monitoramento de tráfego de redes em ambientes multi-vendor.

Este artigo explica como o sFlow funciona, como se diferencia do NetFlow, quais informações ele coleta e quando faz sentido adotá-lo em uma infraestrutura corporativa.

Como o protocolo sFlow funciona

O sFlow opera com dois componentes principais: o sFlow Agent e o sFlow Collector.

O sFlow Agent é implementado diretamente no hardware do switch ou roteador, geralmente nos ASICs de encaminhamento. Ele captura amostras de pacotes a uma taxa configurável, tipicamente 1 em cada 100 a 1000 pacotes por interface, dependendo da configuração. Além das amostras de pacotes (Flow Sampling), o Agent também coleta contadores de interface a intervalos regulares (Counter Sampling), como utilização de banda, erros e descartes.

O sFlow Collector é o servidor que recebe os datagramas UDP enviados pelo Agent, processa as amostras e as armazena para análise. Ferramentas de análise leem os dados do Collector e produzem relatórios sobre protocolos mais usados, endereços IP com maior consumo de banda, aplicações dominantes e comportamentos anômalos.

Para medir o que a amostragem entrega na prática, subimos o protocolo em laboratório. O agente é o hsflowd 2.1.26, isto é, a implementação que a InMon mantém para Linux. Já o coletor é o sflowtool 6.11. Os números desta página saíram de testes rodados em 1º de setembro de 2026, sobre Debian 13 em Docker.

Não é um switch: a amostragem acontece em software, no lugar do ASIC. O protocolo na rede é o mesmo. Ainda assim, a taxa não vem de fábrica: ela é declarada na configuração do agente.

sflow {
  agent = eth0
  # Counter Sample: contador de interface, lido a cada 20 segundos
  polling = 20
  # Flow Sample: 1 pacote amostrado em cada 100
  sampling = 100
  # sem esta linha o agente usa 1:10000 na interface de 10 Gbps
  sampling.10G = 100
  collector { ip=172.31.10.31  udpport=6343 }
  pcap { dev = eth0 }
}

Nesse arquivo, a linha sampling.10G não é redundante. Sem ela, o agente ignorou o valor pedido e amostrou 1 pacote em cada 10.000. Isso acontece porque ele escolhe a taxa pela velocidade do link. No teste, a interface se declarava de 10 Gbps.

Vale conferir, portanto, a taxa efetiva no coletor antes de confiar em qualquer relatório. O número que o agente aplicou viaja dentro do datagrama, no campo meanSkipCount. Foi assim que a troca de 100 por 10.000 apareceu.

A diferença crítica para o NetFlow: o sFlow amostra pacotes individuais independentemente do fluxo e envia o cabeçalho completo do pacote para o Collector. Isso dá visibilidade desde a camada 2 (MAC) até a camada 7 (aplicação). Em contrapartida, exige processamento estatístico no Collector para inferir o comportamento do tráfego.

sFlow versus NetFlow: diferenças técnicas e casos de uso

A escolha entre sFlow e NetFlow depende do contexto da infraestrutura e do que se precisa monitorar.

O NetFlow acumula dados por fluxo IP (combinação de IP de origem, IP de destino, portas e protocolo) e exporta registros de fluxo completos quando cada fluxo termina ou expira. Isso gera dados mais ricos por fluxo, mas consome mais CPU e memória dos dispositivos de rede. Em redes de altíssima velocidade, o NetFlow pode degradar o desempenho de encaminhamento.

O sFlow delega o trabalho pesado para o hardware (ASICs), operando a velocidade de linha sem impacto no desempenho de encaminhamento. O custo é a imprecisão estatística: com taxa de amostragem de 1:1000, fluxos pequenos e de curta duração podem não ser capturados nas amostras. Para detectar tráfego dominante, identificar top talkers e monitorar tendências de longo prazo, a precisão estatística é suficiente. Para auditoria de segurança com granularidade por fluxo individual, o NetFlow oferece mais completude.

Essa imprecisão tem tamanho medido. Antes de tudo, geramos uma captura única de 149.683 pacotes e 138,9 MB, com quatro perfis de tráfego. Em seguida, codificamos o mesmo arquivo em três taxas de amostragem, cinco rodadas para cada uma. Assim, a verdade de campo veio da leitura de todos os pacotes, sem amostrar nada.

 
Portanto, a leitura operacional é direta. Para volume por host, a taxa 1:1000 erra cerca de 10% e ainda sustenta uma curva de tendência. Já para o host que responde por 1% do tráfego, a mesma taxa erra 88%. Em duas das cinco rodadas esse host não apareceu.

Já a contagem de conversas não se recupera com escala. A 1:1000, por exemplo, o coletor enxergou 2% dos 4.864 fluxos TCP da captura. Por isso o sFlow responde bem quanto passou e quem consumiu, sem responder quantas conexões existiram.

A confusão gerada em parte vem do fato que em redes multi-vendor o NetFlow proprietário da Cisco muitas vezes não é suportado, enquanto o sFlow é um padrão aberto suportado pela maioria dos fabricantes de switches. Para equipamentos HP, Brocade ou Huawei, o sFlow é frequentemente a única opção nativa de análise de tráfego.

O que o sFlow coleta e como interpretar os dados

Os dados coletados pelo sFlow se dividem em dois tipos, que juntos formam um retrato completo do tráfego:

As amostras de pacotes (Flow Samples) contêm o cabeçalho completo de cada pacote amostrado, incluindo endereços MAC de origem e destino, endereços IP, portas, protocolo e tipo de serviço. Essas amostras permitem identificar quais aplicações, hosts e protocolos dominam o tráfego de cada interface.

Vale olhar uma amostra crua. O bloco abaixo é uma Flow Sample real do laboratório, já decodificada pelo sflowtool:

sampleType          FLOWSAMPLE
meanSkipCount       100       # a taxa que o agente aplicou
samplePool          100       # pacotes que passaram até esta amostra
dropEvents          0         # amostras perdidas por falta de recurso
sampledPacketSize   330       # tamanho do quadro no fio
headerLen           128       # quanto do quadro viajou até o coletor
srcIP               172.31.10.20
dstIP               172.31.10.11
IPProtocol          6
TCPSrcPort          80
TCPDstPort          50768
TCPFlags            24

Três campos explicam o mecanismo inteiro. O meanSkipCount declara a taxa em vigor. Em seguida, o sampledPacketSize traz o tamanho do quadro na rede, aqui 330 bytes. Por fim, o headerLen mostra quanto disso o agente enviou: 128 bytes, o padrão do protocolo.

A distinção entre os dois últimos costuma passar despercebida. O coletor sabe o tamanho real de cada pacote amostrado, mesmo sem receber o pacote inteiro. Dessa forma, a conta de bytes usa o tamanho declarado, nunca os 128 bytes que trafegaram.

Os contadores de interface (Counter Samples) são coletados a intervalos configuráveis (tipicamente a cada 30 segundos) e contêm métricas como bytes transmitidos e recebidos, pacotes descartados, erros de interface e utilização de banda. Esses contadores permitem monitorar latência e saturação de links ao longo do tempo.

O contador não passa por amostragem nenhuma. O agente lê o valor inteiro do dispositivo, então o número é exato:

sampleType       COUNTERSSAMPLE
ifName           eth0
ifSpeed          10000000000
ifInOctets       37308564    # exato, não estimado
ifInUcastPkts    25074
ifInDiscards     0
ifInErrors       0
ifOutOctets      352124
ifOutUcastPkts   4386

Na prática, os dois tipos dividem o trabalho. Assim, o Counter Sample responde quanto passou no link, sem margem de erro. Já a Flow Sample mostra a composição desse volume, com o erro que a taxa de amostragem impõe.

Combinados, os dois tipos de dado permitem respostas a perguntas operacionais concretas: qual host está consumindo a maior parte da banda de um link WAN? Qual protocolo representa a maior fração do tráfego em horário de pico? Qual switch tem interfaces com taxa de descarte elevada?

Casos de uso práticos em ambientes corporativos

O sFlow tem aplicação direta em quatro cenários comuns de operação de redes corporativas.

O primeiro é o planejamento de capacidade: coletando amostras por semanas ou meses, equipes de NOC identificam tendências de crescimento de tráfego em links críticos antes que a saturação gere impacto em usuários. O sFlow é mais adequado que o SNMP para esse objetivo porque permite identificar quais aplicações ou hosts impulsionam o crescimento, não apenas o volume total.

O segundo é a detecção de anomalias de segurança: picos súbitos de tráfego UDP a partir de múltiplos hosts internos podem indicar tráfego de botnet ou DDoS. Varreduras de porta aparecem como distribuição anormal de conexões para múltiplos destinos. O sFlow, por amostrar pacotes em tempo real, pode detectar essas anomalias em segundos, enquanto ferramentas baseadas em fluxo acumulado levam dezenas de segundos para exportar os primeiros registros.

O terceiro é a troubleshooting de performance: quando usuários relatam lentidão em aplicações críticas, os dados do sFlow permitem identificar rapidamente qual host ou protocolo está consumindo banda de forma desproporcional no segmento afetado.

O quarto é a validação de políticas de QoS: comparando a distribuição de tráfego observada pelo sFlow com as políticas de priorização configuradas nos dispositivos, equipes identificam se o tráfego crítico está de fato recebendo a prioridade esperada.

A especificação oficial do sFlow, mantida pela sflow.org, descreve o protocolo como padrão aberto. Ela documenta os formatos de datagrama suportados nas versões 2, 4 e 5. A versão 5 é a mais amplamente implementada e suportada pelas principais ferramentas de análise de tráfego do mercado. Ela não tem RFC própria: a RFC 3176 é informativa e descreve a versão 4.

A escolha da ferramenta de análise impacta diretamente o que é possível extrair dos dados. Algumas soluções, como o OpMon (desenvolvido pela OpServices), suportam sFlow nativamente e permitem visualizar os dados em dashboards com drilldown por interface, protocolo e endereço IP.

Conclusão

O protocolo sFlow é a escolha técnica mais indicada para monitoramento de tráfego em redes multi-vendor de alta velocidade, onde o impacto no desempenho dos dispositivos é uma restrição real. Sua arquitetura de amostragem a velocidade de linha, com visibilidade de camada 2 a camada 7 e suporte nativo na maioria dos fabricantes, torna o sFlow uma ferramenta versátil para planejamento de capacidade, detecção de anomalias e troubleshooting operacional.

A limitação da amostragem estatística é real, mas na prática é aceitável para os casos de uso mais comuns: identificar tendências, detectar top talkers e monitorar a saúde dos links ao longo do tempo.

A OpServices oferece monitoramento de tráfego com suporte a sFlow e NetFlow, com visibilidade em tempo real por protocolo, host e aplicação. Para estruturar o monitoramento de tráfego da sua rede, fale com nossos especialistas.