Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
The following are the prerequisites for wireless Flexible NetFlow:
Ensure that the networking device is running a Cisco release that supports wireless Flexible NetFlow.
Ensure that the target is connected to a WLAN.
The networking device must be configured to support protocol types such as IP, IPv6, and datalink.
Valid flow record and monitor are required before generating the flow.
Restrictions for Flexible NetFlow
The following are restrictions for Flexible NetFlow:
Traditional NetFlow (TNF) accounting is not supported.
Flexible NetFlow v5 export format is not supported, only NetFlow v9 export format is supported.
Both ingress and egress NetFlow accounting is supported.
Microflow policing feature shares the NetFlow hardware resource with FNF.
Only one flow monitor per interface and per direction is supported.
Layer 2, IPv4, and IPv6 traffic types are supported; however, the switch can apply a flow monitor to only one of these types at a time for a given direction and interface.
Layer 2, VLAN, and Layer 3 interfaces are supported, but the switch does not support SVI and tunnels.
The following NetFlow table sizes are supported:
Trim Level
Ingress NetFlow Table
Egress NetFlow Table
LAN Base
Not supported
Not supported
IP Base
8 K
16 K
IP Services
8 K
16 K
Depending on the switch type, a switch will have one or two forwarding ASICs. The capacities listed in the above table are on a per-ASIC basis.
The NetFlow tables are on separate compartments and cannot be combined. Depending on which ASIC processed the packet, the flows will be created in the table in the corresponding ASIC.
Both full flow accounting and sampled NetFlow accounting are supported.
NetFlow hardware implementation supports four hardware samplers. You can select a sampler rate from 1 out of 2 to 1 out of 1024. Only random sampling mode is supported.
With the microflow policing feature (which is enabled only for wireless implementation), NetFlow can and should be used only in full flow mode i.e. NetFlow policing cannot be used. For wireless traffic, applying a sampler is not permitted, as it
hinders
microflow QoS.
Only full flow accounting is supported for wireless traffic.
NetFlow hardware uses hash tables internally. Hash collisions can occur in the hardware. Therefore, in spite of the internal overflow Content Addressable Memory (CAM), the actual NetFlow table utilization could be about 80 percent.
Depending on what fields are used for the flow, a single flow could take two consecutive entries. IPv6 flows also take two entries. In these situations, the effective usage of NetFlow entries is half the table size, which is separate from the above hash collision limitation.
The switch supports up to 16 flow monitors.
Microflow policing uses a separate set of flow monitors (limit 3).
SSID-based NetFlow accounting is supported. SSID is treated in a manner similar to an interface. However, certain fields are not supported (such as AP MAC address and user ID ).
NetFlow v9 format NetFlow export is supported.
The NetFlow software implementation supports distributed NetFlow export, so the flows are exported from the same switch in which the flow was created.
Ingress flows are present in the ASIC that first received the packets for the flow. Egress flows are present in the ASIC from which the packets actually left the switch set up.
The reported value for the bytes count field (called “bytes long”) is Layer-2-packet-size—18 bytes. For classic Ethernet traffic (802.3), this will be accurate. For all other Ethernet types, this field will not be accurate. Use the "bytes layer2” field, which always reports the accurate Layer 2 packet size.
For information about supported Flexible NetFlow fields, see Supported Flexible NetFlow Fields.
Information About Flexible NetFlow
NetFlow is a Cisco technology that provides statistics on packets flowing through the switch. NetFlow is the standard for acquiring IP operational data from IP networks. NetFlow provides data to enable network and security monitoring, network planning, traffic analysis, and IP accounting. Flexible NetFlow improves on original NetFlow by adding the capability to customize the traffic analysis parameters for your specific requirements. Flexible NetFlow facilitates the creation of more complex configurations for traffic analysis and data export through the use of reusable configuration components.
Flexible NetFlow uses flows to provide statistics for accounting, network monitoring, and network planning.
A flow is a unidirectional stream of packets that arrives on a source interface and has the same values for the keys. A key is an identified value for a field within the packet. You create a flow using a flow record to define the unique keys for your flow.
The switch supports the Flexible NetFlow feature that enables enhanced network anomalies and security detection. Flexible NetFlow allows you to define an optimal flow record for a particular application by selecting the keys from a large collection of predefined fields.
All key values must match for the packet to count in a given flow. A flow might gather other fields of interest, depending on the export record version that you configure. Flows are stored in the Flexible NetFlow cache.
You can export the data that Flexible NetFlow gathers for your flow by using an exporter and export this data to a remote Flexible NetFlow collector.
You define the size of the data that you want to collect for a flow using a monitor. The monitor combines the flow record and exporter with the Flexible NetFlow cache information.
The wireless Flexible NetFlow infrastructure supports the following:
Flexible NetFlow Version 9.0
User-based rate limiting
Microflow policing
Voice and video flow monitoring
Reflexive access control list (ACL)
Microflow Policing and User-Based Rate Limiting
Microflow policing associates a 2-color 1-rate policer and related drop statistics to each flow present in the NetFlow table. When the flow mask comprises all packet fields, this functionality is known as microflow policing. When the flow mask comprises either source or destination only, this functionality is known as user-based rate limiting.
Voice and Video Flow Monitoring
Voice and video flows are full flow mask-based entries. The ASIC provides the flexibility to program the policer parameters, share policers across multiple flows and rewrite the IP address and Layer 4 port numbers of these flows.
Note
For dynamic entries, the NetFlow engine will use the policer parameters that are derived for the flow based on the policy (ACL/QoS-based policies). Dynamic entries cannot share policer across multiple flows.
Reflexive ACL
Reflexive ACLs allow IP packets to be filtered based on upper-layer session information. The ACLs allow outbound traffic and limit inbound traffic in response to the sessions that originate inside the trusted network. The reflexive ACLs are transparent to the filtering mechanism until a data packet that matches the reflexive entry activates it. At this time, a temporary ACL entry is created and added to the IP-named access lists. The information obtained from the data packet to generate the reflexive ACL entry is permit/deny bit, the source IP address and port, the destination IP address, port, and the protocol type. During reflexive ACL entry evaluation, if the protocol type is either TCP or UDP, then the port information must match exactly. For other protocols, there is no port information to match. After this ACL is installed, the firewall is then opened for the reply packets to pass through. At this time, a potential hacker could have access to the network behind the firewall. To narrow this window, an idle timeout period can be defined. However, in the case of TCP, if two FIN bits or an RST is detected, the ACL entry can be removed.
A flow record defines the keys that Flexible NetFlow uses to identify packets in the flow, as well as other fields of interest that Flexible NetFlow gathers for the flow. You can define a flow record with any combination of keys and fields of interest. The switch supports a rich set of keys. A flow record also defines the types of counters gathered per flow. You can configure 64-bit packet or byte counters. The switch enables the following match fields as the defaults when you create a flow record:
The following table describes Flexible NetFlow match parameters. You must configure at least one of the following match parameters for the flow records.
Table 1 Match Parameters
Command
Purpose
match datalink {dot1q | ethertype | mac | vlan }
Specifies a match to datalink or Layer 2 fields. The following command options are available:
dot1q—Matches to the dot1q field.
ethertype—Matches to the ethertype of the packet.
mac—Matches the source or destination MAC fields.
vlan—Matches to the VLAN that the packet is located on (input or output).
match flow direction
Specifies a match to the flow identifying fields.
match interface {input | output}
Specifies a match to the interface fields. The following command options are available:
input—Matches to the input interface.
output—Matches to the output interface.
match ipv4 {destination | protocol | source | tos | ttl | version}
Specifies a match to the IPv4 fields. The following command options are available:
destination—Matches to the IPv4 destination address-based fields.
protocol—Matches to the IPv4 protocols.
source—Matches to the IPv4 source address based fields.
tos—Matches to the IPv4 Type of Service fields.
ttl—Matches to the IPv4 Time To Live fields.
version—Matches to the IP version from the IPv4 header.
match ipv6 {destination | hop-limit | protocol | source | traffic-class | version }
Specifies a match to the IPv6 fields. The following command options are available:
destination—Matches to the IPv6 destination address-based fields.
hop-limit—Matches to the IPv6 hop limit fields.
protocol—Matches to the IPv6 payload protocol fields.
source—Matches to the IPv6 source address based fields.
traffic-class—Matches to the IPv6 traffic class.
version—Matches to the IP version from the IPv6 header.
match transport {destination-port | igmp | icmp | source-port}
Specifies a match to the Transport Layer fields. The following command options are available:
destination-port—Matches to the transport destination port.
icmp—Matches to ICMP fields, including ICMP IPv4 and IPv6 fields.
igmp—Matches to IGMP fields.
source-port—Matches to the transport source port.
Flexible NetFlow Collect Parameters
The following table describes the Flexible NetFlow collect parameters.
Table 2 Collect Parameters
Command
Purpose
collect counter { bytes { layer2 { long } | long } | packets { long } }
Collects the counter fields total bytes and total packets.
collect interface {input | output}
Collects the fields from the input or output interface.
collect timestamp absolute {first | last}
Collects the fields for the absolute time the first packet was seen or the absolute time the most recent packet was last seen (in milliseconds).
collect transport tcp flags
Collects the following transport TCP flags:
ack—TCP acknowledgement flag
cwr—TCP congestion window reduced flag
ece—TCP ECN echo flag
fin—TCP finish flag
psh—TCP push flag
rst—TCP reset flag
syn—TCP synchronize flag
urg—TCP urgent flag
Note
On the switch, you cannot specify which TCP flag to collect.
You can only specify to collect transport TCP flags. All TCP flags will be collected with this command.
Exporters
An exporter contains network layer and transport layer details for the Flexible NetFlow export packet. The following table lists the configuration options for an exporter.
The switch exports data to the collector whenever a timeout occurs or when the flow is terminated (TCP Fin or Rst received, for example). You can configure the following timers to force a flow export:
Active timeout—The flow continues to have the packets for the past m seconds since
the flow was created.
Inactive timeout—The flow does not have any packets for the past n seconds.
You can create a flow record and add keys to match on and fields to collect in the flow.
SUMMARY STEPS
1.configureterminal
2.flow recordname
3.descriptionstring
4.matchtype
5.collecttype
6.end
7.show flow record [namerecord-name]
8.copy running-config startup-config
DETAILED STEPS
Command or Action
Purpose
Step 1
configureterminal
Example:
Switch# configure terminal
Enters the global configuration mode.
Step 2
flow recordname
Example:
Switch(config)# flow record testSwitch(config-flow-record)#
Creates a flow record and enters flow record configuration mode.
Step 3
descriptionstring
Example:
Switch(config-flow-record)# description Ipv4Flow
(Optional) Describes this flow record as a maximum 63-character string.
Step 4
matchtype
Example:
Switch(config-flow-record)# match ipv4 source addressSwitch(config-flow-record)# match ipv4 destination addressSwitch(config-flow-record)# match flow direction
This example shows how to create a flow and apply it to an interface:
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# flow export export1Switch(config-flow-exporter)# destination 10.0.101.254Switch(config-flow-exporter)# transport udp 2055Switch(config-flow-exporter)# exitSwitch(config)# flow record record1Switch(config-flow-record)# match ipv4 source addressSwitch(config-flow-record)# match ipv4 destination addressSwitch(config-flow-record)# match ipv4 protocolSwitch(config-flow-record)# match transport source-portSwitch(config-flow-record)# match transport destination-portSwitch(config-flow-record)# collect counter byte longSwitch(config-flow-record)# collect counter packet longSwitch(config-flow-record)# collect timestamp absolute firstSwitch(config-flow-record)# collect timestamp absolute lastSwitch(config-flow-record)# exitSwitch(config)# flow monitor monitor1Switch(config-flow-monitor)# record record1Switch(config-flow-monitor)# exporter export1Switch(config-flow-monitor)# exitSwitch(config)# interface tenGigabitEthernet 1/0/1Switch(config-if)# ip flow monitor monitor1 inputSwitch(config-if)# end
Example: Configuring IPv4 Flexible NetFlow in WLAN (Ingress Direction)
The following example shows how to configure IPv4 Flexible NetFlow on WLAN ingress direction:
Switch# configure terminalSwitch(config)# flow record fr_v4Switch(config-flow-record)# match ipv4 destinationSwitch(config-flow-record)# match ipv4 sourceSwitch(config-flow-record)# match ipv4 protocolSwitch(config-flow-record)# match ipv4 tosSwitch(config-flow-record)# match ipv4 ttlSwitch(config-flow-record)# match ipv4 versionSwitch(config-flow-record)# collect counter packets longSwitch(config-flow-record)# collect counter bytes longSwitch(config-flow-record)# collect timestamp sys-uptime firstSwitch(config-flow-record)# collect timestamp sys-uptime lastSwitch(config-flow-record)# exitSwitch(config)# flow monitor fm_v4Switch(config-flow-monitor)# record fr_v4Switch(config-flow-record)# exitSwitch(config)# wlan 1Switch(config-wlan)# ip flow monitor fm_v4 inSwitch(config-wlan)# endSwitch# show flow monitor fm_v4 cache
The Cisco Support website provides extensive online resources,
including documentation and tools for troubleshooting and
resolving technical issues with Cisco products and technologies.
To receive security and technical information about your
products, you can subscribe to various services, such as the
Product Alert Tool (accessed from Field Notices), the Cisco
Technical Services Newsletter, and Really Simple Syndication
(RSS) Feeds.
Access to most tools on the Cisco Support website requires a
Cisco.com user ID and password.