netflow config with eta

[virtualpedia]

I have a few stealthwatch questions that I hope the community can help answer.

For the Cat 9300s with ETA enabled, my current netflow config looks like this

flow record SW-RECORD
match datalink mac source address input
match datalink mac destination address input
match datalink vlan input
match ipv4 ttl
match ipv4 tos
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match interface input
collect interface output
collect counter bytes long
collect counter packets long
collect timestamp absolute first
collect timestamp absolute last

I believe the below is the correct config for 9300's with ETA enabled (correct me if I'm wrong)

match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect counter bytes long
collect counter packets long
collect timestamp absolute first
collect timestamp absolute last

My question is, what kind of issues can arise with the current configuration? Also, should ETA be enabled on ports that connect to cisco access points? I currently use vWLC

[brford]

That's a good looking  9300 NetFlow for Stealthwatch config but it doesn't enable ETA.

While Encrypted Traffic Analytics (ETA) currently uses Cisco NetFlow v9 as it's transport (export) protocol it is not enabled as part of the standard NetFlow configuration.  You want to take a look at the 'et-analytics ...' commands in order to enable ETA processing and export.

The ETA process on the 9300 is separate from the NetFlow process.  ETA uses one of the available exporters; so if you configure NetFlow as you described and enable ETA your device will report 2 exporters.

For the 9300 see: 

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-6/configuration_guide/nmgmt/b_166_nmgmt_9300_cg/b_166_nmgmt_9300_cg_chapter_01000.pdf

[virtualpedia]

Thanks for the reply.  Yes, I have ETA already configured.  My question was really what problem is created by using the first netflow configuration vs the second. 

I'm going with the second config as that is what is recommended by Cisco, but I was just curious

[brford]

OK.  For this flow record to work with Cisco Stealthwatch (v6.10 or later) you'll need the following:

match ipv4 proto

match ipv4 source addr

match ipv4 destination addr

match transport source-port

match transport destination-port

match ipv4 tos

collect interface out

collect counter bytes

collect counter packets

collect timestamp sys-uptime first

collect timestamp sys-uptime last

These are REQUIRED flow record fields for Stealthwatch v6.10 and later. 

You can add the following optional data elements to that flow record:

collect routing next-hop address ipv4 (used for closest interface determination)

collectipv4 ttl minimum

collect ipv4 ttl max (these two data elements are used to understand the path of the flow through the network)

collect transport tcp flag (to gain more insight into TCP connections) 

[virtualpedia]

Hi @brford 

Appreciate the reply.  There is where the configuration becomes confusing.

Per this guide, I see the configuration that you posted, which includes the required fields that you specified.

https://www.cisco.com/c/dam/en/us/td/docs/security/stealthwatch/netflow/config-trouble-netflow-stealth.pdf

However, also per this guide, if you scroll down, it shows the below, which was the tested configuration for Cat9K.

Netflow with Encrypted Traffic Analytics (ETA) on Catalyst 9k example
When configuring ETA to work with Stealthwatch you will configure both a Flexible NetFlow Monitor (and enable ETA enhanced NetFlow export
(for the ETA specific fields). The below configuration was validated with IOS v16.6.2

flow record ETA-C9K-RECORD
description Flow Record for ETA with Stealthwatch
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect counter bytes long
collect counter packets long
collect timestamp absolute first
collect timestamp absolute last

Should "match ipv4 tos" be included?