Cisco Application Visibility and Control User Guide for IOS Release 15.5(1)T and IOS XE Release 3.14S

Overview

The Easy Performance Monitor (“Easy perf-mon” or “ezPM”) feature provides an “express” method of provisioning monitors. ezPM adds functionality without affecting the traditional, full-featured perf-mon configuration model for provisioning monitors.

Profiles

ezPM does not provide the full flexibility of the traditional perf-mon configuration model. ezPM provides “profiles” that represent typical deployment scenarios. See Profiles. ezPM profiles include:

• Application Experience (legacy only)
• Application Performance
• Application Statistics

After selecting a profile and specifying a small number of parameters, ezPM provides the remaining provisioning details.

For additional information about configuring ezPM, see:
Easy Performance Monitor

Multiple Policies

It is possible to configure multiple ezPM policies on a single interface. Multiple policies enable additional flexibility in metrics collection. Policies may overlap, collecting some of the same varieties of metrics, or different metrics altogether. One use case is to configure two policies on an interface, one collecting “coarse-grain” metrics and the other collecting “fine-grain” metrics. For information, see Configuring Multiple Policies on an Interface.

Profiles

The following sections describe ezPM profiles:

• Application Experience Profile
• Application Performance Profile
• Application Statistics Profile

Application Experience Profile

Note Application Experience remains available only to support legacy configurations, but it is recommended to use the improved Application Performance profile for new configurations.

The Application Experience profile enables use of five different traffic monitors, described in Table 4-3 .

Application Experience implements the improved data exporting model introduced in Cisco IOS XE 3.10S, which is optimized for maximum performance, exporting the maximum possible amount of available information for monitored traffic. Based on the requirements of the reports that have been defined:

• For each type of traffic, the exported record contains all of the collected data required for the defined reports, with the required granularity.
• Exported records do not contain unnecessary data, such as data redundant with previously exported records or data that is not required for the defined reports.
• Exported records include server information.

Monitor Details

Table 4-3 Application Experience Traffic Monitors

For the monitor parameters shown in Table 4-4 , default values can be overridden to configure the monitors differently. For an example of how to configure parameters in the Application Experience profile, see ezPM Configuration Example 2: Application Performance Profile. (The example describes the Application Performance profile, but the configuration details are otherwise applicable to the Application Experience profile.)

Table 4-4 Application Experience Traffic Monitors: Configurable Parameters

Notes and Limitations

Cisco IOS Platforms

• Context Limitation —On Cisco IOS platforms, only one context can be attached to any single interface. The context can be from any currently available profile, such as Application Experience, Application Performance, or Application Statistics.

Cisco IOS XE Platforms

• Infrastructure —The Application Experience profile operates by provisioning performance monitor CLIs. It utilizes the performance monitor infrastructure, including performance monitor policy maps, performance monitor records, and so on.
• Context Limitation —For information about the total number of contexts that can be attached to a single interface, see Configuring Multiple Policies on an Interface.

Export Model

Figure 4-1 illustrates how the Application Experience profile exports different types of traffic statistics.

Figure 4-1 Export Model—Application Experience Profile

Application Performance Profile

Note The Application Performance profile is an improved form of the earlier Application Experience profile. Application Experience remains available to support legacy configurations, but it is recommended to use the Application Performance profile for new configurations. Table 4-6 describes the differences between the two profiles, including the improvements provided by the Application Performance profile.

The Application Performance profile enables use of five different traffic monitors, described in Table 4-6 .

Application Performance implements the improved data exporting model introduced in Cisco IOS XE 3.10S, which is optimized for maximum performance, exporting the maximum possible amount of available information for monitored traffic. Based on the requirements of the reports that have been defined:

• For each type of traffic, the exported record contains all of the collected data required for the defined reports, with the required granularity.
• Exported records do not contain unnecessary data, such as data redundant with previously exported records or data that is not required for the defined reports.
• Exported records include server information.

Comparison with Application Experience Profile

The Application Performance profile is an improved form of the earlier Application Experience profile. Table 4-6 describes the differences.

Table 4-5 Application Experience vs. Application Performance Profiles

Monitor Details

Table 4-6 Application Performance Traffic Monitors

For the monitor parameters shown in Table 4-7 , default values can be overridden to configure the monitors differently. For an example of how to configure parameters in the Application Performance profile, see ezPM Configuration Example 2: Application Performance Profile.

Table 4-7 Application Performance Traffic Monitors: Configurable Parameters

Notes and Limitations

Cisco IOS Platforms

• Context Limitation —On Cisco IOS platforms, only a one context can be attached to any single interface. The context can be from any currently available profile, such as Application Performance or Application Statistics.
• Interface Limitation —When using ART, URL, or Application-Client-Server-Stats monitors, apply the ezPM Application Performance profile only to WAN interfaces.

Cisco IOS XE Platforms

