LINUX.ORG.RU
Форум — Admin  

перезагрузка свича с помошью SNMP

 , ,


0

1

Хочу иметь возможность перегружать свитч по крону. В его веб морде это можно задать только один раз, неудобственно каждыйр раз взводить. ТП посоветовала SNMP.

Скачал mib, нашел oid нужный делаю (ВНИМАНИЕ) из сетки 172.16.0.0/24 через VPN:

 snmpget -c public -v 2c 172.16.15.241 .1.3.6.1.4.1.171.10.76.29.1.4.2.0
SNMPv2-SMI::enterprises.171.10.76.29.1.4.2.0 = INTEGER: 2

Делаю тоже самое с Linux в его же сетке 172.16.15.0/24 

 snmpget -c public -v 2c 172.16.15.241 .1.3.6.1.4.1.171.10.76.29.1.4.2.0
Timeout: No Response from 172.16.15.241.

Фаервол исключен, сканирую порт nmap, все открыто 

 nmap -sU 172.16.15.241
...
PORT    STATE SERVICE
161/udp open  snmp

Почему не отвечает и отваливается по таймауту, что я делаю не так? Пните в нужном направлении.

★★★★

Фаервол исключен

Точно? Конфиг свича сам писал, или кто-то? Как правило там сразу список допустимых IP задаётся. Или там по-умолчанию всем всё можно?

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Точно?

Я же кинул результаты сканирования nmap

Конфиг свича сам писал, или кто-то?

Да какой там конфиг, он с коропки! имя прописал да ip назначил в настройки SNMP не лазил даже, но проверил никаких фильтров не нашел. Но через vpn отвечает, а своей сетке нет... отваливается по таймауту.

свич Dlink DGS-1210-52/ME почти весь забит кордами, раза 2-3 вис напрочь, обновил прошивку, ТП говорит, что должно помочь, как обычно выкинули на рынок сыроватый продукт, но хотелось бы иметь инструмент.

alex_sim ★★★★
() автор топика
Последнее исправление: alex_sim (всего исправлений: 1)
Ответ на: комментарий от alex_sim

Я же кинул результаты сканирования nmap

Это ровным счётом ничего не значит. Посмотри tcpdump-ом трафик в обоих случаях. nmap просто проверяет доступность порта, а snmpget не дожидается ответа на snmp-запрос. А вот почему не дожидается, это надо понять: то ли он не долетает, то ли его не отправляют. Хотя, если nmap открытый порт видит, долетать должно.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Посмотри tcpdump-ом трафик в обоих случаях.

Да вот что то не соображу, на каком интерфейсе то смотреть

запрос с 172.16.1.100 к 172.16.15.241 через vpn 10.1.15.2-10.1.15.1 ну хрен с ним тут то как раз работает.

а вот запрос с 172.16.15.100 к 172.16.15.241 

tcpdump -n -i p1p1| grep 172.16.15.241
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p1p1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:48:55.620920 IP 172.16.15.100.36073 > 172.16.15.241.snmp:  GetRequest(34)  .1.3.6.1.4.1.171.10.76.29.1.4.2.0
12:48:55.624086 IP 172.16.15.241.snmp > 172.16.15.100.36073:  GetResponse(35)  .1.3.6.1.4.1.171.10.76.29.1.4.2.0=2

Дак вроде и тут работает, а почему ответа не вижу?!?!

Timeout: No Response from 172.16.15.241.
alex_sim ★★★★
() автор топика
Последнее исправление: alex_sim (всего исправлений: 1)
Ответ на: комментарий от alex_sim

а вот на туннеле глянул

 tcpdump -n -i tun0|grep 172.16.15.241
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
13:03:31.317284 IP 10.1.15.2.32921 > 172.16.15.241.snmp:  GetRequest(34)  .1.3.6.1.4.1.171.10.76.29.1.4.2.0
13:03:31.320507 IP 172.16.15.241.snmp > 10.1.15.2.32921:  GetResponse(35)  .1.3.6.1.4.1.171.10.76.29.1.4.2.0=2

Тоже все шоколадно вроде, но в одном случае естьрезультат а в другом нет.

alex_sim ★★★★
() автор топика
Ответ на: комментарий от AS

Тут уже копай линуксовый хост. Явно ответ пришёл. -e добавь, вдруг не на тот MAC летит.

и тут и там линукс

Явно ответ пришёл. -e добавь, вдруг не на тот MAC летит.

 tcpdump -e -n -i p1p1| grep 172.16.15.241
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p1p1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:09:21.151685 00:40:f4:6b:e3:e5 > 18:0f:76:62:04:2e, ethertype IPv4 (0x0800), length 91: 172.16.15.100.34028 > 172.16.15.241.snmp:  GetRequest(34)  .1.3.6.1.4.1.171.10.76.29.1.4.2.0
13:09:21.154873 18:0f:76:62:04:2e > 00:40:f4:6b:e3:e5, ethertype IPv4 (0x0800), length 92: 172.16.15.241.snmp > 172.16.15.100.34028:  GetResponse(35)  .1.3.6.1.4.1.171.10.76.29.1.4.2.0=2

Да вроде тоже все ОК Чудеса! Видимо ответ надо в tcpdump читать :))))

alex_sim ★★★★
() автор топика
Последнее исправление: alex_sim (всего исправлений: 2)
Ответ на: комментарий от alex_sim

Да вроде тоже все ОК Чудеса! Видимо ответ надо в tcpdump читать :))))

Тут дальше только смотреть, что в *tables. Ответ явно есть, значит его кто-то дропает.

AS ★★★★★
()
Ответ на: комментарий от AS

Тут дальше только смотреть, что в *tables. Ответ явно есть, значит его кто-то дропает.

Точно, надо смотреть iptables, попробовать опустить и все станет ясно. Найду, спасибо за помошь!

alex_sim ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin