Есть компьютер на базе LinuxMint 8.1
IP 172.16.250.46
тестовый D-link DES-3028
IP 10.142.240.1 с поддержкой SNMP — настройки SNMP по умолчанию + для теста добавлено community = secret
сеть из примерно 1000 длинков с преконфигурированным SNMP, а именно community public и private на оборудовании отсутствуют, прописаны trustedhost`ы
требуется настроить SNMP-мониторинг сетевого оборудования D-link
установлен из репозитория net-snmp Version: 5.4.1
команда
Код: Выделить всё
yena@crazy ~ $ snmpwalk -v 2c -c public 10.142.240.1выдает кучу бакавок и циферок)
Код: Выделить всё
yena@crazy ~ $ snmpwalk -v 2c -c secret 10.142.240.1
Timeout: No Response from 10.142.240.1В тоже время переходим к компьютеру с OC WindowsXP с помощью родной утилиты D-view и ключа secret получаем доступ к девайсу des3028 10.142.240.1
Доступ к остальным девайсам сети по SNMP из под WIN происходит без проблем при условии наличия IP компьютера в таблице довереных хостов. (подопытные компы оба по умолчанию в этой таблице)
далее
правим файлик /etc/default/snmpd
добиваемся такого результата:
Код: Выделить всё
yena@crazy ~ $ sudo netstat -nlp| grep snmpd
udp 0 0 0.0.0.0:161 0.0.0.0:* 19302/snmpd
yena@crazy ~ $ sudo ps ax | grep snmpd
19302 ? S 0:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid
19805 pts/0 R+ 0:00 grep --colour=auto snmpdфаерволл отключен
после манипуляций получаем аналогичный предыдущему результат (
идем на сервер под FreeBSD с установленным по умолчанию NET-snmp получаем результат аналогичный Linux — машине = с ключем по умолчанию public SNMP работает, с ключем secret нет.
Куда копать?
I am trying to monitor network devices in our company using SCOM. So far the devices are not responding to SNMP request. These devices support SNMP. Firewall is not an issue since the monitoring server is already in the company’s network. Trying the command below gave the following result for one device:
~$ snmpget -v 1 -c ro345iu5672 11.248.154.10 .1.3.6.1.2.1.1.1.0
Timeout: No Response from 11.248.154.10.
Additional research suggested that the target SNMP device needs to enable the whole system MIB/OID-tree to be discoverable in SCOM. If any of the following OIDs are missing, you will not be able to discover the device:
• 1.3.6.1.2.1.1.1.0 --> system.sysDescr
• 1.3.6.1.2.1.1.2.0 --> system.sysObjectID
• 1.3.6.1.2.1.1.4.0 --> system.sysContact
• 1.3.6.1.2.1.1.5.0 --> system.sysName
• 1.3.6.1.2.1.1.6.0 --> system.sysLocation
How can I enable these OID’s for a network device?
asked May 12, 2016 at 10:21
1
There is pretty simple scenario to access device via SNMP and get information you want.
-
Enable SNMP on the device, select SNMP version (v1, v2c, v3), set read/write community (it’s like «password» in SNMP)
-
Find out MIB file for that device vendor/product(usually developers include .mib files with firmware versions/updates)
-
Check exactly what that device can «tell» you via SNMP (check MIB file), it’s usually easier to do with some software like Castle Rock SNMPc Network Manager or some else products, that can «scan» device using IP address, mib file, and communities you wrote in. (yeah, this is for win* systems, but I’m pretty sure there is *nix alternatives).
After you have found what exactly you need to know — you will know OID, and should use the command you wrote above to get info you need.
Now, responding for your situation. I guess you should do steps in this order:
-
Check network connection to this device (if we are assuming that ping is working — than you should use check 161 port as mentioned above by Orlando.)
-
Check that your device have SNMP=enabled in configuration. Check SNMP version and communities.
-
Check that your device know something about OID you are writing there (but I guess it’s not the case cause there should be some respond at all, even with wrong OID. imo.)
answered May 12, 2016 at 11:52
6
You probarly need to enable SNMP on your devices, with the correct community, unless you do that, no response could be received by your SCOM. If you already done this, then you can check on the logs of your devices to see if SNMP request are received, and some kind of error, if happens. It is not, you need to check if the SNMP default port, 161, are been filtered in some place. Remember, this is only a global answer, every equipment have it owns steps to configure SNMP. If yow can’t resolve, you can edit your question and put devices model.
answered May 12, 2016 at 11:02
- Board index ‹ Community Support Forums For Nagios Open Source Projects ‹ Open Source Nagios Projects
Commercial Support Clients: Clients with support contracts can get escalated support assistance by visiting Nagios Answer Hub. These forums are for community support services. Although we at Nagios try our best to help out on the forums here, we always give priority support to our support clients.
SNMPWALK — TimeOut: No Response from address
I am running Nagios Core 4.2.2
snmpwalk on the localhost returns information on MIB.
snmpwalk run against a switch with snmp turned on returns a timeout message.
All thing being equal shouldn’t I get some response besides timeout?
# snmpwalk -v 1 -c public localhost
SNMPv2-MIB::sysDescr.0 = STRING: Linux nagios.mynetwork.local 2.6.32-642.el6.x86_64
(the rest remove to save space)
# snmpwalk -v 1 -c public 10.30.25.11
Timeout: No Response from 10.30.25.11
# yum list installed
net-snmp.x86_64 1:5.5-60.el6 @base
net-snmp-libs.x86_64 1:5.5-60.el6 @base
net-snmp-perl.x86_64 1:5.5-60.el6 @base
net-snmp-utils.x86_64 1:5.5-60.el6 @base
(the rest remove to save space)
Thanks for any guidance
~hbackus
-
hbackus - Posts: 36
- Joined: Tue May 17, 2011 5:02 pm
Re: SNMPWALK — TimeOut: No Response from address
by cdienger » Mon Jul 02, 2018 11:24 am
Yes, you should be getting a response assuming everything is equal.
Is the device only doing v1? 2c is pretty common and I’d try running the command with the «-v 2c» option as well.
There could also be a firewall between the devices preventing communication over UDP port 161. Can you verify on the end device if the SNMP traffic is even making it over?
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
-
cdienger - Support Tech
- Posts: 5044
- Joined: Tue Feb 07, 2017 11:26 am
Re: SNMPWALK — TimeOut: No Response from address
by hbackus » Mon Jul 02, 2018 3:07 pm
Thanks for the kind response. Here is what I have uncovered so far.
It is obvious at this point that I do not know all the ins and outs on setting up SNMP.
Telling snmpwalk to use version 1 or version 2c does not change the message from the Nagios server running snmpwalk. «Timeout: No response from (ip_address)».
There is no firewall between the systems but they are on separate LAN segments.
I setup a packet capture on a span port for the server and I see the SNMP “get-next-request” made by the Nagios snmpwalk command.
I also see a return frame with «Error-status (no-error)» in the «SNMP data section» of the capture.
So if the request is going out and the reply is coming back, what would I have miss-configured or failed to configure for SNMP at the Nagios server that would cause “Timeout: No response from (ip_address)” to occurr?
-
hbackus - Posts: 36
- Joined: Tue May 17, 2011 5:02 pm
Re: SNMPWALK — TimeOut: No Response from address
by cdienger » Tue Jul 03, 2018 10:47 am
I would take a closer look at the resposne. Try the following on XI’s command like to get a packet capture:
yum -y install tcpdump
tcpdump -s 0 -i any host 10.30.25.11 -w output.pcap
Let this run just long enough to run the snmpwalk command and then use CTRL+C to stop it. output.pcap can be viewed with wireshark and you can also PM it to me if you’d like a second pair of eyes to take a look.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
-
cdienger - Support Tech
- Posts: 5044
- Joined: Tue Feb 07, 2017 11:26 am
Re: SNMPWALK — TimeOut: No Response from address
by cdienger » Fri Jul 06, 2018 9:14 am
Thanks for the tcpdump. The behavior it shows is strange.
First XI sends a snmpwalk request from source port 53373 to destination port 161 — so far so good
The destination appears to react to the request but not in an expected way and one that would produce the error message. Instead of sending a response to XI on port 53373, it sends XI a SNMP Trap on port 162 — This is the problem. In order for the SNMPWALK to work the destination should respond with a SNMP get-response message on port 53373 and not a snmpV2-trap message on port 162.’
You can see valid SNMP traffic with the example at
https://wiki.wireshark.org/SampleCaptures#SNMP
.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
-
cdienger - Support Tech
- Posts: 5044
- Joined: Tue Feb 07, 2017 11:26 am
Re: SNMPWALK — TimeOut: No Response from address
by hbackus » Fri Jul 06, 2018 11:17 am
OK, thanks.
I will look into it and update when I can.
-
hbackus - Posts: 36
- Joined: Tue May 17, 2011 5:02 pm
Re: SNMPWALK — TimeOut: No Response from address
by cdienger » Fri Jul 06, 2018 12:22 pm
Sounds good. We’ll be here 
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
-
cdienger - Support Tech
- Posts: 5044
- Joined: Tue Feb 07, 2017 11:26 am
Re: SNMPWALK — TimeOut: No Response from address
by hbackus » Fri Jul 06, 2018 3:27 pm
If you like weird, I may have just the thing for you.
I made no changes to the Nagios Core server.
I went to the switch I was running snmpwalk against and added a config line that said the snmp client was the Nagios server.
No change, the snmpwalk still timed out with no response as the error message.
I removed all the snmp configuration lines in the switch and then added them back in (in reverse order).
The configuration on the switch still showed the entries in the same order as before.
I ran snmpwalk and got a response.
SNMPv2-MIB::sysDescr.0 = STRING: Brocade Communications Systems, Inc.
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.1991.1.3.48.5.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1829683300) 211 days, 18:27:13.00
[lines removed for brevity]
SNMPv2-SMI::mib-2.192.1.1.1.0 = Gauge32: 50
SNMPv2-SMI::mib-2.192.1.1.2.0 = INTEGER: 2
Not sure if I needed all the lines in the configuration of the switch or not or if just removing them and adding them back “bumped” snmp enough that it started working.
I have about 15 more switch stacks to try this on, but I am leaving this one as is.
Thanks for your time and efforts. You can lock this thread down if you like.
-
hbackus - Posts: 36
- Joined: Tue May 17, 2011 5:02 pm
Re: SNMPWALK — TimeOut: No Response from address
by cdienger » Fri Jul 06, 2018 4:08 pm
I’ll take weird as long as it’s resolved
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
-
cdienger - Support Tech
- Posts: 5044
- Joined: Tue Feb 07, 2017 11:26 am
Return to Open Source Nagios Projects
Who is online
Users browsing this forum: Fess [Nagios Bot] and 10 guests
Прежде чем добавлять в zabbix или другие средства мониторинга необходимо проверить значения через snmpwalk или snmpget. При этом на коммутаторах Alcatel вы можете обнаружить следующую ошибку:
Timeout: No Response from 10.20.30.40
Первоначально проверим настройки snmp:
-> show configuration snapshot snmp ! SNMP : snmp security no security snmp authentication trap enable snmp community map «public» user «snmpuser» on
Если у Вас уже вписаны такие же настройки, но snmpwalk продолжает выдавать ошибку, необходимо проверить наличие пользователя snmpuser и его настройки:
-> show user User name = admin, Password expiration = None, Password allow to be modified date = None, Account lockout = None, Password bad attempts = 1, Read Only for domains = None, Read/Write for domains = All , Snmp allowed = NO, Console-Only = Disabled User name = default (*), Password expiration = None, Password allow to be modified date = None, Account lockout = None, Password bad attempts = 0, Read Only for domains = None, Read/Write for domains = None, Snmp allowed = NO, Console-Only = Disabled, (*)Note: The default user is not an active user account. It constains the default user account settings, for new user accounts.
В данном примере snmpuser отсутствует, приступим к его созданию и настройке:
-> user snmpuser password PA$$WORD no auth -> user snmpuser read-only all
без использования no auth snmp не сработает
Теперь проверим, что пользователь создан верно:
-> show user User name = admin, Password expiration = None, Password allow to be modified date = None, Account lockout = None, Password bad attempts = 1, Read Only for domains = None, Read/Write for domains = All , Snmp allowed = NO, Console-Only = Disabled User name = default (*), Password expiration = None, Password allow to be modified date = None, Account lockout = None, Password bad attempts = 0, Read Only for domains = None, Read/Write for domains = None, Snmp allowed = NO, Console-Only = Disabled, (*)Note: The default user is not an active user account. It constains the default user account settings, for new user accounts. User name = snmpuser, Password expiration = None, Password allow to be modified date = None, Account lockout = None, Password bad attempts = 0, Read Only for domains = All , Read/Write for domains = None, Snmp allowed = YES, Snmp authentication = NONE, Snmp encryption = NONE, Console-Only = Disabled
Проверим, получение данных:
root@xak:~# snmpwalk -v 2c -c public 124.42.30.15 1.3.6.1.4.1.6486.800.1.2.1.33.1.1.1.1.1.2 SNMPv2-SMI::enterprises.6486.800.1.2.1.33.1.1.1.1.1.2.1 = INTEGER: 1 SNMPv2-SMI::enterprises.6486.800.1.2.1.33.1.1.1.1.1.2.2 = INTEGER: 1
Все. Теперь можно спокойно получать данные по snmp с коммутатора
I have implemented AgentX using mib2c.create-dataset.conf ( with cache enabled)
In my snmd.conf :: agentXTimeout 15
In testtable.h file I have changed cache value as below…
#define testTABLE_TIMEOUT 60
According to my understanding It loads data every 60 second.
Now my issue is if the data in data table is exceeds some amount it takes some amount of time to load it.
As in between If I fired SNMPWALK it gives me “no response from the host” If I use SNMPWALK for whole table and in between testTABLE_TIMEOUT occurs it stops in between and shows following error (no response from the host).
Please tell me how to solve it ? In my table large amount of data is present and changing frequently.
I read some where:
(when the agent receives a request for something in this table and the cache is older than the defined timeout (12s > 10s), then it does re-load the data. This is the expected behaviour.
However the agent does not automatically release the local cache (i.e. call the ‘free’ routine) as soon as the timeout has expired.
Instead this is handled by a regular «garbage collection» run (once a minute), which will free any stale caches.
In the meantime, a request that tries to use that cache will spot that it’s expired, and reload the data.)
Is there any connection between these two ?? I can’t get this… How to resolve my problem ???
- Печать
Страницы: [1] Вниз
Тема: Проблема с SNMP. Snmpwalk -> Timeout: No Response from localhost (Прочитано 5593 раз)
0 Пользователей и 1 Гость просматривают эту тему.
sNick
Snmpwalk не возвращает никаких значений. Для тестов использовал OID System Uptime .1.3.6.1.2.1.1.3.0
user@02:/$ snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.1.3.0
Timeout: No Response from localhost
Tcpdump выдаёт следующее:
user@02:/$ sudo tcpdump -i any -n -v -s 0 host localhost and port 161
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 6553 5 bytes
19:01:04.628329 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
127.0.0.1.54717 > 127.0.0.1.161: { SNMPv2c C=public { GetNextRequest(28) R =1538628062 .1.3.6.1.2.1.1.3.0 } }
19:01:05.629527 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
127.0.0.1.54717 > 127.0.0.1.161: { SNMPv2c C=public { GetNextRequest(28) R =1538628062 .1.3.6.1.2.1.1.3.0 } }
19:01:06.630515 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
127.0.0.1.54717 > 127.0.0.1.161: { SNMPv2c C=public { GetNextRequest(28) R =1538628062 .1.3.6.1.2.1.1.3.0 } }
19:01:07.631369 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
127.0.0.1.54717 > 127.0.0.1.161: { SNMPv2c C=public { GetNextRequest(28) R =1538628062 .1.3.6.1.2.1.1.3.0 } }
19:01:08.632328 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
127.0.0.1.54717 > 127.0.0.1.161: { SNMPv2c C=public { GetNextRequest(28) R =1538628062 .1.3.6.1.2.1.1.3.0 } }
19:01:09.633532 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
127.0.0.1.54717 > 127.0.0.1.161: { SNMPv2c C=public { GetNextRequest(28) R =1538628062 .1.3.6.1.2.1.1.3.0 } }
Порт не блокирован.
user@02:/$ sudo nmap -sU localhost -p 161
Starting Nmap 6.00 ( http://nmap.org ) at 2013-10-23 18:19 MSK
Nmap scan report for localhost (127.0.0.1)
Host is up.
Other addresses for localhost (not scanned): 127.0.0.1
PORT STATE SERVICE
161/udp open|filtered snmp
Содержание snmpd.conf следующее
cat /etc/snmp/snmpd.conf
rocommunity public
А в /etc/default/snmpd такое
# This file controls the activity of snmpd and snmptrapd
# Don’t load any MIBs by default.
# You might comment this lines once you have the MIBs downloaded.
export MIBS=/usr/share/snmp/mibs# snmpd control (yes means start daemon).
SNMPDRUN=yes# snmpd options (use syslog, close stdin/out/err).
#SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid’
SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf’# snmptrapd control (yes means start daemon). As of net-snmp version
# 5.0, master agentx support must be enabled in snmpd before snmptrapd
# can be run. See snmpd.conf(5) for how to do this.
TRAPDRUN=no# snmptrapd options (use syslog).
TRAPDOPTS=’-Lsd -p /var/run/snmptrapd.pid’# create symlink on Debian legacy location to official RFC path
SNMPDCOMPAT=yes
Snmp пакеты стоят такие
user@02:/$ sudo apt-show-versions | grep snmp
libsnmp-base/wheezy uptodate 5.4.3~dfsg-2.7
libsnmp15/wheezy uptodate 5.4.3~dfsg-2.7
snmp/wheezy uptodate 5.4.3~dfsg-2.7
snmpd/wheezy uptodate 5.4.3~dfsg-2.7
Debian 7.2 установлен.
Подскажите куда рыть? Напрочь не вижу нигде ошибки 
.
« Последнее редактирование: 23 Октября 2013, 16:50:30 от sNick »
Alexander1977
пишу для себя, т.к. с большой вероятностью опять попаду в такую историю 
непустой дамп не гарантирует что порт не заблокирован, в моем случае всем виной был DROP в iptables
- Печать
Страницы: [1] Вверх