NetFlow: o que é, como funciona e por que usar no monitoramento de redes

O que é Netflow
Pedro Tebaldi Autor: Pedro Tebaldi PM do KeepGreenEdnilson Correa Revisão técnica: Ednilson Correa SRE
Publicado jan/2015Atualizado set/2026

Quando o time de redes recebe a chamada de "a rede está lenta", o problema é saber onde fica o gargalo. O SNMP mostra que a interface encostou no teto de utilização. Porém não diz quem consome essa banda, para quais destinos nem se há tráfego anômalo no caminho.

É para isso que existe o NetFlow. Ele transforma o roteador ou o switch em fonte de dados sobre o tráfego, com fluxo, aplicação e host identificados um a um. Ou seja, essa é a granularidade que o SNMP não entrega.

Neste artigo você vai ver o que é NetFlow, como funciona a arquitetura de coleta e como as versões se diferenciam.

Além disso, todo número aqui saiu de laboratório próprio. O exportador é o softflowd 1.1.1 mandando NetFlow v9 para o nfdump 1.7.5, medido em 1º de setembro de 2026.

 

O que é NetFlow

NetFlow é um protocolo de monitoramento de fluxo de tráfego desenvolvido pela Cisco Systems e padronizado pelo IETF como RFC 3954.

Ele coleta metadados sobre os pacotes IP que passam por uma interface de rede. Em seguida, agrupa esses metadados em fluxos, ou seja, sequências unidirecionais de pacotes com atributos em comum.

Um fluxo NetFlow clássico é identificado por 7 campos: IP de origem, IP de destino, porta de origem, porta de destino e protocolo IP. Somam-se ainda a interface de entrada e o Type of Service (ToS). Qualquer pacote que compartilhe esses 7 valores pertence ao mesmo fluxo.

 
Esses campos não são abstração: eles são as colunas que o coletor devolve. Por exemplo, o bloco abaixo veio do nfdump lendo os fluxos que o laboratório gerou.




terminal
nfdump -R /data -o "fmt:%pr %sap -> %dap %flg %pkt %byt %td" -c 8 'proto tcp'
Proto      Src IP Addr:Port          Dst IP Addr:Port     Flags  Packets    Bytes Duration
TCP        172.31.9.11:50638 ->      172.31.9.20:80    ...AP.SF       95     5189     00:00:00.003
TCP        172.31.9.20:80    ->      172.31.9.11:50638 ...AP.SF      196    8.7 M     00:00:00.003
TCP        172.31.9.11:50648 ->      172.31.9.20:80    ...AP.SF      116     6125     00:00:00.004
TCP        172.31.9.20:80    ->      172.31.9.11:50648 ...AP.SF      200    8.4 M     00:00:00.004
TCP        172.31.9.12:45200 ->      172.31.9.20:8080  ...AP.SF       52     2841     00:00:00.002
TCP        172.31.9.20:8080  ->      172.31.9.12:45200 ...AP.SF       63    2.1 M     00:00:00.002
TCP        172.31.9.12:45216 ->      172.31.9.20:8080  ...AP.SF       63     3377     00:00:00.002
TCP        172.31.9.20:8080  ->      172.31.9.12:45216 ...AP.SF       69    2.1 M     00:00:00.002

 
Duas leituras saltam da saída. A primeira é a assimetria: o cliente 172.31.9.11 enviou 5.189 bytes e recebeu 8,7 MB no mesmo par de fluxos. A segunda são as flags acumuladas, onde o S e o F mostram a conexão aberta por SYN e encerrada por FIN.

Analisar o fluxo em vez do pacote individual é o que torna o NetFlow escalável para ambiente de alta largura de banda. Assim, em vez de inspecionar cada byte da interface, o protocolo sumariza o comportamento e exporta registros consolidados.

 

Como funciona a arquitetura NetFlow

Três componentes operam em sequência para o NetFlow funcionar dentro da rede.

 
O diagrama abaixo resume o caminho do dado e o que cada etapa custou no laboratório.

 
Diagrama das três etapas do NetFlow: exportador que agrupa pacotes por 7 campos, coletor que grava 146 bytes por registro e analisador com os top talkers

 

 

