Ошибка snmp 223 - Решение и исправление самых разных ошибок на TopOshibok.ru

Hello,

I read all the posts here on error 223 and couldn’t figure out why snmpwalk AND Paessler SNMP Tester 5.2.3 returned the same 223 error when SNMPTester was in «Custom OID» request mode.

Had written a post requesting help when I spotted the solution: Turned out I had to add «.0» to the end of the OID.

According to the documentation, the OID should be 1.3.6.1.4.1.3375.2.6.1.4.3. This works with snmp walk, but not when using «Custom OID» request type.

Then I spotted that the Walk type request returned a response where the OID had a .0 added to the end.
The number could be different for other OIDs, I guess.

Problem 223:

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 
15.07.2016 09:46:30 (8 ms) : Device: x.x.x.x
15.07.2016 09:46:30 (12 ms) : SNMP V2c
15.07.2016 09:46:30 (16 ms) : Custom OID 1.3.6.1.4.1.3375.2.6.1.4.3
15.07.2016 09:46:30 (25 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHINSTANCE
15.07.2016 09:46:30 (30 ms) : -------
15.07.2016 09:46:30 (33 ms) : Value: 223 (No such instance (SNMP error # 223))
15.07.2016 09:46:30 (38 ms) : Done

But using Walk worked, request includes an altered OID.

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 
15.07.2016 09:46:26 (8 ms) : Device: x.x.x.x
15.07.2016 09:46:26 (12 ms) : SNMP V2c
15.07.2016 09:46:26 (16 ms) : Walk 1.3.6.1.4.1.3375.2.6.1.4.3
15.07.2016 09:46:26 (24 ms) : 1.3.6.1.4.1.3375.2.6.1.4.3.0 = "3" [ASN_APP_COUNTER64]

Simply adding a .0 to the end of the OID when I got the 223 error was the trick.
I guess the «.0» has something to do with the data type returned.

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 
15.07.2016 09:57:04 (8 ms) : Device: x.x.x.x
15.07.2016 09:57:04 (11 ms) : SNMP V2c
15.07.2016 09:57:04 (15 ms) : Custom OID 1.3.6.1.4.1.3375.2.6.1.4.3.0
15.07.2016 09:57:04 (22 ms) : SNMP Datatype: ASN_APP_COUNTER64
15.07.2016 09:57:04 (26 ms) : -------
15.07.2016 09:57:04 (30 ms) : Value: 3 (OK)
15.07.2016 09:57:04 (34 ms) : Done

#223
prtg
snmp
solved
walk

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.

Источник

Добрый день!
На тестировании находится Ваш коммутатор: MES2324
Версия:
MES2324-test#show ver
Active-image:

flash://system/images/mes3300-4014-R5.ros

Version: 4.0.14
Commit: ae3f55b3
Build: 5 (master)
MD5 Digest: 712c9569bb9c63159f81212528a51908
Date: 08-Jul-2020
Time: 15:20:28

В методике тестирования есть раздел про SNMP и получение данных по SNMP
“Просмотреть серийный номер модуля SFP, а также информацию DDM с модуля SFP через SNMP на компьютере:
snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.4.1.35265.1.23.53.1.1.1
snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.4.1.89.90.1.2.1.3.57

$ snmpwalk -v2c -c public 10.201.1.59 1.3.6.1.4.1.35265.1.23.53.1.1.1
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.1.57 = INTEGER: 1
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.2.57 = INTEGER: 3
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.3.57 = STRING: «BaseBX10»
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.4.57 = INTEGER: 1550
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.5.57 = STRING: «OEM»
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.6.57 = STRING: «S1C53253000252»
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.7.57 = INTEGER: 65535
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.8.57 = INTEGER: 20000
SNMPv2-SMI::enterprises.35265.1.23.53.1.1.1.9.57 = INTEGER: 1

$ snmpwalk -v2c -c public 10.201.1.59 1.3.6.1.4.1.89.90.1.2.1.3.57
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.5 = INTEGER: 25
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.6 = INTEGER: 3320000
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.7 = INTEGER: 9400
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.8 = INTEGER: -5540
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.9 = INTEGER: -40000
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.10 = INTEGER: 1
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.11 = INTEGER: 1
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.12 = INTEGER: 0
SNMPv2-SMI::enterprises.89.90.1.2.1.3.57.26 = INTEGER: 2
“

Линукса под рукой нет, есть PRTG.

Коммутатор добавлен в PRTG, SNMP комюнити прописаны, Ip адрес PRTG тоже прописан на коммутаторе
Добавляю в ручном режиме сенсор со строкой:
1.3.6.1.4.1.35265.1.23.53.1.1.1.4.57
В идеале должен получить какое-то значение
Но ПРТГ выдает сообщение
No such instance (ошибка SNMP № 223)
Подскажите пожалуйста, я где-то что-то не так пишу или коммутатор с prtg не очень дружит ?

Источник

SNMP Error 223

на
05:18

on четверг, 27 февраля 2014 г.

При добавлении нового сенсора (snmpcustomsensor) в PRTG столкнулся с ошибкой «No such instance (SNMP error # 223)«. Методом тыка нашел решение — к OID нужно добавить ноль.

Например, есть значение OID 1.3.6.1.4.1.9.2.1.46 (Cisco bufferFail). Для того чтобы PRTG его схавало, нужно писать 1.3.6.1.4.1.9.2.1.46.0

Откуда берется этот нолик? Проверяем значение snmpwalk’ом
snmpwalk -v1 -c public 192.168.1.1 1.3.6.1.4.1.9.2.1.46
iso.3.6.1.4.1.9.2.1.46.0 = INTEGER: 3900003

I am able to retrieve the SNMP information RFC1213-mib using the SnmpB tool but when I add these variables to the PRTG I get No such instance (SNMP error # 223) errors messages.

I have tried using auto discovery and manually adding the OIDs 1.3.6.1.2.1.2.2.1.8 and none of them work.

This is what is retrieved by the SnmpB tool.

1: sysDescr.0 Raven XE EV-DO
2: sysObjectID.0 airlink.12.20
3: sysUpTimeInstance 7:18:54.22
4: sysContact.0 
5: sysName.0 
6: sysLocation.0 
7: sysServices.0 76
8: ifNumber.0 1
9: ifIndex.1 1
10: ifDescr.1 Sierra Wireless Ethernet Port
11: ifType.1 ethernetCsmacd(6)
12: ifMtu.1 1500
13: ifSpeed.1 100000000
14: ifPhysAddress.1 00:14:3e:04:01:26
15: ifAdminStatus.1 up(1)
16: ifOperStatus.1 up(1)
17: ifInOctets.1 4000317
18: ifOutOctets.1 3394212

mib2
prtg
snmp

SNMP Error 223

на
05:18

on четверг, 27 февраля 2014 г.

Например, есть значение OID 1.3.6.1.4.1.9.2.1.46 (Cisco bufferFail). Для того чтобы PRTG его схавало, нужно писать 1.3.6.1.4.1.9.2.1.46.0

I am able to retrieve the SNMP information RFC1213-mib using the SnmpB tool but when I add these variables to the PRTG I get No such instance (SNMP error # 223) errors messages.

I have tried using auto discovery and manually adding the OIDs 1.3.6.1.2.1.2.2.1.8 and none of them work.

This is what is retrieved by the SnmpB tool.

1: sysDescr.0 Raven XE EV-DO
2: sysObjectID.0 airlink.12.20
3: sysUpTimeInstance 7:18:54.22
4: sysContact.0 
5: sysName.0 
6: sysLocation.0 
7: sysServices.0 76
8: ifNumber.0 1
9: ifIndex.1 1
10: ifDescr.1 Sierra Wireless Ethernet Port
11: ifType.1 ethernetCsmacd(6)
12: ifMtu.1 1500
13: ifSpeed.1 100000000
14: ifPhysAddress.1 00:14:3e:04:01:26
15: ifAdminStatus.1 up(1)
16: ifOperStatus.1 up(1)
17: ifInOctets.1 4000317
18: ifOutOctets.1 3394212

mib2
prtg
snmp

О деактивации форума Eltex

Уважаемые коллеги! В связи с потерей актуальности данного ресурса, нами было принято решение о частичной деактивации форума Eltex. Мы отключили функции регистрации и создания новых тем, а также возможность оставлять сообщения. Форум продолжит работу в «режиме чтения», так как за долгие годы работы здесь накопилось много полезной информации и ответов на часто встречающиеся вопросы.

Мы активно развиваем другие каналы коммуникаций, которые позволяют более оперативно и адресно консультировать наших клиентов. Если у вас возникли вопросы по работе оборудования, вы можете обратиться в техническую поддержку Eltex, воспользовавшись формой обращения на сайте компании или оставить заявку в системе Service Desk. По иным вопросам проконсультируют наши менеджеры коммерческого отдела:

eltex@eltex-co.ru

xneo: Сообщения: 15; Зарегистрирован: 13 янв 2016 21:35; Reputation: 0

MES3124F / SNMP

Здравствуйте.

Мониторим коммутатор MES3124F с помощью SNMP / Paessler PRTG. Несколько сенсоров, включая трафик, uptime, загрузку CPU. Почему-то в среднем раз в час при запросе загрузки CPU коммутатор возвращает ошибку «No such instance (ошибка SNMP № 223)». Как минимум об этом сообщает PRTG (сниффером не смотрели пока). Остальные сенсоры запрашиваются нормально. Рядом стоит MES3324F, мониторится так же, ошибок нет.

P.S.: SW version 2.5.48.2[9521e00c] ( date 26-Jun-2018 time 10:35:26 )

xneo: Сообщения: 15; Зарегистрирован: 13 янв 2016 21:35; Reputation: 0

Re: MES3124F / SNMP

Сообщение xneo » 09 янв 2019 01:03

Проверил сниффером, видно ответ коммутатора с ошибкой.

Нашёл схожую тему на форуме

viewtopic.php?t=6411

.
Очень похоже на наш случай.

: 2019-01-08_200149.png (10.52 КБ) 1554 просмотра

Евгений Т: Сообщения: 1613; Зарегистрирован: 18 мар 2013 09:48; Reputation: 7; Откуда: Элтекс

Re: MES3124F / SNMP

Сообщение Евгений Т » 10 янв 2019 09:48

Здравствуйте.

Проблема известная. Прошу сообщить в ЛС название Вашей организации и критичность проблемы для Вас.

Вернуться в «Коммутаторы и маршрутизаторы Ethernet»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей

Hi,

I’m referring to an older question of another User in this Forum (http://www.lansweeper.com/Forum/yaf_postst11320findunread_Any-way-of-debugging-SNMP-v3-queries.aspx#post42246)

We encountered a similar problem, that our Alcatel Switches are not able to be scanned via SNMP v3 through Lansweeper. Even the device-Tester is not able to get a reply from those devices. We double-checked everything, authentication, connection and even with a secondary tool (Paessler) to check if anything is possible.

First thing we found with Paessler:

1.3.6.1.2.1.1.2.0 works
1.3.6.1.2.1.1.2 not

———————— New Test ————————
Paessler SNMP Tester 5.2.3 Computername: xxxxxx Interface: (10.XX.X.50)
04.01.2017 14:27:20 (22 ms) : Device: 10.XX.XXX.11
04.01.2017 14:27:20 (49 ms) : SNMP V3
04.01.2017 14:27:20 (54 ms) : Custom OID 1.3.6.1.2.1.1.2
04.01.2017 14:27:20 (183 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHINSTANCE
04.01.2017 14:27:20 (193 ms) : ——-
04.01.2017 14:27:20 (216 ms) : Value: No such instance (SNMP error # 223)
04.01.2017 14:27:20 (220 ms) : Done

———————— New Test ————————
Paessler SNMP Tester 5.2.3 Computername: xxxxxx Interface: (10.XX.X.50)
04.01.2017 14:27:25 (19 ms) : Device: 10.XX.XXX.11
04.01.2017 14:27:25 (29 ms) : SNMP V3
04.01.2017 14:27:25 (39 ms) : Custom OID 1.3.6.1.2.1.1.2.0
04.01.2017 14:27:25 (151 ms) : SNMP Datatype: ASN_OBJECT_ID
04.01.2017 14:27:25 (157 ms) : ——-
04.01.2017 14:27:25 (163 ms) : Value: 1.3.6.1.4.1.6486.800.1.1.2.1.10.1.6
04.01.2017 14:27:25 (169 ms) : Done

Paessler shows that the Custom OID used by Lansweeper device-tester seems to be incorrect / not showing a result. The same OID added with a «.0» gives the result desired.

We already had contact via EMail to Lansweeper support but ended in «Please monitor the traffic between Lansweeper and the device with Wireshark» that then has been too much hassle for us. As shown above the main thing might be the OID.

Would someone be able to assist us in this matter? Could it be that the device-tester needs to be changed / fixed?

Another, second problem:
When those switches are stacked they will be recognized as ONE Element only (we did this with SNMPv2) and if you try to enter the stacks manually they will be merged to the master (without adding hardware-information / serial-no., etc.) to the lansweeper database afterwards.

Is there a chance to get at least the details of the merged element(s) to the entry of the stack?

Thanks in advance for any help,
Martin!

Hi,

I try it, but i have some errors. I’m trying to query data from my fortigate.
I get these errors:

/opt/splunk/etc/apps/snmp_ta/bin/snmp.py" Traceback (most recent call last):
/opt/splunk/etc/apps/snmp_ta/bin/snmp.py"   File "/opt/splunk/etc/apps/snmp_ta/bin/snmp.py", line 492, in <module>
/opt/splunk/etc/apps/snmp_ta/bin/snmp.py"     do_run()
/opt/splunk/etc/apps/snmp_ta/bin/snmp.py"   File "/opt/splunk/etc/apps/snmp_ta/bin/snmp.py", line 316, in do_run
/opt/splunk/etc/apps/snmp_ta/bin/snmp.py"     lookupNames=True, lookupValues=True)
/opt/splunk/etc/apps/snmp_ta/bin/snmp.py" UnboundLocalError: local variable 'oid_args' referenced before assignment

In my splunk index:

FORTINET-FORTIGATE-MIB::fgSysCpuUsage."" = "No Such Instance currently exists at this OID" 
FORTINET-CORE-MIB::fnSysSerial."" = "No Such Instance currently exists at this OID"

With MibViewer I have received the snmp reply:

Send snmp get request to x.x.x.x:161
.1.3.6.1.4.1.12356.100.1.1.1.0 (not in loaded mib files) --> FG600C3912801998

Send snmp get request to x.x.x.x1:161
.1.3.6.1.4.1.12356.101.4.1.3.0 (not in loaded mib files) --> 0

О деактивации форума Eltex

eltex@eltex-co.ru

xneo: Сообщения: 15; Зарегистрирован: 13 янв 2016 21:35; Reputation: 0

MES3124F / SNMP

Здравствуйте.

P.S.: SW version 2.5.48.2[9521e00c] ( date 26-Jun-2018 time 10:35:26 )

xneo: Сообщения: 15; Зарегистрирован: 13 янв 2016 21:35; Reputation: 0

Re: MES3124F / SNMP

Сообщение xneo » 09 янв 2019 01:03

Проверил сниффером, видно ответ коммутатора с ошибкой.

Нашёл схожую тему на форуме

viewtopic.php?t=6411

.
Очень похоже на наш случай.

: 2019-01-08_200149.png (10.52 КБ) 1557 просмотров

Евгений Т: Сообщения: 1613; Зарегистрирован: 18 мар 2013 09:48; Reputation: 7; Откуда: Элтекс

Re: MES3124F / SNMP

Сообщение Евгений Т » 10 янв 2019 09:48

Здравствуйте.

Проблема известная. Прошу сообщить в ЛС название Вашей организации и критичность проблемы для Вас.

Вернуться в «Коммутаторы и маршрутизаторы Ethernet»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость

Hi,

I’m referring to an older question of another User in this Forum (http://www.lansweeper.com/Forum/yaf_postst11320findunread_Any-way-of-debugging-SNMP-v3-queries.aspx#post42246)

First thing we found with Paessler:

1.3.6.1.2.1.1.2.0 works
1.3.6.1.2.1.1.2 not

Paessler shows that the Custom OID used by Lansweeper device-tester seems to be incorrect / not showing a result. The same OID added with a «.0» gives the result desired.

Would someone be able to assist us in this matter? Could it be that the device-tester needs to be changed / fixed?

Is there a chance to get at least the details of the merged element(s) to the entry of the stack?

Thanks in advance for any help,
Martin!

Источник

Hi there,

Device : 1500D

Firmware : 5.0.12

Background. I do an auto discovery of interfaces though SNMP on a weekly basis to update monitoring on any new customers being provisioned and provide visibility on these new interfaces. I removed an IPSec tunnel that was not longer in use the other day and this seems to have caused a problem on SNMP Walks on the device. When I now query this SNMP interface index that was removed it returns a Generic error (#5) this halts the SNMP walk as opposed to a No such instance (SNMP Error #223) for when such an index does not exist.

I went and tracked down this SNMP index in backups of the firewall from before this IPSec was removed and it seems to be the only instance thereof for this index number. Below is what the SNMP outputs for that specific OID. The below is just for the query on the Interface index values, If I query a different interface value such as MTU on that interface index it returns a NO_SUCH_Instance which is correct. Any ideas? Would changing a unused interface to SNMP Index 341 potentially resolve this problem.

Thanks in Advance,

Gus

———————— New Test ————————
Paessler SNMP Tester 5.2.1
3/1/2016 5:08:33 PM (9 ms) : Device:
3/1/2016 5:08:33 PM (13 ms) : SNMP V2c
3/1/2016 5:08:33 PM (20 ms) : Custom OID 1.3.6.1.2.1.2.2.1.1.340
3/1/2016 5:08:33 PM (29 ms) : SNMP Datatype: ASN_INTEGER
3/1/2016 5:08:33 PM (34 ms) : ——-
3/1/2016 5:08:34 PM (38 ms) : Value: 340
3/1/2016 5:08:34 PM (42 ms) : Done

———————— New Test ————————
Paessler SNMP Tester 5.2.1
3/1/2016 5:08:37 PM (9 ms) : Device:
3/1/2016 5:08:37 PM (12 ms) : SNMP V2c
3/1/2016 5:08:37 PM (17 ms) : Custom OID 1.3.6.1.2.1.2.2.1.1.341
3/1/2016 5:08:37 PM (25 ms) : SNMP Datatype: ASN_PRIMITIVE
3/1/2016 5:08:37 PM (29 ms) : ——-
3/1/2016 5:08:37 PM (32 ms) : Value: Generic Error (SNMP error # 5)
3/1/2016 5:08:37 PM (36 ms) : Done

———————— New Test ————————
Paessler SNMP Tester 5.2.1
3/1/2016 5:10:52 PM (8 ms) : Device:
3/1/2016 5:10:52 PM (11 ms) : SNMP V2c
3/1/2016 5:10:52 PM (15 ms) : Custom OID 1.3.6.1.2.1.2.2.1.1.342
3/1/2016 5:10:52 PM (23 ms) : SNMP Datatype: ASN_INTEGER
3/1/2016 5:10:52 PM (27 ms) : ——-
3/1/2016 5:10:52 PM (31 ms) : Value: 342
3/1/2016 5:10:52 PM (34 ms) : Done

———————— New Test ————————
Paessler SNMP Tester 5.2.1
3/1/2016 5:11:01 PM (8 ms) : Device:
3/1/2016 5:11:01 PM (13 ms) : SNMP V2c
3/1/2016 5:11:01 PM (18 ms) : Custom OID 1.3.6.1.2.1.2.2.1.1.560
3/1/2016 5:11:01 PM (26 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHINSTANCE
3/1/2016 5:11:01 PM (29 ms) : ——-
3/1/2016 5:11:01 PM (33 ms) : Value: No such instance (SNMP error # 223)
3/1/2016 5:11:01 PM (37 ms) : Done

Источник

C-29

Cisco IOS Software Configuration Guide for Cisco Aironet Access Points

OL-30644-01

AppendixC Error and Event Messages

SNMP Error Messages

Error Message SENSOR-3-VOLT_NORMAL: System sensor “d”(“d”) is now operating under

NORMAL voltage

Explanation One of the measured environmental test points is under normal

operating voltage.

Recommended Action None.

Error Message SENSOR-3-VOLT_WARNING: Voltage monitor “d”(“d”) has exceeded voltage

thresholds

Explanation One of the measured voltage test points indicates that voltage is out of normal range.

Explanation Check Power Supplies or contact TAC

SNMP Error Messages

Error Message SNMP-3-AUTHFAILIPV6: Authentication failure for SNMP request from

hostUnrecognized format ‘ %P’

Explanation An SNMP request was sent by this host which was not properly authenticated.

Recommended Action Make sure that the community/user name used in the SNMP req has been

configured on the router.

Error Message SNMP-3-INPUT_QFULL_ERR: Packet dropped due to input queue full

Explanation Snmp packet dropped due to input queue full error

Recommended Action Use the command show snmp to see the number of packets dropped. Stop any

SNMP access to the device until the error condition is recovered.

Error Message SNMP-3-INTERRUPT_CALL_ERR: “s” function, cannot be called from

interrupt handler

Explanation This message indicates that a call has been made to the function from an interrupt

handler. This is not permitted because it will fail and device will reboot down the stack in malloc

call.

Recommended Action If this messages recurs, copy it exactly as it appears and report it to your

technical support representative.

Источник