Table Of Contents
NetFlow Layer 2 and Security Monitoring Exports
Prerequisites for NetFlow Layer 2 and Security Monitoring Exports
Restrictions for NetFlow Layer 2 and Security Monitoring Exports
Information About NetFlow Layer 2 and Security Monitoring Exports
Understanding the NetFlow Application
NetFlow Cisco IOS Packaging Information
Understanding NetFlow Network Flows
Benefits of NetFlow Layer 2 and Security Monitoring
Layer 3 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports
Layer 2 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports
How to Configure NetFlow Layer 2 and Security Monitoring Exports
Configuring NetFlow Layer 2 and Security Monitoring Exports
Verifying NetFlow Layer 2 and Security Monitoring Exports
Configuration Examples for NetFlow Layer 2 and Security Monitoring Exports
NetFlow Layer 2 and Security Monitoring Exports
NetFlow is a Cisco IOS application that provides statistics on packets flowing through the router. It is emerging as a primary network accounting and security technology. This document describes the NetFlow application and the new NetFlow Layer 2 and Security Monitoring Exports feature.
The NetFlow Layer 2 and Security Monitoring Exports feature adds the ability for NetFlow to capture the values from several fields in Layer 3 IP traffic and Layer 2 LAN traffic to obtain information that can be used to classify and identify network traffic. This information can be used to help identify network attacks and their origin.
Feature History for NetFlow Layer 2 and Security Monitoring
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for NetFlow Layer 2 and Security Monitoring Exports
•
•
•
•
Prerequisites for NetFlow Layer 2 and Security Monitoring Exports
NetFlow and Cisco Express Forwarding (CEF), distributed CEF (dCEF), or fast switching must be configured on your system.
Restrictions for NetFlow Layer 2 and Security Monitoring Exports
If you want to export the data captured with the NetFlow Layer 2 and Security Monitoring feature you must configure Netflow to use the NetFlow Version 9 data export format.
Information About NetFlow Layer 2 and Security Monitoring Exports
To configure the NetFlow feature, you should understand the following concepts:
•
•
•
•
Understanding the NetFlow Application
NetFlow identifies packet flows for both ingress and egress IP packets. It does not involve any connection-setup protocol. NetFlow is completely transparent to the existing network, including end stations and application software and network devices like LAN switches. Also, NetFlow capture and export are performed independently on each internetworking device; NetFlow need not be operational on each router in the network.
NetFlow can capture a rich set of traffic statistics. These traffic statistics include user, protocol, port, and type of service (ToS) information that can be used for a wide variety of purposes, including network traffic analysis and capacity planning, security, enterprise accounting and departmental chargebacks, Internet Service Provider (ISP) billing, data warehousing, and data mining for marketing purposes.
NetFlow is supported on IP and IP encapsulated traffic over most interface types and Layer 2 encapsulations.
You can display and clear NetFlow statistics. NetFlow statistics consist of IP packet size distribution, IP flow switching cache information, and flow information.
NetFlow Benefits
NetFlow captures a rich set of traffic statistics. These traffic statistics include user, protocol, port, and type of service (ToS) information that can be used for a wide variety of purposes such as network application and user monitoring (user monitoring is performed by monitoring the IP addresses of the devices that users are running applications on), network analysis and planning, denial of service (DoS) and Security Analysis, Accounting and Billing, Traffic Engineering, and Data Mining.
Network Application and User Monitoring
NetFlow data enables you to view detailed, time - and application- based usage of a network. This information allows you to plan and allocate network and application resources, and provides for extensive near real-time network monitoring capabilities. It can be used to display traffic patterns and application-based views. NetFlow provides proactive problem detection and efficient troubleshooting, and it facilitates rapid problem resolution. You can use NetFlow information to efficiently allocate network resources and to detect and resolve potential security and policy violations.
Network Analysis and Planning
You can use NetFlow to capture data over a long period of time, which enables you to track and anticipate network growth and plan upgrades. NetFlow service data can be used to optimize network planning, which includes peering, backbone upgrades, and routing policy planning. It also enables you to minimize the total cost of network operations while maximizing network performance, capacity, and reliability. NetFlow detects unwanted WAN traffic, validates bandwidth and quality of service (QoS) behavior, and enables the analysis of new network applications. NetFlow offers valuable information that you can use to reduce the cost of operating the network.
Denial of Service and Security Analysis
You can use NetFlow data to identify and classify denial of service (DoS) attacks, viruses, and worms in real time. Changes in network behavior indicate anomalies that are clearly reflected in NetFlow data. The data is also a valuable forensic tool that you can use to understand and replay the history of security incidents.
Accounting and Billing
NetFlow data provides fine-grained metering for highly flexible and detailed resource utilization accounting. For example, flow data includes details such as IP addresses, packet and byte counts, timestamps, and information about type of service (ToS) and application ports. Service providers might utilize the information for billing based on time-of-day, bandwidth usage, application usage, or QoS. Enterprise customers might utilize the information for departmental chargeback or cost allocation for resource utilization.
Traffic Engineering
NetFlow provides autonomous system (AS) traffic engineering details. You can use NetFlow-captured traffic data to understand source-to-destination traffic trends. This data can be used for load-balancing traffic across alternate paths or for forwarding traffic along a preferred route. NetFlow can measure the amount of traffic crossing peering or transit points to help you decide if a peering arrangement with other service providers is fair and equitable.
NetFlow Data Storage and Data Mining
NetFlow data (or derived information) can be stored for later retrieval and analysis in support of marketing and customer service programs. For example, the data can be mined to find out which applications and services are being used by internal and external users and target the users for improved service and advertising. In addition, NetFlow data gives market researchers access to the who, what, where, and how long information relevant to enterprises and service providers
NetFlow Cisco IOS Packaging Information
Cisco 7200/7500/7400/MGX/AS5850
Although NetFlow functionality is included in all software images for these platforms, you must purchase a separate NetFlow feature license. NetFlow licenses are sold on a per-node basis.
Other Routers
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Understanding NetFlow Network Flows
A NetFlow network flow is defined as a unidirectional stream of packets between a given source and destination. The source and destination are each defined by a network-layer IP address and transport-layer source and destination port numbers. Specifically, a flow is defined by the combination of the following seven key fields:
•
•
•
•
•
•
•
These seven key fields define a unique flow. If a packet has one key field different from another packet, it is considered to belong to another flow. A flow might also contain other accounting fields (such as the AS number in the NetFlow export Version 5 flow format), depending on the export record version that you configure. Flows are stored in the NetFlow cache.
NetFlow Main Cache Operation
The key components of NetFlow are the NetFlow cache that stores IP flow information and the NetFlow export or transport mechanism that sends NetFlow data to a network management collector, such as the NetFlow Collection Engine. NetFlow operates by creating a NetFlow cache entry (a flow record) for each active flow. NetFlow maintains a flow record within the cache for each active flow. Each flow record in the NetFlow cache contains fields that can later be exported to a collection device, such as the NetFlow Collection Engine.
NetFlow Data Capture
NetFlow captures data from ingress (incoming) and egress (outgoing) packets. NetFlow gathers data for the following ingress IP packets:
•
•
NetFlow captures data for all egress (outgoing) packets through use of the following features:
•
•
NetFlow Export Formats
NetFlow exports data in User Datagram Protocol (UDP) datagrams in one of five formats: Version 9, Version 8, Version 7, Version 5, or Version 1. Version 9 export format, the latest version, is the most flexible and extensible format. Version 1 was the initial NetFlow export format; Version 8 only supports export from aggregation caches, and Version 7 is supported only on certain platforms. (Versions 2 through 4 and Version 6 were either not released or are not supported.)
•
•
•
•
•
Benefits of NetFlow Layer 2 and Security Monitoring
The Layer 2 and Layer 3 fields supported by the NetFlow Layer 2 and Security Monitoring Exports feature increase the amount of information that can be obtained by NetFlow about the traffic in your network. You can use this new information for applications such as traffic engineering and usage-based billing.
The new Layer 3 IP header fields that the NetFlow Layer 2 and Security Monitoring Exports feature captures the values of are:
•
•
•
•
See the "Layer 3 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports" section for more information on these Layer 3 fields.
The new Layer 2 fields that NetFlow Layer 2 and Security Monitoring Exports feature captures the values of are:
•
•
•
•
See the "Layer 2 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports" section for more information on these Layer 2 fields.
The Layer 3 fields captured by the NetFlow Layer 2 and Security Monitoring Exports feature improve NetFlow's capabilities for identifying DoS attacks. The Layer 2 fields captured by the NetFlow Layer 2 and Security Monitoring Exports feature can help you identify the path that the DoS attack is taking through the network.
The Layer 2 and Layer 3 fields captured by the NetFlow Layer 2 and Security Monitoring Exports feature are not key fields. They provide additional information about the traffic in an existing flow. Changes in the values of NetFlow key fields such as the source IP address from one packet to the next packet result in the creation of a new flow. For example if the first packet captured by NetFlow has a source IP address of 10.34.0.2 and the second packet captured by NetFlow has a source IP of 172.16.213.65, NetFlow will create two separate flows.
Many DoS attacks consist of an attacker sending the same type of IP datagram over and over again in an attempt to overwhelm the target systems. In such cases the incoming traffic often has similar characteristics such as the same values in each datagram for one or more of the fields that the NetFlow Layer 2 and Security Monitoring Exports feature can capture.
There is no easy way to identify the originator of many DoS attacks because the IP source address of the device sending the traffic is usually forged. However by capturing the MAC address and VLAN-ID fields using the NetFlow Layer 2 and Security Monitoring Exports feature, you can easily trace the traffic back through the network to the router that it is arriving on. If the router that the traffic is arriving on supports NetFlow, you can configure the NetFlow Layer 2 and Security Monitoring Exports feature on it to identify the interface where the traffic is arriving. Figure 1 shows an example of an attack in progress.
Figure 1 DoS Attack Arriving over the Internet
Note
Once you have concluded that a DoS attack is taking place by analyzing the Layer 3 fields in the NetFlow flows, you can analyze the Layer 2 fields in the flows to discover the path that the DoS attack is taking through the network.
An analysis of the data captured by the NetFlow Layer 2 and Security Monitoring Exports feature for the scenario shown in Figure 1 indicates that the DoS attack is arriving on Router C because the upstream MAC address is from the interface that connects Router C to Switch A. It is also evident that there are no routers between the target host (the email server) and the NetFlow router because the destination MAC address of the DoS traffic that the NetFlow router is forwarding to the email server is the MAC address of the email server.
You can find out the MAC address that Host C is using to send the traffic to Router C by configuring the NetFlow Layer 2 and Security Monitoring Exports feature on Router C. The source MAC address will be from Host C. The destination MAC address will be for the interface on the NetFlow router.
Once you know the MAC address that Host C is using and the interface on Router C that Host C's DoS attack is arriving on, you can mitigate the attack by reconfiguring Router C to block Host C's traffic. If Host C is on a dedicated interface you, disable the interface. If Host C is using an interface that carries traffic from other users, you must configure your firewall to block Host C's traffic but still allow the traffic from the other users to flow through Router C.
The "Configuration Examples for NetFlow Layer 2 and Security Monitoring Exports" section has two examples for using the NetFlow Layer 2 and Security Monitoring Exports feature to identify an attack in progress and the path that the attack is taking through a network.
Layer 3 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports
The NetFlow Layer 2 and Security Monitoring Exports feature adds support for capturing four fields from Layer 3 IP traffic in a flow:
•
•
•
•
Figure 2 shows the fields in an IP packet header. Figure 3 shows the fields in an ICMP datagram. ICMP datagrams are carried in the data area of an IP datagram, after the IP header.
Figure 2 IP Packet Header Fields
Figure 3 ICMP Datagram
Layer 2 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports
The NetFlow Layer 2 and Security Monitoring Exports feature adds the ability to capture the values of the MAC address and VLAN ID fields from flows. The two supported VLAN types are 802.1q and Cisco's Inter-Switch Link (ISL).
•
•
Understanding Layer 2 MAC Address Fields
The new Layer 2 fields that the NetFlow Layer 2 and Security Monitoring Exports feature captures the values of are:
•
•
•
•
The Ethernet Type II and Ethernet 802.3 frame formats are shown in Figure 4. The destination address field and the source address field in the frame formats are the MAC addresses whose values NetFlow captures. The fields for the Ethernet frame formats are explained in Table 3.
Figure 4 Ethernet Type II and 802.3 Frame Formats
For examples of other types of LAN frame formats refer to the Cisco Internetworking Technology Handbook. Refer to the NetFlow on Logical Interfaces white paper for more information on the other types of interfaces that NetFlow can be used with.
Understanding Layer 2 VLAN ID Fields
NetFlow can capture the value in the VLAN ID field for 802.1q tagged VLANs and Cisco ISL encapsulated VLANs. The section describes the two types of VLANs.
Note
•
Understanding 802.1q VLANs
Devices that use 802.1q insert a four-byte tag into the original frame before it is transmitted. Figure 5 shows the format of an 802.1q tagged Ethernet frame. The fields for 802.1q VLANs are described in Table 4.
Figure 5 802.1q Tagged Ethernet Type II or 802.3 Frame
Table 4 802.1q VLAN Encapsulation Fields
DA, SA, Type or Length, Data, and FCS
These fields are described in Table 3.
Tag Protocol ID (TPID)
This 16-bit field is set to a value of 0x8100 to identify the frame as an IEEE 802.1q tagged frame.
Priority
Also known as user priority, this 3-bit field refers to the 802.1p priority. It indicates the frame priority level which can be used for prioritizing traffic and is capable of representing 8 levels (0-7).
Tag Control Information
The 2-byte Tag Control Information field is comprised of two sub-fields:
•
•
Understanding Cisco ISL VLANs
ISL is a Cisco proprietary protocol for encapsulating frames on a VLAN trunk. Devices that use ISL add an ISL header to the frame. This process is known as VLAN encapsulation. 802.1Q is the IEEE standard for tagging frames on a VLAN trunk. Figure 6 shows the format of a Cisco ISL-encapsulated Ethernet frame. The fields for 802.1q VLANs are described in Table 5.
Figure 6 Cisco ISL Tagged Ethernet Frame
How to Configure NetFlow Layer 2 and Security Monitoring Exports
This section contains the following procedure:
•
•
Configuring NetFlow Layer 2 and Security Monitoring Exports
Prerequisites
CEF, dCEF, or fast switching for IP must be configured on your system before you configure NetFlow Layer 2 and Security Monitoring Exports.
The optional Verifying NetFlow Layer 2 and Security Monitoring Exports task uses the show ip cache verbose flow command to display the values of the fields that you have configured the NetFlow Layer 2 and Security Monitoring Exports feature to capture. In order for you to see the values of the fields that you have configured the NetFlow Layer 2 and Security Monitoring Exports feature to capture your router must be forwarding IP traffic that meets the criteria for these fields. For example, if you configure the ip flow-capture ipid command your router must be forwarding IP datagrams to capture the IP id values from the IP datagrams in the flow.
Restrictions
The "Verifying NetFlow Layer 2 and Security Monitoring Exports" uses the show ip cache verbose flow command. The following restrictions apply to using the show ip cache verbose flow command.
Displaying Detailed NetFlow Cache Information on Platforms Running Distributed Cisco Express Forwarding
On platforms running dCEF, NetFlow cache information is maintained on each line card or Versatile Interface Processor. If you want to use the show ip cache verbose flow command to display this information on a distributed platform, you must enter the command at a line card prompt.
Cisco 7500 Series Platform
To display detailed NetFlow cache information on a Cisco 7500 series router that is running distributed dCEF, enter the following sequence of commands:
Router# if-con slot-numberLC-slot-number# show ip cache verbose flowFor Cisco IOS Releases 12.3(4)T, 12.3(6), and 12.2(20)S and later, enter the following command to display detailed NetFlow cache information:
Router# execute-on slot-number show ip cache verbose flowCisco 12000 Series Platform
To display detailed NetFlow cache information on a Cisco 12000 Series Internet Router, enter the following sequence of commands:
Router# attach slot-numberLC-slot-number# show ip cache verbose flowFor Cisco IOS Releases 12.3(4)T, 12.3(6), and 12.2(20)S and later, enter the following command to display detailed NetFlow cache information:
Router# execute-on slot-number show ip cache verbose flow .
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
and/or
ip flow egress11.
12.
DETAILED STEPS
Verifying NetFlow Layer 2 and Security Monitoring Exports
To verify the configuration of NetFlow Layer 2 and Security Monitoring Exports use the following step.
SUMMARY STEPS
1.
DETAILIED STEPS
Step 1
The display output below shows that NetFlow Layer 2 and Security Monitoring Exports is working properly because the values have been captured from the Layer 2 and Layer 3 fields in the flows. The values captured by the NetFlow Layer 2 and Security Monitoring Exports feature from the Layer 2 and Layer 3 fields in the flows are shown in bold text.
Router# show ip cache verbose flowIP packet size distribution (25229 total packets):1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000512 544 576 1024 1536 2048 2560 3072 3584 4096 4608.000 .000 .000 .206 .793 .000 .000 .000 .000 .000 .000IP Flow Switching Cache, 278544 bytes6 active, 4090 inactive, 17 added505 ager polls, 0 flow alloc failuresActive flows timeout in 1 minutesInactive flows timeout in 10 secondsIP Sub Flow Cache, 25736 bytes12 active, 1012 inactive, 39 added, 17 added to flow0 alloc failures, 0 force free1 chunk, 1 chunk addedlast clearing of statistics neverProtocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)-------- Flows /Sec /Flow /Pkt /Sec /Flow /FlowTCP-Telnet 1 0.0 362 940 2.7 60.2 0.0TCP-FTP 1 0.0 362 840 2.7 60.2 0.0TCP-FTPD 1 0.0 362 840 2.7 60.1 0.1TCP-SMTP 1 0.0 361 1040 2.7 60.0 0.1UDP-other 5 0.0 1 66 0.0 1.0 10.6ICMP 2 0.0 8829 1378 135.8 60.7 0.0Total: 11 0.0 1737 1343 147.0 33.4 4.8SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActiveEt0/0.1 10.251.138.218 Et1/0.1 172.16.10.2 06 80 00 650015 /0 0 0015 /0 0 0.0.0.0 840 10.8MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0Configuration Examples for NetFlow Layer 2 and Security Monitoring Exports
This section provides the following configuration examples:
Configuring and Using NetFlow Layer 2 and Security Monitoring Exports to Analyze a Simulated FTP Attack: Example
The following example shows how to use the NetFlow Layer 2 and Security Monitoring Exports feature to find out whether your network is being attacked by a host that is sending fake FTP traffic in an attempt to overwhelm the FTP server. This attack might cause end users to see a degradation in the ability of the FTP server to accept new connections or to service existing connections.
This example uses the network shown in Figure 7. Host A is sending fake FTP packets to the FTP server.
This example also shows you how to use the Layer 2 data captured by the NetFlow Layer 2 and Security Monitoring Exports feature to learn where the traffic is originating and what path it is taking through the network.
Figure 7 Test Network
Tip
Note
R2
!hostname R2!interface Ethernet0/0mac-address aaaa.bbbb.cc02ip address 172.16.1.2 255.255.255.0!interface Ethernet1/0mac-address aaaa.bbbb.cc03no ip address!interface Ethernet1/0.1encapsulation dot1Q 5ip address 172.16.6.1 255.255.255.0!!router ripversion 2network 172.16.0.0no auto-summary!R3
!hostname R3!ip flow-capture packet-lengthip flow-capture ttlip flow-capture vlan-idip flow-capture ip-idip flow-capture mac-addresses!interface Ethernet0/0mac-address aaaa.bbbb.cc04no ip address!interface Ethernet0/0.1encapsulation dot1Q 5ip address 172.16.6.2 255.255.255.0ip accounting output-packetsip flow ingress!interface Ethernet1/0mac-address aaaa.bbbb.cc05no ip address!interface Ethernet1/0.1encapsulation dot1Q 6ip address 172.16.7.1 255.255.255.0ip accounting output-packetsip flow egress!router ripversion 2network 172.16.0.0no auto-summary!R4
!hostname R4!interface Ethernet0/0mac-address aaaa.bbbb.cc07ip address 172.16.10.1 255.255.255.0!interface Ethernet1/0mac-address aaaa.bbbb.cc06no ip address!interface Ethernet1/0.1encapsulation dot1Q 6ip address 172.16.7.2 255.255.255.0!router ripversion 2network 172.16.0.0no auto-summary!The show ip cache verbose flow command displays the NetFlow flows that have been captured from the FTP traffic that Host A is sending.
The fields that have the values captured by the ip flow-capture command are in Table 9. These are the fields and the values that are used to analyze the traffic for this example. The other fields captured by the show ip cache verbose flow command are explained in Table 6, Table 7, and Table 8.
R3# show ip cache verbose flowIP packet size distribution (3596 total packets):1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480.000 .003 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000512 544 576 1024 1536 2048 2560 3072 3584 4096 4608.000 .000 .000 .995 .000 .000 .000 .000 .000 .000 .000The preceding output shows the percentage distribution of packets by size. In this display, 99.5 percent of the packets fall in the 1024-byte size range, and 0.3 percent fall in the 64-byte range.
The next section of the output can be divided into four parts. The section and the table corresponding to each are as follows:
•
•
•
•
IP Flow Switching Cache, 278544 bytes5 active, 4091 inactive, 25 added719 ager polls, 0 flow alloc failuresActive flows timeout in 1 minutesInactive flows timeout in 10 secondsIP Sub Flow Cache, 25736 bytes10 active, 1014 inactive, 64 added, 25 added to flow0 alloc failures, 0 force free1 chunk, 1 chunk addedlast clearing of statistics neverProtocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)-------- Flows /Sec /Flow /Pkt /Sec /Flow /FlowTCP-FTP 5 0.0 429 840 6.6 58.1 1.8Total: 5 0.0 129 835 6.6 17.6 7.9SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActiveEt0/0.1 10.132.221.111 Et1/0.1 172.16.10.2 06 80 00 1980015 /0 0 0015 /0 0 0.0.0.0 840 41.2MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 10.251.138.218 Et1/0.1 172.16.10.2 06 80 00 1980015 /0 0 0015 /0 0 0.0.0.0 840 41.2MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 10.10.12.1 Et1/0.1 172.16.10.2 06 80 00 2030015 /0 0 0015 /0 0 0.0.0.0 840 42.2MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 10.231.185.254 Et1/0.1 172.16.10.2 06 80 00 2030015 /0 0 0015 /0 0 0.0.0.0 840 42.2MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 10.71.200.138 Et1/0.1 172.16.10.2 06 80 00 2030015 /0 0 0015 /0 0 0.0.0.0 840 42.2MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0R3#Table 6 describes the significant fields shown in the NetFlow cache section of the output.
Table 7 describes the significant fields shown in the activity by protocol section of the output.
Table 7 Field Descriptions in the Activity by Protocol Section of the Output
Protocol
IP protocol and the well-known port number. (Refer to http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
Note
Total Flows
Number of flows for this protocol since the last time statistics were cleared.
Flows/Sec
Average number of flows for this protocol per second; equal to the total flows divided by the number of seconds for this summary period.
Packets/Flow
Average number of packets for the flows for this protocol; equal to the total packets for this protocol divided by the number of flows for this protocol for this summary period.
Bytes/Pkt
Average number of bytes for the packets for this protocol; equal to the total bytes for this protocol divided by the total number of packets for this protocol for this summary period.
Packets/Sec
Average number of packets for this protocol per second; equal to the total packets for this protocol divided by the total number of seconds for this summary period.
Active(Sec)/Flow
Number of seconds from the first packet to the last packet of an expired flow divided by the number of total flows for this protocol for this summary period.
Idle(Sec)/Flow
Number of seconds observed from the last packet in each nonexpired flow for this protocol until the time at which the show ip cache verbose flow command was entered divided by the total number of flows for this protocol for this summary period.
Table 8 describes the significant fields in the NetFlow record section of the output.
Table 8 Field Descriptions in the NetFlow Record Section of the Output
SrcIf
Interface on which the packet was received.
Port Msk AS
Source port number (displayed in hexadecimal format), IP address mask, and autonomous system number. This is always set to 0 in MPLS flows.
SrcIPaddress
This is the source IP address of the traffic in the five flows. The traffic is using five different IP source addresses
•
•
•
•
•
DstIf
Note
Port Msk AS
Source port number (displayed in hexadecimal format), IP address mask, and autonomous system number. The value of this field is always set to 0 in MPLS flows.
DstIPaddress
This is the destination IP address of the traffic.
Note
NextHop
The BGP next-hop address. This is always set to 0 in MPLS flows.
Pr
IP protocol "well-known" port number, displayed in hexadecimal format. (Refer to http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
ToS
Type of service, displayed in hexadecimal format.
B/Pk
Average number of bytes observed for the packets seen for this flow.
Flgs
TCP flags, shown in hexadecimal format. This value is the result of bitwise OR of the TCP flags from all packets in the flow.
Pkts
Number of packets in this flow.
Active
Time the flow has been active.
Table 9 describes the fields and values for the NetFlow Traffic Classification and Identification fields for the NetFlow record section of the output.
The fact that the Layer 3 TTL, identifier and packet length fields in the five flows have the same values is a good indication that this traffic is a DoS attack. If this data had been captured from real traffic the values would typically be different. The fact that all six of these flows have a TTL value of 59 indicates that this traffic is originating from points that are the same distance away from R3. Real user traffic would normally be arriving from many different distances away; therefore the TTL values would be different.
If this traffic is identified as a DoS attack (based on the data captured in the Layer 3 fields) you can use the Layer 2 information in the flows to identify the path the traffic is taking through the network. In this example, the traffic is being sent to R3 on VLAN 5 by R2. You can demonstrate that R2 is transmitting the traffic over interface 1/0.1 because the source MAC address (aaaa.bbb.cc03) belongs to 1/0.1 on R2. You can identify that R3 is transmitting the traffic using VLAN 6 on interface 1/0.1 to interface 1/0.1 on R4 because the destination MAC address (aaaa.bbbb.cc06) belongs to interface 1/0.1 on R4.
You can use this information to develop a plan to mitigate this attack. One possible way to mitigate this attack is by configuring an extended IP access list that blocks FTP traffic from any host with a source address that is on the 10.0.0.0 network. Another possible solution is to configure a default route for the 10.0.0.0 network that points to the null interface on the router.
Caution
Configuring and Using NetFlow Layer 2 and Security Monitoring Exports to Analyze a Simulated ICMP Ping Attack: Example
The following example shows how to use the NetFlow Layer 2 and Security Monitoring Exports feature to find out that your network is being attacked by ICMP traffic. It uses the network shown in Figure 7. Host A is sending very large ICMP ping packets to the FTP server.
R2
!hostname R2!interface Ethernet0/0mac-address aaaa.bbbb.cc02ip address 172.16.1.2 255.255.255.0!interface Ethernet1/0mac-address aaaa.bbbb.cc03no ip address!interface Ethernet1/0.1encapsulation dot1Q 5ip address 172.16.6.1 255.255.255.0!!router ripversion 2network 172.16.0.0no auto-summary!R3
!hostname R3!ip flow-capture packet-lengthip flow-capture ttlip flow-capture vlan-idip flow-capture icmpip flow-capture ip-idip flow-capture mac-addresses!interface Ethernet0/0mac-address aaaa.bbbb.cc04no ip address!interface Ethernet0/0.1encapsulation dot1Q 5ip address 172.16.6.2 255.255.255.0ip accounting output-packetsip flow ingress!interface Ethernet1/0mac-address aaaa.bbbb.cc05no ip address!interface Ethernet1/0.1encapsulation dot1Q 6ip address 172.16.7.1 255.255.255.0ip accounting output-packetsip flow egress!router ripversion 2network 172.16.0.0no auto-summary!R4
!hostname R4!interface Ethernet0/0mac-address aaaa.bbbb.cc07ip address 172.16.10.1 255.255.255.0!interface Ethernet1/0mac-address aaaa.bbbb.cc06no ip address!interface Ethernet1/0.1encapsulation dot1Q 6ip address 172.16.7.2 255.255.255.0!router ripversion 2network 172.16.0.0no auto-summary!The show ip cache verbose flow command displays the NetFlow flows that have been captured from the ICMP traffic that Host A is sending.
The fields that have their values captured by the ip flow-capture command are explained in Table 13. These are the fields and the values that are used to analyze the traffic for this example. The other fields captured by the show ip cache verbose flow command are explained in Table 10, Table 11 and Table 12.
R3# show ip cache verbose flowIP packet size distribution (5344 total packets):1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000512 544 576 1024 1536 2048 2560 3072 3584 4096 4608.000 .000 .000 .166 .832 .000 .000 .000 .000 .000 .000The preceding output shows the percentage distribution of packets by size. In this display, 16.6 percent of the packets fall in the 1024-byte size range and 83.2 percent fall in the 1536-byte range.
The next section of the output can be divided into four sections. The section and the table corresponding to each are as follows:
•
•
•
•
IP Flow Switching Cache, 278544 bytes3 active, 4093 inactive, 7 added91 ager polls, 0 flow alloc failuresActive flows timeout in 1 minutesInactive flows timeout in 10 secondsIP Sub Flow Cache, 25736 bytes7 active, 1017 inactive, 17 added, 7 added to flow0 alloc failures, 0 force free1 chunk, 0 chunks addedlast clearing of statistics 00:01:13Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)-------- Flows /Sec /Flow /Pkt /Sec /Flow /FlowICMP 2 0.0 1500 1378 42.8 11.4 10.9Total: 2 0.0 600 1378 42.9 11.5 10.8SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActiveEt0/0.1 10.106.1.1 Et1/0.1 172.16.10.2 01 00 10 3910000 /0 0 0800 /0 0 0.0.0.0 1500 8.6MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 1500 Max plen: 1500Min TTL: 59 Max TTL: 59ICMP type: 8 ICMP code: 0IP id: 13499Et0/0.1 10.106.1.1 Et1/0.1 172.16.10.2 01 00 00 19500000 /0 0 0000 /0 0 0.0.0.0 1354 8.6MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 772 Max plen: 1500Min TTL: 59 Max TTL: 59ICMP type: 0 ICMP code: 0IP id: 13499R3#Table 10 describes the significant fields shown in the NetFlow cache lines of the output.
Table 11 describes the significant fields shown in the activity by protocol lines of the output.
Table 11 Field Descriptions in the Activity by Protocol Section of the Output
Protocol
IP protocol and the well-known port number. (Refer to http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
Note
Total Flows
Number of flows for this protocol since the last time statistics were cleared.
Flows/Sec
Average number of flows for this protocol per second; equal to the total flows divided by the number of seconds for this summary period.
Packets/Flow
Average number of packets for the flows for this protocol; equal to the total packets for this protocol divided by the number of flows for this protocol for this summary period.
Bytes/Pkt
Average number of bytes for the packets for this protocol; equal to the total bytes for this protocol divided by the total number of packets for this protocol for this summary period.
Packets/Sec
Average number of packets for this protocol per second; equal to the total packets for this protocol divided by the total number of seconds for this summary period.
Active(Sec)/Flow
Number of seconds from the first packet to the last packet of an expired flow divided by the total number of flows for this protocol for this summary period.
Idle(Sec)/Flow
Number of seconds observed from the last packet in each nonexpired flow for this protocol until the time at which the show ip cache verbose flow command was entered divided by the total number of flows for this protocol for this summary period.
Table 12 describes the significant fields in the NetFlow record lines of the output.
Table 12 Field Descriptions in the NetFlow Record Section of the Output
SrcIf
Interface on which the packet was received.
Port Msk AS
Source port number (displayed in hexadecimal format), IP address mask, and autonomous system number. The value of this field is always set to 0 in MPLS flows.
SrcIPaddress
IP address of the device that transmitted the packet. The sending host is using 10.106.1.1 as the source IP address.
DstIf
Note
Port Msk AS
Destination port number (displayed in hexadecimal format), IP address mask, and autonomous system. This is always set to 0 in MPLS flows.
DstIPaddress
IP address of the destination device.
NextHop
The BGP next-hop address. This is always set to 0 in MPLS flows.
Pr
IP protocol "well-known" port number, displayed in hexadecimal format. (Refer to http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
ToS
Type of service, displayed in hexadecimal format.
B/Pk
Average number of bytes observed for the packets seen for this flow.
Flgs
TCP flags, shown in hexadecimal format. This value is the result of bitwise OR of the TCP flags from all packets in the flow.
Pkts
Number of packets in this flow.
Active
Time the flow has been active.
Table 13 describes the fields and values for the NetFlow Traffic Classification and Identification fields for the NetFlow record lines of the output.
There are two ICMP flows shown in the output. You can tell that they are from the same ICMP datagram because they have the same IP id field value of 13499. When two ICMP flows have the same IP id value, the ICMP datagram being analyzed has been fragmented. The first flow has the ICMP type field set to 8, which indicates that this is an ICMP echo request (ping) datagram. The value of 0 in the ICMP type field of the second flow does not mean that this flow is an ICMP echo reply as Table 2 shows. In this case the ICMP type field value is set to 0 because the ICMP headers for fragments of ICMP datagrams do not have the type and code fields. The default value of 0 has been inserted instead.
Note
Although you cannot find out the original size of the ICMP datagram from the information shown by the show ip cache verbose flow the fact that it was large enough to be fragmented in transit is a good indication that this is not a normal ICMP datagram. Notice the values in the minimum and maximum packet length fields for both flows. The values for both fields are set to 1500 for the first flow. The value for the minimum packet length is set to 772 and the value for the maximum packet length is set to 1500 for the second flow.
If this traffic is identified as a DoS attack based on the data captured in the Layer 3 fields, you can use the Layer 2 information in the flows to identify the path the traffic is taking through the network. In this example, the traffic is being sent to R3 on VLAN 5 by R2. You can demonstrate that R2 is transmitting the traffic over interface 1/0.1 because the source MAC address (aaaa.bbb.cc03) belongs to 1/0.1 on R2. You can demonstrate that R3 is transmitting the traffic using VLAN 6 on interface 1/0.1 to interface 1/0.1 on R4, because the destination MAC address (aaaa.bbbb.cc06) belongs to interface 1/0.1 on R4.
You can use this information to mitigate this attack. One possible way to mitigate this attack is by configuring an extended IP access list that blocks ICMP traffic from any host with a source address that is on the 10.0.0.0 network. Another possible solution is to configure a default route for the 10.0.0.0 network that points to the null interface on the router.
Caution
Additional References
The following sections provide references related to NetFlow Layer 2 and Security Monitoring Exports.
Related Documents
General NetFlow Overview
NetFlow Overview section of the Cisco IOS Switching Configuration Guide, Release 12.3
Standards
MIBs
RFCs
Technical Assistance
Command Reference
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS command reference publications.
ip flow-capture
To capture Layer 2 or Layer 3 fields from NetFlow traffic, use the ip flow-capture command in global configuration mode. To disable capturing Layer 2 or Layer 3 fields from NetFlow traffic, use the no ip flow-capture command.
ip flow-capture {icmp | ip-id | mac-addresses | packet-length | ttl | vlan-id}
no ip flow-capture {icmp | ip-id | mac-addresses | packet-length | ttl | vlan-id}
Syntax Description
Defaults
The ip flow-capture command is disabled by default. You must select one of the keywords when you configure the ip flow-capture command.
Command Modes
Global configuration
Command History
Usage Guidelines
•
•
Note
Note
Note
ip flow-capture icmp
ICMP is used for several purposes. One of the most common is the ICMP ping command. ICMP ping echo packets are sent by a host to a destination host to verify that the destination host is reachable by IP. If the destination is reachable, it should respond by sending ICMP ping reply. Refer to RFC792 (http://www.freesoft.org/CIE/RFC/792/) for more information on ICMP.
ICMP packets have been used in many types of attacks on networks. Two of the most common attacks are denial-of-service (DoS) attacks and the ping of death attack.
•
•
Finding out the types of ICMP traffic in your network can help you decide if your network is being attacked by ICMP packets.
The ip flow-capture icmp command captures the value of the ICMP type field and the ICMP code field from the first ICMP packet detected in a flow.
ip flow-capture ip-id
It is possible for a host to receive IP datagrams from two or more senders concurrently. When this happens the receiving host must be able to identify the fragments from each of the incoming datagrams to ensure that it does combine datagram fragments from different sources into the same datagram during the datagram reassembly process. The IP header identification field is used for this purpose.
The ip flow-capture ip-id command captures the value of the IP header identification field from the first packet in the flow. The value in the IP header identification field is a sequence number assigned by the host that originally transmitted the IP datagram. All of the fragments of an IP datagram have the same identifier value. This ensures that the destination host can match the IP datagram to the fragment during the IP datagram reassembly process. The sending host is responsible for ensuring that each subsequent IP datagram it sends to the same destination host has a unique value for the IP header identification field.
If you are seeing several flows with the same value for the IP header identification field, it is possible that your network is being attacked by a host that is constantly sending the same IP packets over and over.
ip flow-capture packet-length
The value in the length field in an IP datagram indicates the length of the IP datagram, excluding the IP header.
Use the ip flow-capture packet-length command to capture the value of the IP header length field for packets in the flow. The ip flow-capture packet-length command keeps track of the minimum and maximum values captured from the flow. This data is updated when a packet with a packet length that is lower or higher than the currently stored value is received. For example if the currently stored value for the minimum packet length is 1024 bytes and the next packet received has a packet length of 512 bytes, the 1024 is replaced with 512.
If you are seeing several IP datagrams in the flow with the same value for the packet-length field, it is possible that your network is being attacked by a host that is constantly sending the same IP packets over-and-over.
ip flow-capture ttl
The TTL field is used to prevent the indefinite forwarding of IP datagrams. The TTL field contains a counter value set by the source host. Each router that processes this datagram decreases the TTL value by 1. When the TTL value reaches 0, the datagram is discarded.
There are two scenarios where an IP packet without a TTL field could live indefinitely in a network:
•
•
The ip flow-capture ttl command keeps track of the minimum and maximum values captured from the flow. This data is updated when a packet with a TTL that is lower or higher than the currently stored value is received. For example if the currently stored value for the minimum TTL is 64 and the next packet received has a TTL of 12, the 64 is replaced by 12.
If you are seeing several flows with the same value for the TTL, it is possible that your network is being attacked by a host that is constantly sending the same IP packets over and over. Under normal circumstances, flows come from many sources, each a different distance away. Therefore you should see a variety of TTLs across all the flows that NetFlow is capturing.
ip flow-capture mac-addresses
The ip flow-capture mac-addresses command captures the incoming source mac-address and the outgoing destination mac-address from the first Layer 2 frame in the flow. If you discover that your network is being attacked by Layer 3 traffic, you can use these addresses to identify the device that is transmitting the traffic that is being received by the router and the next hop or final destination device to which the router is forwarding the traffic.
ip flow-capture vlan-id
VLANs are a broadcast domain within a switched network. Broadcast domains are the domain where a network propagates a broadcast frame generated by a station. Some switches can be configured to support single or multiple VLANs. Whenever a switch supports multiple VLANs, broadcasts within one VLAN never appear in another VLAN.
Each VLAN is also a separate Layer 3 network. A router or a multilayer switch must be be used to interconnect the Layer 3 networks that are assigned to the VLANs. For example in order for a device on VLAN 2 with an IP address of 172.16.0.76 to communicate with a device on VLAN 3 with an IP address of 172.17.0.34, the two devices must use a router as an intermediary device, because they are on different Class B IP networks. This is typically accomplished by connecting a switch to a router and configuring the link between them as a VLAN trunk. In order for the link to be used as a VLAN trunk, the interfaces on the router and the switch must be configured for the same VLAN encapsulation type.
Note
When a router or a switch needs to send traffic on a VLAN trunk, it must either tag the frames using the IEEE 802.1q protocol or encapsulate the frames using the Cisco Inter-Switch Link (ISL) protocol. The VLAN tag or encapsulation header must contain the correct VLAN ID to ensure that the device receiving the frames can process them properly. The device that receives the VLAN traffic examines the VLAN ID from each frame to find out how it should process the frame. For example when a switch receives an IP broadcast datagram such as an Address Resolution Protocol (ARP) datagram with an 802.1q tagged VLAN ID of 6 from a router, it forwards the datagram to every interface that is assigned to VLAN 6 and any interfaces that are configured as VLAN trunks.
The ip flow-capture vlan-id command captures the VLAN ID number from the first frame in the flow it receives that has an 802.1q tag or that is encapsulated with ISL. When the received traffic in the flow is transmitted over an interface that is configured with either 802.1q or ISL trunking, the ip flow-capture vlan-id command captures the destination VLAN ID number from the 802.1q or ISL VLAN header from the first frame in the flow.
Note
Your router configuration must meet the following criteria before NetFlow can capture the value in the VLAN-ID field:
•
•
•
If you discover that your network is being attacked by Layer 3 traffic, you can use the VLAN-ID information to help you find out which VLAN the device that is sending the traffic is on. The information can also help you identify the VLAN to which the router is forwarding the traffic.
Examples
•
•
ip flow-capture icmp
The following example shows how to configure NetFlow to capture the value of the ICMP Type field and the value of the Code field from the IP datagrams in the flow:
RouterA(config)# ip flow-capture icmpip flow-capture ip-id
The following example shows how to configure NetFlow to capture the value of the IP-ID field from the IP datagrams in the flow:
RouterA(config)# ip flow-capture ip-idip flow-capture packet-length
The following example shows how to configure NetFlow to capture the value of the packet length field from the IP datagrams in the flow:
RouterA(config)# ip flow-capture packet-lengthip flow-capture ttl
The following example shows how to configure NetFlow to capture the TTL field from the IP datagrams in the flow:
RouterA(config)# ip flow-capture ttlip flow-capture mac-addresses
The following example shows how to configure NetFlow to capture the MAC addresses from the IP datagrams in the flow:
RouterA(config)# ip flow-capture mac-addressesip flow-capture vlan-id
The following example shows how to configure NetFlow to capture the vlan-id from the IP datagrams in the flow:
RouterA(config)# ip flow-capture vlan-idRelated Commands
show ip cache verbose flow
To display a detailed summary of NetFlow statistics, use the show ip cache verbose flow command in privileged EXEC mode.
show ip cache verbose flow
Syntax Description
This command has no keywords or arguments.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the show ip cache verbose flow command to display flow record fields in the NetFlow cache in addition to the fields that are displayed with the show ip cache flow command. The values in the additional fields that are shown depend on the NetFlow features that are enabled and the flags that are set in the flow.
Note
Some of the content in the display of the show ip cache verbose flow command uses multiline headings and multiline data fields. Figure 8 shows how to associate the headings with the correct data fields when there are two lines of headings and two lines of data fields. The first line of the headings is associated with the first line of data fields. The second line of the headings is associated with the second line of data fields.
When other features such as IP Multicast are configured, the number of lines in the headings and data fields increases. The method for associating the headings with the correct data fields remains the same.
Figure 8 How to use the Multiline Headings and Multiline Data Fields in the Display Output of the show ip cache verbose flow Command
When the NetFlow Multicast Support feature is enabled, the show ip cache verbose flow command displays the number of replicated packets and the packet byte count for NetFlow multicast accounting. When you configure the NetFlow Version 9 Export Format feature, this command displays additional NetFlow fields in the header.
When you configure the MPLS-aware NetFlow feature, you can use the show ip cache verbose flow command to display both the IP and MPLS portions of MPLS flows in the NetFlow cache on a router line card. To display only the IP portion of the flow record in the NetFlow cache when MPLS-aware NetFlow is configured, use the show ip cache flow command.
Displaying Detailed NetFlow Cache Information on Platforms Running Distributed Cisco Express Forwarding
On platforms running Distributed Cisco Express Forwarding (dCEF), NetFlow cache information is maintained on each line card or Versatile Interface Processor. If you want to use the show ip cache verbose flow command to display this information on a distributed platform, you must enter the command at a line card prompt.
Cisco 7500 Series Platform
To display detailed NetFlow cache information on a Cisco 7500 series router that is running distributed dCEF, enter the following sequence of commands:
Router# if-con slot-numberLC-slot-number# show ip cache verbose flowFor Cisco IOS Releases 12.3(4)T, 12.3(6), and 12.2(20)S and later, enter the following command to display detailed NetFlow cache information:
Router# execute-on slot-number show ip cache verbose flowCisco 12000 Series Platform
To display detailed NetFlow cache information on a Cisco 12000 Series Internet Router, enter the following sequence of commands:
Router# attach slot-numberLC-slot-number# show ip cache verbose flowFor Cisco IOS Releases 12.3(4)T, 12.3(6), and 12.2(20)S and later, enter the following command to display detailed NetFlow cache information:
Router# execute-on slot-number show ip cache verbose flowExamples
The following example shows output from the show ip cache verbose flow command:
Router# show ip cache verbose flowIP packet size distribution (25229 total packets):1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000512 544 576 1024 1536 2048 2560 3072 3584 4096 4608.000 .000 .000 .206 .793 .000 .000 .000 .000 .000 .000The preceding output shows the percentage distribution of packets by size. In this display, 20.6 percent of the packets fall in the 1024-byte size range and 79.3 percent fall in the 1536-byte range.
The next section of the output can be divided into three sections. The section and the table corresponding to each are as follows:
•
•
•
IP Flow Switching Cache, 278544 bytes6 active, 4090 inactive, 17 added505 ager polls, 0 flow alloc failuresActive flows timeout in 1 minutesInactive flows timeout in 10 secondsIP Sub Flow Cache, 25736 bytes12 active, 1012 inactive, 39 added, 17 added to flow0 alloc failures, 0 force free1 chunk, 1 chunk addedlast clearing of statistics neverProtocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)-------- Flows /Sec /Flow /Pkt /Sec /Flow /FlowTCP-Telnet 1 0.0 362 940 2.7 60.2 0.0TCP-FTP 1 0.0 362 840 2.7 60.2 0.0TCP-FTPD 1 0.0 362 840 2.7 60.1 0.1TCP-SMTP 1 0.0 361 1040 2.7 60.0 0.1UDP-other 5 0.0 1 66 0.0 1.0 10.6ICMP 2 0.0 8829 1378 135.8 60.7 0.0Total: 11 0.0 1737 1343 147.0 33.4 4.8SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActiveEt0/0.1 10.251.138.218 Et1/0.1 172.16.10.2 06 80 00 650015 /0 0 0015 /0 0 0.0.0.0 840 10.8MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 172.16.6.1 Et1/0.1 172.16.10.2 01 00 00 48800000 /0 0 0000 /0 0 0.0.0.0 1354 20.1MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 772 Max plen: 1500Min TTL: 255 Max TTL: 255ICMP type: 0 ICMP code: 0IP id: 2943 FO: 185Et0/0.1 10.10.13.1 Et1/0.1 172.16.10.2 06 80 00 650017 /0 0 0017 /0 0 0.0.0.0 940 10.8MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 940 Max plen: 940Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 10.89.38.215 Et1/0.1 172.16.10.2 06 80 00 650014 /0 0 0014 /0 0 0.0.0.0 840 10.8MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 840 Max plen: 840Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 10.10.14.1 Et1/0.1 172.16.10.2 06 80 00 660019 /0 0 0019 /0 0 0.0.0.0 1040 11.0MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 1040 Max plen: 1040Min TTL: 59 Max TTL: 59IP id: 0Et0/0.1 172.16.6.1 Et1/0.1 172.16.10.2 01 00 10 9750000 /0 0 0800 /0 0 0.0.0.0 1500 20.1MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)Min plen: 1500 Max plen: 1500Min TTL: 255 Max TTL: 255ICMP type: 8 ICMP code: 0IP id: 2944R3#Table 14 describes the significant fields shown in the NetFlow cache section of the output.
Table 15 describes the significant fields shown in the activity by protocol section of the output.
Table 15 Field Descriptions in the Activity by Protocol Section of the Output
Protocol
IP protocol and the well-known port number. (Refer to http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
Note
Total Flows
Number of flows in the cache for this protocol since the last time the statistics were cleared.
Flows/Sec
Average number of flows for this protocol per second; equal to the total flows divided by the number of seconds for this summary period.
Packets/Flow
Average number of packets for the flows for this protocol; equal to the total packets for this protocol divided by the number of flows for this protocol for this summary period.
Bytes/Pkt
Average number of bytes for the packets for this protocol; equal to the total bytes for this protocol divided by the total number of packets for this protocol for this summary period.
Packets/Sec
Average number of packets for this protocol per second; equal to the total packets for this protocol divided by the total number of seconds for this summary period.
Active(Sec)/Flow
Number of seconds from the first packet to the last packet of an expired flow divided by the number of total flows for this protocol for this summary period.
Idle(Sec)/Flow
Number of seconds observed from the last packet in each nonexpired flow for this protocol until the time at which the show ip cache verbose flow command was entered divided by the total number of flows for this protocol for this summary period.
Table 16 describes the significant fields in the NetFlow record section of the output.
Table 16 Field Descriptions in the NetFlow Record Section of the Output
SrcIf
Interface on which the packet was received.
Port Msk AS
Source port number (displayed in hexadecimal format), IP address mask, and autonomous system number. The value of this field is always set to 0 in MPLS flows.
SrcIPaddress
IP address of the device that transmitted the packet.
DstIf
Note
Port Msk AS
Destination port number (displayed in hexadecimal format), IP address mask, and autonomous system. This is always set to 0 in MPLS flows.
DstIPaddress
IP address of the destination device.
NextHop
The BGP next-hop address. This is always set to 0 in MPLS flows.
Pr
IP protocol "well-known" port number, displayed in hexadecimal format. (Refer to http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
ToS
Type of service, displayed in hexadecimal format.
B/Pk
Average number of bytes observed for the packets seen for this Flow.
Flgs
TCP flags, shown in hexadecimal format (result of bitwise OR of TCP flags from all packets in the flow).
Pkts
Number of packets in this flow.
Active
Time the flow has been active.
MAC
Source and destination MAC addresses from the Layer 2 frames in the flow.
VLAN id
Source and destination VLAN IDs from the Layer 2 frames in the flow.
Min plen
Minimum packet length for the packets in the flows.
Note
Max plen
Maximum packet length for the packets in the flows.
Note
Min TTL
Minimum Time-To-Live (TTL) for the packets in the flows.
Note
Max TTL
Maximum TTL for the packets in the flows.
Note
IP id
IP identifier field for the packets in the flow.
ICMP type
Internet Control Message Protocol (ICMP) type field from the ICMP datagram in the flow.
ICMP code
ICMP code field from the ICMP datagram in the flow.
FO
Fragment offset field from the first fragmented datagram in the flow.
The following example shows the NetFlow output of the show ip cache verbose cache flow command in which the sampler, class-id, and general flags are set. What is displayed for a flow depends on what flags are set in the flow. If the flow was captured by a sampler, the output shows the sampler ID. If the flow was marked by Modular QoS CLI (MQC), the display includes the class ID. If any general flags are set, the output includes the flags.
...SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActiveBGP: BGP NextHopEt1/0 8.8.8.8 Et0/0* 9.9.9.9 01 00 10 30000 /8 302 0800 /8 300 3.3.3.3 100 0.1BGP: 2.2.2.2 Sampler: 1 Class: 1 FFlags: 01Table 17 describes the significant fields shown in the NetFlow output for a sampler, for an MQC policy class, and for general flags.
The following example shows the NetFlow output for the show ip cache verbose flow command when NetFlow BGP next-hop accounting is enabled:
Router# show ip cache verbose flow...SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActiveMUL:M_Opaks M_Obytes BGP:BGP_NextHopEt0/0/2 12.0.0.2 Et0/0/4 13.0.0.5 01 00 10 200000 /8 0 0800 /8 0 11.0.0.6 100 0.0BGP:26.0.0.6Et0/0/2 12.0.0.2 Et0/0/4 15.0.0.7 01 00 10 200000 /8 0 0800 /8 0 11.0.0.6 100 0.0BGP:26.0.0.6Et0/0/2 12.0.0.2 Et0/0/4 15.0.0.7 01 00 10 200000 /8 0 0000 /8 0 11.0.0.6 100 0.0BGP:26.0.0.6Table 18 describes the significant fields shown in the NetFlow BGP next-hop accounting lines of the output.
The following example shows the NetFlow output for the show ip cache verbose flow command when NetFlow multicast accounting is configured:
Router# show ip cache verbose flow...SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActiveIPM:OPkts OBytesIPM: 0 0Et1/1/1 11.0.0.1 Null 227.1.1.1 01 55 10 1000000 /8 0 0000 /0 0 0.0.0.0 28 0.0IPM: 100 2800Et1/1/1 11.0.0.1 Se2/1/1.16 227.1.1.1 01 55 10 1000000 /8 0 0000 /0 0 0.0.0.0 28 0.0IPM: 0 0Et1/1/2 12.0.0.1 Et1/1/4 227.2.2.2 01 55 10 1000000 /8 0 0000 /0 0 0.0.0.0 28 0.1Et1/1/2 12.0.0.1 Null 227.2.2.2 01 55 10 1000000 /8 0 0000 /0 0 0.0.0.0 28 0.1IPM: 100 2800Table 19 describes the significant fields shown in the NetFlow multicast accounting lines of the output.
The following example shows the output for both the IP and MPLS sections of the flow record in the NetFlow cache when MPLS-aware NetFlow is enabled:
Router# show ip cache verbose flow...SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs PktsPort Msk AS Port Msk AS NextHop B/Pk ActivePO3/0 10.1.1.1 PO5/1 10.2.1.1 01 00 10 90100 /0 0 0200 /0 0 0.0.0.0 100 0.0Pos:Lbl-Exp-S 1:12305-6-0 (LDP/10.10.10.10) 2:12312-6-1Table 20 describes the significant fields for the IP and MPLS sections of the flow record in the output.
Related Commands
Guest
