Sent from a teeny tiny keyboard, so please excuse typos > On 23 Sep 2016, at 20:24, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > > Andy Lemin <a...@brandwatch.com> writes: > >> Hi, >> >> TLDR; Is there a way of fixing the "source address" that SNMPD should use? >> >> >> We are having issues with reply snmpd packets sourcing from the egress >> interface and not the loopback interface which the poll request was sent to >> :( >> >> We have many GRE tunnels and various routes which traffic can take to and >> from our OpenBSD boxes. As such we poll the loopback interfaces instead of >> a specific interface, however the snmpwalk replies reply with the source IP >> of the egress interface and not the IP which was connected to. >> >> We tried setting "listen on $IP_Lo1" etc, and this seemed to work, but it >> is unstable. That is, occasionally packets start being sourced from the >> egress interface again when something changes until snmpd is restarted. > > I don't understand why binding on a loopback doesn't work. What is > "when something changes" here?
I haven't been able to figure that out yet. We have about 20 OpenBSD boxes, and at some point or another, seemingly randomly, our monitoring system looses connection to snmpd as it starts responding with the egress IP again and not its loop back. It's happened on about 4 or 5 out of the 20 so far. Restarting snmpd fixes it each time. And we still have the trap source IP problem as the monitoring system (Observium) recognises the device by its loopback. > >> Also traps are always sourced from the Egress interface regardless of >> "listen on", however our monitoring system only knows about the loopback >> interface and so the traps are dropped. >> >> Cheers, Andy. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
