What NetFlow sees, what it misses and where sensors belong
You do not need an exporter on every endpoint, but you do need observation at the boundaries traffic actually crosses.
Network visibility projects often begin with an impossible requirement: install an agent or exporter everywhere. Flow telemetry works differently. Routers, firewalls, switches and virtual network layers can summarize connections they already forward.
Choose the evidence you need
NetFlow and IPFIX describe conversations: source and destination addresses, ports, protocol, byte and packet counts, interfaces and timing. sFlow samples packets and counters. These formats are efficient for discovering talkers, unexpected destinations, scans and volumetric changes.
They do not provide complete packet payloads. Encrypted application content remains encrypted, and sampled records cannot reconstruct every exchange. Use full packet capture or protocol-aware sensors only where that depth is justified.
Place collection at traffic boundaries
A gateway exporter observes internet ingress and egress that passes through it. It will not necessarily observe two devices communicating through the same access switch or virtual bridge. For east-west visibility, enable flow export on the relevant switching, firewall, hypervisor or cloud network layer.
SPAN or TAP sends a copy of packets to a sensor. It adds deeper inspection but requires capacity planning, careful port selection and secure retention. The useful architecture often combines broad flow coverage with selective packet inspection.
Virtualization creates more boundaries
Traffic between virtual machines on one hypervisor may never reach the physical router. Kubernetes pod traffic can be routed, overlaid or proxied depending on the CNI and service path. Cloud workloads expose flow logs through provider APIs rather than a physical appliance.
Map the forwarding layers first: internet gateway, firewall, physical switching, hypervisor bridges, Kubernetes nodes and cloud networks. Then attach the least invasive source that can observe each important boundary.
Make new devices useful, not merely visible
An ARP or neighbor table can identify a new local device quickly. Combine that identity with DHCP, DNS, vendor information, open services and observed flows. The first useful questions are:
- Which addresses did the device contact?
- Were destinations expected for this device class?
- Did it scan many ports or peers?
- Did it expose services to the local network?
- Did its traffic volume or packet pattern depart from the baseline?
This context turns “new MAC address” into a triage decision.
Be explicit about visibility limits
A product should state whether it currently has endpoint-only, gateway-flow, switched-traffic or packet-level visibility. Operators need to know what is not observed. A confident empty graph built from the wrong vantage point is more dangerous than a clearly marked limitation.
Start at the gateway for immediate value, then add east-west sources based on asset criticality and threat model. Coverage should expand because a decision requires it, not because another exporter is available.