• Infrastructure —The Application Performance profile operates by provisioning performance monitor CLIs. It utilizes the performance monitor infrastructure, including performance monitor policy maps, performance monitor records, and so on.
• Context Limitation —For information about the total number of contexts that can be attached to a single interface, see Configuring Multiple Policies on an Interface.

Application Statistics Profile

Application Statistics is a simpler profile than Application Performance (or the legacy Application Experience). In contrast to the Application Performance profile, it provides only application statistics and does not report performance statistics.

The Application Statistics profile provides two different traffic monitors, application-stats and application-client-server-stats, described in Table 4-8 . The monitors operate on all IPv4 and IPv6 traffic.

Selecting a Monitor

The Application Statistics profile includes two monitors, but operates with only one or the other of the two monitors. It is not possible to run both monitors simultaneously, and doing so would not be useful because the application-client-server-stats monitor reports all of the same information as the application-stats monitor, plus additional information.

Consequently, when configuring this profile, the traffic monitor all command is not available.

Monitor Details

Table 4-8 Application Statistics Traffic Monitors

Table 4-9 indicates the parameters that can be set differently from the default values when configuring monitors in the Application Statistics profile.

Table 4-9 Application Statistics Traffic Monitors: Configurable Parameters

Notes and Limitations

Cisco IOS Platforms

• Context Limitation —On Cisco IOS platforms, only one context can be attached to any single interface. The context can be from any currently available profile, such as Application Performance or Application Statistics.
• AOR —Account on Resolution (AOR) is supported.
• Infrastructure —On Cisco IOS platforms, the Application Statistics profile operates by provisioning in the performance monitor infrastructure, similarly to the Application Performance (or Application Experience) profile.

Although the Application Statistics profile operates using a different infrastructure on Cisco IOS XE platforms, provisioning is handled in the same way and the infrastructure differences are essentially transparent to the user.

Cisco IOS XE Platforms

• AOR —Account on Resolution (AOR) is not supported.
• Infrastructure —To provide maximum performance, on Cisco IOS XE platforms the Application Statistics profile operates by provisioning native FNF monitors on the interface. The profile does not include the complexity and flexibility of the performance monitor infrastructure, such as policy maps and so on.

Although the Application Statistics profile operates using a different infrastructure on Cisco IOS platforms, provisioning is handled in the same way and the infrastructure differences are essentially transparent to the user.

• GETVPN Interoperability —Because the Application Statistics profile operates on Cisco IOS XE platforms using native FNF, and FNF monitors encrypted traffic, GETVPN interoperability is not supported on these platforms.
• Context Limitation —For information about the total number of contexts that can be attached to a single interface, see Configuring Multiple Policies on an Interface.

Configuring Easy Performance Monitor

Usage Guidelines

• Only traffic monitors available in the profile can be activated.
• Each traffic monitor is configured on a separate line. If only the traffic-monitor name is specified, the monitor is activated with the default configuration defined in the profile.

Configuration Steps

Note See Table 4-10 for information about which releases support each option.

1. enable

2. configure terminal

3. performance monitor context context-name profile profile-name

4. exporter destination { hostname | ipaddress } source interface interface-type number [ port port-value transport udp vrf vrf-name ]

5. (Optional) Repeat Step 4 to configure up to three (3) exporters.

6. traffic monitor { traffic-monitor-name [ ingress | egress ] } [[ cache-size max-entries ] | [ cache-type { normal | synchronized }] | [{ class-and | class-replace4 } class-name ] | ipv4 | ipv6 ] [ sampling-rate number ]

7. To configure additional traffic monitor parameters, repeat Step 6.

8. exit

9. interface interface-type number

10. performance monitor context context-name

11. exit

Table 4-10 Easy Performance Monitor Configuration Options

Configuration Examples

See: ezPM Configuration Examples.

Related Topics

For additional information about configuring ezPM, see:

Easy Performance Monitor

Usefulness of Multiple Policies

Configuring multiple policies enables additional flexibility in metrics collection:

• Different provisioning clients can monitor the same target.
• A single client can create multiple contexts/policies.
• Each client receives monitor statistics separately.

Note Applying multiple policies to an interface causes some degradation of performance.

Use Cases

Use Case: Coarse-grain and Fine-grain Metrics

One use case is to configure two policies on an interface, one collecting “coarse-grain” metrics and the other collecting “fine-grain” metrics. The results are reported separately and can be used for entirely separate purposes.

Use Case: Diagnosing Network Problems

To diagnose network problems, a policy designed for troubleshooting can be added to an interface with an existing policy. The troubleshooting metrics are reported separately from the metrics collected by the existing policy.

Limitations

Exceeding Supported Number of Policies

The system does not prevent attempts to configure more than the total supported number of policies (see Table 4-11 ), such as configuring five (5) policies for a single direction on an interface. No error message is displayed. However, this is not supported and leads to unpredictable results.

Error Caused By Downgrading from Cisco IOS XE 3.14

