Configuring NetFlow

This chapter describes how to configure NetFlow statistics collection in Cisco IOS Release 12.2SX.


Note For complete syntax and usage information for the commands used in this chapter, see these publications:

http://www.cisco.com/en/US/docs/ios/netflow/command/reference/nf_book.html


 


Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum


 

This chapter contains the following sections:

Understanding NetFlow

NetFlow Overview

The NetFlow feature collects traffic statistics about the packets that flow through the switch and stores the statistics in the NetFlow table. The NetFlow table on the route processor (RP) captures statistics for flows routed in software and the NetFlow table on the PFC (and on each DFC) captures statistics for flows routed in hardware.

Several features use the NetFlow table. Features such as network address translation (NAT) use NetFlow to modify the forwarding result; other features (such as QoS microflow policing) use the statistics from the NetFlow table to apply QoS policies. The NetFlow Data Export (NDE) feature provides the ability to export the statistics to an external device (called a NetFlow collector).

In PFC3A mode, NetFlow collects statistics only for routed traffic. With other PFCs, you can configure NetFlow to collect statistics for both routed and bridged traffic.

Collecting and exporting a large volume of statistics can significantly impact switch processor (SP) and route processor (RP) CPU usage, so NetFlow provides configuration options to control the volume of statistics. These options include the following:

  • NetFlow flow masks determine the granularity of the flows to be measured. Very specific flow masks generate a large number of NetFlow table entries and a large volume of statistics to export. Less specific flow masks aggregate the traffic statistics into fewer NetFlow table entries and generate a lower volume of statistics.
  • Per-interface NetFlow allows you to enable or disable NetFlow data collection on Layer 3 interfaces.
  • NetFlow Flow Sampling exports data for a subset of traffic in a flow, which can greatly reduce the volume of statistics exported. NetFlow Flow Sampling does not reduce the volume of statistics collected.
  • NetFlow aggregation merges the collected statistics prior to export. Aggregation reduces the volume of records exported, but does not reduce the volume of statistics collected. NetFlow aggregation increases SP CPU utilization and reduces the data available at the collector. NetFlow aggregation uses NetFlow version 8.

NetFlow defines three configurable timers to identify stale flows that can be deleted from the table. NetFlow deletes the stale entries to clear table space for new entries.

NetFlow on the PFC

The NetFlow table on the PFC captures statistics for flows routed in hardware. A flow is a unidirectional stream of packets between a source and a destination. The flow mask specifies the fields in the incoming packet that NetFlow uses to match (or create) a NetFlow table entry.

All flow masks include the ingress interface in their definition. Therefore, NetFlow always collects statistics on a per-interface basis. You can also enable or disable NetFlow per-interface.

The PFC supports the following flow masks:

  • interface-source—A less-specific flow mask. Statistics for all ingress flows on an interface from each source IP address aggregate into one entry.
  • interface-destination—A less-specific flow mask. Statistics for all ingress flows on an interface to each destination IP address aggregate into one entry.
  • interface-destination-source—A more-specific flow mask. Statistics for all ingress flows on an interface between the same source IP address and destination IP address aggregate into one entry.
  • interface-full—The most-specific flow mask. The PFC creates and maintains a separate table entry for each IP flow on an interface. An interface-full entry includes the source IP address, destination IP address, protocol, and protocol ports.

The flow mask determines the granularity of the statistics gathered, which controls the size of the NetFlow table. The less-specific flow masks result in fewer entries in the NetFlow table and the most-specific flow masks result in the most NetFlow entries.

For example, if the flow mask is set to interface-source, the NetFlow table contains one entry per source IP address. (Assume that NetFlow is enabled on only one interface). The statistics for all flows from each source are accumulated in the one entry. However, if the flow mask is configured as interface-full, the NetFlow table contains one entry per full flow. Many entries may exist per source IP address, so the NetFlow table can become very large. See the “NetFlow Restrictions” section for information about NetFlow table capacity.

NetFlow on the RP

The NetFlow feature on the RP captures statistics for flows routed in software.

For additional information about configuring NetFlow on the RP, see the Cisco IOS NetFlow Configuration Guide, Release 12.2SX.

NetFlow Features

NetFlow supports the following features:

Per Interface NetFlow

