Fundamentals of NetFlow

NetFlow identifies packet flows for IP packets, where a flow is identified by a number of fields in the data packet. NetFlow does not involve any connection-setup protocol between routers, networking devices, or end stations. NetFlow does not change the IP packets and is transparent to the existing network infrastructure.

NetFlow operates by creating a NetFlow cache entry that contains the information for each active flow. Unless sampling has been configured, the NetFlow process inspects every packet and creates a new flow record in the cache or updates the usage parameters (such as the number of packets and bytes) of existing flow records. Each flow record is created by identifying packets with same flow characteristics and counting or tracking the packets and bytes per flow. The cache entries are exported to a collector periodically based on the flow timers. The NetFlow Collector stores the flow records that were exported by the network elements.

It is important to note that NetFlow is not a switching path, as it was originally. In fact, NetFlow is an accounting feature on top of existing switching paths, such as Cisco Express Forwarding (CEF) or Distributed CEF. NetFlow is very efficient; the typical amount of export data is about 1.5 percent of the switched traffic in the network element. On most Cisco platforms, NetFlow accounts for every packet and provides a highly condensed and detailed view of all network traffic that passed the device. Some high-end platforms, such as the Cisco 12000 router, prefer sampled NetFlow, which meters ("samples") only a subset of all packets entering the interface.

Next to the monitoring of IPv4 flows, NetFlow supports the monitoring of IPv6 environments. NetFlow captures data from ingress (incoming) and egress (outgoing) packets. NetFlow gathers data for the following ingress IP packets:

• IP-to-IP packets

• IP-to-Multiprotocol Label Switching (MPLS) packets

• Frame Relay-terminated packets

• ATM-terminated packets

NetFlow captures data for egress packets through the following features:

• Egress NetFlow Accounting gathers data for egress packets for IP traffic only

• NetFlow MPLS Egress gathers data for egress MPLS-to-IP packets

Flow Definition

A flow is defined as a set of packets having common properties: one or more packet header fields (e.g. destination IP address, transport header field), one or more characteristics of the packet itself (e.g. number of MPLS labels), one or more fields derived from packet treatment (e.g. the BGP next hop). A packet belongs to a flow record if it completely matches all defined flow properties.

NetFlow defines a flow by a combination of key-fields in the packet. In the documentation they are also called "flow keys" because they define a flow. Usually additional information is reported in a flow, such as number of packets and bytes, start and stop time, and so on. These reporting fields do not define a flow; therefore, they are called "flow values" or "non-key-fields". For consistency, we use only the terms "key-field" and "non-key-field."

Initially, NetFlow defines a flow as the combination of the following seven key-fields:

• Source IP address.

• Destination IP address.

• Source port number.

• Destination port number.

• Layer 3 protocol type.

• ToS byte.

• Logical interface (ifIndex), which is the input ifIndex in case of ingress NetFlow, or the output ifIndex with egress NetFlow. Note also that the command ip flow-egress input-interface lets you use the input ifIndex as a key-field even if NetFlow egress is configured. This means that the input ifIndex is an additional key-field.

Key-fields are a set of values that determine how a flow is identified. The seven key-fields define a unique flow that represents a unidirectional stream of packets. If a flow has a different field than another flow, it is considered a new flow. A flow contains other accounting fields (such as the AS number in the NetFlow version 5 flow format) that depend on the version record format that you configure for export. Next to the key-fields, the non-key-fields complete the flow records with extra information such as number of packets, number of bytes, and BGP AS numbers.

Specific to the router, the "router-based aggregation feature" aggregates the flow records further. It works by reducing or modifying the initial set of seven key-fields. For example, as described later, in Table 7-3, the Protocol Port-TOS aggregation type applies the source and destination application ports as key-fields. Alternatively, the destination IP address key-field can be modified to the destination prefix key-field, entailing flow records aggregation. Various aggregation types imply different key-field selection. More details are described in the section "NetFlow Version 8: Router-Based Aggregation."

Additionally, the Catalyst 6500/Cisco 7600 offers extra flexibility in the key-field configuration. The flow mask is used for data aggregation in the NetFlow cache. You can select (configure) the flow mask from a predefined set of values. For example, if you are interested in the traffic accounting per source and destination IP address, the destination-source (see Figure 7-2) is the best flow mask option, because it uses only the source and destination IP addresses as key-fields to classify the observed packets.