Exportador

O exportador é o dispositivo de rede habilitado para NetFlow, em geral um roteador, switch ou firewall. Com o NetFlow ativo em uma interface, o exportador passa a observar os pacotes que entram por ela. Em seguida, identifica os fluxos e mantém em memória a tabela dos que seguem ativos, o NetFlow Cache.

São quatro as situações em que o exportador manda o fluxo ao coletor. Inatividade acima de 15 segundos, duração acima de 30 minutos, encerramento da conexão TCP por FIN ou RST, ou tabela de fluxos cheia.

 

Coletor

O coletor recebe, armazena e pré-processa os registros NetFlow que chegam por UDP. Assim, ele centraliza os dados de vários exportadores num ponto único de análise. Em ambientes corporativos complexos, o coletor permite correlacionar tráfego que atravessa diferentes pontos da topologia, construindo uma visão unificada do comportamento da rede.

 

Analisador

O analisador é a interface de análise e visualização dos dados coletados. Portanto, é de lá que saem os relatórios de top talkers, top protocols, anomalias e tendências de utilização. Esses relatórios sustentam as decisões operacionais e as de capacidade.

 

Versões do NetFlow e protocolos relacionados

Com o tempo, o protocolo evoluiu. Por isso, versões diferentes coexistem na mesma rede corporativa. A escolha muda o que o coletor consegue enxergar.

NetFlow v5 é a versão mais implantada em roteador Cisco legado. Define um conjunto fixo de campos, atende apenas IPv4 e não aceita campo customizado. Por outro lado, é simples de configurar e toda ferramenta de análise lê.

NetFlow v9 introduz os templates: o próprio exportador declara quais campos compõem cada registro. Dessa forma, ele acomoda IPv6, MPLS, BGP e VLAN. Além disso, é a base sobre a qual o IPFIX nasceu.

 
IPFIX é o padrão aberto do IETF derivado do NetFlow v9, às vezes chamado de NetFlow v10.

A especificação em vigor é a RFC 7011, elevada a norma STD 77 em 2013, que substituiu a RFC 5101.

Além disso, fora da Cisco, fabricantes entregam variantes compatíveis como Juniper J-Flow e Huawei NetStream.

sFlow amostra pacotes em vez de rastrear o fluxo inteiro. Ele inspeciona 1 em cada N pacotes. Consequentemente, custa menos CPU e entrega menos precisão.

A versão em uso é a sFlow v5, mantida pela sflow.org, enquanto a RFC 3176 documenta a versão 4.

 

Protocolo Norma IPv6 Templates Amostragem Onde aparece
NetFlow v5 formato da Cisco, sem RFC não não, campos fixos não roteador Cisco legado
NetFlow v9 RFC 3954 (informativa, 2004) sim sim opcional Cisco e boa parte do mercado
IPFIX RFC 7011, norma STD 77 (2013) sim sim, com elementos da IANA sim padrão aberto multi-vendor
sFlow sFlow v5, da sflow.org sim não, estruturas fixas sempre, 1 em cada N switch de alta velocidade

 
Nesse sentido, a linha que decide costuma ser a do IPv6. Rede que já roteia IPv6 e exporta em v5 perde metade do inventário sem aviso, porque o formato antigo não tem onde escrever o endereço.

 

NetFlow vs. SNMP: qual a diferença real

A comparação entre SNMP e NetFlow é recorrente. As duas tecnologias são complementares, não excludentes.

O SNMP coleta dados do estado do dispositivo: utilização de CPU, memória, status de interface, erros de pacotes, utilização de banda em bytes totais. É excelente para saber que a interface está congestionada. Mas não diz o porquê.

O NetFlow coleta dados do comportamento do tráfego: quem está gerando esse tráfego, para quais destinos, usando quais aplicações e protocolos. Nesse sentido, é a camada analítica que explica o que o SNMP apenas detecta.

