Table Of Contents

NetFlow Layer 2 and Security Monitoring Exports

Contents

Prerequisites for NetFlow Layer 2 and Security Monitoring Exports

Restrictions for NetFlow Layer 2 and Security Monitoring Exports

NetFlow Data Export

Information About NetFlow Layer 2 and Security Monitoring Exports

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

Prerequisites

Restrictions

Verifying NetFlow Layer 2 and Security Monitoring Exports

Configuration Examples for NetFlow Layer 2 and Security Monitoring Exports

Configuring and Using NetFlow Layer 2 and Security Monitoring Exports to Analyze a Simulated FTP Attack: Example

Configuring and Using NetFlow Layer 2 and Security Monitoring Exports to Analyze a Simulated ICMP Ping Attack: Example

Where to Go Next

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Glossary

Feature Information for NetFlow Layer 2 and Security Monitoring Exports

NetFlow Layer 2 and Security Monitoring Exports

---

This document contains information about and instructions for configuring NetFlow Layer 2 and Security Monitoring Exports. Configuring NetFlow Layer 2 and Security Monitoring Exports improves your ability to detect and analyze network threats such as denial of service attacks (DoS) by increasing the number of fields that netFlow can capture the values from.

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.

Module History

This module was first published on June 27th, 2005, and last updated on February 16th, 2006.

Finding Feature Information in This Module

Your Cisco IOS software release may not support all features. To find information about feature support and configuration, use the "Feature Information for NetFlow Layer 2 and Security Monitoring Exports" section.

Contents

•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

•How to Configure NetFlow Layer 2 and Security Monitoring Exports

•Configuration Examples for NetFlow Layer 2 and Security Monitoring Exports

•Additional References

•Glossary

•Feature Information for NetFlow Layer 2 and Security Monitoring Exports

Prerequisites for NetFlow Layer 2 and Security Monitoring Exports

Before you enable NetFlow you must:

•Configure the router for IP routing

•Ensure that one of the following is enabled on your router, and on the interfaces that you want to configure NetFlow on: Cisco Express Forwarding (CEF), distributed CEF, or fast switching

•Understand the resources required on your router because NetFlow consumes additional memory and CPU resources.

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.

Memory Impact

During times of heavy traffic, the additional flows can fill up the global flow hash table. If you need to increase the size of the global flow hash table, increase the memory of the router.

Performance Impact

Configuring Egress NetFlow accounting with the ip flow egress command might adversely affect network performance because of the additional accounting-related computation that occurs in the traffic-forwarding path of the router.

Cisco IOS Releases 12.2(14)S, 12.0(22)S, or 12.2(15)T

If your router is running a version of Cisco IOS prior to releases 12.2(14)S, 12.0(22)S, or 12.2(15)T the ip route-cache flow command is used to enable NetFlow on an interface.

If your router is running Cisco IOS release 12.2(14)S, 12.0(22)S, 12.2(15)T, or later the ip flow ingress command is used to enable NetFlow on an interface.

NetFlow Data Export

Restrictions for NetFlow Version 9 Data Export

•Backward compatibility—Version 9 is not backward-compatible with Version 5 or Version 8. If you need Version 5 or Version 8, you must configure it.

•Export bandwidth—Export bandwidth use increases for Version 9 (because of template flowsets) versus Version 5. The increase in bandwidth usage versus Version 5 varies with the frequency with which template flowsets are sent. The default is to resend templates every 20 packets, which has a bandwidth cost of about 4 percent. If necessary, you can lower the resend rate with the ip flow-export template refresh-rate packets command.

•Performance impact—Version 9 slightly decreases overall performance, because generating and maintaining valid template flowsets require additional processing.

Restrictions for NetFlow Version 8 Export Format

Version 8 export format is available only for aggregation caches, and it cannot be expanded to support new features.

Restrictions for NetFlow Version 5 Export Format

Version 5 export format is suitable only for the main cache, and it cannot be expanded to support new features.

Restrictions for NetFlow Version 1 Export Format

