Configuring FlowTracker for non-TCP Analytics
Analytics is a process where the data is collected and analyzed for storing statistics, improving performance and network security in case of any diagnostic network problems.
Starting from NetVisor OS 7.0.1 version, support for non-TCP analytics is available with the introduction of FlowTracker feature.
The main objective of the FlowTracker feature is to extend Arista Analytics solution beyond TCP to ensure visibility into DNS/ DHCP, generic UDP and ICMP echo traffic. This is done by collecting information about the non-TCP flows and creating statistical data using the Exact Match sub-system.
FlowTracker creates 5-tuples (source IP address, destination IP address, source port number, destination port number and the protocol in use) flow entries in Exact-match sub-system in the hardware. Packet and bytes statistics are also maintained for the flow in hardware. The stats data is periodically fetched from software and hence data shown in the connection-show is not real-time.
The FlowTracker feature for non-TCP analytics is available on the following platforms in NetVisor OS version 7.0.1:
- Dell: S5232F-ON, S5248F-ON
- Ericsson: NRU03, NRU-S0301
- Edgecore: AS7726-32X, AS7326-56X, AS5835-54X, AS5835-54T
- Freedom: F9432-C, F9480-V, F9460-X, F9460-T
Note: By default, the FlowTracker feature is disabled. You must reboot the switch after enabling or disabling the FlowTracker feature.
While showing DHCP or a DNS, the show command will display protocol as UDP whereas for ICMP, the protocol will be displayed as ICMP.
System vFlow entries are created to identify the broad family of protocols of interest (DHCP, DNS and other generic UDP flows) for which analytics is needed.
The first packet of the flow is copied to the CPU using the copy-to-cpu vFlow action and from the vFlow callback, a signature for the flow is extracted from the packet which consists of source IP address, destination IP address, destination (dest) port, source (src) port, protocol, ICMP type-code (in case of ICMP).
The subsequent packets for the flow are not copied to the CPU by the vFlow.
If limits are reached in the table when creating a new entry, the oldest flow is purged and that slot is reclaimed. There will be no explicit timer to age out the entries. An upper limit would be set on how many packets are copied to the CPU for each category of flows per second. Statistics from the hash table entries is collected in a periodic manner.
Note: Each entry is visited once in 8 seconds. In one second, stats are collected for a maximum of 4000 entries.
Note: Support for scale number is available for tracking a maximum of 32k Non-TCP flows.
To start the analysis for a protocol, perform the following:
- Enable the FlowTracker feature.
- Add the protocols.
Enabling and Configuring FlowTracker:
To enable the FlowTracker feature, use the command :
CLI (network-admin@switch) > system-settings-modify flow-tracker-enable
Enabling FlowTracker results in resizing of Unified Field Tables (UFT) which reduces space for L2 table.
You should reboot the system for this change to take effect.
Note: To enable the FlowTracker feature, the analytics needs to be enabled. By default, the FlowTracker feature is disabled.
To disable the FlowTracker feature, use the command:
CLI (network-admin@switch) > system-settings-modify no-flow-tracker-enable
To see if the FlowTracker is enabled, use the command:
CLI (network-admin@switch) > system-settings-show
optimize-arps: off
lldp: on
policy-based-routing: on
optimize-nd: off
reactivate-mac: on
reactivate-vxlan-tunnel-mac: on
manage-unknown-unicast: off
manage-broadcast: off
manage-wake-on-lan: off
auto-trunk: off
auto-host-bundle: off
cluster-active-active-routing: on
routing-over-vlags: off
source-mac-miss: copy-to-cpu
optimize-datapath: all
cpu-class-enable: on
usb-port: on
igmp-snoop: use-l3
vle-tracking-timeout: 3
pfc-buffer-limit: 40%
cosq-weight-auto: off
lossless-mode: off
snoop-query-stagger: no-stagger-queries
host-refresh: off
proxy-conn-retry: on
proxy-conn-max-retry: 3
proxy-conn-retry-interval: 500
optimize-rxlos: off
xcvr-link-debug: disable
fastpath-bfd: on
linkscan-interval: 150000
linkscan-mode: software
single-pass-l2-known-multicast: on
single-pass-flood: on
single-pass-riot: on
hybrid-mode: off
xcvr-oir-debug-port: none
batch-move-mac-hw-group-for-vlan-only: on
memory-tracker: on
bcm-ctr-thread-freq: 1
symmetric-hash: off
hash-suppress-unidir-fields: off
bcm-interrupt-timeout: 2000
prioritize-rx-reasons: off
hash-inner-ip-over-gre: on
multiple-tunnel-next-hops: on
l3-use-host-table: off
offline-notification-new-thread: off
uplink-oversubscription-action: default
flow-tracker-enable: on
Note: By default, the FlowTracker feature is disabled. You must reboot the switch after enabling or disabling FlowTracker.
When analytics is enabled, it is enabled only for TCP by default. To enable it for non-TCP protocols, Flow-Tracker needs to be enabled as well. After the feature is enabled, to start the analysis for a particular protocol, it needs to be added separately using the CLI flow-tracker-add-protocol protocol <protocol>.
You can monitor the following protocols using the FlowTracker:
- DNS
- NTP
- DHCP
- ping4
- UDP
- ping6
- DHCPv6
To enable the analysis for any of the protocols, you need to first add the protocol by using the command:
CLI (network-admin@switch) > flow-tracker-add-protocol protocol <protocol> server-port <port>
To stop the analysis for a particular protocol and remove it from the analytics list, use the command.
CLI (network-admin@switch) > flow-tracker-remove-protocol protocol <protocol> server-port <port>
Note: The server-port is needed only in case of protocol choice of UDP. For other protocols, the server-port is not valid.
Note: In case of any UDP-based protocols, both client side and server side flows are captured for analysis.
Note: For ping4 and ping6, both echo request and reply are captured.
To see which protocols are enabled for analysis, use the command:
CLI (network-admin@switch) > flow-tracker-show
switch protocol server-port
------ -------- -----------
switch ping4
switch udp 20010
To view the flows that are being monitored after adding an ICMP protocol, use the command:
CLI (network-admin@switch) > connection-show
switch vlan src-ip dst-ip proto icmp_type obytes total-bytes total-pkts age
------ ---- -------------- -------------- ----- --------- ------ ----------- ---------- ---
switch 1 200.220.220.20 200.220.220.10 icmp reply 204 204 2 3s
switch 1 200.220.220.10 200.220.220.20 icmp echo 204 204 2 3s
switch 1 200.220.220.10 200.220.220.20 icmp reply 204 204 2 11s
switch 1 200.220.220.20 200.220.220.10 icmp echo 204 204 2 11s
To view the flows that are being monitored after adding a UDP protocol, use the command:
CLI (network-admin@switch) > connection-show
switch vlan src-ip dst-ip src-port dst-port proto obytes total-bytes total-pkts age
------ ---- -------------- -------------- -------- -------- ----- ------ ----------- ---------- ---
switch 1 200.220.220.10 200.220.220.20 42155 20010 udp 64 64 1 5s
switch 1 200.220.220.10 200.220.220.20 41882 20010 udp 11s
Note: Connections that are created in the non-TCP FlowTracker feature are seen using the same commands as in TCP.
While adding a DHCP, the protocol is displayed as UDP. Only for ICMP, the protocol will be displayed as ICMP whereas for DHCP or DNS, the connection-show will display protocol as UDP. The destination (dst) port helps to identify the application.
Note: For details regarding the protocol in use, refer the destination (dst) port.
To clear the entries from the table while the protocol is still enabled for analysis, use the command:
CLI (network-admin@switch) > connection-clear
Limitations and Guidelines
The non-TCP flows are first matched using vFlows and hence have the following limitations:
- The first packet of the flow is copied to CPU, which causes CPU load and bandwidth utilization of vFlow queues.
- Exact Match does not work with VXLAN encapsulated packets and hence the solution can work only on leaf nodes.