This "flow mask" concept is different from the router-based aggregation scheme. Router-based aggregation uses multiple caches; data aggregation is performed by processing flow entries as they expire from the main cache. Flow mask aggregates the flow information directly into the main NetFlow cache on the Catalyst 6000/Cisco 7600. Enhanced scalability is the main reason for the flow mask concept, which also decreases the amount of flow export. While the flow mask increases the NetFlow cache efficiency, it also decreases the level of information. Figure 7-2 shows the Catalyst 6500/Cisco 7600 flow masks' possible options.

Originally, the key-fields on the routers were defined by a fixed seven tuples of packet fields or were determined by the selected router-based aggregation. However, Flexible NetFlow overcomes those limitations by letting you define aggregation schemes. This extra flexibility for the metering process allows administrators to specify their own set of key-fields and non-key-fields. On one hand, this optimizes the metering process, because only the flows of interest are looked at. On the other hand, it optimizes the exporting process, because only the information of interest is exported. Each aggregation specified with Flexible NetFlow produces its own cache on the router and allows real-time diagnosis without exporting the flow records to the collector. In addition to the available key-fields defined in NetFlow versions 5, 8, and 9, Flexible NetFlow introduces a series of new information elements available as key-fields or non-key-fields. A full section is dedicated to Flexible NetFlow later in this chapter.

Cache Concept

The characteristics of active flows can be analyzed by displaying the cache, which makes NetFlow a powerful troubleshooting tool, even without exporting the flow records to a collector. For a better understanding, look at the following output from the NetFlow command show ip cache flow:

7200-netflow#show ip cache flow
1. IP packet size distribution (1693 total packets):
2. 1-32 64    96   128   160  192  224   256  288  320  352  384  416  448    480
3. .000 .190  .190 .615   .000 .000 .000  .000  .000 .000 .000  .000 .000  .000
.000
4. 512   544   576   1024   1536  2048  2560  3072  3584  4096   4608
5. .000 .000  .003  .000   .000  .000  .000  .000  .000  .000   .000
6. IP Flow Switching Cache, 4456704 bytes
7. 2 active, 65534 inactive, 7 added
8. 120 ager polls, 0 flow alloc failures
9. Active flows timeout in 30 minutes
10. Inactive flows timeout in 15 seconds
11. last clearing of statistics 00:03:18
12. Protocol  Total  Flows  Packets  Bytes  Packets  Active (Sec)  Idle (Sec)
13. -----     Flows  /Sec   /Flow    /Pkt    /Sec    /Flow         /Flow
14. TCP-Telnet  3    0.0    12       106     0.1     4.2            15.8
15. ICMP        2    0.0    500      100     5.2     2.6            15.4
16. Total:      5    0.0    207      100     5.4     3.6            15.6
17. SrcIf     SrcIPaddress  DstIf  DstIPaddress  Pr  SrcP  DstP  Pkts
18. Et0/0     10.10.10.34   Et0/0  10.10.10.255  11  0208  0208  1
19. Se3/0.16  10.1.10.1     Fa4/0  192.168.10.1  06  0017  2AFF  6


					  

The first portion of the output, in lines 1 through 5, is the packet size distribution. Several questions that operators ask are answered here, such as "What percentage of packets of each size have passed through this router?" This information can be very useful for network troubleshooting, traffic engineering, and capacity planning.

Lines 6 through 8 describe the parameters assigned to the NetFlow cache. The default maximum number of cached flows is 65,536. In this example, two cache entries are in use, and 65,534 are available for new flows. Furthermore, the "added" parameter on line 7 displays the total number of flows examined in the cache.

Lines 9 through 11 show how long a particular flow will stay in the cache. In this example, if there were no activity on the flow for 15 seconds, the entry would have been exported and purged from the cache. If an active entry is in the cache for 30 minutes, it is expired, even if traffic still exists. A new cache entry is built on the receipt of the next packet for that particular flow. Connection-oriented flows, such as Telnet and FTP, are purged as soon as the session is closed, which is identified by TCP-FIN (finish) or TCP-RST (reset) packets.

Lines 12 through 16 break down the flows by protocol. Again, this is an ideal source of information for the network administrator, because it lists traffic distribution by type of applications.