The Version 1 format was the initially released version. Do not use Version 1 format unless you are using a legacy collection system that requires it. Use Version 9 or Version 5 export format.

Information About NetFlow Layer 2 and Security Monitoring Exports

To configure NetFlow Layer 2 and Security Monitoring Exports, you should understand the following concept:

•NetFlow Layer 2 and Security Monitoring

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 Layer 3 IP header fields that the NetFlow Layer 2 and Security Monitoring Exports feature captures the values of are:

•Time-to-Live field

•Packet Length field

•ID field

•ICMP type and code fields

See the "Layer 3 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports" section for more information on these Layer 3 fields.

The Layer 2 fields that NetFlow Layer 2 and Security Monitoring Exports feature captures the values of are:

•Source MAC address field from frames that are received by the NetFlow router

•Destination MAC address field from frames that are transmitted by the NetFlow router

•VLAN ID field from frames that are received by the NetFlow router

•VLAN ID field from frames that are transmitted by the NetFlow router

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 You can analyze the data captured by NetFlow directly from the router using the show ip cache verbose flow command or with the CNS NetFlow Collector Engine.

---

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 has support for capturing four fields from Layer 3 IP traffic in a flow:

•Time-to-Live field

•Packet Length field

•ID field

•ICMP type and code

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

Table 1 IP Packet Header Fields 

Field	Description
Version	The version of the IP protocol. If this field is set to 4 it is an IPv4 datagram. If this field is set to 6 it is an IPv6 datagram. Note The IPv6 header has a different structure than an IPv4 header.
IHL (Internet Header Length)	Internet Header Length is the length of the internet header in 32-bit word and thus points to the beginning of the data. Note The minimum value for a correct header is 5.
ToS	ToS provides an indication of the abstract parameters of the quality of service desired. These parameters are to be used to guide the selection of the actual service parameters when a networking device transmits a datagram through a particular network.
Total Length	Total length is the length of the datagram, measured in octets, including internet header and data.
Identification (ID)	The value in the ID field is entered by the sender. All of the fragments of an IP datagram have the same value in the ID field. Subsequent IP datagrams from the same sender will have different values in the ID field. It is very common for a host to be receiving fragmented IP datagrams from several senders concurrently. It is also common for a host to be receiving multiple IP datagrams from the same sender concurrently. The value in the ID field is used by the destination host to ensure that the fragments of an IP datagram are assigned to the same packet buffer during the IP datagram reassembly process. The unique value in the ID field is also used to prevent the receiving host from mixing together IP datagram fragments of different IP datagrams from the same sender during the IP datagram reassembly process.
Flags	A sequence of 3 bits used to set and track IP datagram fragmentation parameters. •001 = The IP datagram can be fragmented. There are more fragments of the current IP datagram in transit. •000 = The IP datagram can be fragmented. This is the last fragment of the current IP datagram. •010 = The IP Datagram cannot be fragmented. This is the entire IP datagram.
TTL (Time-to-Live)	This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value 0, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least 1 even if it processes the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram can exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.
Protocol	Indicates the type of transport packet included in the data portion of the IP datagram. Common values are: 1 = ICMP 6 = TCP 17 = UDP
Header checksum	A checksum on the header only. Since some header fields, such as the time-to-live field, change every time an IP datagram is forwarded, this value is recomputed and verified at each point that the internet header is processed.
Source IP Address	IP address of the sending station.
Destination IP Address	IP address of the destination station.
Options and Padding	The options and padding may or may not appear or not in datagrams. If they do appear, they must be implemented by all IP modules (host and gateways). What is optional is their transmission in any particular datagram, not their implementation.

Figure 3 ICMP Datagram

Table 2 ICMP Packet Format 