Uma estratégia madura de monitoramento de infraestrutura usa os dois. O SNMP alerta sobre a condição do ativo. O NetFlow diagnostica a causa raiz do problema de rede em tempo útil.

 

Casos de uso operacionais do NetFlow

O NetFlow resolve problemas concretos que o monitoramento só com SNMP não alcança.

Identificação de top talkers: descobrir quais hosts, aplicações ou departamentos consomem mais banda. Inclusive, é o insumo da política de QoS e do chargeback por centro de custo.

 
No laboratório, a resposta a essa pergunta coube em uma linha de comando.




terminal
nfdump -R /data -s srcip/bytes -n 5
Top 5 Src IP Addr ordered by bytes:
Date first seen             Duration     Proto       Src IP Addr    Flows(%)     Packets(%)       Bytes(%)
2026-09-01 15:23:30.913     00:00:33.087 any         172.31.9.20       47(46.1)      861(53.6)   23.8 M(99.8)
2026-09-01 15:23:30.962     00:00:00.196 any         172.31.9.13       30(29.4)      240(14.9)    15450( 0.1)
2026-09-01 15:23:30.913     00:00:00.014 any         172.31.9.11        2( 2.0)      211(13.1)    11314( 0.0)
2026-09-01 15:23:30.934     00:00:00.020 any         172.31.9.12        3( 2.9)      176(11.0)     9491( 0.0)
2026-09-01 15:23:31.166     00:00:32.834 any         172.31.9.14       14(13.7)      107( 6.7)     7518( 0.0)
# Summary: total flows: 102, total bytes: 23.8 M, total packets: 1607

 
O topo da lista é o servidor, não o usuário. Como o registro de fluxo é unidirecional, quem serve o arquivo aparece como maior emissor, enquanto quem pediu o download fica no rodapé da tabela.

Por isso a leitura de top talkers começa pela direção. O host 172.31.9.13 abriu 30 fluxos somando 15.450 bytes. Já o 172.31.9.11 aparece com 11.314 bytes enviados, embora tenha puxado 17 MB do servidor.

Detecção de anomalias e ameaças: varredura de porta, DDoS distribuído e exfiltração para IP externo incomum aparecem no dado de fluxo. Inclusive, aparecem antes de o caso virar incidente no service desk. Nesse ponto o NetFlow alimenta AIOps e análise comportamental.

Planejamento de capacidade: a série histórica de fluxo revela a tendência de crescimento por segmento. Dessa forma, o dimensionamento de link e o upgrade de infraestrutura saem de dados reais, não de estimativa. É o mesmo insumo do monitoramento contínuo do tráfego.

Validação de QoS: conferir se a política de qualidade de serviço para ERP, VoIP e videoconferência chega mesmo ao roteador. Vale sobretudo em rede MPLS, onde ler a configuração não prova o que acontece com o pacote.

Resposta a incidentes e forense: o registro de fluxo reconstrói o comportamento da rede no momento do ataque. Quais IPs conversaram, quanto trafegou, em que janela de tempo. Por fim, esse material entra direto no postmortem.

 

Boas práticas de implementação

Quatro decisões de implantação afetam direto a qualidade do dado coletado.

Posicionamento dos exportadores: ligar o NetFlow no centro da topologia, isto é, nos roteadores de core e de borda, dá visibilidade do tráfego agregado. Por outro lado, ligar em todo lugar sobrecarrega a CPU dos equipamentos.

Sampled NetFlow: em interfaces de altíssima velocidade (10Gbps+), o rastreamento de todos os fluxos pode comprometer a CPU do roteador. Nesse caso, o Sampled NetFlow examina 1 em cada N pacotes e reduz o overhead. Em seguida, a análise reajusta os volumes de forma estatística.

Versionamento consistente: misturar v5 e v9 no mesmo ambiente sem uma ferramenta de coleta compatível com ambos gera gaps de dados. Portanto, definir uma versão padrão por tipo de dispositivo simplifica a operação.