Cisco IOS Release 12.2(33)SXH and later releases support per-interface NetFlow, which enables PFC NetFlow data collection on a per-interface basis. With releases earlier than Release 12.2(33)SXH, NetFlow on the PFC could be only be enabled and disabled globally.

When you upgrade to a software release that supports the per-interface NetFlow feature, the system automatically enables per-interface NetFlow and configures the ip flow ingress command on every Layer 3 interface. This one-time action takes place on the first reload after the upgrade and maintains backward compatibility with the global NetFlow enable command. After the reload, you can configure the no ip flow ingress command on Layer 3 interfaces to selectively disable PFC and RP NetFlow data collection.

The per-interface NetFlow feature only applies to IPv4 unicast flows on Layer 3 interfaces. Flows for non-IPv4 protocols (such as IPv6 and MPLS) are not controlled by this feature.

NetFlow Aggregation

NetFlow supports aggregation for packets forwarded in hardware (PFC) or software (RP). See the Cisco IOS NetFlow Configuration Guide, Release 12.2SX for information about these features:

  • NetFlow aggregation schemes
  • Configuring NetFlow aggregation
  • ToS-based router aggregation, which is supported by NetFlow on the RP

NetFlow for Multicast IP

NetFlow is supported for multicast IP packets forwarded in hardware (PFC) or software (RP).

NetFlow multicast provides ingress accounting and egress accounting. With ingress accounting, NetFlow creates one flow per source and includes information about how many packet replications occur. With egress accounting, NetFlow creates one flow for each outgoing interface.

Optionally, NetFlow multicast keeps statistics for multicast packets that fail the reverse path fail (RPF) check.


Note Disabling the mls netflow command globally will cause non-RPF multicast traffic to be dropped in software, as new non-RPF Netflow entries will not be created.


Default NetFlow Configuration

Table 63-1 shows the default NetFlow configuration.

 

Table 63-1 Default NetFlow Configuration

Feature
Default Value

NetFlow

Enabled

NetFlow of routed IP traffic

Disabled

NetFlow of ingress bridged IP traffic

Disabled

NetFlow Sampling

Disabled

NetFlow Aggregation

Disabled

Per-interface NDE

Enabled

Exclude ACL-denied traffic

Disabled (NetFlow creates entries for ACL-denied traffic)

NetFlow Restrictions

General NetFlow Restrictions

  • The CEF table (rather than the NetFlow table) implements Layer 3 switching in hardware.
  • Except in PFC3A mode, NetFlow supports bridged IP traffic. PFC3A mode does not support NetFlow bridged IP traffic.
  • NetFlow supports multicast IP traffic.
  • Supervisor Engine 720 and earlier hardware do not support egress Netflow accounting for unicast traffic. It is supported only for multicast traffic. However, Supervisor Engine 2T supports ingress and egress Netflow accounting for unicast traffic.
  • In PFC3A mode, NAT requires a non-interface-full flow mask for fragmented packets because the PFC cannot provide hardware acceleration for them. Fragmented NAT traffic is sent to the RP to be processed in software, which requires additional fragment ACE entries in the ACL TCAM.

Other PFC3 modes support the mls ip nat netflow-frag-l4-zero command, which removes the specific flow mask requirement and resolves NetFlow mask conflicts between NDE and NAT features. With the mls ip nat netflow-frag-l4-zero command configured, the PFC clears the initial fragmented packet L4 information before it gets NAT is applied.

  • By default, NAT overload processes initial fragments in software on the RP because NAT for subsequent fragments depends on the Layer 4 information in the first fragment. To ensure that initial fragments do not get switched in hardware, two ACL entries that require a flowmask different from the one for NAT NetFlow are added to the NAT inside interface. Initial fragments hit one of the fragment ACL entries on the NAT inside interface and because it uses a different flowmask, they do not hit the NetFlow shortcut and so are not hardware switched. The two additional ACL entries added to the NAT inside interface could lead to a merge blowup if a big ACL is configured on the NAT inside interface.

Except in PFC3A mode, you can configure the mls ip nat netflow-frag-l4-zero command to zero out the Layer 4 port information from the NetFlow lookup key for fragmented packets, which are then correctly sent to the RP for processing. In Layer 4 zero mode, fragmented packets (including initial fragments) do not match the NetFlow entries that have non-zero Layer 4 port information. In this mode, the 2 additional fragment entries for NAT are not required.