Type	Name	Codes
0	Echo reply	0—None
1	Unassigned	—
2	Unassigned	—
3	Destination unreachable	0—Net unreachable. 1—Host unreachable. 2—Protocol unreachable. 3—Port unreachable. 4—Fragmentation needed and DF bit set. 5—Source route failed. 6—Destination network unknown. 7—Destination host unknown. 8—Source host isolated. 9—Communication with destination network is administratively prohibited. 10—Communication with destination host is administratively prohibited. 11—Destination network unreachable for ToS. 12—Destination host unreachable for ToS.
4	Source quench	0—None.
5	Redirect	0—None. 0—Redirect datagram for the network. 1—Redirect datagram for the host. 2—Redirect datagram for the TOS and network. 3—Redirect datagram for the TOS and host.
6	Alternate host address	0—Alternate address for host.
7	Unassigned	—
8	Echo	0—None.
9	Router advertisement	0—None.
10	Router selection	0—None.
11	Time Exceeded	0—Time to live exceeded in transit.
12	Parameter problem	0—Pointer indicates the error. 1—Missing a required option. 2—Bad length.
13	Timestamp	0—None.
14	Timestamp reply	0—None.
15	Information request	0—None.
16	Information reply	0—None.
17	Address mask request	0—None.
18	Address mask reply	0—None.
19	Reserved (for security)	—
20-29	Reserved (for robustness experiment)	—
30	Trace route	—
31	Datagram conversion error	—
32	Mobile host redirect	—
33	IPv6 where-are-you	—
34	IPv6 I-am-here	—
35	Mobile registration request	—
36	Mobile registration reply	—
37-255	Reserved	—

Layer 2 Information Capture Using NetFlow Layer 2 and Security Monitoring Exports

The NetFlow Layer 2 and Security Monitoring Exports feature has 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

•Understanding Layer 2 VLAN ID Fields

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 source MAC address field from frames that are received by the NetFlow router

•The destination MAC address field from frames that are transmitted by the NetFlow router

•The VLAN ID field from frames that are received by the NetFlow router

•The VLAN ID field from frames that are transmitted by the NetFlow router

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

Table 3 Ethernet Type II and 802.3 Frame Fields 

Field	Description
Preamble	The entry in the Preamble field is an alternating pattern of 1s and 0s that tells receiving stations that a frame is coming. It also provides a means for the receiving stations to synchronize their clocks with the incoming bit stream.
SOF (Start of frame )	The SOF field holds an alternating pattern of 1s and 0s, ending with two consecutive 1-bits indicating that the next bit is the first bit of the first byte of the destination MAC address.
Destination Address	The 48-bit destination address identifies which station(s) on the LAN should receive the frame. The first two bits of the destination MAC address are reserved for special functions: •The first bit in the DA field indicates whether the address is an individual address (0) or a group address (1). •The second bit indicates whether the DA is globally administered (0) or locally administered (1). The remaining 46 bits are a uniquely assigned value that identifies a single station, a defined group of stations, or all stations on the network.
Source Address	The 48-bit source address identifies which station transmitted the frame. The source address is always an individual address and the left-most bit in the SA field is always 0.
Type or Length	Type—In an Ethernet Type II frame this part of the frame is used for the Type field. The Type field is used to identify the next layer protocol in the frame. Length—In an 802.3 Ethernet frame this part of the frame is used for the Length field. The Length field is used to indicate the length of the Ethernet frame. The value can be between 46 and 1500 bytes.
Data or 802.2 header and data	(Ethernet type II) 46-1500 bytes of data or (802.3/802.2) 8 bytes of header and 38-1492 bytes of data.
FCS (Frame Check Sequence)	This field contains a 32-bit cyclic redundancy check (CRC) value, which is created by the sending station and is recalculated by the receiving station to check for damaged frames. The FCS is generated for the DA, SA, Type, and Data fields of the frame. The FCS does not include the data portion of the frame.

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 It has become common to refer to both 802.1q and ISL as VLAN encapsulation protocols.

---

•Understanding 802.1q VLANs

•Understanding Cisco ISL VLANs

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 

Field	Description
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: •(CFI)Canonical Format Indicator (CFI)—If the value of this 1-bit field is 1, then the MAC address is in noncanonical format. If the value of this field is 0, then the MAC address is in canonical format. •VLAN ID—This 12-bit field uniquely identifies the VLAN to which the frame belongs. It can have a value between 0 and 4095.

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