Lines 17 through 19 show the actual NetFlow cache entries. The show ip cache verbose flow command shows extra information about all the information elements contained in the flow record. Actually, every information element that will be exported to a NetFlow collector is visible in the cache. The following example offers the output of flow records displayed by the show ip cache verbose flow command.

7200-netflow#show ip cache verbose flow
12. SrcIf     SrcIPaddress  DstIf  DstIPaddress  Pr   TOS  Flgs         Pkts
13. Port      Msk           AS     Port          Msk  AS   NextHop     B/pk  Active
14. Et0/0     10.10.10.34   Et1    10.10.10.255  11   00   10           1
15. 0208      /0            0      0208          /0   0    10.48.71.1  52     0.0
16. Se3/0.16  10.1.10.1     Fa4/0  192.168.10.1  06   00   10          3
17. 0017     /24            0      2AFF          /24  0    10.1.20.1   78     1.5


					  

Compared to the output of show ip cache flow, only the flow records section is different (starting at line 12), because it now contains extra information elements for the flow. The first flow records are displayed in lines 14 and 15, and the second flow records are displayed in lines 16 and 17. The information element type is shown in lines 12 and 13.

The NetFlow cache size can vary from 1024 to 524,288 entries and is configurable for software-based platforms (such as the Cisco 7200 and 7500 routers). Each cache entry consumes a minimum of 64 bytes of memory. Some features such as BGP Next-Hop and MPLS-Aware NetFlow require extra bytes for additional information elements. The amount of memory on a Cisco 12000 line card denotes how many flows are possible in the cache. The maximum number of entries is directly related to the physical memory. For example, if an engine 3 line card has 256 MB of memory, NetFlow allocates 256 K entries (where K equals 1024). The Cisco Catalyst 6500/Cisco 7600 has different hardware cache sizes, based on the supervisor card and Policy Feature Card (PFC).

Table 7-1 displays the number of effective flow entries of the different supervisor engines on the Catalyst 6500/Cisco 7600.

The hash efficiency and the effective number of flow entries improved dramatically from the very first to the latest supervisor types. This was achieved by using more bits in the hash key size and algorithm enhancements. Combined with the table size of 256 K, the maximum effective size is 230-K entries on the latest SUP720-3BXL.

Aging Flows on a Router

On the router, the rules for expiring flow records from the cache entries include the following:

• Inactive timer. Flows that have been idle for a specified time are expired and removed from the cache for export. The inactive timer has a default setting of 15 seconds of traffic inactivity. The user can configure the inactive timer between 10 and 600 seconds.

• Active timer. Long-lived flows are expired and removed from the cache. By default, flows are not allowed to live longer than 30 minutes, even if the underlying packet conversation remains active. The user can configure the active timer between 1 and 60 minutes.

• If the cache reaches its maximum size, a number of heuristic expiry functions are applied to export flows faster to free up space for new entries. Note that in this case, the "free-up" function has a higher priority than the active and passive timers do!

• TCP connections that have reached the end of byte stream (FIN) or that have been reset (RST).

Figure 7-3 illustrates the life of a non-TCP flow. The active timer 1 (AT1) starts when the first packet arrives and a flow entry is created in the cache. In this example, we assume that packets flow constantly, with 18 packets in total. AT1 expires when it exceeds the default value of 30 minutes. At this time, the flow record, which contains the accounting details for the first 30 minutes, is exported. Because packets for this flow definition continue to arrive, the metering process creates a new flow entry in the cache that is identical to the previous one. This triggers the start of a new active timer (AT2). The inactive timer immediately starts after every packet and is cleared if new packets arrive before it expires. When no more packets for this flow arrive, the inactive timer (IT1) continues to count and expires after the default value of 15 minutes. At this point, the flow is considered inactive and is expired from the cache and exported. (Note that in Figure 7-3, IT1 actually starts 18 times and is cleared 17 times, but for simplicity this is shown only once.)

Figure 7-4 shows the flow aging mechanism for the export of flow records from the main cache.

Aging Flows on a Catalyst

Flows on Catalyst switches use different flow aging timers than the ones associated with the NetFlow cache on routers. However, the flow records aging mechanisms are almost similar to the ones on the router. On a Catalyst switch, the following three timers influence the flow aging:

• Aging timer— Flows that have been idle for a specified time are expired and removed from the cache. The inactive timer exports a packet with a default setting of 256 seconds of traffic inactivity. The user can configure the time interval for the inactive timer between 32 and 4092 seconds. The configuration statement is mls aging normal.