For platforms operating with Cisco IOS XE 3.14S, ISSU downgrade to an earlier release when multiple policies have been configured on a single interface is not supported. Doing so causes a router error. For more information, see Error Caused By Downgrading from Cisco IOS XE 3.14.

Coarse-grain Mode: Features and Limitations

Features

By minimizing deep packet inspection, coarse-grain mode offers a performance advantage and reduces memory resource demands. This mode can be used in scenarios where the full power of fine-grain classification is not required. (See Recommended Usage.)

• Simplified classification : Coarse-grain mode employs a simplified mode of classification, minimizing deep packet inspection. NBAR caches classification decisions made for earlier packets, then classifies later packets from the same server similarly.
• Classification by first packet : Most flows are classified based on the first packet of the flow (even in the case of a SYN packet) because no payload inspection is performed. Consequently, policies apply to the entire flow rather than depending on the payload.
• Media protocols : Media protocol classification is identical to that of fine-grain mode.
• Optimization : The performance optimization provided by coarse-grain mode applies primarily to server-based and port-based protocols, including:

– Protocols used in local deployments

– Protocols used in cloud deployments

– Encrypted traffic

Limitations

Coarse-grain mode limitations in metric reporting detail:

• Field extraction and sub-classification : Only partially supported. In coarse-grain mode, the reported results of field extraction and sub-classification are less accurate and may be sampled.
• Granularity : Caching may result in some reduction in the granularity. For example, NBAR might classify some traffic as ms-office-365 instead of as the more specific ms-office-web-apps .
• Evasive applications : Classification of evasive applications, such as BitTorrent, eMule, and Skype, may be less effective than in fine-grain mode. Consequently, blocking or throttling may not work as well for these applications.

Recommended Usage

Use fine-grain mode when per-packet reporting is required. For any use case that does not require specific per-packet operations, coarse-grain mode is recommended, as it offers a performance and memory advantages.

Comparison of Fine-grain and Coarse-grain Modes

Table 4-12 compares fine-grain and coarse-grain modes.

Table 4-12 NBAR Fine-grain and Coarse-grain Modes

Determining the Mode