Table 5 ISL VLAN Encapsulation 

Field	Description
DA (destination address)	This 40-bit field is a multicast address and is set at 0x01-00-0C-00-00 or 0x03-00-0c-00-00. The receiving host determines that the frame is encapsulated in ISL by reading the 40-bit DA field and matching it to one of the two ISL multicast addresses.
Type	This 4-bit field indicates the type of frame that is encapsulated and could be used in the future to indicate alternative encapsulations. TYPE codes: •0000 = Ethernet •0001 = Token Ring •0010 = FDDI •0011 = ATM
USER	This 4-bit field is used to extend the meaning of the Frame TYPE field. The default USER field value is 0000. For Ethernet frames, the USER field bits 0 and 1 indicate the priority of the packet as it passes through the switch. Whenever traffic can be handled more quickly, the packets with this bit set should take advantage of the quicker path. Such paths however are not required. USER codes: •XX00 = Normal priority •XX01 = Priority 1 •XX10 = Priority 2 •XX11 = Highest priority
SA	This 48-bit field is the source address field of the ISL packet. It should be set to the 802.3 MAC address of the switch port transmitting the frame. The receiving device can ignore the SA field of the frame.
LEN	This 16-bit value field stores the actual packet size of the original packet. The LEN field represents the length of the packet in bytes, excluding the DA, TYPE, USER, SA, LEN, and FCS fields. The total length of the excluded fields is 18 bytes, so the LEN field represents the total length minus 18 bytes.
AAAA03(SNAP)	The AAAA03 SNAP field is a 24-bit constant value of 0xAAAA03.
HSA	This 24-bit field represents the upper three bytes (the manufacturer's ID portion) of the SA field. It must contain the value 0x00-00-0C.
VLAN	This 15-bit field is the Virtual LAN ID of the packet. This value is used to mark frames on different VLANs.
BPDU	The bit in the BPDU field is set for all BPDU packets that are encapsulated by the ISL frame. The BPDUs are used by the spanning tree algorithm to find out information about the topology of the network. This bit is also set for CDP and VTP frames that are encapsulated.
INDEX	This 16-bit field indicates the port index of the source of the packet as it exits the switch. It is used for diagnostic purposes only, and may be set to any value by other devices. It is ignored in received packets.
RES	This 16-bit field is used when Token Ring or FDDI packets are encapsulated with an ISL frame.
Encapsulated FRAME	This field contains the encapsulated Layer 2 frame.
FCS	The FCS field consists of 4 bytes. It includes a 32-bit CRC value, which is created by the sending station and is recalculated by the receiving station to check for damaged frames. The FCS covers the DA, SA, Length/Type, and Data fields. When an ISL header is attached to a Layer 2 frame, a new FCS is calculated over the entire ISL packet and added to the end of the frame. Note The addition of the new FCS does not alter the original FCS that is contained within the encapsulated 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 (required)

•Verifying NetFlow Layer 2 and Security Monitoring Exports (optional)

Configuring NetFlow Layer 2 and Security Monitoring Exports

To configure NetFlow Layer 2 and Security Monitoring Exports perform the steps in this required task. This section contains the following subsections:

•Prerequisites

•Restrictions

•SUMMARY STEPS

•DETAILED STEPS

Prerequisites

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" task 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-number

LC-slot-number# show ip cache verbose flow 

For 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 

Cisco 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-number

LC-slot-number# show ip cache verbose flow

For 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. enable

2. configure terminal

3. ip flow-capture icmp

4. ip flow-capture ip-id

5. ip flow-capture mac-addresses

6. ip flow-capture packet-length

7. ip flow-capture ttl

8. ip flow-capture vlan-id

9. ip flow-export destination {{ip-address | hostname} udp-port}

10. Repeat Step 9 once to configure an additional export destination

11. interface interface-type interface-number

12. ip flow {ingress | egress}

13. exit

14. Repeat Steps 11 through 13 to enable NetFlow on other interfaces

15. end

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	(Required) Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	(Required) Enters global configuration mode.
Step 3	ip flow-capture icmp Example: Router(config)# ip flow-capture icmp	(Optional) Enables you to capture the value of the ICMP type and code fields from ICMP datagrams in a flow.
Step 4	ip flow-capture ip-id Example: Router(config)# ip flow-capture ip-id	(Optional) Enables you to capture the value of the IP-ID field from the first IP datagram in a flow.
Step 5	ip flow-capture mac-addresses Example: Router(config)# ip flow-capture mac-addresses	(Optional) Enables you to capture the values of the source and destination MAC addresses from the traffic in a flow.
Step 6	ip flow-capture packet-length Example: Router(config)# ip flow-capture packet-length	(Optional) Enables you to capture the minimum and maximum values of the packet length field from IP datagrams in a flow.
Step 7	ip flow-capture ttl Example: Router(config)# ip flow-capture ttl	(Optional) Enables you to capture the minimum and maximum values of the Time-to-Live (TTL) field from IP datagrams in a flow.
Step 8	ip flow-capture vlan-id Example: Router(config)# ip flow-capture vlan-id	(Optional) Enables you to capture the 802.1q or ISL VLAN-ID field from VLAN encapsulated frames in a flow that are received or transmitted on trunk ports.
Step 9	ip flow-export destination {{ip-address | hostname} udp-port} Example: Router(config)# ip flow-export destination 10.0.19.2 999	(Required) Specifies the IP address, or hostname of the NetFlow collector, and the UDP port the NetFlow collector is listening on.
Step 10	Repeat Step 9 to add a second NetFlow collector	(Optional) —
Step 11	interface interface-type interface-number Example: Router(config)# interface ethernet 0/0	(Required) Specifies the interface that you want to enable NetFlow on and enters interface configuration mode.
Step 12	ip flow {ingress | egress} Example: Router(config-if)# ip flow ingress or Example: Router(config-if)# ip flow egress	(Required) Enables NetFlow on the interface. •ingress—captures traffic that is being received by the interface •egress—captures traffic that is being transmitted by the interface
Step 13	exit Example: Router(config-if)# exit	(Optional) Exits interface configuration mode and returns to global configuration mode. Note You only need to use this command if you want to enable NetFlow on another interface.
Step 14	Repeat Steps 11 through 13 to enable NetFlow on other interfaces	(Optional) —
Step 15	end Example: Router(config-if)# end	(Required) Exits the current configuration mode and returns to privileged EXEC mode.

Verifying NetFlow Layer 2 and Security Monitoring Exports

To verify the configuration of NetFlow Layer 2 and Security Monitoring Exports perform the step in this optional task.

SUMMARY STEPS

1. show ip cache verbose flow

DETAILIED STEPS

---

Step 1 show ip cache verbose flow

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 flow

IP 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 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608

   .000 .000 .000 .206 .793 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes

  6 active, 4090 inactive, 17 added

  505 ager polls, 0 flow alloc failures

  Active flows timeout in 1 minutes

  Inactive flows timeout in 10 seconds

IP Sub Flow Cache, 25736 bytes

  12 active, 1012 inactive, 39 added, 17 added to flow

  0 alloc failures, 0 force free

  1 chunk, 1 chunk added

  last clearing of statistics never

Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)

