Netflow configuration file
How to edit this file.
/usr/local/share/trisul-probe/cfgedit then select “Netflow” to edit. See Plugin Configuration
In a file called PI-7CA09636-02D4-45E7-AA00-BE0D49B94E26.xml in /usr/local/etc/trisul-probe/domainX/probeX/contextX
The following nodes under the global Netflow policy.
|MeterHosts||True||Whether or not traffic stats for each host is metered.|
|MeterSubnets||TRUE||Whether or not traffic stats for each subnet is metered.|
|MeterApplications||TRUE||Whether or not traffic stats for each application is metered. In this context application refers to the UDP/TCP port or to special network level apps like ICMP, IPSEC, etc. In case of TCP/UDP ports, the default behavior is to only meter the lower numbered port. This works in most cases, but if you want to count both ports, set the MeterBothPorts parameter.|
|MeterNetflowSources||TRUE||If set, Trisul tracks traffic volume from each exporting router. The meters tracked are
Netflow export rate in bytes
Netflow export rate in records
Total traffic volume on router in bytes
|MeterNetflowInterfaces||TRUE||If set, Trisul tracks traffic into and out of network interfaces.|
|MergeMultipleSources||TRUE||If set, duplicate flows from different routers will be merged.|
|MatchBiDirectionalFlows||TRUE||Netflow records are unidirectional. If set, Trisul will merge two unidirectional flows into one bidirectional flow.
If you set this option to false, Trisul will retain the uni-directional flow as-is.
|UseRouterTimestamps||FALSE||If set, Trisul will use the timestamp from the Netflow records.
If not set, Trisul will use the timestamp at the server running Trisul. This is the default and recommended option unless you have routers which synchronize their timestamps automatically.
|MergeHTTP||TRUE||If set, multiple requests over HTTP between the same client and server within a time window but on different ports will be merged. The big advantage of this is a dramatic reduction in flow records without too much compromise on resolution.
Set to false, if you would rather see each individual parallel request between the same client and server separately.
|MergeHTTPS||TRUE||If set, multiple requests over HTTP between the same client and server within a time window but on different ports will be merged.|
|MergeDNS||TRUE||If set, multiple DNS name requests client and server within a time window will be merged.
Set to false, if you would rather see each individual DNS request.
|IgnoreESP||FALSE||Ignore IPSEC ESP flows. These are tunneled interfaces containing no flow information within them.|
|MeterHomeNetwork||TRUE||Classifies traffic relative to your Home Network.
INCOMING Destination IP is in your home network but Source IP is not
OUTGOING Source IP is in your home network but Destination IP is not
INTERNAL Both the Source IP and Destination IP are in your home network
TRANSIT Both the Source IP and Destination IP are not in your home network
When set to FALSE : The default behaviour of Trisul is to only meter the low numbered port. The assumption is that low numbered ports represent servers. This is usually accurate for traditional server applications that run below port 1024.
When set to TRUE : Meters both ports for applications above port 1024. Ports below 1024 (such as HTTP) are still counted in the normal way.
Set this to TRUE if you have P2P / VoIP Traffic you wish to track.
|MeterTCPConnections||TRUE||Meter connection count for the flow end points. This allows you to get basic reports for hosts with maximum connections, etc. With Netflow it is not possible to accurately determine client-server status of any given flow. So we count the aggregate flow count. In other words, for any TCP flow, both the client and server end points are metered.|
|MeterAppConnections||TRUE||Meter connection count for the TCP based application. This option is required if you want connection based reports for applications. For ports < 1024, the lower numbered port is metered, for others both the ports are metered.|
|FilterInterfacesInclude||A comma separated list of interfaces.
When set, Trisul will accept and process flows that exit or enter these interfaces.
IMPORTANT The list of interfaces must be in trisul key format (IP address of router _ interface id)
If you only want to accept flows that use the WAN link (if Index = 108) on router (18.104.22.168) and T3 link (ifIndex = 120) also on router (22.214.171.124)
You have the two interfaces as follows
In key format (both the IP and ifindex are converted to hex) to yield
|FilterInterfacesExclude||A comma separated list of interfaces.
When set, Trisul will only process flows that DO NOT use these interfaces.
The format is same as the parameter FilterInterfacesInclude
NOTICE Note that you cant use the FilterInterfacesInclude and Exclude parameters at the same time.
|CheckPacketsForCorruption||FALSE||Turns on heuristics to check each netflow record for corruption. Use this option when you see the problem on the field. We have seen this in production environments where unpatched routers can transmit corrupted records.
To enable strict checking, add the following line
|LogTemplateMessages||TRUE||If enabled , Trisul will log template updates to the probe log files. Disable if you feel there are too many of these messages.|
|IgnoreV9EgressFromDevices||Sometimes we find that customers erroneously enable both Netflow v9 INGRESS and EGRESS on all ports. This will result in double counting. The solution is to only configure INGRESS+EGRESS on a single port such as the uplink ports. Oftentimes, we are unable to get the Netflow change request done. This option allows you to adjust for this. This option contains a comma separated list of IP addresses of devices from which Trisul will ignore EGRESS netflow V9 records. The following example ignores Netflow v9 EGRESS from two devices
|EnableShimTunnel||FALSE||If Enabled, Trisul will decapsulate the special SHIM tunnel used to forward Netflow packets from a remote network to the Trisul probe. Normal Netflow will also be processed correctly. For more information see on Github netflow-shim-tunnel|
Typically you dont need to use this section. We have used this section in the past to address various firmware bugs in some devices which did not export Netflow templates correctly. Templates fields specified in this section will override those received on the network.
Some routers such as Juniper IPFIX support sampling. However the sampling rate is not sent via the IPFIX packet itself. Use this section to manually configure the sample rate. Add a separate line for each router as shown below
<SamplingRates> <Rate router="126.96.36.199" rate="100" /> </SamplingRates>