IPSEC SNMP Issue

[damprieto86]

Hi to all,

i have an odd problem with Cisco MIB for IPSEC:

We have a GETVPN network established for one client. Everything related to encryption works fine between group members (IKE phase 1 and 2). Our client request us to monitor all active VPN tunnels in all group members, so we decided to check cipSecGlobalActiveTunnels in all group members to verify all active ipsec sessions between GM's. the problem is when we check cipSecGlobalActiveTunnels when no ipsec session is established (i.e ISAKMP and IPSEC are disabled) the SNMP object returns a nonzero value, returns "2". IT means two ipsec active sessions, but no IPSEc sessions is established when we check on CLI.

FIrst i thought it may be a software bug, but we have an identical solution for other customer, monitoring the same SNMP object and the SNMP object returns the correct value when IPSEC is disabled (returns "0" active tunnles) and is a GETVPN infraestructure too. We compared the IOS from routers on different solutions and is the same:

sh ver | inc IOS

Cisco IOS Software, 1841 Software (C1841-ADVIPSERVICESK9-M), Version 12.4(15)T8, RELEASE SOFTWARE (fc3)

when IPSEC and ISAKMP is enabled, and IPSEC sessions are active, the SNMP returns again the total of ipsec active sessions plus 2. but in the other solution shows just the total of ipsec active sessions.

both solutions diffres only in Phase 1 authentication ( odd one uses Certificates and normal one uses PSK)

Any ideas about this issue?

thanks in advance.

Damián

[Joe Clarke]

It could be due to a problem in the clearing of a previous IPSec tunnel.  If there is an error reporting a tunnel

termination, then the stats counter is not properly decremented.  There was also a bug in which the "clear crypto session" command did not return this object to a zero value (but that bug could never be reproduced internally).  If you enable "debug crypto mib error" and "debug crypto mib detail", any future problems decrementing the active tunnel counter should be seen in the router log.  However, you may not want that extra overhead.  In any event, a reboot will return the object to zero.  If you find you are able to reliably reproduce this problem, opening a TAC service request would be a good idea.  You can point your engineer to CSCsl16701 which describes the "clear crypto session" issue.