- Derived Fields Caveat
- Oversubscribed FNF Monitor Caveat
- Use Synchronized Cache for Optimized Monitors
- Incorrect Record Metric Values When FNF Cache Is Full
- Clock Mismatch Between QFP and Operating System Causes Records To Be Dropped
- CSR1000V Platform: Large Jitter Value Reported for Voice/Video Flow
- Incorrect Jitter Value Reported for RTP Streams
- After Route Processor Switchover, ezPM Record Export May Fail
Notes
Hidden Fields
Two hidden fields (first/last timestamp) are implicitly added to each record, even when these fields are not explicitly configured. When the fields are not explicitly configured, the fields are not exported and are not displayed using show commands. Because of these two hidden fields, the effective maximum number of supported fields is the upper limit defined for the release, minus two.
Cache Size Recommendation
The cache size to configure is determined by the traffic profile. The cache should be large enough to store all traffic records, but not excessively large. A warning message may appear if the configured cache exceeds 25% of DRAM. For troubleshooting information, see Memory/Cache Warning.
Limitations
Multicast
AVC support for multicast is as follows:
–
MediaMonitoring (Calculates and reports media (RTP) performance metrics)
Delay Before New NBAR Configuration Is Activated
After updating an NBAR configuration, there is a delay before the new configuration is active on the data path.
When you update a configuration, a parallel configuration (the previous) operates during the changeover of configuration to prevent any impact on classification during the transition from one configuration to the next.
After changing a configuration, it takes some time before NBAR classifies traffic according to the new configuration.
The following query indicates the status of the new configuration:
– ASYNC—In normal operation, the NBAR configuration send mode is asynchronous.
– Ready—The new configuration is active.
– Pending—The new configuration is not yet active. The previous configuration remains active until the new configuration becomes active.
– Error—The new configuration is not active in the data path due to an error. In this error state, the previous configuration may or may not be active.
Do Not Use the Management Interface for Exporting Records
All Cisco IOS XE platforms operating with AVC.
Do not use the management interface (typically GigabitEthernet0) as the source interface of the exporter. The management interface can be identified by the “MGMT ETHERNET” or “GigE” labeling of the physical port. Not following this guideline may cause unexpected behavior, including system crash.
Minimum Interval Between Assigning and Removing a Performance Monitor
A minimum interval of approximately 5 seconds is required between assigning a performance monitor and removing it, or between removing and assigning again.
- After assigning an AVC performance monitor to an interface, wait approximately 5 seconds before removing the performance monitor from the interface.
- After removing an AVC performance monitor from an interface, wait approximately 5 seconds before re-assigning the same performance monitor to the interface.
Not waiting the required time interval may cause some AVC functionality to fail; waiting the required 5 seconds and attempting the configuration again typically resolves the issue. In extreme cases, AVC may stop functioning; to resolve this, restart the router.
ISSU Limitations
Cisco In-Service Software Upgrade (ISSU) provides transparent router software upgrade or downgrade. ISSU enables bug fixes, deployment of new features, and even complete upgrade of the Cisco IOS software image. For more information, see: In-Service Software Upgrade .
Removing Aliases before Downgrading from Cisco IOS 15.4(1)T / Cisco IOS XE 3.10 or Later
In Cisco IOS XE release 3.10S and Cisco IOS release 15.4(1)T, aliases were introduced to the AVC monitor configuration syntax. Using the all alias simplifies configuration statements and optimizes performance. (See CLI Field Aliases.)
Before downgrading from one of these releases, or a later release, to a version that does not support aliases, remove the aliases and manually expand the statements to specify each of the required fields explicitly. Failure to remove aliases before downgrading will result in undesired behavior, including possible system crash.
Downgrading to an IOS XE Version that Does Not Support More than 32 Fields
AVC for Cisco IOS XE 3.10 introduced support for configuring records containing 40 fields. If a record configuration includes more than 32 fields, downgrading to an IOS XE version that does not support more than 32 fields is not supported.
Before downgrading from Cisco IOS XE 3.10 or later, to a version, such as IOS XE 3.9, that does not support more than 32 fields, remove any record configuration of more than 32 fields.
Note Some record configurations include hidden fields. Hidden fields count toward the total supported number of fields. See Hidden Fields.
Note Upgrading from a version that does not support more than 32 fields to a version that does support more than 32 fields is supported.
Error Caused By Using a Performance Monitor With Default Cache Size
Using a performance monitor when the cache size is set to its default value may cause an error during the Cisco In-Service Software Upgrade (ISSU) process. An error in the console log will indicate a failure to update the monitor cache size.
1.
Applicable to all Cisco IOS XE platforms.
2. Occurs when running ISSU, which provides transparent router software upgrade or downgrade.
3. May occur when doing either one of the following:
– Upgrading from Cisco IOS XE 3.10 or earlier to IOS XE 3.11 or later version
– Downgrading from IOS XE 3.11 (or later) to a version earlier than 3.11
A preventive workaround and typical use case is to configure the cache size manually rather than using the default.
If using the default cache size, use the following workaround to avoid the error:
Affect of Specific Metrics on Performance
Performance monitors operate in different modes, depending on the metrics that they are configured to collect. For maximum performance, any of the following metrics may be used. Including other metrics may impact performance.
– match application name [account-on-resolution]
– match connection client ipv4 (or ipv6) address
– match connection server ipv4 (or ipv6) address
– match connection client transport port
– match connection server transport port
– collect application http host
– collect application http uri statistics
– collect datalink mac source address
– collect interface [input/output]
– collect ipv4 ttl (or ipv6 hop-limit)
– collect policy qos classification hierarchy
– collect policy qos queue [drops/index]
– collect timestamp sys-uptime first
– collect timestamp sys-uptime last
Example of Record Including Metrics That Do Not Reduce Performance
Caveats
Caveats describe unexpected behavior. Severity 1 caveats are the most serious caveats. Severity 2 caveats are less serious. Severity 3 caveats are moderate caveats.
To view caveats related to the use of AVC, see the release notes for your platform.
If you have an account on Cisco.com, you can also use the Bug Search tool to find select caveats of any severity. See: https://tools.cisco.com/bugsearch/search
(If the defect that you have requested is not displayed, it may be that the defect number does not exist, the defect does not have a customer-visible description, or the defect is for internal Cisco use.)
- Derived Fields Caveat
- Oversubscribed FNF Monitor Caveat
- Use Synchronized Cache for Optimized Monitors
- Incorrect Record Metric Values When FNF Cache Is Full
- Clock Mismatch Between QFP and Operating System Causes Records To Be Dropped
- CSR1000V Platform: Large Jitter Value Reported for Voice/Video Flow
- Incorrect Jitter Value Reported for RTP Streams
- After Route Processor Switchover, ezPM Record Export May Fail
Derived Fields Caveat
Caveat CSCue53207 , described in the Cisco ASR 1000 Series Aggregation Services Routers Release Notes , describes a bug in some earlier releases, in which a record that contains certain derived fields (listed below) may be punted incorrectly to the route processor (RP) and lost. When using any of the connection delay fields listed in the Workaround description below, downgrading to a release that contains this bug is not recommended.
The following is a description of the bug:
A record that contains certain derived fields (listed below) may be punted incorrectly to the route processor (RP) and lost.
Records can collect "derived" fields; calculating derived fields is dependent on the values of other fields. The fields listed below are incorrectly defined as derived and dependent on other fields. When a record contains one of these fields and does not include its dependent fields, the record is punted to the route processor (RP) to complete the record processing. Punting these records might lead to record loss.
When configuring a monitor to collect one of the fields listed below, collect each of the dependent fields also. The list indicates the dependencies:
1. “connection delay application sum” is dependent on:
connection delay response to-server sum
connection delay network to-server sum
connection server response sum
2. “connection delay application min” is dependent on:
connection delay response to-server min
connection delay network to-server sum
3. “connection delay application max” is dependent on:
connection delay response to-server max
connection delay network to-server sum
4. “connection delay response client-to-server sum” is dependent on:
connection delay response to-server sum
connection delay network to-server sum
connection server response sum
5. “connection delay response client-to-server min” is dependent on:
connection delay response to-server min
connection delay network to-server sum
connection server response sum
connection delay response to-server sum
connection delay network to-server min
6. “connection delay response client-to-server max” is dependent on:
connection delay response to-server max
connection delay network to-server sum
connection server response sum
Oversubscribed FNF Monitor Caveat
Caveat CSCud15949 , described in the Cisco ASR 1000 Series Aggregation Services Routers Release Notes , describes a bug affecting releases prior to IOS XE 3.10S. For these releases, you can attach up to two policies per interface and direction. The total number of monitors included in the two policies should not exceed 10. In calculating the total number of monitors:
- Each policy is considered to include at least five monitors, even if fewer than five monitors are configured for the policy.
- An FNF static monitor is counted as 1 monitor.
The bug may occur (on the affected releases) if these limits are exceeded on any interface, either for ingress or egress traffic on the interface. This condition is called “oversubscribed.”
When a system is oversubscribed, downgrading to a release that contains this bug is not recommended. For oversubscribed systems, Cisco In-Service Software Upgrade (ISSU) does not enable downgrading to a release prior to 3.10S.
The following is a description of the bug:
The CPP traceback notifying monitor cannot be reserved.
The issue was seen when the MMA policy, mediatrace policy, and one FNF monitor were attached to an interface.
Ensure that the total number of monitors does not exceed the limits outlined above, in the description of this bug.
Use Synchronized Cache for Optimized Monitors
Caveat CSCuh87789 describes a limitation affecting routers running Cisco IOS 15.4(1)T. On affected releases, use “synchronized cache” when configuring optimized monitors. Do not use, for example, the “normal cache” option. Synchronized cache is the default cache mode for the router.
Using a cache option other than synchronized may result in failure to export certain metrics, resulting in incomplete records.
Incorrect Record Metric Values When FNF Cache Is Full
Caveat CSCum52041 describes a problem that may occur when the FNF cache reaches a full state.
Updating of some records in the FNF cache may fail intermittently. Metrics in these records may not reflect complete router traffic.
1. A large number of match keys are defined in the configuration: total length of all key fields is more than 32 bytes.
2. The FNF record cache is full.
To determine if the FNF cache was full at some time during record collection, use one of the following commands. A value greater than 0 for the flows-not-added counter indicates that the cache reached the full state at some point.
Clock Mismatch Between QFP and Operating System Causes Records To Be Dropped
Caveat CSCul27478 describes a problem that may occur due to a clock mismatch between the IOS XE operating system and the router’s QuantumFlow Processor (QFP). When this occurs, records punted from the QFP to IOS may be identified as late records, and incorrectly dropped instead of being exported.
Records are dropped (not exported).
The problem may occur when there is a clock mismatch between QFP and the IOS XE operating system.
A workaround for this issue may be to configure an NTP server that allows the IOS clock to be synchronized with network time.
Alternatively, upgrade to a release that resolves this issue.
If the following CLI shows that there are late records, this problem may be occurring:
It is also possible to compare timestamps between QFP and IOS XE to determine whether there is a clock mismatch. This may be done by comparing timestamps in an RP platform debug log.
- Caveat CSCul00248 . If you have an account on Cisco.com, you can use the Bug Search tool to view this caveat.
- Caveat CSCum07636 . If you have an account on Cisco.com, you can use the Bug Search tool to view this caveat.
CSR1000V Platform: Large Jitter Value Reported for Voice/Video Flow
Caveat CSCun33822 describes a problem affecting jitter values reported on CSR1000V platforms.
Jitter values for voice/video flows are reported inaccurately, often in the hundreds of milliseconds.
Relevant for a voice/video RTP flow on a CSR1000V platform.
A Medianet performance monitor is configured to monitor and report RTP statistics, such as jitter and packet-loss.
Incorrect Jitter Value Reported for RTP Streams
The jitter measurement for RTP streams with a dynamic payload type (96-127) may be incorrect.
There is no dynamically learned mapping between the payload type and the clock frequency used in the specific RTP stream. The frequency is always set to 90 KHz.
After Route Processor Switchover, ezPM Record Export May Fail
Caveat CSCun24943 describes a problem affecting ezPM record export after a route processor switchover.
After route processor (RP) switchover, ezPM does not operate on the newly active RP. Records are not exported.
Stateful switchover (SSO) is configured. Switchover occurs.
Re-apply the ezPM configuration or switchover to the original RP after it recovers from failure.
Feedback