Sending Ciscowrks device credential Verification Job alters the device ARP table.

mikik · ‎03-22-2011

Hi:

I send a Device credential verification Job to two different devices , a Cisco 3750 and a blade switch WS-CBS3120. I configured SNMP write access to the switches. The SNMP write access in either SNMP v1 or SNMP V3 , tried both.

The job is send from the Ciscoworks server.

Once the job has completed, I do a show ip arp on the device and find a new entry with the IP address of the Ciscoworks Server and the mac-address of the L2 next hop.

We would not have noticed this behavior had it not been that in the case that the switch next hop is an HSRP vlan on a nexus , the ARP entry entered into the switch is incorrect, and from then on the switch loses connection to Ciscoworks.

The Mac-address that is entered by Ciscoworks , in the case of nexus is a statice mac defined on the Nexus for the Vlan in question , but it is NOT the HSRP default gateway MAC address. Therefore we lose connection between the switch and Ciscoworks. One has to manually clear the ARP table inorder to again reach the Ciscoworks.

Questions:

1. Why does Ciscoworks insist on changing the ARP table?
2. Is this ARP entry aged out or is it permeant as would an ARP entry which is entered through CLI be permeant ?
3. In the case of the Nexus connection, this ARP entry does not allow Ciscoworks and the device to communicate. This is not productive!

Has any one come across this situation ? Any known fixes, workarround? I was not able to find a word about this on Cisco's site.

Our Ciscoworks is at the following levels:

CW Common services    3.3.0
LMS portal                    1.2.0
CW Assistent                1.2.0
RME                             4.3.1
Device fault manager      3.2.0
IPM                              4.2.1
Cisco View                    6.1.9
campus Manager            5.2.1

thanks for any help

Mickey

Joe Clarke · ‎03-26-2011

CiscoWorks does not change the ARP table, at least not overtly. A credential verification job will do the following things depending on what protocols are selected to test:

SNMP RO : Fetches sysLocation.0

SNMP RW : Sets sysLocation.0 to the value currently stored in sysLocation.0

Telnet : Logs in using DCR username and password

SSH : Logs in using DCR username and password

Enable : Enters enable mode and verifies privilege level 15

If one of these things are causing the ARP table to change, then there is something fishy in the device or network configuration. I've never heard of such behavior relating to CiscoWorks before.