--------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow

TCP-Telnet           1      0.0       362   940      2.7      60.2       0.0

TCP-FTP              1      0.0       362   840      2.7      60.2       0.0

TCP-FTPD             1      0.0       362   840      2.7      60.1       0.1

TCP-SMTP             1      0.0       361  1040      2.7      60.0       0.1

UDP-other            5      0.0         1    66      0.0       1.0      10.6

ICMP                 2      0.0      8829  1378    135.8      60.7       0.0

Total:              11      0.0      1737  1343    147.0      33.4       4.8

SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts

Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active

Et0/0.1        10.251.138.218  Et1/0.1        172.16.10.2     06 80  00      65 

0015 /0  0                     0015 /0  0     0.0.0.0               840    10.8

MAC: (VLAN id) aaaa.bbbb.cc03  (005)          aaaa.bbbb.cc06  (006)

Min plen:      840                            Max plen:       840

Min TTL:        59                            Max TTL:         59

IP id:           0

Configuration 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

•Configuring and Using NetFlow Layer 2 and Security Monitoring Exports to Analyze a Simulated ICMP Ping Attack: Example

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 Keep track of the MAC addresses and IP addresses of the devices in your network. You can use them to analyze attacks and to resolve problems.

---

---

Note This example does not include the ip flow-capture icmp command that captures the value of the ICMP type and code fields. The use of the ip flow-capture icmp command is described in "Configuring and Using NetFlow Layer 2 and Security Monitoring Exports to Analyze a Simulated ICMP Ping Attack: Example."

