The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter addresses Cisco AVC configuration and includes the following topics:
Table 4-1 describes select configuration features added in recent releases, and limitations. It does not include all configuration features or limitations.
Table 4-1 Configuration Features and Enhancements
|
|
|
|
---|---|---|---|
Easy Performance Monitor “express” method of provisioning monitors |
For information, see |
||
For limitations, see: |
|||
For limitations, see: |
|||
For information, see |
|||
For information, see For limitations, see |
|||
For information, see |
|||
For information, see For limitations, see: |
|||
For information, see |
|||
Option to specify the cache timeout (exporting interval), for exporting cached NetFlow records. |
For information, see the interval-timeout parameter at |
Cisco AVC provides two methods for configuring monitors:
See Table 4-2 for details.
Table 4-2 Comparison: Performance Monitor and ezPM
|
|
|
---|---|---|
Full-featured, offering complete control of policy and class maps |
||
3. Attach one or more policies to an interface. (For limitations, see Configuring Multiple Policies on an Interface.) |
1. Select a preconfigured ezPM profile. 3. Attach one or more ezPM “contexts” to an interface. (For limitations, see Configuring Multiple Policies on an Interface.) |
|
Application Visibility and Control Configuration Guide, Cisco IOS Release 15M&T Application Visibility and Control Configuration Guide, Cisco IOS XE Release 3S |
||
|
|
---|---|
|
|
|
|
In release IOS 15.5(2)T added:
|
|
Note Before downgrading to an earlier Cisco IOS XE release, review ISSU Limitations. Configurations that employ features introduced in a later Cisco IOS XE release are not compatible with earlier releases.
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.
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:
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
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.
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:
Table 4-3 Application Experience Traffic Monitors
|
|
|
---|---|---|
HTTP applications1 |
||
1.The ezPM URL monitor is configured by default with a pre-defined class that contains a subset of HTTP-based protocols. To modify the list of monitored HTTP protocols, use the class-replace command (see Configuring Easy Performance Monitor) or configure the monitor manually. In the Application Performance profile, the URL monitor automatically supports all HTTP-based protocols supported by the protocol pack; no modification by CLI is required. |
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
|
|
||||
---|---|---|---|---|---|
Response-Time (ART) |
|
|
|
|
|
Figure 4-1 illustrates how the Application Experience profile exports different types of traffic statistics.
Figure 4-1 Export Model—Application Experience 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:
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
(legacy) |
|
|
---|---|---|
Handling of asymmetric routes within the router (a flow seen on different interfaces) |
Monitors collect total interface output. Irregularities may occur in metrics for asymmetric routes. |
Monitors collect all traffic per observation-point. This improves metrics accuracy in the case of asymmetric routes. |
Traffic monitor counters relate only to the L4 information (and do not include L3). |
Traffic monitor counters relate to the complete L3 information. |
|
URL and Media monitors rely on a list of specific applications to define HTTP/RTP traffic. |
URL and Media traffic monitors use the NBAR class-hierarchy feature, which identifies all HTTP/RTP traffic without requiring a list of specific applications. |
|
Improved URL monitor specificity—does not include ART traffic. |
||
Includes new ART metrics for 'long lived flows' and 'client/server retransmissions'. |
||
Yes2 ART and application-client-server monitors include 'host name' and 'SSL common-name' |
||
Conversation-Traffic-Stats monitor: Will have NULL in the IP addresses |
||
|
Table 4-6 Application Performance Traffic Monitors
|
|
|
---|---|---|
Remaining TCP/UDP traffic not matching other classifications |
||
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
|
|
||||
---|---|---|---|---|---|
Response-Time (ART) |
|
|
|
|
|
Sampling Rate3 |
|||||
|
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.
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.
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
|
|
|
---|---|---|
|
|
|
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.
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.
Note See Table 4-10 for information about which releases support each option.
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 ] [ interval-timeout timeout ]5
7. To configure additional traffic monitor parameters, repeat Step 6.
9. interface interface-type number
Table 4-10 Easy Performance Monitor Configuration Options
|
|
|
---|---|---|
Application Experience profile: Application Performance profile: |
||
Traffic monitor type. Options include the following: |
Application Experience profile: |
|
Selects whether monitor is active for ingress or egress traffic. If not specified, it is applied to both. |
||
Cache size: Maximum aggregate number of entries for all monitors. The following example includes four monitors: IPv4 in, IPv4 out, IPv6 in, IPv6 out. Each monitor can have a maximum of 1000 entries. The following example includes two monitors: IPv4 in, IPv4 out. Each monitor can have a maximum of 2000 entries. |
||
Restrict the default traffic classification. class-name represents a user defined class-map. Note : Not applicable to the Application Statistics profile. |
||
Replace the entire class hierarchy with a user pre-defined class. class-name represents a user defined class-map. Note : Not applicable to the Application Statistics profile. |
||
Optionally overrides the default traffic-monitor sampling rate. The range of possible sampling-rate values is determined by the platform. |
||
Specifies the cache timeout (exporting interval) in seconds. At this interval, the cached NetFlow records are exported.
Note (on Cisco IOS platforms) : Within a single context, configure all timeouts to the same value. The following traffic monitors support interval-timeout :
– url (on Cisco IOS platforms only)
– application-client-server-stats
– application-client-server-stats – url (on Cisco IOS platforms only) See ezPM Configuration Example 6: Configuring Cache Type and Interval Timeout. |
|
|
---|---|
Multiple policies can be configured simultaneously on an interface. Policy types:
Table 4-11 describes the number of policies that can be configured on an interface, according to platform type and IOS/IOS XE release.
Table 4-11 Number of Policies Possible to Configure on an Interface
|
(per direction) 6 |
---|---|
|
|
|
|
6.Configuring more than the maximum number of polices indicated here is not supported and causes unpredictable results. See Exceeding Supported Number of Policies. |
No Change in Method of Configuration
Configuring multiply policies on an interface does not require any change in the configuration process. This is true even if more than one policy collects some of the same metrics.
Configuring multiple policies enables additional flexibility in metrics collection:
Note Applying multiple policies to an interface causes some degradation of performance.
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.
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.
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.
|
|
---|---|
Beginning in 15.5(3)T, NBAR does not operate in fine-grain mode by default. |
Beginning in 3.16S, NBAR does not operate in fine-grain mode by default. |
NBAR provides two levels of application recognition—coarse-grain and fine-grain. Fine-grain mode provides NBAR's full application recognition capabilities.
NBAR fine-grain mode is equivalent to NBAR functionality and performance prior to introduction of separate fine-grain and coarse-grain modes. This provides full backward compatibility for existing configurations.
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.)
– Protocols used in local deployments
– Protocols used in cloud deployments
Coarse-grain mode limitations in metric reporting detail:
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.
Table 4-12 compares fine-grain and coarse-grain modes.
Table 4-12 NBAR Fine-grain and Coarse-grain Modes
|
|
|
---|---|---|
Some classification according to similar earlier packets. See Limitations. |
||
Any use case that does not require specific per-packet operations |
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.
In this example, configuring an ezPM policy using the Application Statistics profile invokes the coarse-grain NBAR mode.
The following CLI shows the currently configured mode (coarse-grain in the example output):
For details, see NBAR Configuration Guide.
|
|
---|---|
Monitoring a configuration is done using performance-monitor unified monitor and policy.
– Multiple flow monitors under a class-map
– Up to 5 monitors per attached class-map
– Up to 256 classes per performance-monitor policy
Attach a policy to the interface using following command:
Displaying Policy Map Performance Monitor Data
Display policy map performance monitor data using the command below. Example output is shown here.
Metric producer-specific parameters are optional and can be defined for each metric producer for each class-map.
The react CLI defines the alerts applied to a flow monitor. The react CLI has a performance impact on the router. When possible, send the monitor records directly to the Management and Reporting system and apply the network alerts in the Management and Reporting system.
Note Cisco IOS XE Platforms: Applying reacts on the device requires punting the monitor records to the route processor (RP) for alert processing. To avoid the performance reduction of punting the monitor records to the RP, send the monitor records directly to the Management and Reporting system, as described above.
|
|
---|---|
Flow monitor defines monitor parameters, such as record, exporter, and other cache parameters.
Configuration Format: Cisco IOS Platforms
Configuration Format: Cisco IOS XE Platforms
– Sends the record close to the time that it has ended.
– Exports only one record on true termination.
– Conserves memory in the cache and reduces the load on the Management and Reporting system.
– Enables exporting multiple transactions of the same flow. (This requires a protocol pack that supports multi-transaction.)
The flow record defines the record fields. With each Cisco IOS release, the Cisco AVC solution supports a more extensive set of metrics.
The sections that follow list commonly used AVC-specific fields organized by functional groups. These sections do not provide detailed command reference information, but highlight important usage guidelines.
In addition to the fields described below, a record can include any NetFlow field supported by the platform.
A detailed description of NetFlow fields appears in the Cisco IOS Flexible NetFlow Command Reference.
Note On Cisco IOS XE platforms, the record size is limited to 40 fields (key and non-key fields or match and collect fields).
The following are L3/L4 fields commonly used by AVC.
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.
The following are L7 fields commonly used by the Cisco AVC solution.
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.
The following are interface and direction fields commonly used by the Cisco AVC solution:
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:
The following are fields commonly used for TCP performance metrics by the Cisco AVC solution:
The following limitations apply to TCP performance metrics:
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
The following are fields commonly used for media performance metrics by the Cisco AVC solution:
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.
The following are L2 fields commonly used by the Cisco AVC solution:
|
|
---|---|
The following are WAAS fields commonly used by the Cisco AVC solution:
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:
The following are classification fields commonly used by the Cisco AVC solution:
Use this field to report the matched class for the performance-monitor policy-map.
NetFlow option templates map IDs to string names and descriptions:
Use the following commands to show NetFlow/IPFIX information:
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.
|
|
---|---|
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:
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.
Previous releases of AVC included the following pre-defined attribute values, which could not be user-customized:
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.
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:
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.
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:
|
|
---|---|
Use the following commands to enable packet capture:
This section applies to Cisco IOS platforms. (For information about QoS Metrics configuration for Cisco IOS XE platforms, see QoS Metrics: Cisco IOS XE Platforms.)
This section describes how to configure a performance monitor to include Quality of Service (QoS) metrics.
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
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:
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:
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:
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).
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.
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.
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.”
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.
Use the following configuration to create a policy-map that will collect both monitors.
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.
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:
This section applies to Cisco IOS XE platforms. (For information about QoS Metrics configuration for Cisco IOS platforms, see QoS Metrics: Cisco IOS Platforms.)
This section describes how to configure Flexible NetFlow (FNF) monitors to include Quality of Service (QoS) metrics.
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 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
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:
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:
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:
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.
To verify that QoS metrics collection is enabled, use the following command:
The following is an example of the output of the command:
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).
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.
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.
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.
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:
In contrast to the QoS Packet Drop monitor, a QoS Class Hierarchy monitor can be combined with another monitor to export additional metrics.
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.
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.
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.
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:
|
|
---|---|
Flexible NetFlow (FNF) monitors can report on individual transactions within a flow. This enables greater resolution for traffic metrics. This section describes how to configure connection and transaction metrics, including transaction-id and connection id, for FNF monitors. The connection/transaction monitoring feature is referred to as “Multi-transaction.”
Note The Multi-transaction feature requires an NBAR protocol pack that supports the feature. The protocol pack provided with Cisco AVC for IOS XE release 3.9S and later protocol packs support this feature.
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:
– 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.
The following subsections describe the Multi-transaction feature:
The following requirements apply when using the Multi-transaction feature:
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.
This section describes commands useful for verification and troubleshooting the FNF configuration. There are subsections for:
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
Verifying Multi-transaction Status
Display the Multi-transaction status:
If Multi-transaction is enabled, the value is: is_multi_trs_enable==1
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.
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.
|
|
---|---|
Aliases provide a mechanism for simplifying configuration statements. The all alias refers to the set of all fields possible for a given statement. For example, “ collect connection delay
all ” configures all fields that are possible to configure by the “ collect connection delay
” statement.
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.
|
|
---|---|
The “observation point id” metric identifies a monitored interface for traffic in both directions (ingress and egress). A single flow definition using this metric can be used in place of match interface input and match interface output, making configuration more compact and enabling a single record collected on an interface to include metrics for traffic in both directions.
The metric may be collected from LAN or WAN interfaces.
Configure the monitor on both the ingress and egress directions.
In the following example configuration, a single monitor identifies the interface for traffic in both directions:
|
|
---|---|
NBAR can be configured to classify and report on tunneled IPv6 traffic. NBAR, QoS, and performance metric calculations support IPv6 pass-through tunneling.
The following NBAR command displays the options for enabling the feature:
|
|
---|---|
NBAR classifies tunneled traffic as one of the IPv6 tunneling protocols, such as: |
|
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.
When using the ezPM Application Experience profile and IPv6-over-IPv4 tunneling:
The issue is not relevant for the ezPM Application Statistics profile, which does not report the tuple.
This section contains AVC configuration examples. These examples provide a general view of a variety of configuration scenarios, combining multiple AVC features. Configuration is flexible and supports different types of record configurations.
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).
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.
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.
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).
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:
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.
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.
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.
– conversation-traffic-statistics
The following ezPM configuration example combines two contexts on the GigabitEthernet0/0/1 interface:
The cache type setting for each monitor of an ezPM profile is determined by one of the following:
The functionality of the interval-timeout parameter depends on the cache type.
The default cache type for the application-client-server-stats monitor used in this example is normal, so the interval-timeout parameter defines the active timeout.
The following line configures the interval timeout (seconds):
The output of show performance monitor context perf includes the following, showing the active timeout as 300 seconds (bold added):
The default cache type for the application-response-time monitor used in this example is synchronized, so the interval-timeout parameter defines the synchronized timeout.
The following line configures the interval timeout (seconds):
The output of show performance monitor context perf includes the following, showing the synchronized timeout as 100 seconds (bold added):
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.
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:
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:
police
statement limits the bandwidth of business-critical traffic to 50% in the example.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:
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:
The configuration is for IPv4 traffic. Similar monitors should be configured for IPv6.
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.
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).
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.
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.
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
Example of Exported Value—No Backslash after URL
Address: http://usr:pwd@www.test.com
The uri statistics command exports a zero length field.
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.
The monitor configured in the following examples collect application traffic statistics.
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.
The monitor configured in the following example reports on media traffic:
For detailed information about metrics, see Cisco AVC Field Definition Guide for Third-Party Customers.