Showing results for 
Search instead for 
Did you mean: 

NAM snmp to Cisco6509 Sup720

Hi, iam having a communication problem between the NAM and the switch, with the following message in the NAM web page:

Performing SNMP test from NAM ( to switch (

Access to the switch failed. This may be due to the switch's SNMP access control list is enabled.

Check if your switch's SNMP access control list is enabled and make sure

that the NAM's IP address is included in the access control list.

I have found the following message on my trapd station:

2007-06-21 19:49:05 [x.y.132.25] (via [x.y.81.24]) TRAP, SNMP v1, community public

enterprises.9.1.283 Authentication Failure Trap (0) Uptime: 0

enterprises. = IpAddress: x.y.130.254

It seems to be a commnuty string problem, but the snmp communities are the same in the NAM and in the switch.

Besides... the log message claims for "public" community string.

The IP .254 is the NAM

The IP .25 is the Sup720

The IP .24 is my CiscoWorks

I can ping from the Sup720 to the NAM and from the NAM to the Sup720.

The access-lists for SNMP has the IP of the NAM.

I have the following command in the switch:

analysis module 8 management-port access-vlan 330

Following the VLAN configuration:

interface Vlan330

description ama/SC-SAb/x.y.130.192/26/V330

mac-address 4209.0882.0e00

ip address x.y.130.196

no ip redirects

no ip unreachables

no ip proxy-arp

ip route-cache flow

no ip mroute-cache

logging event link-status

load-interval 60

arp timeout 420

standby 1 ip x.y.130.193

standby 1 timers 1 6

standby 1 priority 200

standby 1 preempt

standby 1 authentication vlan330

standby 2 ip x.y.130.194

standby 2 timers 1 6

standby 2 priority 150

standby 2 preempt delay minimum 60

standby 2 authentication vlan330


Also this command in the NAM:

supervisor address x.y.132.25

I do not know what else i should check...


Accepted Solutions
Joe Clarke
Hall of Fame Cisco Employee

Note: when you remove the supervisor address, you need to leave the loopback IP in your ACL.

View solution in original post

Joe Clarke
Hall of Fame Cisco Employee

The "public" in the trap is the community string being used to send the trap, and not the one that used to do the polling. What version of software is running on the NAM, and what version of IOS is on the switch? What model of NAM is this?

It would also be helpful to see the output of "show vlan", a full "show run" from the switch, and a "show snmp" from the NAM. This would help to confirm if there are SNMP ACLs, typos, or a problem with the VLAN. If you cannot share this information, I suggest you open a TAC service request to get further assistance.

I forgot, i also try this command in the NAM

root@nam-b# ip interface internal

Command not supported on the HW platform.Invalid command!


The NAM is connected throu the copper module, is the a way to connect it to the 6509 internaly?

I am attaching a file with the req info

I have upgraded the NAM to... but i still have the same problem

root@nam-b# show ver

NAM application image version: 3.6(1)

Maintenance image version: 2.1(3)

NAM Daughter Card Micro code version: (NAM)

BIOS Version: 4.0-Rel 6.0.9

Installed patches:

Fri Jun 22 12:41:06 2007 Patch: nam-app.3-6.strong-crypto-patchK9-1-0 Description: Strong Crypto Patch for NAM.


Ive perform a showtech in the NAM, and if found this...

Switch IP Address

Switch Community String


Joe Clarke
Hall of Fame Cisco Employee

It looks like your access list 83 is the problem. The NAM polls the switch via the internal loopback address of 127.0.0.X where X is a factor the NAM's module number. Since the NAM is in slot 8, add to your SNMP Community string access list, and see if that helps.

I try that... but still the same...

I am thinking in the results of the showtech, that i mention previously

Switch IP Address


Switch Community String


and this community string changes every time i reset the module.

As extra info, the ACL has no hits, so i think that maybe the community string used by the NAM to query the Sup720 is wrong... or blocked... some bug?

Joe Clarke
Hall of Fame Cisco Employee

Try removing the supervisor address on the NAM with the command "no supervisor address" then reload the NAM, and see if that helps.

Joe Clarke
Hall of Fame Cisco Employee

Note: when you remove the supervisor address, you need to leave the loopback IP in your ACL.


This solve the problem!!!

Thanks a lot

Joe Clarke
Hall of Fame Cisco Employee

You are being affected by the known bug CSCsi45556. The only workaround is to re-enable the internal NAM/switch communication channel (which is what you just did).