Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

FWSM authentication error when running inventory

I'm again attempting to perform inventory on a FWSM on a Cat 6513. The credentials appear good, the snmp v2 community string appears to be good, the device is configured for snmp and ssh access and has been reverified (string/username-password) on the device and in ciscoworks (CS/RME). I have adjusted the SNMP timeout to 30 seconds...However when running the inventory, it get the following error:

Transport session to device failed. Cause: Authentication failed on device

any thoughts on this?

Cisco Employee

Re: FWSM authentication error when running inventory

This is the same problem you've seen in the past. Either the SNMP credentials are wrong on the FWSM or in DCR, the SNMP packets are not making it to the FWSM, or the FWSM is not configured to allow the LMS server to poll it. A sniffer trace on the LMS server of SNMP traffic to this device will show you what credentials RME is using, and whether or not replies are making back to the LMS server.

A sniffer trace on the FWSM side will tell you if the SNMP packets are making it to the device.

A visual inspection of he FWSM config will show you if the IP address of the RME server is allowed to poll the FWSM with SNMP.

New Member

Re: FWSM authentication error when running inventory

I know, I know...same old problem...just getting back to it...havent put a sniffer on it (but will), snmp creds are correct on fwsm and dcr (changed, verified and reverified)...fwsm is set to allow polling from the LMS server "snmp-server host poll community "...

i'll stick the sniffer on it tomorrow and see what i get...


New Member

Re: FWSM authentication error when running inventory

Alrighty J,

You were (as usual) correct...after getting the sniffer on there, and a bunch of packet capturing analysis, I found that though TCP port 161 was open, UDP port 161 was not...once I had UDP 161 opened, BAM, worked like a champ...

thanks for pointing me in the correct direction...