• Fast aging timer— Expires flows that have not received X number of packets during the last Y seconds since the flow creation. The user can configure the values X and Y. By default, this timer is disabled. The configuration command is mls aging fast, where both X and Y range from 1 to 128.

• Long aging timer— Flows are not allowed to live more than 32 minutes (1920 seconds) by default, even if the underlying packet conversation remains undisturbed. The user can configure the time interval for the active timer between 64 and 1920 seconds in increments of 64. The configuration statement is mls aging long.

The aging of a flow entry occurs when no more packets are switched for that flow (inactive timer). Fast aging reduces the number of entries in the cache for short-duration connections. For example, the fast aging timer can be configured to 128 seconds. That would ensure that short-lived flows or very slow flows would be purged more frequently. This setting can help limit the growth of the NetFlow table if the number of flows is still below the recommended upper bound and the growth trend is low. Much faster aging is required when the NetFlow table utilization gets closer to its limit. You can configure a minimum fast aging time as the most aggressive way of purging active entries to free up space for new flows. However, this drastic approach has an increasing impact on the CPU utilization as more flows are exported. A good example of fast-aging timers is to quickly clean out the many single-packet flows, such as DNS, NTP, and port scans, that consume valuable space in the flow table and offer little value in the reports.

Export Version and Related Information Elements

Expired flows are grouped into NetFlow export packets to transport them from the network element to a collector. NetFlow export packets may consist of up to 30 flow records, depending on the NetFlow protocol version.

A NetFlow export packet consists of a header and a sequence of flow records. The header contains information such as sequence number, record count, sysUpTime, and universal time (UTC). The flow record provides flow information elements such as IP addresses, ports, and routing information.

The next sections cover NetFlow versions 1, 5, 7, 8, 9 and IPFIX in detail. Versions 2, 3, and 4 were never released, and version 6 was developed for one specific customer and is no longer supported.

NetFlow Version 1: The Beginning

NetFlow version 1 is the original export protocol format and has been supported since IOS version 11.0. It is rarely used today and should not be used unless a legacy collection system requires it. Preferably, use version 5 or 9 instead.

NetFlow Version 5: The Foundation

The NetFlow protocol version 5 format adds Border Gateway Protocol (BGP) Autonomous System information and flow sequence numbers.

Figure 7-5 shows the information elements available in the NetFlow version 5 export format. The show ip route cache verbose flow command visualizes the content of all these information element values. Remember the seven key-fields: input ifIndex, type of service, protocol, IP source and destination addresses, and TCP/UDP source and destination port numbers.

Figure 7-5. NetFlow Version 5

[View full size image]

The export of flow records with NetFlow version 5 offers answers to many questions, such as "Who are the users?", "Which applications are they using?", "In what quantities?", "At what times?", and "For how long?".

NetFlow Version 7: Catalyst-Specific

The Catalyst is the only platform that supports NetFlow version 7. From an architectural perspective, the Catalyst 6500/Cisco 7600 are composed of a supervisor, called the Policy Feature Card (PFC), and an optional Multilayer Switch Feature Card (MSFC), which performs the routing function. To grasp the NetFlow version 7 concepts on the Catalyst, you must understand the Multilayer Switching (MLS) architecture in conjunction with PFC version 1. MLS is an excellent method of accelerating routing performance with dedicated Application-Specific Integrated Circuits (ASIC). MLS offloads a significant portion of the routing function (packet rewrite) to hardware; thus, it is also called switching. Hence, MLS and Layer 3 switching are equivalent terms. MLS identifies flows on the PFC after the first packet is routed by the MSFC. By creating an entry on the PFC for routed flows, MLS transfers the process of traffic forwarding for these flows to the PFC. This mechanism bypasses the MSFC for subsequent packets of the same flow, which reduces the load on the MSFC. The flow mask command specifies the properties of these entries on the PFC.

