Choosing NTA Sources

Consider the following when adding NTA sources:

Review your site's policy goals and ask how flow or SNMP traffic statistics can satisfy these.
Browse the NTA Sources Library for devices already configured for flow export but not yet enabled.
Check NTA Sources Library to and Potential Netflow Sources dialog to understand which metrics are readily available (flow, SNMP, NBAR for example).
Ensure flow export or SNMP is configured and available on the source devices.

Identify Critical Paths and Potential Source Devices

Understanding the purpose of the monitoring helps you to identify the target source device.

Device	Purpose
Gateway to ISP	Measure WAN traffic movement. Application level traffic analysis. SLA and uptime auditing. Track traffic by application, geographic region, and domain. Anomaly tracking, forensics, and diagnostics.
WAN and LAN routers and significant interfaces and ports.	Capacity planning. Validate traffic rules implemented at switch. Anomaly tracking, forensics, and diagnostics.
Ingress and egress interfaces for proxy host, critical services, and head nodes.	Validate IP rules/traffic. Capacity planning. Validate load balancer function. Anomaly tracking, forensics, and diagnostics.

Browse for Devices Already Configured to Export Flow Packets

You can browse for devices which are already configured or support remote configuration MIBs from the Potential Netflow Sources dialog.

Firewall Considerations

Once a potential Network Traffic Analysis source has been identified, you should consider the location of the device with respect to other networking devices, particularly those devices that perform network address translation (NAT). Depending on where the source is located relative to the device performing NAT, traffic to and from an internal (private) IP addresses are reported differently in the exported NetFlow data.

If the device is inside the firewall, or if no firewall exists, the exported flow data includes the internal IP address for devices generating and receiving traffic. This allows you to pinpoint the exact device in the internal network to which the traffic belongs.
If the device is outside the firewall, the exported flow data aggregates all traffic to and from internal devices and reports it as belonging to a single public address belonging to the device performing the address translation. In this case, you can only determine that an internal device originated or received traffic, but you cannot pinpoint the traffic as belonging to a specific internal device.
If the device exporting flows is also performing NAT, you can configure the device to export the flow data using either the private or the public translated address, mimicking either of the above scenarios. To see internal IP addresses, configure the device to export data on ingress and egress for the internal interface. To see all traffic reported using the external translated IP address, configure the device to export data on ingress and egress for external interfaces.

NAT and Virtual Machine Considerations

Other conditions that may also change the nature of the data reported by Network Traffic Analysis include:

When address translation occurs anywhere in the path between the source and the destination, IP addresses reported are altered to include the translated address. In most cases, this does not present a problem, but it may require monitoring multiple flow-enabled devices to track traffic in complex network environments.
Virtual private networks and other tunneling technology (such as ESP or SSH) can appear to distort reports. In these cases, Network Traffic Analysis reports large amounts of traffic sent over a small number of flows. This is expected behavior, as VPNs and other tunnels aggregate traffic from multiple connections and funnel it through a single connection.