This can alleviate possible merge failures if a big ACL is configured on the NAT inside interface, and avoids flowmask conflicts between NAT and other features like NDE that arise due to the NAT requirement for a non-interface-full flowmask for fragment entries.


Note In this mode, fragmented packets are not counted correctly if NDE uses the full or interface-full flowmask. Similarly, initial fragments are not counted against the correct bucket with microflow policing that uses the full-flow mask.


  • No statistics are available for flows that are switched when the NetFlow table is full.
  • If the NetFlow table utilization exceeds the recommended utilization levels, there is an increased probability that there will be insufficient room to store statistics. Table 63-2 lists the recommended maximum utilization levels.

 

Table 63-2 NetFlow Table Utilization

PFC
Recommended NetFlow Table Utilization
Total NetFlow Table Capacity

PFC3CXL

235,520 (230 K) entries

262,144 (256 K) entries

PFC3C

117,760 (115 K) entries

131,072 (128 K) entries

PFC3BXL

235,520 (230 K) entries

262,144 (256 K) entries

PFC3B

117,760 (115 K) entries

131,072 (128 K) entries

PFC3A

65,536 (64 K) entries

131,072 (128 K) entries

Flow Mask Conflicts

Several features use the NetFlow table. Table 63-3 lists the flow mask requirements for each feature.

 

Table 63-3 Feature Requirements for Flow Masks

Note “Min” indicates that the flowmask requirement is flexible: a more granular flowmask will also work. For example, “interface-source min” indicates that interface-source-destination can also be used.

“Exact” indicates that the flowmask requirement is not flexible.

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

Reflexive ACL

 

 

 

 

 

 

Exact

 

TCP Intercept

 

 

 

 

 

Min

 

 

Web Cache Redirect (WCCP)

 

 

 

 

 

 

Exact

 

Server Load Balancing (SLB)

 

 

 

 

 

Min

 

 

Network Address Translation (NAT)

  • Without mls ip nat netflow-frag-l4-zero :

 

 

 

 

 

 

Exact

Exact

  • With mls ip nat netflow-frag-l4-zero :

 

 

 

 

 

 

Exact

 

NetFlow Data Export (NDE)

  • With mls flow ip interface-source :

 

Min

 

 

 

 

 

 

  • With mls flow ip interface-destination :

 

 

 

Min

 

 

 

 

  • With mls flow ip interface-destination-source :

 

 

 

 

Min

 

 

 

  • With mls flow ip interface-full :

 

 

 

 

 

 

Min

 

NetFlow Sampling

 

 

 

 

 

 

Min

 

NetFlow Aggregation

 

 

 

Min

 

 

 

 

Microflow Policing

  • With police flow mask full-flow :

 

 

 

 

 

 

Exact

 

  • With police flow mask src-only :

Exact

 

 

 

 

 

 

 

  • With police flow mask dest-only :

 

 

Exact

 

 

 

 

 

 

NetFlow data export, hardware accelerated NetFlow features, and microflow policers are the three categories of features that request flowmasks. All of them can be configured at the same time, but depending on the flowmask that each requests, the configuration might be allowed or not. Typically, only one of the hardware accelerated NetFlow features is configured on an interface. If multiple hardware accelerated NetFlow features are configured, some of them might not be hardware accelerated if the flow is subject to more than one of these features.

Each of these features request a flowmask. The final flowmask depends on the other features.

Example Feature Configurations


Note “Min” indicates that the flowmask requirement is flexible: a more granular flowmask will also work. For example, “interface-source min” indicates that interface-source-destination can also be used.

  • “Exact” indicates that the flowmask requirement is not flexible.
  • You can use the information in Table 63-3 to check for conflicts between features.


 

NAT “Non-interface Full” would conflict with NDE “Interface Full”, but NAT “Interface Full” would not conflict with NDE “Interface Full”:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

Network Address Translation (NAT)
without mls ip nat netflow-frag-l4-zero :

 

 

 

 

 

 

Exact

Exact

NetFlow Data Export (NDE)
with mls flow ip interface-full :

 

 

 

 

 

 

Min

 

NAT “Interface Full” would not conflict with NDE “Interface Full”:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

Network Address Translation (NAT)
with mls ip nat netflow-frag-l4-zero :

 

 

 

 

 

 

Exact

 

NetFlow Data Export (NDE)
with mls flow ip interface-full :

 

 

 

 

 

 

Min

 