The mode is determined by either of the following (#1 has higher priority):

1. CLIs to configure NBAR classification mode. These commands can override the mode selected by other means.

2. Granularity selected by an NBAR client.

Example:

In this example, configuring an ezPM policy using the Application Statistics profile invokes the coarse-grain NBAR mode.

Viewing the Configured NBAR Mode

The following CLI shows the currently configured mode (coarse-grain in the example output):

For details, see NBAR Configuration Guide .

L3/L4 Fields

The following are L3/L4 fields commonly used by the Cisco AVC solution.

Usage Guidelines

The client is determined according to the initiator of the connection.

The client and server fields are bi-directional. The source and destination fields are uni-directional.

L7 Fields

The following are L7 fields commonly used by the Cisco AVC solution.

Usage Guidelines

• The application ID is exported according to RFC-6759.
• Account-On-Resolution configures FNF to collect data in a temporary memory location until the record key fields are resolved. After resolution of the record key fields, FNF combines the temporary data collected with the standard FNF records. Use the account-on-resolution option when the field used as a key is not available at the time that FNF receives the first packet.

The following limitations apply when using Account-On-Resolution:

– Flows ended before resolution are not reported.

– On Cisco IOS XE platforms, FNF packet/octet counters, timestamp, and TCP performance metrics are collected until resolution. All other field values are taken from the packet that provides resolution or the following packets.

• For information about extracted fields, including the formats in which they are exported, see:
  Cisco Application Visibility and Control Field Definition Guide for Third-Party Customers

Interfaces and Directions

The following are interface and direction fields commonly used by the Cisco AVC solution:

Counters and Timers

The following are counter and timer fields commonly used by the Cisco AVC solution.

Note Two aliases provide backward compatibility for configurations created on earlier releases:

• connection client bytes transport long is an alias for connection client bytes long .
• connection server bytes transport long is an alias for connection server bytes long .

On Cisco IOS platforms:

On Cisco IOS XE platforms:

TCP Performance Metrics

The following are fields commonly used for TCP performance metrics by the Cisco AVC solution:

Usage Guidelines

The following limitations apply to TCP performance metrics:

• All TCP performance metrics must observe bi-directional traffic.
• The policy-map must be applied in both directions.

Figure 4-2 provides an overview of network response time metrics.

Figure 4-2 Network Response Times

Figure 4-3 provides details of network response time metrics.

Figure 4-3 Network Response Time Metrics in Detail

Media Performance Metrics

The following are fields commonly used for media performance metrics by the Cisco AVC solution:

Usage Guidelines

Some of the media performance fields require punt to the route processor (RP). For more information, see Cisco Application Visibility and Control Field Definition Guide for Third-Party Customers .

L2 Information

The following are L2 fields commonly used by the Cisco AVC solution:

WAAS Interoperability

The following are WAAS fields commonly used by the Cisco AVC solution:

Usage Guidelines

Account-On-Resolution configures FNF to collect data in a temporary memory location until the record key fields are resolved. After resolution of the record key fields, FNF combines the temporary data collected with the standard FNF records. Use this option ( account-on-resolution ) when the field used as a key is not available at the time that FNF receives the first packet.

The following limitations apply when using Account-On-Resolution:

• Flows ended before resolution are not reported.
• FNF packet/octet counters, timestamp and TCP performance metrics are collected until resolution. All other field values are taken from the packet that provides resolution or the following packets.

Classification

The following are classification fields commonly used by the Cisco AVC solution:

Usage Guidelines

Use this field to report the matched class for the performance-monitor policy-map.

NetFlow/IPFIX Option Templates

NetFlow option templates map IDs to string names and descriptions:

NetFlow/IPFIX Show commands

Use the following commands to show NetFlow/IPFIX information:

Customizing NBAR Attributes

Use the following commands to customize the NBAR attributes:

Note These commands support all attributes defined by the NBAR2 Protocol Pack, including custom-category, custom-sub-category, and custom-group available in Protocol Pack 3.1 and later.

Customizing Attribute Values

Background

Attribute maps enable users to map various attribute values to protocols, changing the built-in grouping of protocols. The “custom attributes value” feature enables users to add new values to existing attributes.

For example, when using custom protocols to define enterprise specific protocols, it can be useful to classify the custom protocols as a new group (example: my-db-protocols-group). Beginning in the current release, new values can be defined for:

• category
• sub-category
• application-group

Customized attributes can be used for QoS matching, and the customized values appear in AVC reports.

Future Protocol Pack versions may enable defining additional attributes. For information about viewing which attributes can be customized and how many new groups can be defined, see Additional Usage Guidelines.

Basic Usage

CLI

Backward Compatibility

Previous releases of AVC included the following pre-defined attribute values, which could not be user-customized:

• For the category attribute: custom-category
• For the sub-category attribute: custom-sub-category
• For the application-group attribute: custom-application-group

To provide backward compatibility with existing configurations, the current release supports configurations that were created for earlier releases and that include one or more of these attributes.

Examples—Defining Values

The following examples define custom values for the category and sub-category attributes, and provide the optional explanatory help string:

Example—Removing Custom Values

The following example removes the custom value (“XYZ-app-group”) that had been assigned for the application-group attribute:

Additional Usage Guidelines

Help

The following command provides help, indicating which attributes can have custom values.

Displaying Customizable Attributes and Custom Values

The following command indicates which attributes can be defined with custom values (depends on the Protocol Pack version installed on the device), and displays the currently defined custom values.

Customizing NBAR Protocols

Use the following commands to customize NBAR protocols and assign a protocol ID. A protocol can be matched based on HTTP URL/Host or other parameters:

Packet Capture Configuration

Use the following commands to enable packet capture:

Background—QoS

QoS configuration is based on class maps and policy maps . Class maps categorize traffic; policy maps determine how to handle the traffic. Based on the policy identified for each packet, the packet is placed into a specific QoS queue , which determines the priority and pattern of transmission. Each queue is identified by a Queue ID field.

For additional information about QoS, see: http://www.cisco.com/go/qos

Exported Metrics

AVC enables configuration of QoS Packet Drop and QoS Class Hierarchy monitors on an interface, using one or more of the following QoS metrics, which can be included in exported performance monitor records:

• Queue ID—Identifies a QoS queue.
• Queue Packet Drops—Packets dropped (on the monitored interface) per QoS queue, due to a QoS policy that limits resources available to a specific type of traffic.
• Class Hierarchy—Class hierarchy of the reported flow. The class hierarchy is determined by the QoS policy map and determines the traffic priority.

QoS Packet Drop Monitor Output in Exported Record

When a QoS Packet Drop monitor is configured, the performance monitor record includes packet drop data per QoS queue in the following format:

QoS Class Hierarchy Information Included in Exported Record

QoS class hierarchy information is exported using the following performance monitor fields:

• Hierarchy policy for each flow (defined by the policy map)
• Queue ID for each flow

This section provides an example of a QoS policy map configuration, followed by the information provided in a performance monitor record for three flows governed by this configuration.

The example includes two levels of policy map hierarchy. In the example, the service-policy P11 statement in bold type creates a hierarchy with the P11 policy map as a child of the P1 policy map.

Note QoS class hierarchy reporting supports a hierarchy of five levels.

Based on the configuration, the following applies to a packet with, for example, a DSCP value of “ef” in the IP header:

1. The C1 class definition includes the packet by the match any statement.

2. The C11 class definition includes the packet by the match ip dscp ef statement.

3. Because the packet is included in class C1, policy map P1 defines the policy for the packet with the shaping average statement.

4. Policy map P1 invokes policy map P11 for class C1 with the service-policy P11 statement.

5. Because the packet is included in class C11, policy map P11 assigns the packet to a queue which has been allocated 10% of remaining bandwidth.

Table 4-13 shows an example of the information provided in an FNF record for three flows governed by this configuration.

Table 4-13 QoS Class Hierarchy Information in the Flow Record

In Table 4-13 , policy and class information is shown using the true policy and class names, such as P1 and C1. However, the record exports policy and class names using numerical identifiers in place of policy and class names. The monitor periodically outputs a “policy option template” and a “class option template” indicating the policy names and class names that correspond to the numbers used in the exported records. These option templates are defined in the exporter configuration, using statements such as the following, which create the option templates and indicate the time interval at which the monitor outputs the option template information:

Configuration

Configuring a QoS Packet Drop Monitor

A QoS Packet Drop monitor can only export the Queue ID and Queue Packet Drop fields. It cannot be combined with other monitors to export additional fields. At the given reporting interval, the monitor reports only on queues that have dropped packets (does not report value of 0).

Step 1: Create the QoS Packet Drop Monitor

Use the following performance monitor configuration to create a QoS Packet Drop monitor. The process specifies a flow record of type performance monitor named “qos-record” and attaches the record to a monitor of type performance monitor named “qos-monitor.” In the steps that follow, the qos-monitor is attached to the desired policy map.

Step 2: Configure the QoS Policy

The following example shows configuration of a QoS policy map. It includes a hierarchy of three policies: avc, avc-parent, and avc-gparent. Note that avc-gparent includes avc-parent, and avc-parent includes avc.

Step 3: Create the QoS Class Hierarchy Record

To correlate the queue drops collected from the QoS Drops monitor, create a flow record that includes the class hierarchy and Queue id and flow key fields. The data exported by this monitor indicates which flows are assigned to which QoS Queue Id.

The following example configuration creates a QoS class record. The process specifies a record of type performance monitor named “qos-class-record.”

Step 4: Create the QoS Class Hierarchy Monitor

Use the following performance monitor configuration to create a QoS Class Hierarchy monitor. The process specifies a monitor of type “class-hier-monitor.” In the steps that follow, the monitor is attached to the desired interface.

Step 5: Create the Performance Monitor Policy

Use the following configuration to create a policy-map that will collect both monitors.

Step 6: Attach the Performance Monitor and QoS Policy to an Interface

Use the following to attach the monitor to the desired interface. For <interface> , specify the interface type—for example: GigabitEthernet0/2/1

Specify the IP address of the interface in IPv4 or IPv6 format.

Verifying the QoS Packet Drop Monitor Configuration

This section provides commands that are useful for verifying or troubleshooting a QoS Packet Drop Monitor configuration.

Verifying that the Monitor is Allocated

Use the following command to verify that the QoS monitor exists:

Use the following commands to verify additional monitor details:

Verifying QoS Queue IDs, Queue Drops, and Class Hierarchies

The following show command displays the record collected:

Background—FNF and QoS

FNF Monitors

Flexible NetFlow (FNF) enables monitoring traffic on router interfaces. FNF monitors are configured for a specific interface to monitor the traffic on that interface. At defined intervals, the monitor sends collected traffic data to a “collector,” which can be a component within the router or an external component.

Beginning with Cisco AVC for IOS XE release 3.9, FNF records include new fields for QoS metrics.

QoS

QoS configuration is based on class maps and policy maps . Class maps categorize traffic; policy maps determine how to handle the traffic. Based on the policy identified for each packet, the packet is placed into a specific QoS queue , which determines the priority and pattern of transmission. Each queue is identified by a Queue ID field.

For additional information about QoS, see: http://www.cisco.com/go/qos

Exported Metrics

AVC enables configuration of QoS Packet Drop and QoS Class Hierarchy monitors on an interface, using one or more of the following QoS metrics, which can be included in exported FNF records:

• Queue ID—Identifies a QoS queue.
• Queue Packet Drops—Packets dropped (on the monitored interface) per QoS queue, due to a QoS policy that limits resources available to a specific type of traffic.
• Class Hierarchy—Class hierarchy of the reported flow. The class hierarchy is determined by the QoS policy map and determines the traffic priority.

QoS Packet Drop Monitor Output in Exported Record

When a QoS Packet Drop monitor is configured, the FNF record includes packet drop data per QoS queue in the following format:

QoS Class Hierarchy Information Included in Exported Record

QoS class hierarchy information is exported using the following FNF fields:

• Hierarchy policy for each flow (defined by the policy map)
• Queue ID for each flow

This section provides an example of a QoS policy map configuration, followed by the information provided in an FNF record for three flows governed by this configuration.

The example includes two levels of policy map hierarchy. In the example, the service-policy P11 statement in bold type creates a hierarchy with the P11 policy map as a child of the P1 policy map.

Note QoS class hierarchy reporting supports a hierarchy of five levels.

Based on the configuration, the following applies to a packet with, for example, a DSCP value of “ef” in the IP header:

1. The C1 class definition includes the packet by the match any statement.

2. The C11 class definition includes the packet by the match ip dscp ef statement.

3. Because the packet is included in class C1, policy map P1 defines the policy for the packet with the shaping average statement.

4. Policy map P1 invokes policy map P11 for class C1 with the service-policy P11 statement.

5. Because the packet is included in class C11, policy map P11 assigns the packet to a queue which has been allocated 10% of remaining bandwidth.

Table 4-14 shows an example of the information provided in an FNF record for three flows governed by this configuration.

Table 4-14 QoS Class Hierarchy Information in the FNF record

In Table 4-14 , policy and class information is shown using the true policy and class names, such as P1 and C1. However, the FNF record exports policy and class names using numerical identifiers in place of policy and class names. The monitor periodically outputs a “policy option template” and a “class option template” indicating the policy names and class names that correspond to the numbers used in the exported FNF records. These option templates are defined in the exporter configuration, using statements such as the following, which create the option templates and indicate the time interval at which the monitor outputs the option template information:

Configuration

Enabling QoS Metric Collection

Enabling

To enable the QoS metrics collection feature for the platform, enter global configuration mode using configure terminal , then use the following QoS configuration command. The command causes QoS to begin collecting QoS metrics for FNF.

Note Enabling QoS metrics collection requires resetting all performance monitors on the device.

Verifying

To verify that QoS metrics collection is enabled, use the following command:

The following is an example of the output of the command:

Configuring a QoS Packet Drop Monitor

A QoS Packet Drop monitor can only export the Queue ID and Queue Packet Drop fields. It cannot be combined with other monitors to export additional fields. At the given reporting interval, the monitor reports only on queues that have dropped packets (does not report value of 0).

Step 1: Create the QoS Packet Drop FNF Monitor

Use the following FNF configuration to create a QoS Packet Drop monitor. The process specifies a flow record of type “qos-record” and attaches the record to a monitor of type “qos-monitor.” In the steps that follow, the qos-monitor is attached to the desired interface.

Note Ensure that QoS metrics collection is enabled. See Enabling QoS Metric Collection.

Step 2: Configure the QoS Policy

The following example shows configuration of a QoS policy map. It includes a hierarchy of three policies: avc, avc-parent, and avc-gparent. Note that avc-gparent includes avc-parent, and avc-parent includes avc.

Step 3: Attach the FNF Monitor and QoS Policy to an Interface

Use the following to attach the monitor to the desired interface. For <interface> , specify the interface type—for example: GigabitEthernet0/2/1

Specify the IP address of the interface in IPv4 or IPv6 format.

Verifying the QoS Packet Drop Monitor Configuration

This section provides commands that are useful for verifying or troubleshooting a QoS Packet Drop Monitor configuration.

Verifying that the Monitor is Allocated

Use the following command to verify that the QoS monitor exists:

Use the following commands to verify additional monitor details:

Verifying QoS queues and Class-Hierarchies

The following show commands display the statistics that QoS has collected. “gigX/X/X” refers to the interface for which the monitor has been configured.

Verifying FNF-QOS FIA Activation

Use the following show command to verify that the FNF-QoS FIA (feature activation array) is enabled on the interface (GigabitEthernet0/2/1 in this example):

Verifying the FNF Monitor and Record

Use the following debug commands to verify that the FNF monitor and record have been created:

Configuring a QoS Class Hierarchy Monitor

In contrast to the QoS Packet Drop monitor, a QoS Class Hierarchy monitor can be combined with another monitor to export additional metrics.

Step 1: Create the QoS Class Record

The following example configuration creates a QoS class record. The process specifies a record of type “qos-class-record.” The example specifies “ipv4 source” and “ipv4 destination” addresses, but you can configure the record to match according to other criteria.

Note Ensure that QoS metrics collection is enabled. See Enabling QoS Metric Collection.

Step 2: Create the QoS Class Hierarchy Monitor

Use the following FNF configuration to create a QoS Class Hierarchy monitor. The process specifies a monitor of type “class-hier-monitor.” In the steps that follow, the monitor is attached to the desired interface.

Step 3: Attach the QoS Class Hierarchy Monitor to an Interface

Use the following to attach the monitor to the desired interface. For <interface> , specify the interface type—for example: GigabitEthernet0/2/1

Specify the IP address of the interface in IPv4 or IPv6 format.

Note Attaching the service-policy to the interface, as indicated by the “service-policy” statement below, is a required step.

Verifying the QoS Class Hierarchy Monitor Configuration

This section provides commands that are useful for verifying or troubleshooting a QoS Class Hierarchy Monitor configuration.

Verifying that the Monitor is Allocated

Use the following command to verify that the QoS monitor exists:

Use the following commands to verify additional details:

Verifying FNF-QOS FIA Activation

In the following feature invocation array (FIA) verification example, the interface is GigabitEthernet0/2/1.

Verifying the FNF Monitor and Record

Use the following debug commands to verify that the FNF monitor and record have been created:

Introduction

Flexible NetFlow (FNF) monitors typically report traffic metrics per flow. (A flow is defined as a connection between a specific source address/port and destination address/port.) A single flow can include multiple HTTP transactions. Enabling the Multi Transaction feature for a monitor enables reporting metrics for each transaction individually.

You can configure the FNF record to identify the flow or the flow+transaction, using one of the following two metrics:

• connection id—A 4-byte metric identifying the flow.
• transaction-id—An 8-byte metric composed of two parts:

– MSB—Identifies the flow and is equivalent to the connection id metric.

– LSB—Identifies the transaction. The value is a sequential index of the transaction, beginning with 0.

Configuration

The following subsections describe the Multi-transaction feature:

• Requirements
• Configuring Exporter, Record, and Monitor in Performance Monitor Mode
• Verifying and Troubleshooting the Configuration

Requirements

The following requirements apply when using the Multi-transaction feature:

• The record configuration must use match , not collect .
• Specify only “connection id” or “transaction-id,” but not both.
• Include “application name” in the record.
• Include “cache timeout event transaction-end” which specifies that the record is transmitted immediately and not stored in the monitor cache.

Configuring Exporter, Record, and Monitor in Performance Monitor Mode

Flexible Netflow (FNF) performance monitor (perf-monitor) mode enables configuring monitors with advanced filtering options that filter data before reporting it. Options for configuring filtering include IP access list, policy-map, and so on.

The following perf-monitor example configures a monitor and specifies the transaction-id metric for the FNF record, as shown in bold . Alternatively, you can specify the connection id metric.

Note See Configuring Exporter, Record, and Monitor in Performance Monitor Mode for additional configuration information.

Verifying and Troubleshooting the Configuration

This section describes commands useful for verification and troubleshooting the FNF configuration. There are subsections for:

• Native or Performance Monitor Mode
• Native FNF Mode
• Performance Monitor Mode

Note For information about the show commands in the sections below, see the FNF command reference guide:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fnetflow/command/fnf-cr-book.html

Native or Performance Monitor Mode

Verifying Multi-transaction Status

Display the Multi-transaction status:

If Multi-transaction is enabled, the value is: is_multi_trs_enable==1

Native FNF Mode

Validating the Configuration

Use the following show commands to validate the configuration.

Viewing Collected FNF Data and Statistics

Use the following show commands to view the collected FNF data and statistics.

Performance Monitor Mode

Validating the Configuration

Use the following show commands to validate the configuration.

Viewing Collected FNF Data and Statistics

Use the following show commands to view the FNF collected data and statistics.

Performance Impact

Enabling NBAR application classification and reporting of tunneled IPv6 traffic involves a performance impact, depending on the amount of tunneled traffic. Handling more tunneled packets causes a greater performance penalty.

Limitations

Reported Tuple

When using the ezPM Application Experience profile and IPv6-over-IPv4 tunneling:

• Teredo protocol: Reports the tuple correctly
• Non-Teredo protocol: Reports the external IPv4 tunnel header

The issue is not relevant for the ezPM Application Statistics profile, which does not report the tuple.

Performance Monitor Configuration Examples

This section describes attaching policies to an interface using the full-featured Performance Monitor configuration method. Alternatively, use the ezPM “express” method (ezPM Configuration Examples).

Performance Monitor Configuration Example 1: Multiple Policies on a Single Interface

The following configuration defines two policies, VM_POLICY and VM_POLICY_RTP_ONLY (shown in bold), then attaches them both to the Ethernet0/0 interface.

Note For details about support for multiple policies on an interface, including limitations, see Configuring Multiple Policies on an Interface.

ezPM Configuration Examples

This section describes attaching ezPM contexts to an interface using the Easy Performance Monitor (ezPM) express configuration method. Alternatively, use the full-featured Performance Monitor method (Performance Monitor Configuration Examples).

ezPM Configuration Example 1

The following ezPM configuration example activates all traffic monitors in the profile and attaches the policy-maps, both ingress and egress, to the GigabitEthernet0/0/1 interface:

ezPM Configuration Example 2: Application Performance Profile

The following ezPM “Application Performance” profile configuration example activates three traffic monitors, and specifies monitoring only IPv4 traffic. The context is then attached to two interfaces.

Note Beginning with Cisco IOS XE 3.14, it is possible to configure multiple contexts on the same interface. See Configuring Multiple Policies on an Interface.

ezPM Configuration Example 3: Application Statistics Profile

The following ezPM “Application Statistics” profile configuration example uses the “app-usage” context and activates one traffic monitor: application-stats.

The application-stats monitor provides per interface/application/direction/protocol and IP version traffic (bytes/packets) and flow (new flows/concurrent flows) statistics.

ezPM Configuration Example 4: Two Contexts Configured on a Single Interface

The following configuration attaches two contexts, my-visibility and my-visibility-troubleshooting , to the GigabitEthernet0/0/0 interface using the "express" ezPM configuration method.

The predefined traffic monitors used for each context reflect the different roles of the two contexts.

• The my-visibility context:

– application response-time

– conversation-traffic-statistics

– url

– media

• The my-visibility-troubleshooting context:

– troubleshooting

ezPM Configuration Example 5: Fine-grain and Coarse-grain Contexts Configured on a Single Interface

The following ezPM configuration example combines two contexts on the GigabitEthernet0/0/1 interface:

• One context applies the “Application Performance” profile, referred to as fg (fine grain). In the example, this context configures detailed reporting for critical applications.
• One context applies the “Application Statistics” profile, referred to as cg (coarse grain). This context configures more general reporting of application metrics for all traffic.

Notes

• Defining multiple contexts to combine fine-grain and coarse-grain monitoring is currently available on Cisco IOS XE platforms only.
• It is possible to combine one fine-grain and one coarse-grain context on a single interface, but not two fine-grain contexts.

QoS Configuration Examples

QoS Example 1: Control and Throttle Traffic

The following QoS configuration example illustrates how to control and throttle the peer-to-peer (P2P) traffic in the network to 1 megabit per second:

QoS Example 2: Assigning Priority and Allocating Bandwidth

The following QoS configuration example illustrates how to allocate available bandwidth on the eth0/0 interface to different types of traffic. The allocations are as follows:

• Business-critical Citrix application traffic for “access-group 101” users receives highest priority, with 50% of available bandwidth committed and traffic assigned to a priority queue. The police statement limits the bandwidth of business-critical traffic to 50% in the example.
• Web browsing receives a committed 30% of the remaining bandwidth after the business-critical traffic. This is a commitment of 15% of the total bandwidth available on the interface.
• Internal browsing, as defined by a specific domain (myserver.com in the example), receives a committed 60% of the browsing bandwidth.
• All remaining traffic uses the remaining 35% of the total bandwidth.

The policy statements commit minimum bandwidth in the percentages described for situations of congestion. When bandwidth is available, traffic can receive more than the “committed” amount. For example, if there is no business-critical traffic at a given time, more bandwidth is available to browsing and other traffic.

Figure 4-4 illustrates the priority and bandwidth allocation for each class. “Remaining traffic” refers to all traffic not specifically defined by the class mapping.

Figure 4-4 Bandwidth Allocation

In class-map definition statements:

• match-all restricts the definition to traffic meeting all of the “match” conditions that follow. For example, the “business-critical” class only includes Citrix protocol traffic from IP addresses in “access-group 101.”
• match-any includes traffic meeting one or more of the “match” conditions that follow.

Conversation Based Records—Omitting the Source Port

The monitor configured in the following examples sends traffic reports based on conversation aggregation. For performance and scale reasons, it is preferable to send TCP performance metrics only for traffic that requires TCP performance measurements. It is recommended to configure two similar monitors:

• One monitor includes the required TCP performance metrics. In place of the line shown in bold in the example below (collect <any TCP performance metric>), include a line for each TCP metric for the monitor to collect.
• One monitor does not include TCP performance metrics.

The configuration is for IPv4 traffic. Similar monitors should be configured for IPv6.

Example 1: For Cisco IOS Platforms

Example 2: For Cisco IOS XE Platforms

HTTP URL

The monitor configured in the following example sends the HTTP host and URL. If the URL is not required, the host can be sent as part of the conversation record (see Conversation Based Records—Omitting the Source Port).

HTTP URI

The uri statistics command enables exporting the first level of a parsed URI address. The command exports the value in the URI statistics field, which contains the depth 1 URI value, followed by a URI hit count value.

Note Cisco IOS XE Platforms: The URI hit count value is always 1 because the URI statistics field can only be configured per connection or transaction.

If no backslash exists at all after the URL, a zero length field is exported.

If the depth 1 value of the parsed URI exceeds a maximum number of characters, the value is truncated to the maximum length.

Note Cisco IOS XE Platforms: The uri statistics command must be configured with either the connection id or transaction-id commands.

Configuration Example

Example of Exported Value—Typical Address

Address: http://usr:pwd@www.test.com:81/dir/dir.2/index.htm?q1=0&&test1&test2=value#top

The uri statistics command exports: /dir:1

• /dir is the URI depth 1 level value.
• The “ : ” indicates a null character, followed by a URI hit count value of 1 .

Example of Exported Value—No Backslash after URL

Address: http://usr:pwd@www.test.com

The uri statistics command exports a zero length field.

Application Traffic Statistics

The monitor configured in the following example collects application traffic statistics:

Media RTP Report

The monitor configured in the following example reports on media traffic: