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 troubleshooting section includes the following topics:
•Report Is Not Displayed Correctly
•Incorrect TCP Performance Statistics
•More Than 32 Matches per Class
•More Than Five Monitors per Class
The following may be helpful for troubleshooting a report that is not displayed correctly:
•Verify that your flow exporter is configured with the correct destination IP.
•If you are using a VRF, ensure that it is added at the destination.
(config-flow-exporter)#destination 1.1.1.1 vrf myVrf
•Check whether samplers are configured correctly.
•Check the flow exporter statistics for errors.
# show flow exporter statistics
Flow Exporter my_exporter:
Packet send statistics (last cleared 4d00h ago):
Successfully sent: 203808 (280136412 bytes)
Client send statistics:
Client: Option options interface-table
Records added: 18528
- sent: 18528
Bytes added: 1852800
- sent: 1852800
Client: Option options vrf-id-name-table
Records added: 3474
- sent: 3474
Bytes added: 125064
- sent: 125064
Client: Option options sampler-table
Records added: 0
Bytes added: 0
Client: Option options application-name
Records added: 1213584
•Check the cache output and verify that the specific monitor is not empty.
# show performance monitor cache detail [format record]
•Verify policy and class-map hits (counters should increase).
# show policy-map type performance-monitor interface g0/0/2
GigabitEthernet0/0/2
Service-policy performance-monitor input: mymon_in
Class-map: select_ipv4_tcpperf (match-all)
354704 packets, 75729623 bytes
30 second offered rate 1000 bps, drop rate 0000 bps
Match: protocol ip
Match: access-group name ipv4_tcpperf
Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any
•Review the running-config and verify that nothing is missing or misconfigured. The problem can be caused by even a single access-list missing.
•Verify that account-on-resolution (AOR) is active.
–If AOR is active, handles will have a non-zero value, as shown in the following example:
# show platform hardware qfp active feature fnf datapath aor
CFT: ConfigAddress 0x8a1e16a0, Instance 0x8a1de760, Feat ID 1, FlowObj ID 1
CVLA: handle 0x97f00000 epoch 0x4
–If AOR is inactive, handles will have the value of zero, as shown in the following example:
# show platform hardware qfp active feature fnf datapath aor
CFT: ConfigAddress 0x8a1e16a0, Instance 0x00000000, Feat ID 0, FlowObj ID 0
CVLA: handle 0x0 epoch 0x4
The following may be helpful for troubleshooting incorrect TCP performance statistics:
•Verify that the monitor that includes TCP performance metrics is applied to only one interface.
•For that interface, service-policy must be attached in both directions.
•Check for asymmetric routing.
•Verify that routes/route-maps are configured correctly.
•If filtering applications, ensure that the appropriate class-map has hits.
•Verify that account-on-resolution (AOR) is active. For details about verifying AOR, see Report Is Not Displayed Correctly.
•Enable IP NBAR Protocol Discovery on the interface to determine whether the protocol of interest is identified.
Router(config-if)# ip nbar protocol-discovery
Router# show ip nbar protocol-discovery interface g0/0/3
GigabitEthernet0/0/3
Last clearing of "show ip nbar protocol-discovery" counters 00:00:10
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
30sec Bit Rate (bps) 30sec Bit Rate (bps)
30sec Max Bit Rate (bps) 30sec Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
http 7 8
3472 1740
0 0
0 0
The following may be helpful for troubleshooting a Flexible NetFlow (FNF) memory warning:
•The following error message typically occurs if a monitor's cache is exceeded:
Oct 28 14:44:10.358 IST: %QFP_FNF-4-FNF_MEM_UPLIMIT_WARN: F0: cpp_cp: Netflow and Flexible Netflow configuration is using (140199440) bytes of data plane DRAM which exceeds the recommended maximum of (134217728) bytes.
This warning indicates that the router capacity may not be adequate for the network traffic.
•Review the configuration. If there are mismatches, remove the configuration and reapply it.
•Reduce the FNF monitor cache size.
The following may be helpful for troubleshooting the following type of error message regarding configuring more than 32 matching statements:
cannot configure more than 32 matching statements per class-map for the interface
•Review your class-map configuration.
# show class-map
•Make sure every class-map has no more than 32 match instructions, including hierarchical classes. Remove redundant match instructions
The following may be helpful if you receive the following type of error message regarding the limit of five (5) monitors per policy per class:
%Only 5 monitors allowed per policy per class
•Review the class-map configuration.
# show class-map
•Verify that every class-map has no more than five monitors, including FNF monitors which are applied directly on the interface. Remove any redundant monitors and retry.