In practical terms, if five related ping packets traverse a Catalyst 6500/Cisco 7600 with a PFC1, only the first one is routed through the MSFC. The four remaining packets are switched on the PFC. However, the five ping packets are considered a single flow because the characteristics of the packets (such as source address, destination address, and source port number) do not change. At the end of the flow, the Catalyst generates two NetFlow records. Record 1 is composed of the first packet accounted on and exported by the MSFC. Record 2 is composed of the subsequent packets of the same flow accounted on and exported by the PFC. Both records are exported to a NetFlow collector, which can aggregate them into a single flow record. To enable an easy way to merge flow records that are exported by two separate components with two different source IP addresses, the PFC provides the MLS traffic statistics in a NetFlow version 7 flow record. The only difference between NetFlow version 5 and version 7 is an extra information element in version 7: the shortcut IP address, which is the IP address of the MSFC. Because the IP address of the MSFC is also included in the MSFC's flow record, a NetFlow collector can combine the two records into a single flow entry.

With the introduction of PFC version 2, Cisco Express Forwarding (CEF) was introduced. CEF works with a Forwarding Information Base (FIB), which maintains next-hop address information based on the information in the IP routing table. When the Catalyst contains an MSFC card, it runs Distributed CEF (DCEF), which maintains a FIB on the PFC and the MSFC. As a special feature of DCEF, the FIB on the PFC synchronizes routing entries with the FIB on the MSFC, and vice versa. If a packet arrives on the Catalyst and there is no entry for the destination in the FIB on the PFC, the first packet of the flow is sent to the MFSC. Next, the MFSC performs the Address Resolution Protocol (ARP) request to map the destination IP network addresses to the MAC addresses and identify the destination port. Then the MSFC FIB creates the new entry and updates the PFC FIB. Therefore, the MSFC accounts for the first packet for this specific destination, and the PFC accounts for all the subsequent packets of a flow. Although this principle is similar to MLS, the big difference in case of DCEF is that only the first packet to a new adjacency (next hop) is accounted and collected by the MSFC. Note that the first packet to use a new adjacency is incomplete (no output interface, no IGP next hop, no destination prefix) because the ARP reply has not arrived yet. After the initial packet to a new adjacency creates an entry in the PFC's FIBs, all subsequent packets toward this destination are switched by the PFC. MLS, in contrast to DCEF, sends every initial packet of a routed flow to the MSFC. As a consequence, fewer flow records are gathered by the MSFC with DCEF, compared to MLS.

Before PFC version 2, the PFC and MSFC were treated as separate devices and used different source IP addresses, which were reported as different flows at a NetFlow collector and needed to be aggregated there. Starting with PFC version 2, the flow records from the PFC and the MSFC use the same source IP address. This means that even if the collector receives flow records from two different entities, the flow records appear as being exported by the same network element. Consequently, there was no longer a need to export the shortcut IP address. Starting with PFC version 2, flow records are exported with NetFlow version 5, which is the preferred solution.

To summarize NetFlow version 7 at the Catalyst:

• NetFlow version 7 adds NetFlow support for Catalyst switches with PFC1. It adds the shortcut IP address to NetFlow version 5. The shortcut IP address is the IP address of the MSFC, bypassed by the Layer 3 switched flows.

• Catalyst 6500/Cisco 7600 series switches provide Layer 3 switching with Cisco Express Forwarding (CEF) for Supervisor Engine 2 with Policy Feature Card 2 (CEF for PFC2) and Supervisor Engine 720 with PFC3 (CEF for PFC3). When the Catalyst 6500/Cisco 7600 contains an MSFC, DCEF is automatically enabled.

• On the PFC2, NetFlow version 5 is the preferred version (as opposed to NetFlow version 7) starting with IOS version 12.1(13)E.

• The NetFlow cache on the MSFC captures statistics for flows routed in software. Typically, in the case of PFC2 and PFC3, the first packet to a new adjacency or in certain situations where packets are "punted" to the MSFC (NAT, for example).

• The NetFlow cache on the PFC captures statistics for flows routed in hardware.

NetFlow Version 8: Router-Based Aggregation

Enabling NetFlow on multiple interfaces on high-end routers (such as the Cisco 12000) usually results in a large volume of NetFlow records. Aggregation of export data is typically performed by NetFlow collection tools on management workstations. Router-based aggregation allows first-level aggregation of NetFlow records on the router. The NetFlow router-based aggregation feature enables on-board aggregation by maintaining one or more extra NetFlow caches with different combinations of fields that determine which flows from the main cache are grouped. This mechanism offers benefits such as reduced bandwidth requirements between the router and the collector, and a reduced number of collection workstations.