---

R2

!

hostname R2

!

interface Ethernet0/0

 mac-address aaaa.bbbb.cc02

 ip address 172.16.1.2 255.255.255.0

!

interface Ethernet1/0

 mac-address aaaa.bbbb.cc03

 no ip address

!

interface Ethernet1/0.1

 encapsulation dot1Q 5

 ip address 172.16.6.1 255.255.255.0

!

!

router rip

 version 2

 network 172.16.0.0

 no auto-summary

!

R3

!

hostname R3

!

ip flow-capture fragment-offset

ip flow-capture packet-length

ip flow-capture ttl

ip flow-capture vlan-id

ip flow-capture ip-id

ip flow-capture mac-addresses

ip flow-export destination 172.16.10.2 900

!

interface Ethernet0/0

 mac-address aaaa.bbbb.cc04

 no ip address

!

interface Ethernet0/0.1

 encapsulation dot1Q 5

 ip address 172.16.6.2 255.255.255.0

 ip accounting output-packets

 ip flow ingress

!

interface Ethernet1/0

 mac-address aaaa.bbbb.cc05

 no ip address

!

interface Ethernet1/0.1

 encapsulation dot1Q 6

 ip address 172.16.7.1 255.255.255.0

 ip accounting output-packets

 ip flow egress

!

router rip

 version 2

 network 172.16.0.0

 no auto-summary

!

R4

!

hostname R4

!

interface Ethernet0/0

 mac-address aaaa.bbbb.cc07

 ip address 172.16.10.1 255.255.255.0

!

interface Ethernet1/0

 mac-address aaaa.bbbb.cc06

 no ip address

!

interface Ethernet1/0.1

 encapsulation dot1Q 6

 ip address 172.16.7.2 255.255.255.0

!

router rip

 version 2

 network 172.16.0.0

 no 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 flow 

IP 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 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608

   .000 .000 .000 .995 .000 .000 .000 .000 .000 .000 .000

The 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:

•Field Descriptions in the NetFlow Cache Section of the Output (Table 6)

•Field Descriptions in the Activity by Protocol Section of the Output (Table 7)

•Field Descriptions in the NetFlow Record Section of the Output (Table 8)

•NetFlow Layer 2 and Security Monitoring Exports Fields in the NetFlow Record Section of the Output (Table 9)

IP Flow Switching Cache, 278544 bytes

  5 active, 4091 inactive, 25 added

  719 ager polls, 0 flow alloc failures

  Active flows timeout in 1 minutes

  Inactive flows timeout in 10 seconds

IP Sub Flow Cache, 25736 bytes

  10 active, 1014 inactive, 64 added, 25 added to flow

  0 alloc failures, 0 force free

  1 chunk, 1 chunk added

  last clearing of statistics never

Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)

--------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow

TCP-FTP              5      0.0       429   840      6.6      58.1       1.8

Total:               5      0.0       129   835      6.6      17.6       7.9

SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts

Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active

Et0/0.1        10.132.221.111  Et1/0.1        172.16.10.2     06 80  00     198 

0015 /0  0                     0015 /0  0     0.0.0.0               840    41.2

MAC: (VLAN id) aaaa.bbbb.cc03  (005)          aaaa.bbbb.cc06  (006)

Min plen:      840                            Max plen:       840

Min TTL:        59                            Max TTL:         59

IP id:           0 

Et0/0.1        10.251.138.218  Et1/0.1        172.16.10.2     06 80  00     198 