NAT “Interface Full” would not conflict with NDE “Interface Source”:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

Network Address Translation (NAT)
with mls ip nat netflow-frag-l4-zero :

 

 

 

 

 

 

Exact

 

NetFlow Data Export (NDE)
with mls flow ip interface-source :

 

Min

 

 

 

 

 

 

WCCP would not conflict with NDE “Interface Destination Source”:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

Web Cache Redirect (WCCP)

 

 

 

 

 

 

Exact

 

NetFlow Data Export (NDE)
With mls flow ip interface-destination-source :

 

 

 

 

Min

 

 

 

WCCP would not conflict with NDE “Interface Full”:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

Web Cache Redirect (WCCP)

 

 

 

 

 

 

Exact

 

NetFlow Data Export (NDE)
With mls flow ip interface-full :

 

 

 

 

 

 

Min

 

NDE “Interface Full” would conflict with microflow policing “Destination”:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

NetFlow Data Export (NDE)
with mls flow ip interface-full :

 

 

 

 

 

 

Min

 

Microflow Policing
with police flow mask dest-only :

 

 

Exact

 

 

 

 

 

NDE “Interface Full” would not conflict with microflow policing “Interface Full”:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

NetFlow Data Export (NDE)
with mls flow ip interface-full :

 

 

 

 

 

 

Min

 

Microflow Policing
with police flow mask full-flow :

 

 

 

 

 

 

Exact

 

WCCP, NAT “Interface Full”, and NDE “Interface Full” would not conflict:

 

Feature
Source
Interface
Source
Destination
Interface
Destination
Interface
Destination
Source
Full
Interface
Full
Non-interface
Full

Web Cache Redirect (WCCP)

 

 

 

 

 

 

Exact

 

Network Address Translation (NAT)
with mls ip nat netflow-frag-l4-zero :

 

 

 

 

 

 

Exact

 

NetFlow Data Export (NDE)
with mls flow ip interface-full :

 

 

 

 

 

 

Min

 

Configuring NetFlow

These sections describe how to configure NetFlow:

Configuring NetFlow on the PFC

These sections describe how to configure NetFlow statistics collection on the PFC:

NetFlow PFC Commands Summary

Table 63-4 shows a summary of the NetFlow commands available on the PFC.

 

Table 63-4 Summary of PFC NetFlow Commands

Command
Purpose

mls netflow

Enables NetFlow on the PFC.

mls flow ip

Sets the minimum flow mask.

mls aging

Sets the configurable aging parameters.

mls exclude acl-deny

Disables the creation of flows for ACL-denied traffic.

show mls netflow {...}

Displays NetFlow PFC information for unicast and multicast traffic.

show mls netflow aggregation flowmask

Displays the NetFlow aggregation flow mask.

Enabling NetFlow on the PFC

To enable NetFlow statistics collection globally on the PFC, perform this task:

 

Command
Purpose

Router(config)# mls netflow

Enables NetFlow on the PFC.

This example shows how to disable NetFlow statistics collection on the PFC (the default setting is enabled):

Router(config)# no mls netflow

Setting the Minimum IP MLS Flow Mask

You can set the minimum specificity of the flow mask for the NetFlow table on the PFC. The actual flow mask may be more specific than the level configured in the mls flow command, if other configured features need a more specific flow mask (see the “Flow Mask Conflicts” section).

To set the minimum IPv4 flow mask, perform this task:

 

Command
Purpose

Router(config)# mls flow ip { interface-source | interface-destination | interface-destination-source | interface-full }

Sets the minimum flow mask for IPv4 packets.

This example shows how to set the minimum flow mask:

Router(config)# mls flow ip interface-destination
 

To display the IP MLS flow mask configuration, perform this task:

 

Command
Purpose

Router# show mls netflow flowmask

Displays the flow mask configuration.

This example shows how to display the MLS flow mask configuration:

Router# show mls netflow flowmask
current ip flowmask for unicast: if-dst
Router#

Configuring the MLS Aging Time

The MLS aging time (default 300 seconds) applies to all NetFlow table entries. You can configure the normal aging time in the range of 32 to 4092 seconds. Flows can age as much as 4 seconds sooner or later than the configured interval. On average, flows age within 2 seconds of the configured value.

Other events might cause MLS entries to be purged, such as routing changes or a change in link state.