Router-based NetFlow aggregation introduces extra aggregation schemes with separate caches in addition to the main NetFlow cache. As flows expire in the main cache, depending on the selected aggregation scheme, relevant fields are extracted from the expired flows, and the corresponding flow entry in the aggregation cache is updated. As illustrated in Figure 7-6, the same flow aging mechanisms are applied for both the main cache and the router-based aggregation caches. The exception is terminated TCP connections, because TCP flags are not present in any of the aggregation caches.

Router-based aggregation flow records are exported with NetFlow version 8. Note that some router-based aggregations introduce new information elements and therefore require exclusive export with NetFlow version 9. The BGP Next-Hop ToS aggregation scheme is an example of this. For more details, see the next section about NetFlow version 9. For completeness and comparison purposes, Figure 7-6 shows the export of both NetFlow version 5 and 8 flow records. However, when router-based aggregation is enabled, there is no need to export from the main cache with NetFlow version 5, because the router would send redundant information. An exception to this rule is a scenario in which the content of the main cache is exported to the first collector (such as for security monitoring) while the content of the aggregation cache(s) is exported to the second collector (for example, for billing purposes). Indeed, each aggregation cache scheme allows configuration of its individual cache size, its flow aging timeout parameters, its export destination IP address, and its export destination UDP port number. The default size for the secondary NetFlow aggregation cache is 4096 entries.

Selecting a NetFlow Aggregation Scheme

The following are the five non-TOS-based aggregation schemes:

• AS aggregation scheme— Aggregates for both source and destination BGP AS number.

• Destination-prefix aggregation scheme— Aggregates on the destination prefix.

• Prefix aggregation scheme— Aggregates on source and destination prefixes, along with the source and destination BGP AS numbers.

• Protocol-port aggregation scheme— Aggregates on the protocol and port number.

• Source prefix aggregation scheme— Aggregates on the source prefix.

The NetFlow ToS-based router aggregation feature introduces seven additional aggregation schemes that include the ToS byte as a key-field:

• AS-ToS aggregation scheme— Aggregates on both source and destination AS number and ToS field.

• Destination-prefix-ToS aggregation scheme— Aggregates on the destination prefix and ToS field.

• Prefix-ToS aggregation scheme— Aggregates on source and destination prefixes, the source and destination BGP AS numbers, and the ToS.

• Protocol-port-ToS aggregation scheme— Aggregates on the protocol and ToS field plus source and destination ports.

• Source prefix-ToS aggregation scheme— Aggregates on the prefix and ToS field.

• Prefix-port-ToS aggregation scheme— Aggregates on the prefix, port number, and ToS field.

• BGP next-hop ToS aggregation scheme— Aggregates on the BGP next-hop address and ToS field.

Note that the BGP next ToS aggregation scheme is special because the BGP next hop is a new information element introduced with NetFlow version 9. Therefore, this aggregation exports its flow records exclusively with NetFlow version 9. The section "BGP Next-Hop Information Element" in this chapter covers this new aggregation scheme, along with an example.

Tables 7-2 and 7-3 outline the router-based aggregation scheme information, with the exception of the BGP Next Hop ToS aggregation scheme. Table 7-2 shows the flow information elements used in non-ToS-based aggregation schemes; Table 7-3 lists the ones used in ToS-based aggregation schemes.

Table 7-2. Non-ToS-Based Aggregation Schemes

	AS	Protocol Port	Source Prefix	Destination Prefix	Prefix
Source Prefix
Source Prefix Mask
Destination Prefix
Destination Prefix Mask
Source Application Port
Destination Application Port
Input Interface
Output Interface
IP Protocol
Source AS
Destination AS
First Timestamp
Last Timestamp
Number of Flows
Number of Packets
Number of Bytes

Table 7-3. ToS-Based Aggregation Schemes

	AS-TOS	Protocol Port-TOS	Source Prefix-TOS	Destination Prefix-TOS	Prefix-TOS	Prefix-Port
