Conceito e mecanismo
Flexible NetFlow separa record, monitor e exporter. O record define os campos, o monitor associa cache e conteúdo e o exporter envia informação. A observação precisa de aplicação à interface e direção suportadas; criar objetos não garante recolha de tráfego. Uma migração pode deixar o monitor no caminho antigo e produzir um dashboard vazio apesar de o serviço funcionar. SPAN tem outro limite: uma porta de destino saturada pode perder cópias sem perda equivalente no encaminhamento original. Antes de transformar ausência numa captura em conclusão sobre a aplicação, confirma capacidade, âmbito e direção do ponto de observação.
Aplicação guiada
IP SLA também precisa de origem, destino e contexto de routing representativos. Um echo pela tabela global não mede automaticamente uma aplicação noutra VRF, e ICMP não demonstra commit de uma transação. Para leitura programável, NETCONF distingue get-config de get: o primeiro lê configuração do datastore indicado, enquanto o segundo permite incluir estado operacional. Verifica as capabilities antes de assumir candidate ou confirmed commit. Não são garantias decorrentes apenas de uma sessão NETCONF. Num caso fictício de passagem a RUN, conserva os pontos de recolha, critérios e limitações. A equipa deve conseguir saber o que foi medido, quando e com que contexto, para não procurar uma falha de serviço onde existe uma falha de instrumentação.
O coletor está vazio porque o monitor ficou na interface antiga, não porque o batch parou.
Armadilhas comuns
Objeto criado como recolha ativa; captura incompleta como prova de perda; ICMP como sucesso funcional; NETCONF como todas as capacidades.
Tópicos relacionados: Arquitetura e capacidade sobrevivente · Virtualização, VRFs e overlays · Switching e formação de adjacências
Guarda os limites da observação juntamente com o resultado.
Referência: Flexible NetFlow IPv4 flows · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise