This document describes the configuration required for passing AVC traffic through an IPSEC tunnel to the collector. By default, AVC information cannot be exported across an IPSEC tunnel to the collector
Cisco recommends that you have the basic knowledge of these topics:
Application Visibility and Control (AVC)
Easy Performance Monitor (EzPM)
The Cisco AVC feature is used to recognize, analyze and control over multiple applications. With application awareness built into the network infrastructure, plus visibility into the performance of applications running on the network, AVC enables per-application policy for granular control of application bandwidth use, resulting in a better end user experience. Here you can find more details about this technology.
EzPM is a faster and easier way to configure the traditional performance monitoring configuration. Currently EzPM does not provides the full flexibility of the traditional performance monitor configuration model. Here you can find more details about EzPM.
Currently AVC does not support the number of pass-through tunneling protocols, details can be found here.
Internet Protocol Security (IPSec) is one of the unsupported pass-through tunneling protocols for AVC and this document addresses the possible workaround for this limitation.
This section describes the complete configuration used to simulate the given limitation.
In this network diagram all the routers have reachability to each other using the static routes. R1 is configured with the EzPM configuration and has one IPSec tunnel established with R2 router. R3 is working as an exporter here, which could be Cisco Prime or any other kind of exporter which is capable of collecting the performance data.
AVC traffic is generated by R1 and it is sent to the exporter via R2. R1 sends the AVC traffic to R2 over an IPSec tunnel interface.
This section describes the initial configuration for R1 through R3.
! interface Loopback0 ip address 22.214.171.124 255.255.255.255 !
ip address 172.16.1.1 255.255.255.0
ip route 0.0.0.0 0.0.0.0 172.16.1.2
ip address 172.16.2.2 255.255.255.0
ip address 172.16.1.2 255.255.255.0
ip address 172.16.2.1 255.255.255.0
ip route 0.0.0.0 0.0.0.0 172.16.2.2
This section describes the IPSec configuration for R1 and R2 router.
Apply the EzPM profile on the interface which needs to be monitored; here we are monitoring the loopback 0 interface.
ip address 126.96.36.199 255.255.255.255
performance monitor context Performance-Monitor
With the above configuration in place, take the output for show performance monitor contextcontext-nameexporter.
Check for the status of Output Features option, by default it should be in Not Used state, which is an expected behavior and that is why the AVC traffic is not being encapsulated or encrypted here.
In order to let the AVC traffic pass through the IPsec tunnel interface, Output Features option shall be in used state. And to do that, it has to be enabled explicitly in flow exporter profile. Below is the detailed step by step procedure to enable this option.
Take the complete output for show performance monitor context context-name configuration command and save it in notepad. Below is the snip for this output,
Leave the rest of the output as it is, DO NOT alter anything else in the output.
Now, remove the EzPM profile from the Interface and from the router as well.
Interface loopback 0
no performance monitor context Performance-Monitor
no performance monitor context Performance-Monitor profile application-experience
Apply the modified config on the R1 router. Make sure that not a single command is missed out, since it may cause any unexpected behavior.
This section describes the verification method used in this document to check and how this workaround has helped to overcome the limitation for AVC packets mentioned here.
Before applying the workaround, packets received by the IPSec peer router (R2) will be dropped. Below message will be generated as well:
%IPSEC-3-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet, dest_addr= 172.16.2.1, src_addr= 172.16.1.1, prot= 17
Here R2 is expecting the ESP encapsulated packets which are destined for 172.16.2.1, but the received packets are plain UDP packets (prot=17) and it is an expected behavior to drop these packets. Below packet capture shows that the packet received at R2 is a plain UDP packet instead of ESP encapsulated, which is a default behavior for AVC.
After applying the workaround, it is clearly seen from the below packet capture that the AVC packets received at R2 are ESP encapsulated and no more error messages seen on the R2.
Currently there is no specific troubleshooting information available for this configuration.