Note If the number of MLS entries exceeds the recommended utilization (see the “NetFlow Restrictions” section), only adjacency statistics might be available for some flows.


To keep the NetFlow table size below the recommended utilization, enable the following parameters when using the mls aging command:

  • normal—Configures an inactivity timer. If no packets are received on a flow within the duration of the timer, the flow entry is deleted from the table.
  • fast aging—Configures an efficient process to age out entries created for flows that only switch a few packets, and then are never used again. The fast aging parameter uses the time keyword value to check if at least the threshold keyword value of packets have been switched for each flow. If a flow has not switched the threshold number of packets during the time interval, then the entry is aged out.
  • long—Configures entries for deletion that have been active for the specified value even if the entry is still in use. Long aging is used to prevent counter wraparound, which can cause inaccurate statistics.

A typical table entry that is removed by fast aging is the entry for flows to and from a Domain Name Server (DNS) or TFTP server.

If you need to enable MLS fast aging time, initially set the value to 128 seconds. If the size of the NetFlow table continues to grow over the recommended utilization, decrease the setting until the table size stays below the recommended utilization. If the table continues to grow over the recommended utilization, decrease the normal MLS aging time.

To configure the MLS aging time, perform this task:

 

Command
Purpose

Router(config)# mls aging {fast [threshold { 1-128 } | time { 1-128 }] | long 64-1920 | normal 32-4092 }

Configures the MLS aging time for a NetFlow table entry.

This example displays how to configure the MLS aging time:

Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mls aging fast threshold 64 time 30
 

To display the MLS aging-time configuration, perform this task:

 

Command
Purpose

Router# show mls netflow aging

Displays the MLS aging-time configuration.

This example shows how to display the MLS aging-time configuration:

Router# show mls netflow aging
enable timeout packet threshold
------ ------- ----------------
normal aging true 300 N/A
fast aging true 32 100
long aging true 900 N/A
 

Configuring Exclude ACL-deny

By default, NetFlow table entries are created for ACL-denied flows. These flows can cause the NetFlow table to overflow. With Release 12.2(33)SXH and later releases, to exclude ACL-denied flows from the NetFlow table, perform this task:

 

Command
Purpose

Router# mls exclude acl-deny

Excludes ACL-denied flows from the NetFlow table.

This example shows how to exclude ACL-denied flows from the NetFlow table:

Router(config)# mls exclude acl-deny

Displaying PFC NetFlow Information

To display information about NetFlow on the PFC, perform this task:

 

Command
Purpose

Router(config)# show mls netflow { aggregation | aging | creation | flowmask | ip | ipv6 | mpls | table-contention | usage }

Displays information about NetFlow on the PFC.

Configuring NetFlow Features

NetFlow features generally apply to packets forwarded in hardware (PFC) and software (RP). For the features to apply to PFC, you need to enable NetFlow on the PFC.

These sections describe how to configure NetFlow features:

Configuring NetFlow on Layer 3 Interfaces

The per-interface NDE feature allows you to enable or disable NetFlow collection on a per-interface basis for packets forwarded in hardware (PFC) or software (RP). This feature is automatically enabled in Release 12.2(33)SXH and later releases.

To enable or disable NetFlow for a Layer 3 interface, perform this task:

 

Command
Purpose

Step 1

Router(config)# interface { vlan vlan_ID } | { type slot/port } | { port-channel port_channel_number }

Selects a Layer 3 interface to configure.

Step 2

Router(config-if)# ip flow ingress

Enables NetFlow for the specified interface. NetFlow will collect statistics for packets forwarded in hardware (PFC) or software (RP).

Step 3

Router(config-if)# no ip flow ingress

Disables NetFlow for the specified interface. NetFlow will stop collecting statistics for packets forwarded in hardware (PFC) or software (RP).

When you upgrade for the first time to a software image that supports per-interface NetFlow on the PFC, the system automatically configures each Layer 3 interface to enable NetFlow (this ensures backward compatibility with the global mls netflow command). This one-time action occurs during the first system restart after the upgrade. After this action, you can configure Layer 3 interfaces to disable or enable NetFlow data collection.

Enabling NetFlow for Ingress-Bridged IP Traffic

Except in PFC3A mode, NetFlow supports ingress-bridged IP traffic. PFC3A mode does not support NetFlow for bridged IP traffic.


