I've got a routerboard which has mysteriously been not responding to SNMP Requests.
In this case, the router receives input on a different 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-bh60