Source Prefix
Source Prefix Mask
Destination Prefix
Destination Prefix Mask
Source Application Port
Destination Application Port
Input Interface
Output Interface
IP Protocol
Source AS			Network Management: Accounting and Performance Strategies - Graphically Rich Book About the Authors About the Technical Reviewers Acknowledgments Icons Used in This Book Command Syntax Conventions Introduction Part I: Data Collection and Methodology Standards Chapter 1. Understanding the Need for Accounting and Performance Management Definitions and the Relationship Between Accounting and Performance Management The Purposes of Accounting Purposes of Performance Applying the Information to the Business Summary Chapter 2. Data Collection Methodology Data Collection Details: What to Collect Defining the User Metering Methods: How to Collect Data Records Metering Positions: Where to Collect Data Records Collection Infrastructure: How to Collect Data Records Mediation Device Functionality: How to Process Data Records Security Considerations: How to Ensure Data Authenticity and Integrity Summary Chapter 3. Accounting and Performance Standards and Definitions Understanding Standards and Standards Organizations Architectural and Framework Standards: The TMN/FCAPS Model (ITU-T) Architectural and Framework Standards: the eTOM Model (TMF) Informational IETF Standards Information Modeling Data Collection Protocols: SNMP, SMI, and MIB Data Collection Protocols: NetFlow Version 9 and IPFIX Export Protocols Data Collection Protocols: PSAMP Data Collection Protocols: AAA (RADIUS, Diameter, and TACACS+) Data Collection Protocols: IPDR Data Collection Protocols: CMISE/CMIP and GDMO Service Notions Summary Part II: Implementations on the Cisco Devices Chapter 4. SNMP and MIBs MIBs IOS Support for SNMP Versions net-snmp Utilities CLI Operations and Configuration Example for SNMPv2c CLI Operations and Configuration Examples for SNMPv3 MIB Table Retrieval Example MIB Functional Area Comparison Table General-Purpose MIBs for Accounting and Performance Advanced Device Instrumentation Technology-Specific MIBs for Accounting and Performance Creating New MIB Objects: EXPRESSION-MIB Obtaining MIBs Chapter 5. RMON RMON 1 and RMON 2 MIBs DSMON MIB SMON MIB APM MIB and ART MIB Applicability Further Reading Chapter 6. IP Accounting IP Accounting (Layer 3) IP Accounting Access Control List (ACL) IP Accounting MAC Address IP Accounting Precedence Applicability Chapter 7. NetFlow Fundamentals of NetFlow CLI Operations SNMP Operations with the NETFLOW-MIB Example: NetFlow Version 5 on a Router Example: NetFlow Configuration on the Catalyst Example: NetFlow Version 8 Example: NetFlow Version 9 New Features Supported with NetFlow Version 9 Deployment Guidelines Supported Devices and IOS Versions Chapter 8. BGP Policy Accounting Input BGP Policy Accounting Output BGP Policy Accounting Summary of All Four BGP Policy Accounting Combinations Fundamentals BGP Policy Accounting Commands SNMP Operations Examples (CLI and SNMP) Destination-Sensitive Services Applicability Chapter 9. AAA Accounting Fundamentals of AAA Accounting High-Level Comparison of RADIUS, TACACS+, and Diameter RADIUS Diameter Details Chapter 10. NBAR NBAR Functionality Supported Devices and IOS Versions NBAR Protocol Discovery (PD) MIB NBAR Configuration Commands NBAR show Commands NBAR Examples (CLI and SNMP) NBAR Applicability Chapter 11. IP SLA Measured Metrics: What to Measure Operations: How to Measure IP SLA CLI Operations SNMP Operations with the CISCO-RTTMON-MIB Application-Specific Scenario: HTTP Application-Specific Scenario: VoIP Advanced Features Implementation Considerations Chapter 12. Summary of Data Collection Methodology Applicability Part III: Assigning Technologies to Solutions Chapter 13. Monitoring Scenarios Network Blueprint for Monitoring Device and Link Performance Network Connectivity and Performance Application Monitoring Service Monitoring and Routing Optimization Chapter 14. Capacity Planning Scenarios Link Capacity Planning Network Blueprint for Capacity Planning Problem Space Capacity Planning Tools Methods for Generating the Core Traffic Matrix Additional Considerations: Peer-to-Peer Traffic Summary Chapter 15. Voice Scenarios Network Blueprint for IP Telephony Voice Performance Measurement Voice Accounting Is Your Network Ready for IP Telephony? Chapter 16. Security Scenarios Network Blueprint for Security Management Security Management Process Summary Chapter 17. Billing Scenarios Network Blueprint for Billing Billing Approaches Summary Remember the name: eTutorials.org Copyright eTutorials.org 2008-2024. All rights reserved.