Note When you enable NetFlow for ingress-bridged IP traffic, the statistics are available to the NetFlow Flow Sampling feature (see the “NetFlow Overview” section).

  • To enable NetFlow for bridged IP traffic on a VLAN, you must create a corresponding VLAN interface and enter the no shutdown command. The no shutdown command can be followed, if necessary, by the shutdown command.
  • For Layer 3 VLANs, enabling NetFlow for ingress-bridged IP traffic also enables NetFlow for Layer 3 flows on the specified VLANs.
  • The exported bridged flows will have ingress and egress VLAN information and not the physical port information.


 

To enable NetFlow for ingress-bridged IP traffic in VLANs, perform this task:

 

Command
Purpose

Router(config)# ip flow ingress layer2-switched vlan vlan_ID [- vlan_ID ] [, vlan_ID [- vlan_ID ]]

Enables NetFlow for ingress-bridged IP traffic in the specified VLANs.

Note NetFlow for ingress-bridged IP traffic in a VLAN requires that NetFlow on the PFC be enabled with the mls netflow command.

This example shows how to enable NetFlow for ingress-bridged IP traffic in VLAN 200:

Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip flow ingress layer2-switched vlan 200
 

Configuring NetFlow Aggregation

To configure NetFlow aggregation, use the procedures in the Cisco IOS NetFlow Configuration Guide, Release 12.2SX.


Note When you configure NetFlow aggregation, it is configured automatically for packets forwarded in hardware (PFC) or software (RP).

  • The PFC and DFCs do not support NetFlow ToS-based router aggregation.


 

To display NetFlow Aggregation information for the PFC or DFCs, perform this task:

 

Command
Purpose

Router # show ip cache flow aggregation { as | destination-prefix | prefix | protocol-port | source-prefix) module slot_num

Displays the NetFlow Aggregation cache information.

Router # show mls netflow aggregation flowmask

Displays the NetFlow Aggregation flow mask information.


Note The PFC and DFCs do not support NetFlow ToS-based router Aggregation.


This example shows how to display the NetFlow Aggregation cache information:

Router# show ip cache flow aggregation destination-prefix module 1
IPFLOW_DST_PREFIX_AGGREGATION records and statistics for module :1
IP Flow Switching Cache, 278544 bytes
2 active, 4094 inactive, 6 added
236 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
Dst If Dst Prefix Msk AS Flows Pkts B/Pk Active
Gi7/9 9.1.0.0 /16 0 3003 12M 64 1699.8
Gi7/10 11.1.0.0 /16 0 3000 9873K 64 1699.8
Router#
 

This example shows how to display the NetFlow Aggregation flow mask information:

Router# show mls netflow aggregation flowmask
Current flowmask set for netflow aggregation : Vlan Full Flow
Netflow aggregations configured/enabled :
AS Aggregation
PROTOCOL-PORT Aggregation
SOURCE-PREFIX Aggregation
DESTINATION-PREFIX Aggregation
Router

Configuring NetFlow for Multicast IP Traffic

To configure NetFlow for multicast IP traffic, perform this task:

 

Command
Purpose

Step 1

Router(config)# ip multicast netflow output-counters

(Optional) Enables the calculation of output bytes/packets for an ingress flow.

Step 2

Router(config)# ip multicast netflow rpf-failure

(Optional) Enables NetFlow for multicast data that fails the RPF check.

Step 3

Router(config)# interface { vlan vlan_ID } | { type slot/port } | { port-channel port_channel_number }

Selects a Layer 3 interface to configure.

Step 4

Router(config-if)# ip flow { ingress | egress }

Enables NetFlow multicast traffic on the specified interface (for RP and PFC).

  • Specify ingress to enable NetFlow multicast ingress accounting.
  • Specify egress to enable NetFlow multicast egress accounting.

For additional information about configuring NetFlow for multicast traffic, see the “ Configuring NetFlow Multicast Accounting ” section of the Cisco IOS NetFlow Configuration Guide, Release 12.2SX.

The “Configuring NetFlow Multicast Accounting” section specifies as a prerequisite that you need to configure multicast fast switching or multicast distributed fast switching (MDFS), but this prerequisite does not apply when configuring NetFlow multicast support with 12.2SX releases.


Note The Configuring NetFlow Multicast Accounting document describes new configuration commands for Cisco IOS Release 12.2(4) and newer releases. The 12.2SX releases support the new commands.



Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum