|
|
The flexibility and extensibility of the NetFlow version 9 protocol offers new possibilities for the metering process. This section lists a series of features enabled on top of NetFlow version 9.
In the following example, shown in Figure 7-9, the router exports flow records for two different applications:
Flow records from the main cache for security purposes. The flow records are exported to 10.10.10.10 with partial reliability with a backup in failover mode to the host 11.11.11.11.
Flow records from the aggregation cache for billing purposes, which implies that flow records cannot be lost. They are exported with full reliability to 12.12.12.12, while the backup to 13.13.13.13 is configured in redundant mode.
The following CLI configures the scenario shown in Figure 7-9. The backup restore time for the billing scenario has been set to a minimum value. As a result, a smaller number of flow records are transferred to the primary collector in case of backup and restore. This is less critical for the monitoring case.
Router(config)# ip flow-export destination 10.10.10.10 9999 sctp Router(config-flow-export-sctp)# reliability partial buffer-limit 100 Router(config-flow-export-sctp)# backup destination 11.11.11.11 9999 Router(config-flow-export-sctp)# backup fail-over 1000 Router(config-flow-export-sctp)# backup mode fail-over Router(config)# ip flow-aggregation cache destination-prefix Router(config-flow-cache)# export destination 12.12.12.12 9999 sctp Router(config-flow-export-sctp)# backup destination 13.13.13.13 9999 Router(config-flow-export-sctp)# backup mode redundant Router(config-flow-export-sctp)# backup restore-time 1 Router(config-flow-export-sctp)# exit Router(config-flow-cache)# enabled
In the following show command, you see that the backup association to 11.11.11.11 is not connected (backup mode failover), while the backup association to 13.13.13.13 is connected because the selected mode is redundant:
Router# show ip flow export sctp verbose
IPv4 main cache exporting to 10.10.10.10, port 9999, partial
status: connected
backup mode: fail-over
104 flows exported in 84 sctp messages.
0 packets dropped due to lack of SCTP resources
fail-over time: 1000 milli-seconds
restore time: 25 seconds
backup: 11.11.11.11, port 9999
status: not connected
fail-overs: 0
0 flows exported in 0 sctp messages.
0 packets dropped due to lack of SCTP resources
destination-prefix cache exporting to 12.12.12.12, port 9999, full
status: connected
backup mode: redundant
57 flows exported in 42 sctp messages.
0 packets dropped due to lack of SCTP resources
fail-over time: 25 milli-seconds
restore time: 1 seconds
backup: 13.13.13.13, port 9999
status: connected
fail-overs: 0
0 flows exported in 0 sctp messages.
0 packets dropped due to lack of SCTP resources
Due to the increasing interface speed and the higher density of ports on network elements, sampling becomes a very relevant feature in NetFlow. Without sampling, network elements gather so many flow records that these flows consumes a significant part of the total CPU utilization. In addition, the bandwidth requirements for the export link to the collector increase, and the collector requires extensive resources to process all exported flow records.
Sampled NetFlow significantly decreases CPU utilization. On average, at a Cisco 7500, sampling 1:1000 packets reduces the CPU utilization by 82 percent, and sampling 1:100 packets reduces the CPU utilization by 75 percent. The conclusion is that sampled NetFlow is a significant factor in reducing CPU utilization.
Even with NetFlow implementations in hardware ASIC on Cisco platforms such as the Catalyst 4500, 6500, 7600, 10000, and 12000 routers, sampled NetFlow offers advantages. Exporting flow records has a major impact on the CPU utilization on hardware-based NetFlow implementations.
Chapter 2 describes the different types of sampling in detail. Random packet sampling is statistically more accurate than deterministic packet sampling because it avoids any bias due to potential traffic repetitions and patterns.
NetFlow's ability to sample packets was first implemented as a feature called Sampled NetFlow. It uses deterministic sampling, which selects every n-th packet for NetFlow processing on a per-interface basis. For example, if you set the sampling rate to 1 out of 100 packets, Sampled NetFlow samples packets 1, 101, 201, 301, and so on. The Sampled NetFlow feature does not support random sampling and thus can result in inaccurate statistics when traffic arrives with fixed patterns.
Even though the Cisco 12000 router still offers Sampled NetFlow, the majority of the Cisco platforms offer Random Sampled NetFlow. Random Sampled NetFlow selects incoming packets based on a random selection algorithm so that on average one out of n sequential packets is selected for NetFlow processing. For example, if you set the sampling rate to 1 out of 100 packets, NetFlow might sample packets 5, 120, 199, 302, and so on. The sample configuration 1:100 provides NetFlow data on 1 percent of the total traffic. The n value is a configurable parameter, ranging from 1 to 65,535.
The Modular QoS Command-Line Interface (MQC) consists of three components:
The class map defines the traffic for inspection.
The policy map defines action on the classified traffic.
The service policy enables a policy at an interface.
This section offers a typical configuration example on a router, with three configuration steps.
A NetFlow sampler map defines a set of properties (such as the sampling rate and the NetFlow sampler name) for NetFlow sampling. Each NetFlow sampler map can be applied to one or many subinterfaces, as well as physical interfaces. For example, you can create a NetFlow sampler map named mysampler1 with the following properties: random sampling mode and a sampling rate of 1 out of 100 packets. This NetFlow sampler map can be applied to any number of subinterfaces, each of which would refer to mysampler1 to perform NetFlow sampling. In this case, traffic from these multiple subinterfaces is merged into flows, which introduces even more randomness than sampling per single subinterface does.
router(config)# flow-sampler-map mysampler1 router(config-sampler)# mode random one-out-of 100
The following example shows how to apply a NetFlow sampler map called mysampler1 to Ethernet interface 1:
router(config)# interface ethernet 1/0 router(config-if)# flow-sampler mysampler1
Enabling Random Sampled NetFlow on a physical interface does not automatically enable it on all its subinterfaces. In addition, disabling Random Sampled NetFlow on a physical interface or subinterface does not enable full NetFlow. This restriction prevents the unwanted transition from sampling to full NetFlow. Instead, full NetFlow must be configured explicitly.
Router# show flow-sampler
Sampler : mysampler1, id : 1, packets matched : 10, mode : random sampling mode
sampling interval is : 100
The following example displays the NetFlow output of the show ip cache verbose flow command, in which the sampler, class-id, and general flags are set:
Router# show ip cache verbose flow
...
SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active
BGP: BGP NextHop
Et1/0 8.8.8.8 Et0/0* 9.9.9.9 01 00 10 3
0000 /8 302 0800 /8 300 3.3.3.3 100 0.1
BGP: 2.2.2.2 Sampler: 1 Class: 1 FFlags: 01
The ID of the class that matches a packet is stored in the flow. The class ID is exported with version 9. A mapping of the class ID to the class name is sent to the collector using the options templates in NetFlow data export version 9. The collector maintains a mapping table from the class ID to the class name, and the table associates a class name with a flow at the collector so that you can determine which flow is filtered by a specific class.
For information, NetFlow flags (FFlags) that might appear in the show ip cache verbose flow command output are as follows:
FFlags: 01 (#define FLOW_FLAGS_OUTPUT 0x0001)—Egress flow
FFlags: 02 (#define FLOW_FLAGS_DROP 0x0002)—Dropped flow (for example, dropped by an ACL)
FFlags: 04 (#define FLOW_FLAGS_MPLS 0x0004)—MPLS flow
FFlags: 08 (#define FLOW_FLAGS_IPV6 0x0008)—IPv6 flow
FFlags: 10 (#define FLOW_FLAGS_RSVD 0x0010)—Reserved
When the collector receives sampled flow records, a correlation between the sampled traffic and actual traffic that passed the device is required. An approximation is to multiply the sampled number of packet and bytes with the sampling rate. This implies that for each sampler ID the sampling rate is known to the collector. NetFlow version 9 exports the sampling rate in an option template field that matches the sampler ID of the exported flow records.
router(config)# ip flow-export version 9 options sampler
The previous CLI entry enables the export of an option containing random-sampler configuration, including the sampler ID, the sampling mode, and the sampling interval for each configured random sampler. In our example, the collector receives a flow record with the sampler ID equal to 1, along with an option template record containing sampler ID = 1, mode = random sampled NetFlow, and sampling rate = 100.
On the Catalyst 6500/Cisco 7600, the NetFlow cache on the Policy Feature Card (PFC) captures statistics for flows routed in hardware. These platforms do not support packet sampling, because the collection process is implemented in ASICs and does not have any impact on the CPU utilization. Although the metering process is implemented in hardware, the flow export still requires software processing, which has a CPU impact. To reduce this, the PFC supports flow-based sampling, which decreases the CPU utilization, because only a subset of flow records is exported. As opposed to packet-based sampling, flow-based sampling is a post-processing feature, which means a sampling mechanism selects a subset of the existing flow entries for export to a collector.
With a Supervisor Engine 720, sampled NetFlow always uses the full-interface flow mask. With a Supervisor Engine 2, sampled NetFlow uses the full-interface or destination-source-interface flow masks. Sampled NetFlow per LAN port is supported with the full-interface flow mask or the destination-source-interface flow mask. This is a major enhancement compared to Supervisor Engine 2 functions and the other flow masks, where sampled NetFlow can be applied only at the device level instead of the interface level.
Two different flavors of flow-based sampling exist: time-based sampling and packet-based sampling.
Time-based sampling exports a snapshot of the NetFlow cache at certain intervals. The time-based sampling rate is specified in Table 7-5, which displays the corresponding sampling time and export interval for a given sampling rate.
| Sampling Rate (R) | Sampling Interval P (ms) | Sampling Time ΔT (ms) | Idle Time I (ms) |
|---|---|---|---|
| 64 | 8192 | 128 | 8064 |
| 128 | 8192 | 64 | 8128 |
| 256 | 8192 | 32 | 8160 |
| 512 | 8192 | 16 | 8176 |
| 1024 | 8192 | 8 | 8184 |
| 2048 | 8192 | 4 | 8188 |
| 4096 | 16384 | 4 | 16380 |
| 8192 | 32768 | 4 | 32762 |
The sampling interval (P) is the time between two purging events of the NetFlow cache, where ΔT is the length of the sampling window in which a snapshot of all flows traversing the device is taken. The idle time (I) is the sampling interval minus the active sampling time (I = P – ΔT). At time 0, the table is cleared, and flow entries are added. At time 0 + ΔT, all flows are exported, the table is flushed again, and the idle time starts. At time 0 + P the cache is cleared without exporting any data, and all previous steps are repeated cyclically.
For time-based sampled NetFlow, the export interval cannot be configured; the sampling time is calculated as ΔT = P/R. Note that the sampling rate is globally defined for the entire Catalyst chassis.
For example, if you configure a rate of 64, flow-based sampled NetFlow meters traffic for the first 128 ms of a total interval of 4096 ms. If the rate is 2048, sampled NetFlow accounts traffic from the first 4 ms of a 8192-ms interval.
The following configuration enables time-based sampling on the fastethernet 5/12 interface, with a sampling rate of 1 in 64:
Catalyst(config)# mls sampling time-based 64 Catalyst(config)# interface fastethernet 5/12 Catalyst(config-if)# mls netflow sampling
Packet-based sampling allows the post-processing of flow records based on the number of packets observed in the flow. At each sampling interval (configured in milliseconds), NetFlow exports the flow records for which the number of packets is greater than the configured packet-based sampling rate. The user-configurable parameters are the packet rate and the sampling interval. If no sampling interval is specified, 8192 is used as a default.
Packet-based sampling uses the following formula to sample a flow: the number of times sampled is approximately the length divided by the rate (packets_in_flow/sampling_rate). For example, if the flow is 32768 packets long and the sampling rate is 1024, the flow is sampled approximately 32 times (32768/1024).
Catalyst(config)# mls sampling packet-based rate [interval]
rate is the packet-based sampling rate. Valid values are 64, 128, 256, 512, 1024, 2046, 4096, and 8192.
interval (optional) is the sampling interval. Valid values are from 8000 to 16000 milliseconds.
NetFlow Input Filters provide traffic metering on a specific subset of traffic by creating input filters. For example, you can select traffic from a specific group of hosts. NetFlow Input Filters is another NetFlow preprocessing feature, similar to packet-based Random Sampled NetFlow.
For the NetFlow Input Filters feature, classification of packets can be based on any of the following: IP source and destination addresses, Layer 4 protocol and port numbers, incoming interface, MAC address, IP Precedence, DSCP value, Layer 2 information (such as Frame Relay DE bits or Ethernet 802.1p bits), and Network-Based Application Recognition (NBAR). First, the packets are classified (filtered) on these criteria, and then they are grouped into NetFlow flows.
The filtering mechanism uses the MQC to classify flows. You can create multiple filters with matching samplers per subinterface. You can also configure different sampling rates by defining higher sampling rates for high-priority traffic classes and lower sampling rates for low-priority traffic. Figure 7-10 shows a typical example. You probably have a tight SLA linked with the VoIP traffic; therefore, full packet monitoring is executed on this traffic class, while a sampling rate of 1:100 checks the SLA on the VPN traffic. Finally, for monitoring purposes, sampled NetFlow classifies the best-effort traffic with a 1:1000 sampling rate.
MQC offers multiple policy actions, such as limiting bandwidth rates and queuing management. These policies are applied only if a packet matches a criterion in a class map that is applied to the subinterface. A class map contains a set of match clauses and instructions on how to evaluate the clauses and acts as a filter for the policies. The NetFlow Input Filters feature combines NetFlow accounting with the MQC infrastructure. This implies that flow accounting is done on a packet format if it satisfies the match clauses.
NetFlow Input Filters require no additional memory. When comparing native NetFlow with NetFlow Input Filters, it enables a smaller number of NetFlow cache entries, because it can significantly reduce the number of flows. Accounting of classified traffic saves router resources by reducing the number of flows being processed and exported.
NetFlow Input Filters is supported in versions 5 and 9. The following four steps describe a configuration example combined with different sampling rates for different classifications:
Step 1. | Creating a class map for a policy map: Referring to Figure 7-10, the VoIP traffic is classified with access list 101 and a precedence of 5 (DSCP value of 40), and the VPN traffic is classified with access list 102: router(config)# class-map my_high_importance_class router(config-cmap)# match access-group 101 router(config-cmap)# match dscp cs5 router(config)# class-map my_medium_importance_class router(config-cmap)# match access-group 102 |
Step 2. | Creating a sampler map for a policy map: In the following example, three sampler maps called my_high_sampling, my_medium sampling, and my_low_sampling are created for use with a policy map: router(config)# flow-sampler-map my_high_sampling router(config-sampler)# mode random one-out-of 1 router(config)# flow-sampler-map my_medium_sampling router(config-sampler)# mode random one-out-of 100 router(config)# flow-sampler-map my_low_sampling router(config-sampler)# mode random one-out-of 1000 |
Step 3. | Creating a policy containing NetFlow sampling actions: The following example shows how to create a class-based policy containing three NetFlow sampling actions. In this example, a sampling action named my_high_sampling is applied to a class named my_high_importance_class, a sampling action named my_medium_sampling is applied to a class named my_medium_importance_class, and a sampling action named my_low_sampling is applied to the default class: router(config)# policy-map mypolicymap router(config-pmap)# class my_high_importance_class router(config-pmap-c)# netflow-sampler my_high_sampling router(config-pmap)# class my_medium_importance_class router(config-pmap-c)# netflow-sampler my_medium_sampling router(config-pmap)# class class-default router(config-pmap-c)# netflow-sampler my_low_sampling |
Step 4. |
NetFlow can be used effectively in an MPLS network for VPN accounting and capacity planning. Ingress NetFlow can be used to account for traffic entering an MPLS VPN network from the customer site. The customer name can be linked to the associated VRF with the particular customer site by correlating it with the ifIndex value. MPLS-Aware NetFlow is a feature dedicated to the monitoring of MPLS flows, because it aggregates traffic per MPLS label within the MPLS core. This feature meters how much traffic is destined for a specific Provider Edge (PE) router in the network, allowing an operator to calculate a traffic matrix between PE routers in the MPLS network.
An MPLS flow contains up to three incoming MPLS labels of interest, with experimental bits (EXP) and the end-of-stack (S) bit in the same positions in the packet label stack. MPLS-Aware NetFlow captures MPLS traffic that contains Layer 3 IP and Layer 2 non-IP packets and uses the NetFlow version 9 export format.
When MPLS traffic is observed, MPLS-Aware NetFlow captures and reports up to three labels of interest and the label type and associated IP address of the top label, along with the normal NetFlow version 5 data record. Unlike NetFlow, MPLS-Aware NetFlow reports a 0 value for IP next hop, source and destination BGP Autonomous System numbers, or source and destination prefix masks for MPLS packets. A Label Switch Router (LSR) does not have routing information about the IP addresses in the MPLS packets payload. Other fields, such as source IP address, destination IP address, transport layer protocol, source application port number, destination application port number, IP type of service (ToS), TCP flags, input interface, and output interface, may be utilized as key-fields.
When you configure the MPLS-Aware NetFlow feature, you can select MPLS label positions in the incoming label stack that are of interest. You can capture up to three labels from positions 1 to 6 in the MPLS label stack. Label positions are counted from the top of the stack. For example, the position of the top label is 1, the position of the next label is 2, and so on. You enter the stack location value as an argument to the following command:
router(config)# ip flow-cache mpls label-positions [label-position-1 [label- position-2 [label-position-3]]] [no-ip-fields] [mpls-length]
The label-position-n argument represents the position of the label on the incoming label stack. For example, the ip flow-cache mpls label-positions 1 3 4 command configures MPLS-Aware NetFlow to capture and export the first (top), third, and fourth labels. mpls-length reports the length of the MPLS packets, as opposed to the included IP packet length. If the no-ip-fields option is specified, the IP-related fields are reported with null values. With the introduction of Flexible NetFlow supporting MPLS fields, a more convenient solution would be the definition of a new template without those fields containing null values.
In Figure 7-11, some VPN traffic comes from the Customer Edge router 1 (CE1), enters the MPLS core via the Provider Edge router 1 (PE1), is metered with MPLS-Aware NetFlow at Provider router 1 (P1), and exits on PE2, PE3, or PE4.
The following configuration enables MPLS-Aware NetFlow on the PE1-facing interface of P1. It uses the top MPLS label as the key-field (along with the 3 EXP bits and the bottom of the stack bit [S bit]). The bytes reported by NetFlow include the full MPLS packet lengths.
Router(config)#ip flow-cache mpls label-positions 1 no-ip-fields mpls-length
The following show command illustrates that NetFlow cache contains this flow, with a top label of 486, with the 3 EXP bits value of 4, with a bottom-of-the-stack S bit value of 0, and, most importantly, with the Forwarding Equivalent Class (FEC) value of 10.10.10.3. The FEC value points to the loopback of the exit PE router, which is the exit point of the core network.
P1# show ip flow verbose cache
...
SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active
PO2/0 0.0.0.0 PO3/0 0.0.0.0 00 00 10 1729
0000 /0 0 0000 /0 0 0.0.0.0 792 14.6
Pos:Lbl-Exp-S 1:486-4-0 (LDP/10.10.10.3)
Enabling MPLS-Aware NetFlow on all PE-facing interfaces of the P routers produces flow records that provide input to capacity planning tools to draw the core traffic matrix.
The BGP next hop is an important key-field in network-wide capacity planning where the core traffic is required, because the BGP next hop characterizes the network's exit point.
NetFlow adds the BGP next-hop information to the flow records to the main cache and—if aggregation is enabled—to the BGP Next-Hop ToS aggregation cache. The router performs a lookup on the destination IP address in the BGP table and adds the BGP next-hop information to each NetFlow flow record. This action adds an extra 16 bytes to the flow entry, resulting in a total of 80 bytes per entry.
Router(config)# ip flow-export version 9 [origin-as | peer-as] bgp-nexthop
This command enables the export of origin or peer AS information as well as BGP next-hop information from the NetFlow main cache. The origin-as option exports the flow's source and destination BGP AS, and peer-as exports the adjacent source and destination BGP AS.
Router# show ip cache verbose flow
...
SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active
BGP:BGP_NextHop
Et0/0/2 10.10.10.100 Et0/0/4 10.20.10.10 01 00 10 20
0000 /8 10 0800 /8 20 10.10.10.6 100 0.0
BGP:10.10.10.1
The following command enables the BGP Next-Hop ToS aggregation. It reports the BGP origin and destination BGP Autonomous System (AS) value, the input and output interfaces, the DSCP, and the BGP next hop. In addition, the following information elements are present in all aggregations: number of flows, number of packets, number of bytes, and the sysUpTime of the flow start and end time. Note that for ingress NetFlow, the DSCP information element value is the one contained in the observed packet, before any QoS operations are applied on the packet.
Router(config)# ip flow-aggregation cache bgp-nexthop-tos Router(config-flow-cache)# enabled Router# show ip cache flow aggregation bgp-nexthop-tos ... Src If Src AS Dst If Dst AS TOS Flows Pkts B/Pk Active BGP NextHop Et0/0/2 10 Et0/0/4 20 00 9 36 40 8.2 BGP:10.10.10.1
Enabling the BGP Next-Hop ToS feature on all the CE-facing interface of the PE routers would produce flow records that, when combined, would produce the core traffic matrix as input to any capacity planning tools. The principles are similar to MPLS-Aware NetFlow. The differences are that NetFlow is enabled at different routers, that MPLS-Aware NetFlow might produce fewer flow records due to the MPLS top-label aggregation, and that the BGP Next-Hop ToS aggregation monitors only IP traffic.
NetFlow Multicast provides usage information about network traffic for a complete multicast traffic monitoring solution, because it allows metering multicast-specific data for multicast flows, along with the traditional NetFlow data records.
NetFlow Multicast offers three configuration choices:
Multicast ingress accounting— Multicast packets are counted as unicast packets with two additional fields: the number of replicated packets and the byte count. With multicast ingress accounting, the destination interface field and the IP next-hop field are set to 0 for multicast flows.
The number of replicated packets (egress) divided by the number of observed packets (ingress) delivers the multicast replication factor. The total number of flows is limited in the case of multicast ingress accounting, because a new flow entry is generated for the senders only.
Multicast egress accounting— All outgoing multicast streams are counted as separate flows. Note that this option generates a higher number of flow entries as a separate flow for each IP Multicast receiver.
Multicast ingress and multicast egress accounting— Care should be taken not to duplicate the flow records by enabling ingress and egress accounting at the same device.
The following example shows how to configure multicast egress NetFlow accounting on the Ethernet 0/0 interface:
Router(config)# interface ethernet 0/0 Router(config-if)# ip multicast netflow egress
The following example shows how to configure multicast ingress NetFlow accounting on the ingress Ethernet 1/0 interface:
Router(config)# interface serial 2/1/1.16 Router(config-if)# ip multicast netflow ingress Router# show ip cache verbose flow ... SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts Port Msk AS Port Msk AS NextHop B/Pk Active IPM:OPkts OBytes Et1/1/1 11.0.0.1 Null 227.1.1.1 01 55 10 100 0000 /8 0 0000 /0 0 0.0.0.0 28 0.0 IPM: 200 5600 Et1/1/1 11.0.0.1 Se2/1/1.16 227.1.1.1 01 55 10 100 0000 /8 0 0000 /0 0 0.0.0.0 28 0.0
The IPM:OPkts column displays the number of IP multicast output packets, the IPM:OBytes column displays the number of IPM output bytes, and the DstIPaddress column displays the destination IP address for the IP Multicast output packets.
In this example, the first flow is monitored with Multicast NetFlow ingress. The replication factor is 2, as you can deduce from the 200 multicast output packets and the 100 observed packets. Note that the destination interface reports Null, because in this case, NetFlow does not have an information element suitable for reporting a set of multiple interfaces. The second flow in the cache reports the same multicast flow metered by Multicast NetFlow egress: the destination interface is correct, and the number of packets is 100, as observed on the outgoing interface. This flow does not report the IPM:OPkts and IPM:OBytes because unicast and multicast flows cannot be distinguished at the egress interface.
Figure 7-12 illustrates a typical multicast flow, coming from the source 10.0.0.2 and multicast to 224.10.10.100.
Figure 7-13 displays relevant IP Multicast information elements of the flow records, with the three possible configuration scenarios.
Another interesting feature of NetFlow Multicast is the accounting for multicast packets that fail the Reverse Path Forwarding (RPF) check:
Router(config)# ip multicast netflow rpf-failure
In multicast, the primary purpose of the RPF check is to prevent loops, which could lead to multicast storms. NetFlow Multicast accounts the dropped packets and supplies relevant information for multicast routing debugging.
The NetFlow Layer 2 and Security Monitoring Exports feature adds the ability for NetFlow to capture the values from several extra fields in Layer 3 IP traffic and Layer 2 LAN traffic to identify network attacks and their origin.
The following fields are reported:
Time-to-Live (TTL) field, extracted from the IP packet header. The TTL field is used to prevent the indefinite forwarding of IP datagrams. It contains a counter (1 to 255) 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.
Identification (ID) field, extracted from the IP packet header. All fragments of an IP datagram have the same value in the ID field. Subsequent IP datagrams from the same sender have different values in the ID field.
Source MAC address field from received frames.
Destination MAC address field from transmitted frames.
VLAN ID field from received frames.
VLAN ID field from transmitted frames.
NetFlow reports the minimum and maximum values of TTL and packet length in a flow; note that these two attributes are non-key-fields. Reporting only the value of a specific packet in the flow (such as the first or the last) would not offer relevant information for security analysis.
To enable NetFlow version 9 to report the described functions, the following additional configuration command is required:
Router(config)# ip flow-capture {icmp | ip-id | mac-addresses | packet-length | ttl | vlan-id}
A typical flow in the NetFlow cache looks like this:
Router# show ip cache verbose flow
...
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
The NetFlow Top Talkers feature can be useful for analyzing network traffic in any of the following ways:
Security— List the top talkers to see if traffic patterns consistent with a denial of service (DoS) attack are present in your network.
Load balancing— Identify the heavily used network elements and paths in the network, and move network traffic to less-used routes in the network.
Traffic analysis— Consult the data retrieved from the NetFlow MIB and Top Talkers feature to assist in general traffic study and planning for your network. Because the top flow records can be retrieved via SNMP, this feature offers new possibilities in network baselining.
The Top Talkers feature allows the top flows to be sorted for easier monitoring, troubleshooting, and retrieval at the CLI level. Top talkers can be sorted by the following criteria:
In addition to sorting top talkers, specific criteria provide a structured output. The match command, which acts as a filter, is used to specify the criteria, such as source IP address, destination IP address, application port, and many more.
The match command has the following syntax:
match {[byte-range [max-byte-number min-byte-number | max max-byte-number | min min-
byte-number] | class-map map-name | destination [address ip-address [mask | /nn] | as
as-number | port [max-port-number min-port-number | max max-port-number | min min-
port-number] | direction [ingress | egress] | flow-sampler flow-sampler-name | input-
interface interface-type interface-number | nexthop-address ip-address [mask | /nn] |
output-interface interface-type interface-number | packet-range [ max-packets min-
packets | max max-packets | min min-packets] | protocol [protocol-number | udp | tcp] |
source [address ip-address [mask | /nn] | as as-number | port max-port-number min-
port-number | max max-port-number | min min-port-number] | tos [tos-byte | dscp dscp |
precedence precedence]
Table 7-6 lists the different match statement options for the NetFlow Top Talkers feature.
Here is a simple example of configuration for the Top Talkers NetFlow feature:
Router(config)# ip flow-top-talkers Router(config-flow-top-talkers)# top 50 Router(config-flow-top-talkers)# sort-by bytes Router(config-flow-top-talkers)# cache-timeout 2000
This example specifies a collection of the top 50 flows, sorted by bytes. The top talker list is processed only once in a configurable interval (timeout period), because constant processing of large numbers of flow records would be too CPU-intensive. The cache-timeout specifies the length of time, in seconds, for which the list of top talkers is retained. A long timeout period limits the impact on system resources. If a request is made more than once during the timeout period, the same results are displayed, and the list of top talkers is not recalculated until the timeout period expires. A short timeout period ensures that the latest list of top talkers is retrieved; however, the list of top talkers is lost when the timeout period expires. It is advised that you configure the timeout period to be equal to or greater than the time it takes the network management system (NMS) to retrieve the top talkers list. The following example completes the preceding example by adding two match statements. Only flows that fit these criteria are taken into account for the top talkers list.
Router(config)# ip flow-top-talkers Router(config-flow-top-talkers)# top 50 Router(config-flow-top-talkers)# sort-by bytes Router(config-flow-top-talkers)# cache-timeout 2000 Router(config-flow-top-talkers)# match destination port min 80 max 80 Router(config-flow-top-talkers)# match destination address 10.10.10.0/24
The match statements are used to filter the number of entries in the cache. A range of information element values, such as application port range, is also a valid option.
The NetFlow MIB and Top Talkers feature can be configured for a router either by entering command-line interface (CLI) commands or by using the SNMP interface that is available in the CISCO-NETFLOW-MIB. As well as allowing the configuration of the NetFlow Top Talkers feature, the cnfTopFlows group in the CISCO-NETFLOW-MIB permits the retrieval of the top flow records.
Another simple but very interesting feature allows the user to sort and aggregate flows in the NetFlow cache in various ways. With the "dynamic top talkers" feature (note that the "dynamic" keyword is added compared to the "top talkers" previously described), the user can specify how to sort and aggregate the flow records. The main advantage compared to the NetFlow Top Talkers is that the user does not have to configure the search criteria before generating the top talkers list. Therefore, the show command is executed ad hoc, with specific arguments, to delve into the data of interest.
For example, consider the possible output from the show ip flow top 5 aggregate source-address command:
If no match criterion is specified, the aggregated statistics for the top five source IP addresses from the flows on a router are displayed.
If no match criterion is specified, the aggregated statistics for the top five source IP addresses that meet the match criteria that you specified are displayed. The following example looks for up to five top talkers, aggregates them on the source IP address, sorts them in descending order by the number of bytes in the flow, matches on the port range of 20 to 21 (FTP data and control ports, respectively), and displays the output in descending order:
Router# show ip flow top 5 aggregate source-address sorted-by bytes descending match destination-port min 20 max 21 There are 5 top talkers: IPV4 SRC-ADDR bytes pkts flows =============== ========== ========== ========== 10.231.185.254 920 23 2 10.10.12.1 480 12 2 10.251.138.218 400 10 2 10.132.221.111 400 10 2 10.71.200.138 280 7 1 9 of 34 flows matched.
Note
IPV4 SRC-ADDR is shown in uppercase (capital) letters because it is the field that the display is aggregated on.
The sorted-by option, which specifies which field to sort by, offers the following arguments:
- - aggregate— Sorts by the aggregated field in the display data.
- - bytes— Sorts by the number of bytes in the display data.
- - flows— Sorts by the number of flows in the display data.
- - packets— Sorts by the number of packets in the display data.
The match option, which specifies the filtering criteria, offers the possibility to select any fields from the cache. This means that the full content of Table 7-8 and some morefields, such as ICMP type, ICMP code, incoming MAC address, outgoing MAC address, TTL, and so on.
As mentioned earlier, Flexible NetFlow allows the network administrator to configure key-fields and non-key-fields for a flow record, effectively customizing the data collection for an application-specific set of requirements. The key-fields determine how traffic is attributed to a flow, and the non-key-fields provide additional information about the traffic in the flow record. A change in the value of a non-key-field does not create a new flow. Values for the majority of non-key-fields are taken only from the first packet in the flow. There are a few exceptions to this rule. For example, the minimum and maximum packet length fields are monitored and potentially updated for each packet in a flow.
The benefits of Flexible NetFlow include the following:
Flow records can be specified with a minimum set of information elements (key-fields and non-key-fields), resulting in export of flow records of a minimum size. This is a significant gain in export bandwidth. For example, there is no need to export the timestamp fields in every flow record if this information is not required for a particular application.
Flow records can be defined with a minimum set of key-fields, which results in a minimum number of flow records being generated. Compared to the historical seven key-fields, which may not always be required, this significantly reduces the number of flow records. This leads to a lower cache size and export bandwidth, as well as lower CPU consumption for flow classification and export (depending on the NetFlow implementation in hardware or software). Finally, filtering and aggregation overhead at a NetFlow collector are reduced if only the required information elements are exported. For example, it is not necessary to specify the source IP address as a key-field if the monitoring application is only interested in the flows' destination.
Because Flexible NetFlow offers new information elements for key-fields and non-key-fields (for example, Layer 2 payload size, ICMP type and code), an entirely new set of monitoring applications and particular services are now possible.
The Flexible NetFlow infrastructure offers the possibility of creating multiple caches with different flow definitions from the same monitored packets.
Flexible NetFlow is a great innovation that has the potential to change how accounting is done in networks. With the latest extensions, such as MAC address reporting and BGP traffic index, Flexible NetFlow is now ready to replace legacy accounting features such as Cisco IP accounting and BGP Policy Accounting. The permanent cache can even mimic the running counters of a MIB table with the advantage of defining the table columns with Flexible NetFlow key-fields and non-key-fields.
Figure 7-14 shows the major components of Flexible NetFlow.
Flow Monitors are the Flexible NetFlow components that are applied to interfaces for traffic monitoring. Flow Monitors consist of a Flow Cache definition, which is the data structure whose content is specified by the Flow Record definition attached to the Flow Monitor. The Flow Cache is automatically created when a Flow Monitor is applied to an interface. Flow Records are collected based on the definitions of key-fields and non-key-fields and are stored in the Flow Cache.
Based on the Flow Exporter characteristics (such as export format, export destination, and transport protocol), flow records are sent to a remote NetFlow collector. Flow Exporters are created as separate entities in the configuration and are assigned to Flow Monitors.
The term "flexible" in Flexible NetFlow is applicable to both the flow record definition and the infrastructure. Indeed, several Flow Monitors can monitor the same packets for different purposes and therefore create multiple Flow Caches. Note that it is possible with traditional NetFlow under the condition that multiple router-based aggregations are enabled, aggregating the flow records from the main cache.
The new Flexible NetFlow CLI specifies a series of predefined records to allow a phased approach to Flexible NetFlow: you can start using the new CLI while exporting the same information as in NetFlow version 5 and then tune the flow monitor with the user-defined records. Flexible NetFlow includes several predefined records. Two of them (netflow-original and netflow ipv4 original-output) emulate original (ingress) NetFlow and the egress NetFlow Accounting feature, respectively.
The Flexible NetFlow feature is available with Cisco IOS Software Releases 12.4(9)T and 12.0(33)S.
Looking at the list of new key-fields shown in Table 7-7, the number increased considerably compared to traditional NetFlow. Here are just a few of the fields that were added:
The traffic index coming from the BGP Policy Accounting field
Any individual TCP flag field
| IPv4 | Transport | Routing | Flow | Interface | ||
|---|---|---|---|---|---|---|
| IP (Source or Destination) | Payload Size | Destination Port | TCP Flag: ACK | Source AS | Sampler ID | Input |
| Prefix (Source or Destination) | Packet Section (Header) | Source Port | TCP Flag: CWR | Destination AS | Direction | Output |
| Mask (Source or Destination) | Packet Section (Payload) | ICMP Code | TCP Flag: ECE | Peer AS | ||
| Minimum-Mask (Source or Destination) | TTL | ICMP Type | TCP Flag: FIN | Traffic Index (BGP PA) | ||
| Protocol | Options Bitmap | IGMP Type | TCP Flag: PSH | Forwarding Status | ||
| Fragmentation Flags | Version | TCP ACK Number | TCP Flag: RST | IS-Multicast | ||
| Fragmentation Offset | Precedence | TCP Header Length | TCP Flag: SYN | IGP Next Hop | ||
| ID | DSCP | TCP Sequence Number | TCP Flag: URG | BGP Next Hop | ||
| Header Length | TOS | TCP Window-Size | UDP Message Length | |||
| Total Length | TCP Source Port | UDP Source Port | ||||
The list of non-key-fields also has been extended, as shown in Table 7-8. The number of bytes and packets can be selected between the counters 32-bit and 64-bit (with the long keyword). The minimum and maximum total length of the packets of the flow, and the minimum and maximum TTL, are among the non-key-fields.
| Counter | IPv4 | Timestamp |
|---|---|---|
| Bytes | Total Length Minimum | sysUpTime First Packet |
| Bytes Long | Total Length Maximum | sysUpTime First Packet |
| Bytes Square Sum | TTL Minimum | |
| Bytes Square Sum Long | TTL Maximum | |
| Packets | ||
| Packets Long |
Furthermore, any of the key-fields specified in Table 7-7 can be reported as non-key-fields. In this case, its content is the value of the first packet observed in the flow. The only exceptions are the TCP flags and the fragment offset.
The answer to the question of when to select a key-field versus a non-key-field depends on the application using the flow records. For example, should the output interface be a key-field or a non-key-field? Think about a scenario of a load-balancing network design, where you want flow records for each path. The output interface must be a key-field. Otherwise, if reported as a non-key-field, its value is the output interface of the first packet observed in the flow, which is the path the first packet took.
Flexible NetFlow records let you monitor a contiguous section of a packet of a user-configurable size. This can be exported in a flow record as a key-field or a non-key-field, along with other fields and attributes of the packet. The section may also include Layers 3 and 4 and some payload data from the packet.
The packet section fields let you monitor any packet fields that are not covered by the predefined key-fields. The packet sections feature provides more detailed monitoring, facilitates the investigation of distributed denial of service (DDoS) attacks, and lets you implement other security applications such as URL monitoring.
Flexible NetFlow has the following predefined types of packet sections of a user-configurable size:
ipv4 section header size header-size starts capturing the number of bytes specified by the header-size argument from the beginning of a packet's IPv4 header.
ipv4 section payload size payload-size starts capturing bytes immediately after the IPv4 header from each packet. The number of bytes captured is specified by the payload-size argument.
There are three types of Flow Caches: normal, immediate, and permanent.
The default Flow Cache type is normal. In this mode, the entries in the cache are aged out according to the timeout active and timeout inactive settings. When a cache entry is aged out, it is removed from the cache and exported via any exporters configured.
A Flow Cache of type immediate ages out every record as soon as it is created. As a result, every flow contains just one packet. This mode is desirable when only very small flows are expected or when a minimum amount of latency is required between seeing a packet and exporting a flow. A typical example is attack detection in security monitoring—specifically if the packet section is used as a key-field.
Note that the immediate cache type may result in a large number of export flow records, which can overload low-speed links and overwhelm a NetFlow collector. Therefore, using sampling in conjunction with the immediate cache is strongly recommended.
A Flow Cache of type permanent never ages out any flows. This behavior is useful when you expect to see a small number of flows and there is a need to keep long-term statistics on the router. For example, when monitoring IP ToS as a key-field, there are only 256 values, resulting in a maximum of 256 flow entries in the cache. Permanent caches are also useful for billing applications and for an edge-to-edge traffic matrix where a fixed set of flows are being tracked. Update messages are sent periodically to flow exporters. The export interval can be configured with the timeout update command. Note that when a permanent cache becomes full, new flows are not added and a "Packets not added" counter in the cache statistics (show flow monitor monitor-name cache) reflects the number of unaccounted packets.
Some features from the original NetFlow versions (1, 5, 7, 8) are not supported yet with Flexible NetFlow. The objective of Flexible NetFlow is to support all features over time; however, some of the unsupported features can be mimicked easily. Table 7-9 provides a feature-by-feature comparison of original NetFlow and Flexible NetFlow and describes how to emulate a feature.
| Feature | Original NetFlow | Flexible NetFlow | Comments |
|---|---|---|---|
| NetFlow Data Capture | Supported | Supported | Data capture is available with the predefined[*] and user-defined records in Flexible NetFlow. |
| NetFlow Data Export | Supported | Supported | Flow exporters export data from the Flexible NetFlow flow monitor caches to remote systems. |
| NetFlow for IPv6 | Supported in version 9 | Should be available by the time this book is published. | IP version 6 monitoring. |
| MPLS-Aware NetFlow | Supported in version 9 | Not supported | MPLS core monitoring. |
| MPLS Egress NetFlow | Supported in version 9 | Not supported | MPLS edge monitoring. |
| NetFlow BGP Next Hop | Supported in version 9 | Supported | Available in the predefined and user-defined keys in Flexible NetFlow records. |
| Random Packet Sampled NetFlow | Supported | Supported | Available with Flexible NetFlow sampling. |
| NetFlow version 9 Export Format | Supported in version 9 | Supported | Available with Flexible NetFlow exporters. |
| NetFlow subinterface | Supported | Supported | Flexible NetFlow monitors can be assigned to subinterfaces. |
| Multiple Export Destinations | Supported | Supported | Available with Flexible NetFlow exporters. |
| NetFlow ToS-Based Router Aggregation | Supported | Supported | Available in the predefined and user-defined records in Flexible NetFlow records. |
| NetFlow Minimum Prefix Mask for Router-Based Aggregation | Supported | Supported | Available in the predefined and user-defined records. |
| NetFlow Input Filters | Supported in version 9 | Not supported | MQC filters. |
| NetFlow MIB | Supported | Not supported | NetFlow statistics via MIB. |
| NetFlow MIB and Top Talkers | Supported | Not supported | Top Talkers statistics in the NetFlow MIB. |
| NetFlow Dynamic Top Talkers CLI | Supported in version 9 | Not supported | Top Talker statistics via CLI. |
| NetFlow Multicast | Supported | Not supported | Flexible NetFlow collects statistics for multicast flows. However, specific additional fields such as replication counts for bytes (OBYTES) and packets (OPACKETS) are not supported by Flexible NetFlow in Cisco IOS Software Release 12.4(9)T. |
| NetFlow Layer 2 and Security Monitoring Exports | Supported in version 9 | Not supported | Monitoring of Layer 2 details. |
| Egress NetFlow Accounting | Supported | Supported | Flexible NetFlow monitors can be used to monitor egress traffic on interfaces and subinterfaces. |
| NetFlow Reliable Export with SCTP | Supported in version 9 | Not supported |
[*] Flexible NetFlow has several predefined keys that emulate data analysis with original NetFlow.
This section describes the most important configuration commands to enable Flexible NetFlow on Cisco routers. Figure 7-15 displays, using a very simple example, the different configuration steps:
1. | Exporter configuration |
2. | Flow Record configuration |
3. | Flow Monitor configuration |
4. | Interface configuration |
Note that the CLI configuration of Flexible NetFlow for predefined records, which is considered an intermediate step toward flexible records configuration, is not described in this book.
The most important configuration commands to enable Flexible NetFlow on Cisco routers are as follows:
Router(config)# flow exporter exporter-name
Router(config-flow-exporter)# destination {{ip-address | hostname} | vrf vrf-name}
configures an export destination for a Flexible NetFlow flow exporter, optionally in a VRF.
Router(config-flow-exporter)# dscp dscp-number
configures a DSCP value for Flexible NetFlow flow exporter datagrams.
Router(config-flow-exporter)# source source-interface
configures the source IP address interface for flow exporters.
Router(config-flow-exporter)# ttl tt
configures the TTL value for a Flexible NetFlow flow exporter.
Router(config-flow-exporter)# transport udp udp-port
configures the UDP transport protocol and the UDP destination port for a Flexible NetFlow flow exporter.
Router(config)# flow record record-name
creates a Flexible NetFlow flow record.
Router(config-flow-record)# match ...
configures a key-field. The full list of fields displayed in Table 7-7 is available.
Router(config-flow-record)# collect ...
configures a non-key-field. The full list of fields displayed in Table 7-8 is available.
Router(config-flow-monitor)# flow monitor monitor-name
creates a Flexible NetFlow flow monitor.
Router(config-flow-monitor)# exporter exporter-name
configures a flow exporter for a Flexible NetFlow flow monitor.
Router(config-flow-monitor)# record record-name
configures a flow record for a Flexible NetFlow flow monitor. The option (netflow-original | netflow ipv4 record [peer]} refers to the predefined flow records.
Router(config-flow-monitor)# statistics packet {protocol | size}
collects protocol distribution statistics and/or size distribution statistics for a Flexible NetFlow flow Monitor. Note that those statistics were always available with traditional NetFlow.
Router(config-flow-monitor)# cache {entries entries | timeout {active active | inactive inactive | update update} | type {immediate | normal | permanent}}
configures a flow cache parameter for a Flexible NetFlow flow monitor. entries specifies the maximum number of entries in the flow monitor cache, ranging from 16 to 1048576. timeout active specifies the active flow timeout in seconds. timeout inactive specifies the inactive flow timeout in seconds. update specifies the update timeout for a permanent flow cache in seconds. type specifies the type of the Flow Cache, where type immediate means immediate flow removal from the flow cache, type normal means normal flow removal from the flow cache, and type permanent means disable flow removal from the flow cache.
Router(config-if)# ip flow monitor {monitor-name [sampler sampler-name] {input | output}}
enables a Flexible NetFlow flow monitor for traffic that the router is receiving (input) or forwarding (output). Sampling is optionally configured with sampler argument. (Note that the sampler should be configured before it's referenced here.)
The following examples are just two of many possible scenarios of how Flexible NetFlow can be used. The associated CLI configuration and show commands are illustrated for the first scenario only.
By targeting specific information, you can reduce the amount of collected data and the number of exported flows, allowing enhanced scalability and aggregation. If you are interested in TCP application analysis, with Flexible NetFlow you configure the tracking of the source and destination IP addresses, protocol, TCP source, and destination ports. The collected flow records provide traffic statistics for each application port number. For the same scenario in original NetFlow, you would collect more data records based on the seven tuples flow definition and aggregate them afterwards. In Flexible NetFlow, the aggregation is provided with the key-field definition, avoiding collection of unnecessary fields (four fields compared to seven).
Here's the configuration for the preceding scenario:
flow exporter my-exporter destination 10.10.10.10 source FastEthernet0/0 ttl 2 flow record my-record match ipv4 source address match ipv4 destination address match transport tcp source-port match transport tcp destination-port collect counter packets collect counter bytes flow monitor my-monitor record my-record exporter my-exporter statistics packet size interface fastethernet0/0 ip flow monitor my-monitor input
In this case, the NetFlow Collector 10.10.10.10 is situated two hops away from the router. The router's fastethernet0/0 IP address identifies the exporting router. Instead of browsing the full configuration for Flexible NetFlow-related commands, the following set of show commands has been added:
show running flow exporter show running flow monitor show running flow record
These show commands allow the configuration to be verified. For example:
Router#show flow exporter my-exporter Flow Exporter my-exporter: Description: User defined Tranport Configuration: Destination IP address: 10.10.10.10 Source IP address: 10.48.71.24 Source Interface: FastEthernet0/0 Transport Protocol: UDP Destination Port: 9995 Source Port: 50232 DSCP: 0x0 TTL: 2 Router#show flow record my-record flow record my-record: Description: User defined No. of users: 1 Total field space: 22 bytes Fields: match ipv4 source address match ipv4 destination address match transport tcp source-port match transport tcp destination-port collect counter packets collect counter bytes
The following show command, which describes the newly created NetFlow version 9 template, is of great help when troubleshooting:
Router#show flow exporter templates Flow Exporter my-exporter: Client: Flow Monitor my-monitor Exporter Format: NetFlow Version 9 Template ID : 258 Record Size : 20 Template layout _____________________________________________________________________ | Field | Type | Offset | Size | --------------------------------------------------------------------- | ipv4 source address | 8 | 0 | 4 | | ipv4 destination address | 12 | 4 | 4 | | transport tcp source-port | 182 | 8 | 2 | | transport tcp destination-port | 183 | 10 | 2 | | counter packets | 2 | 12 | 4 | | counter bytes | 1 | 16 | 4 | -------------------------------------------------------------------- Router#show flow interface fastethernet0/0 Interface FastEthernet0/0 FNF: monitor: my-monitor direction: Input traffic(ip): on
The next three commands display the content of the cache, with three different options: record, table, and csv:
Router#show flow monitor my-monitor cache format record Cache type: Normal Cache size: 4096 Current entries: 45 High Watermark: 45 Flows added: 45 Flows aged: 0 - Active timeout ( 1800 secs) 0 - Inactive timeout ( 15 secs) 0 - Event aged 0 - Watermark aged 0 - Emergency aged 0 IPV4 SOURCE ADDRESS: 10.48.71.17 IPV4 DESTINATION ADDRESS: 10.48.71.24 TCP SOURCE PORT: 0 TCP DESTINATION PORT: 0 counter packets: 6 counter bytes: 456 IPV4 SOURCE ADDRESS: 10.48.71.129 IPV4 DESTINATION ADDRESS: 10.48.71.24 TCP SOURCE PORT: 0 TCP DESTINATION PORT: 0 counter packets: 28 counter bytes: 3136 IPV4 SOURCE ADDRESS: 10.48.71.199 IPV4 DESTINATION ADDRESS: 10.48.71.24 TCP SOURCE PORT: 11011 TCP DESTINATION PORT: 18710 counter packets: 15 counter bytes: 702 ... Router#show flow monitor my-monitor cache format table Cache type: Normal Cache size: 4096 Current entries: 45 High Watermark: 45 Flows added: 45 Flows aged: 0 - Active timeout ( 1800 secs) 0 - Inactive timeout ( 15 secs) 0 - Event aged 0 - Watermark aged 0 - Emergency aged 0 IPV4 SRC ADDR IPV4 DST ADDR TCP SRC PORT TCP DST PORT pkts bytes ============= ============= ============ ============ ==== ===== 10.48.71.17 10.48.71.24 0 0 7 532 10.48.71.129 10.48.71.24 0 0 30 3360 10.48.71.199 10.48.71.24 11011 18710 15 702 ... Router#show flow monitor my-monitor cache format csv Cache type: Normal Cache size: 4096 Current entries: 45 High Watermark: 45 Flows added: 45 Flows aged: 0 - Active timeout ( 1800 secs) 0 - Inactive timeout ( 15 secs) 0 - Event aged 0 - Watermark aged 0 - Emergency aged 0 IPV4 SRC ADDR,IPV4 DST ADDR,TCP SRC PORT,TCP DST PORT,pkts,bytes 10.48.71.17,10.48.71.24,0,0,7,532 10.48.71.129,10.48.71.24,0,0,29,3248 10.48.71.199,10.48.71.24,11011,18710,15,702
Some of the flow records in the cache, and therefore in the NetFlow Collector, have a value of 0 for the source and destination TCP ports. However, the IANA port assignment lists the value 0 as reserved for both TCP and UDP. Although the configuration has defined the TCP source and destination ports as key-fields, this TCP flow key does not work as a filter. In other words, this does not imply that only TCP flows are monitored. If a UDP flow is monitored, the values of the source and destination ports are 0. So the NetFlow Collector must filter out the flow records with the source and destination value of 0. Note that flexible filtering will be implemented in the future.
Note
If a field is not available for a packet, Flexible NetFlow reports this field with a value of 0.
For troubleshooting purposes, statistics such as the current number of entries and the high watermark are available:
Router#show flow monitor my-monitor statistics
Cache type: Normal
Cache size: 4096
Current entries: 51
High Watermark: 51
Flows added: 51
Flows aged: 0
- Active timeout ( 1800 secs) 0
- Inactive timeout ( 15 secs) 0
- Event aged 0
- Watermark aged 0
- Emergency aged 0
Packet size distribution (2350 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416
.000 .127 .500 .126 .013 .016 .002 .035 .036 .004 .037 .028 .042
448 480 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .014 .000 .004 .004 .005 .000 .000 .000 .000 .000 .000 .000
In the exporter statistics output, which reports the export failures, most of the counters must be 0 (except potentially for the first export packets if ARP is required).
Router#show flow exporter my-exporter statistics
Flow Exporter my-exporter:
Packet send statistics:
Ok 0
No FIB 0
Adjacency failure 0
Enqueued to process level 2
Enqueueing failed 0
IPC failed 0
Output failed 0
Fragmentation failed 0
Encap fixup failed 0
No destination address 0
Client send statistics:
Client: Flow Monitor my-monitor
Records added 0
Packets sent 0 (0 bytes)
Packets dropped 0 (0 bytes)
No Packet available errors 0
Finally, the following command displays NetFlow version 9 export IDs for all fields that are supported by Flexible NetFlow. This facilitates the lookup within the NetFlow version 9 RFC (RFC 3954), the IPFIX Information Model RFC, and the IPFIX IANA registry:
Router#show flow exporter export-ids netflow-v9
Export IDs used by fields in NetFlow-common export format:
ip version : 60
ip tos : 194
ip dscp : 195
ip precedence : 196
ip protocol : 4
ip ttl : 192
ip ttl minimum : 52
ip ttl maximum : 53
ip length header : 189
ip length payload : 204
ip section header : 313
ip section payload : 314
routing source as : 16
routing destination as : 17
routing source as peer : 129
routing destination as peer : 128
routing source traffic-index : 92
routing destination traffic-index : 93
routing forwarding-status : 89
routing is-multicast : 206
routing next-hop address ipv4 : 15
routing next-hop address ipv4 bgp : 18
routing next-hop address ipv6 bgp : 63
ipv4 header-length : 207
ipv4 tos : 5
ipv4 total-length : 190
ipv4 total-length minimum : 25
ipv4 total-length maximum : 26
ipv4 id : 54
ipv4 fragmentation flags : 197
ipv4 fragmentation offset : 88
ipv4 source address : 8
ipv4 source prefix : 44
ipv4 source mask : 9
ipv4 destination address : 12
ipv4 destination prefix : 45
ipv4 destination mask : 13
ipv4 option map : 208
transport source-port : 7
transport destination-port : 11
transport icmp ipv4 type : 176
transport icmp ipv4 code : 177
transport igmp type : 33
transport tcp source-port : 182
transport tcp destination-port : 183
transport tcp sequence-number : 184
transport tcp acknowledgement-number : 185
transport tcp header-length : 188
transport tcp window-size : 186
transport tcp urgent-pointer : 187
transport tcp flags : 6
transport udp source-port : 180
transport udp destination-port : 181
transport udp message-length : 205
interface input snmp : 10
interface output snmp : 14
interface name : 82
interface description : 83
flow direction : 61
flow exporter : 144
flow sampler : 48
flow sampler algorithm export : 49
flow sampler interval : 50
flow sampler name : 84
flow class : 51
v9-scope system : 1
v9-scope interface : 2
v9-scope linecard : 3
v9-scope cache : 4
v9-scope template : 5
counter flows : 3
counter bytes : 1
counter bytes long : 1
counter packets : 2
counter packets long : 2
counter bytes squared long : 198
counter bytes permanent : 85
counter packets permanent : 86
counter bytes squared permanent : 199
counter bytes exported : 40
counter packets exported : 41
counter flows exported : 42
timestamp sys-uptime first : 22
timestamp sys-uptime last : 21
The second scenario deals with security. Flexible NetFlow is an excellent attack detection feature. It can track all parts of the IPv4 header and even packet sections, and can aggregate the data into flows. It is expected that security detection systems will listen to NetFlow data and, upon finding an issue in the network, create a cache that will be configured to track specific information and pinpoint details about the attack pattern or worm propagation. The capability to create caches ad hoc positions Flexible NetFlow as an enhanced security detection feature, compared to current flow technologies. It is anticipated that Flexible NetFlow will track common attacks such as port scans for worm target discovery and worm propagation. The TCP SYN flood attack is a simpler approach in which TCP flags are used to send a large number of connection requests to a server. The attacking device sends a stream of TCP SYN packets to a given destination address but never sends an ACK in response to the destination's SYN-ACK as part of the TCP three-way handshake. This results in a large number of open TCP requests, finally consuming all the victim's resources. The flow information needed for this security monitoring requires the tracking of three key-fields: destination address or subnet, TCP flags, and packet count. The network element may monitor some general NetFlow information initially, and this data may trigger the setup of an additional Flow Monitor, providing a more detailed view of this particular attack. If the security application identifies the attack's root cause, it might then configure an additional Flow Monitor to gather payload information or sections of packets to take a deeper look at a signature within the packet. Because the configuration for this example can be easily derived from the previous example (TCP application monitoring), the CLI and show commands are not displayed. An interesting example of how to use the permanent cache type of Flexible NetFlow for capacity planning is included in Chapter 14, "Capacity Planning Scenarios."
|
|