0015 /0  0                     0015 /0  0     0.0.0.0               840    41.2

MAC: (VLAN id) aaaa.bbbb.cc03  (005)          aaaa.bbbb.cc06  (006)

Min plen:      840                            Max plen:       840

Min TTL:        59                            Max TTL:         59

IP id:           0

Et0/0.1        10.10.12.1      Et1/0.1        172.16.10.2     06 80  00     203 

0015 /0  0                     0015 /0  0     0.0.0.0               840    42.2

MAC: (VLAN id) aaaa.bbbb.cc03  (005)          aaaa.bbbb.cc06  (006)

Min plen:      840                            Max plen:       840

Min TTL:        59                            Max TTL:         59

IP id:           0

Et0/0.1        10.231.185.254  Et1/0.1        172.16.10.2     06 80  00     203 

0015 /0  0                     0015 /0  0     0.0.0.0               840    42.2

MAC: (VLAN id) aaaa.bbbb.cc03  (005)          aaaa.bbbb.cc06  (006)

Min plen:      840                            Max plen:       840

Min TTL:        59                            Max TTL:         59

IP id:           0

Et0/0.1        10.71.200.138   Et1/0.1        172.16.10.2     06 80  00     203 

0015 /0  0                     0015 /0  0     0.0.0.0               840    42.2

MAC: (VLAN id) aaaa.bbbb.cc03  (005)          aaaa.bbbb.cc06  (006)

Min plen:      840                            Max plen:       840

Min TTL:        59                            Max TTL:         59

IP id:           0

R3#

Table 6 describes the significant fields shown in the NetFlow cache section of the output.

Table 6 Field Descriptions in the NetFlow Cache Section of the Output 

Field	Description
bytes	Number of bytes of memory used by the NetFlow cache.
active	Number of active flows in the NetFlow cache at the time this command was entered.
inactive	Number of flow buffers that are allocated in the NetFlow cache but that were not assigned to a specific flow at the time this command was entered.
added	Number of flows created since the start of the summary period.
ager polls	Number of times the NetFlow code caused entries to expire (used by Cisco for diagnostics only).
flow alloc failures	Number of times the NetFlow code tried to allocate a flow but could not.
last clearing of statistics	The period of time that has passed since the clear ip flow stats privileged EXEC command was last executed. The standard time output format of hours, minutes, and seconds (hh:mm:ss) is used for a period of time less than 24 hours. This time output changes to hours and days after the time exceeds 24 hours.

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 

Field	Description
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 Only a small subset of all protocols is displayed.
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 

Field	Description
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 •10.132.221.111 •10.251.138.218 •10.10.12.1 •10.231.185.254 •10.71.200.138
DstIf	Interface from which the packet was transmitted. Note If an asterisk (*) immediately follows the DstIf field, the flow being shown is an egress flow.
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 172.17.10.2 is the IP address of the FTP server.
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.

Table 9 NetFlow Layer 2 and Security Monitoring Exports Fields in the NetFlow Record Section of the Output 

Field	Description
MAC	These are the source and destination MAC addresses from the traffic. The source and destination MAC address are read from left to right in the output. •The traffic is being received from MAC address aaa.bbb.cc03. Note This MAC address is interface 1/0.1 on router R2. •The traffic is being transmitted to MAC address aaa.bbb.cc06. Note This MAC address is interface 1/0.1 on router R4.
VLAN id	These are the source and destination VLAN IDs. The source and destination VLAN IDs are read from left to right in the output. •The traffic is being received from VLAN 5. •The traffic is being transmitted to VLAN 6.
Min plen	This is the minimum packet length for the packets captured in the five flows. The current value is 840.
Max plen	This is the maximum packet length for the packets captured in the five flows. The current value is 840.
Min TTL	This is the minimum Time-to-Live (TTL) for the packets captured in the five flows. The current value is 59.
Max TTL	This is the maximum TTL for the packets captured in the five flows. The current value is 59.
IP id	This is the IP identifier field for the traffic in the five flows. The current value is 0.

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.

I