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 (18.104.22.168) to switch (22.214.171.124)
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 ama-sc-b-lo.argentina.ibm.com [x.y.132.25] (via cw-iga.argentina.ibm.com [x.y.81.24]) TRAP, SNMP v1, community public
enterprises.9.1.283 Authentication Failure Trap (0) Uptime: 0
enterprises.126.96.36.199.0 = 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:
ip address x.y.130.196 255.255.255.192
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
no ip mroute-cache
logging event link-status
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...
Solved! Go to Solution.
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: 188.8.131.52 (NAM)
BIOS Version: 4.0-Rel 6.0.9
Fri Jun 22 12:41:06 2007 Patch: nam-app.3-6.strong-crypto-patchK9-1-0 Description: Strong Crypto Patch for NAM.
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 127.0.0.81 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?
Try removing the supervisor address on the NAM with the command "no supervisor address" then reload the NAM, and see if that helps.
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).