We have 2 RFS6000 controllers and 35 devices of this model in our environment, but I can't retrieve SNMP data from them. We have another 12 devices of the AP7532 model, and I can easily get the information from them.
$ snmpwalk -v2c -c cti 172.19.0.91 (AP621) Timeout: No Response from 172.19.0.91
$ snmpwalk -v2c -c cti 172.19.0.100 iso.22.214.171.124.126.96.36.199 = STRING: "AP7532 Access Point, Version 188.8.131.52-003R MIB=01a" iso.184.108.40.206.220.127.116.11 = OID: iso.18.104.22.168.1.322.214.171.124.40 iso.126.96.36.199.188.8.131.52 = Timeticks: (24005400) 2 days, 18:40:54.00 iso.184.108.40.206.220.127.116.11 = "" iso.18.104.22.168.22.214.171.124 = STRING: "AP-A13-1314"
What is blocking the AP621 model? How can this be fixed?
I tried to follow the steps in the link below, but an error occurred. I think it's a bug.
rfs01(config)*#ip snmp-access-list cti rfs01(config-ip-snmp-acl-cti)*#permit any % Error: Invalid IPv4/mask format rfs01(config-ip-snmp-acl-cti)*#permit ? A.B.C.D/M Source IP address range to match any Any source IP address host Single host address rfs01(config-ip-snmp-acl-cti)*#permit any ? <cr> rfs01(config-ip-snmp-acl-cti)*#permit any % Error: Invalid IPv4/mask format
Thank you in advance!!!
The entries in the ip snmp-access-list specify (if using 'permit' entries) which host or networks are allowed for SNMP traffic with an AP.
In this case, your workstation address needs to exist either as a specific host entry in this list OR the network that your workstation is on needs to exist as a network range in the list.
This is what I am trying to confirm. Does your workstation address match any of the four entries in the snmp-access-list?
So as expected, the 7532 port 161 shows as OPEN.
Also, your workstation address (172.19.0.97) is not an address that would be allowed by SNMP based on the 621's ip snmp-list
Are there any APs responding to snmp (that use the same exact snmp-access-list) that are located on the same network as a 621 that is NOT responding? (trying to eliminate/confirm that this snmp-access-list is the culprit)
ip snmp-access-list cti
permit host 200.x.x.x
permit host 10.60.0.7