I've got a routerboard which has mysteriously been not responding to SNMP Requests.
在这种情况下,路由器接收输入完全不同rent interface than it sends output. Doing a packet sniff shows that in the case of SNMP requests, it sends the replies back on the same interface that the request arrived on, instead of using the path specified in the routing table.
In other words, the router has ether1, and ether2, and receives on ether1 and needs to send on ether2, but when it receives an SNMP request on ether1, it sends the response back on ether1, or at least this is what the packet sniffer claims. As a result, The Dude, and other snmp monitoring software thinks the router is not responding to SNMP.
The router in question is currently version 2.9.42.
It occurs to me that this may also be the cause of some SNMP issues I reported some months ago, where SNMP would mysteriously stop responding.
SNMP replies dropped somewhere on the way out
Just wondering if any progress on this?
The situation is the following:
A router receives an snmp request on ether1, and should send the response out ether2.
According to the packet sniffer on said router, it receives the request and generates a response.
According to a log rule in the firewall output chain, the response is sent. according to a log rule in the bridge filter, the response is NOT sent. According to the packet sniffer of the router connected to ether2 of the first router, a response packet is never received (this is not the same router that generated the snmp request, just the next one in line on ether2's path).
This only happens when the response leaves via a different interface than the request arrived on, and I have now observed the problem in 3.0rc9 (as well as 2.9.x). (this can happen, for instance, when you have a ring topology).
The situation is the following:
A router receives an snmp request on ether1, and should send the response out ether2.
According to the packet sniffer on said router, it receives the request and generates a response.
According to a log rule in the firewall output chain, the response is sent. according to a log rule in the bridge filter, the response is NOT sent. According to the packet sniffer of the router connected to ether2 of the first router, a response packet is never received (this is not the same router that generated the snmp request, just the next one in line on ether2's path).
This only happens when the response leaves via a different interface than the request arrived on, and I have now observed the problem in 3.0rc9 (as well as 2.9.x). (this can happen, for instance, when you have a ring topology).
Re: SNMP ignores routing table?
I have the same problem. Lines 24 and 25 clearly show an ICMP response to xx.xx.222.24 going out eth1, but all snmp responses go out eth2.
Edit - The router this packet sniff was done on is yy.yy.201.30 on it's eth2 interface.
Edit - The router this packet sniff was done on is yy.yy.201.30 on it's eth2 interface.
Code:Select all
# TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-.. SIZE 0 0.29 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 1 0.3 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 2 0.38 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 3 0.322 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 4 0.323 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 5 0.331 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 6 0.947 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 7 0.96 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 8 0.968 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 9 1.952 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 10 1.962 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 11 1.97 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 12 2.028 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 13 2.029 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 14 2.037 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 15 3.948 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 16 3.959 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 17 3.966 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 18 5.951 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 19 5.964 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 20 5.971 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 21 7.951 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 22 7.962 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 23 7.969 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 24 8.952 eth2-p... xx.xx.222.24 yy.yy.201.30 icmp 46 25 8.952 eth1-x... yy.yy.201.30 xx.xx.222.24 icmp 28 26 9.96 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 27 9.969 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 28 9.977 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 29 10.905 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 30 10.918 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 31 10.927 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 32 11.947 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 33 11.957 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 34 11.965 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 35 12.33 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 36 12.338 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 37 12.346 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 38 12.901 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 39 12.91 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 40 12.918 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 41 12.951 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 42 12.952 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 43 12.96 eth2-p... yy.yy.201.30:161 (snmp) xx.xx.222.24:1155 udp 81 44 13.95 eth2-p... xx.xx.222.24:1155 yy.yy.201.30:161 (snmp) udp 80 185 ADo xx.xx.222.0/24 r zz.zz.243.97 eth1-xcon-ProCent 186 A S ;;; Main default route 0.0.0.0/0 r yy.yy.201.29 eth2-pro-kru-bh60Who is online
Users browsing this forum:iozkucukand 29 guests