Detections
Analytics
1.5.3 Configure Netflow on Strategic Ports
Warning! Audit Deprecated
This audit has been deprecated and will be removed in a future update.
View Next Audit VersionInformation
Netflow allows for detailed logging of transit traffic. For a Layer 3 Netflow configuration, this outlines several values identified as 'keys': source and destination ports and protocols, source and destination IP addresses as well as traffic volumes in any combination. Sometimes QOS values (TOS bits only) is also used as a key. Each combination of Protocol, source port, destination port, source IP, destination IP is called a 'tuple'. The possible keys in a Layer 2 Tuple include source mac address, destination mac address, ethertype and vlan.In most cases logging to this level is not recommended for all ports of an NX-OS device, with 10G or faster ports there is just too much data to log and process in a meaningful way, even with sampling (which is required).
However, for strategic ports (for instance, something facing a WAN link or traffic constrained server) this can be a good tool for troubleshooting. This sort of logging does take a fair amount of host resources, so if there is an upstream firewall or router, that device is often better suited to be a Netflow initiator, but if for instance the upstream device is owned by a carrier or a client, or is a host that needs this sort of telemetry, most NX-OS devices are certainly capable of providing Netflow telemetry.
On many NX-OS platforms only inbound Netflow is supported.
Rationale:
Impact:
If monitored graphically, often just a visual inspection of the netflow graphs will highlight anomalous traffic. For instance, a high volume exfiltration from a database server would show a spike of traffic from that database server to a host on the internet (which in most environments is not a normal pattern).
In many cases the netflow database can be queried directly, so anomalies can be queried for programmatically. However, coding 'what is not normal' is not something that is easily done in procedural languages. AI or ML frameworks such as TensorFlow may be helpful in this situation.
Solution
If needed, either Layer 3 or Layer 2 netflow can be configured.Layer 3 IP and IPv6 flow monitors can be applied to VLANs, SVIs, Layer 3 routed interfaces or subinterfaces.
Layer 2 flow monitors can be applied to a physical interface or trunks
L3 netflow - typical application to a VLAN is shown
First, enable the netflow feature:
switch(config)#feature netflow
The flow record defines what data to record and export. Typical settings are shown, the important thing is that a valid flow record setting exists:
switch(config)# flow-record FLOW-RECORD
switch(config-flow-record)# match ipv4 protocol
switch(config-flow-record)# match ipv4 source address
switch(config-flow-record)# match ipv4 destination address
switch(config-flow-record)# match transport source-port
switch(config-flow-record)# match transport destination-port
switch(config-flow-record)# collect routing source as
switch(config-flow-record)# collect routing destination as
switch(config-flow-record)# collect transport tcp flags
switch(config-flow-record)# collect counter bytes
switch(config-flow-record)# collect counter packets
The flow exporter defines the destination and options around sent data. Again, the specific values are not important. The VRF can be specified in the 'destination' line if needed.:
switch(config)# flow exporter FLOW-EXPORT
switch(config-flow-exporter)# transport udp 9996
switch(config-flow-exporter)# destination 10.10.10.10
switch(config-flow-exporter)# source mgmt 0
switch(config-flow-exporter)# version 9
switch(config-flow-exporter-version-9)# option exporter-stats timeout 120
switch(config-flow-exporter-version-9)# option interface-table timeout 120
The flow monitor 'ties' the exporter and record together:
switch(config)# flow monitor FLOW-MONITOR
switch(config-flow-monitor)# exporter FLOW-EXPORT
switch(config-flow-monitor)# record FLOW-RECORD
The sampling rate, 'x packets out of y' can also be defined. Both should be a power of 2 (for instance, 8 out-of 64 is a valid combination)
switch(config)#sampler FLOWSAMPLER01
switch(config-flow-sampler)# mode 8 out-of 64
Finally, apply the monitor and optionally the sampler to a layer 3 interface:
switch(config-flow-monitor)# int vlan <interface number>
10GCORE01(config-if)# ip flow monitor FLOW-MONITOR input sampler FLOWSAMPLER01
=======================================
**L2 netflow - typical application to physical interface shown **
Because if it's reliance on MAC Addresses, L2 netflow implementations are much less often used
switch(config)#feature netflow
The exporter configuration remains the same as L3:
switch(config)# flow exporter L2_FLOWEXPORTER01
switch(config-flow-exporter)# destination <netflow server ip> [use-vrf management]
switch(config-flow-exporter)# transport udp <netflow port>
switch(config-flow-exporter)# source mgmt0
switch(config-flow-exporter)# version 9
The flow record reflects different (layer 2) tuple inputs:
switch(config)# flow record L2_FLOWRECORD01
switch(config-flow-record)# match datalink ethertype
switch(config-flow-record)# match datalink mac source-address
switch(config-flow-record)# match datalink mac destination-address
switch(config-flow-record)# match datalink vlan
The flow monitor remains similar:
switch(config)# flow monitor L2_FLOWMONITOR01
switch(config-flow-monitor)# record L2_FLOWRECORD01
switch(config-flow-monitor)# exporter L2_FLOWEXPORTER01
The flow sampler commands remain the same
switch(config)#sampler FLOWSAMPLER01
switch(config-flow-sampler)# mode <x> out-of <y>
Finally, apply the L2 definition to an L2 interface:
switch(config)# int Ethernet x/yy
switch(config-if)# layer2-switched flow monitor L2_FLOWMONITOR01 input sampler FLOWSAMPLER01
Default Value:
Netflow is not defined by default.
See Also
Item Details
Audit Name: CIS Cisco NX-OS L1 v1.0.0
References: CSCv7|6.3
Plugin: Cisco
Control ID: a245c5bb2530c17fc3ea3369a5deb3e210a78437a07d856b4a2c25a14a80067c