Retenção de dados: o volume em disco decide a política. Esse volume é medível antes da compra. No laboratório, o coletor gravou 102 registros em 14.918 bytes, ou seja, 146 bytes por registro.

Nessa proporção, um exportador que sustente 1.000 fluxos por segundo produz cerca de 12,6 GB por dia. Portanto, guardar dado granular por 7 a 30 dias e agregado por 12 meses é decisão de orçamento, não de gosto.

 

Redes & Tráfego

Identificamos gargalos de rede antes que virem incidentes críticos.

Análise de tráfego com NetFlow, sFlow e SNMP para mapeamento completo de latência, perda de pacotes e capacidade de banda.

Fale com um Especialista →

 

Conclusão

O NetFlow é a base da visibilidade de tráfego em rede corporativa. Sem ele, a operação trabalha com instrumentação parcial: sabe que há um problema, porém não tem o dado para apontar a causa a tempo.

Em resumo, o SNMP cobre o estado do ativo e o NetFlow cobre o comportamento do tráfego. Juntas, as duas leituras fecham a gestão da rede.

Com exportador bem posicionado, coletor centralizado e analisador integrado ao NOC, o dado de fluxo vira capacidade real de diagnóstico. É o que separa responder ao incidente de adivinhar a causa.

A OpServices oferece o OpMon Traffic Analyzer para monitoramento de tráfego via NetFlow e sFlow, integrado ao ecossistema de monitoramento de infraestrutura OpMon. Para entender como estruturar a visibilidade de rede da sua operação, fale com nossos especialistas.

 

Perguntas Frequentes

O que é NetFlow?
NetFlow é um protocolo desenvolvido pela Cisco que coleta metadados sobre o tráfego IP que passa por dispositivos de rede, agrupando-os em fluxos. Ele permite identificar quais hosts, aplicações e protocolos consomem largura de banda, detectar anomalias e planejar capacidade com base em dados reais de tráfego.
Como o NetFlow funciona?
O NetFlow funciona em três etapas: o exportador (roteador ou switch) coleta dados de fluxo e os envia via UDP ao coletor, que armazena e pré-processa os registros. O analisador processa esses dados para gerar relatórios de tráfego, anomalias e tendências para a equipe de redes.
Qual a diferença entre NetFlow e SNMP?
O SNMP monitora o estado dos dispositivos de rede (utilização de CPU, status de interface, bytes totais). O NetFlow monitora o comportamento do tráfego (quem gera, para onde vai, qual aplicação). As duas tecnologias são complementares: SNMP detecta que a rede está congestionada; NetFlow explica o porquê.
Qual a diferença entre NetFlow v5, v9 e IPFIX?
O NetFlow v5 usa campos fixos e atende apenas IPv4. O NetFlow v9 introduz templates flexíveis, com suporte a IPv6 e MPLS. O IPFIX é o padrão aberto do IETF derivado do v9, especificado na RFC 7011, que é norma STD 77 desde 2013 e substituiu a RFC 5101. Em ambiente multi-vendor, o IPFIX é a escolha recomendada.
NetFlow impacta a performance do roteador?
Sim, o NetFlow consome CPU do roteador para rastrear os fluxos. Em interfaces de alta velocidade, recomenda-se usar o Sampled NetFlow, que analisa apenas 1 em cada N pacotes, reduzindo o overhead computacional enquanto mantém visibilidade estatística do tráfego. O posicionamento estratégico dos exportadores também ajuda a minimizar o impacto.
Acompanhe a OpServices10.576 profissionais de TI já seguemSeguir

Estou na OpServices desde 2011, onde sou Gerente de Marketing e Product Manager do KeepGreen, plataforma de gestão de incidentes de TI que higieniza alertas, aponta causa raiz com IA, escreve o post-mortem e analisa custos de nuvem. Também lidero os projetos de governança de inteligência artificial da empresa. Escrevo neste blog desde 2013, com mais de 550 artigos publicados sobre monitoramento, observabilidade, SRE e ITSM. LinkedIn

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *