On many of my backhaul links, I have dual links with staggered link costs, (say, 10 and 12) to give me a dedicated upload and download link.
I also use SMNP for voltage monitoring in dude (low voltage email warnings for solar gear, graphing, etc)
this works great, but for some reason the SNMP monitoring (voltage, temperature etc) in dude stops working to any router which is asymmetrically routed.
is there a fix for this?
We have the same problem - an easy fix is to build an EOIP to the router and bridge it to the Ethernet port the ammo based monitor is on - then have the subnet used for monitoring on the other end of the tunnel - as close as possible to your monitoring software
just set the device IP in dude to the gateway IP of one of the link legs on the route back to the dude server (i set it to the “tx” leg, and bingo, works fine)
does that make sense?
now if there was only a way to get the link graph to show the tx for one interface, and the rx for the other.
rhauf - yes I understand pointing snmp at the remote tx address - trouble is it only works when that link is active - as soon as the active path changes, it stops.
jklpl - As for EoIP not being efficient - does it really matter? How much snmp data can one possibly need to retrieve from one site?
Don’t you mean, it only works if that interface is active? if the link on that interface goes down, it would then become a symmetrical path through the other interface.
i know it’s not a perfect workaround, but its good enough for me, so i thought i’d share.
that is a feature not a bug. SNMP was specially altered to respond on the same interface it received request on. And response source is request destination. Hence, some suggested workarounds do work, like monitoring outgoing interface ip address or creating a tunnel and monitoring through the tunnel. If this is through your network where can enforce MTU of the link, you can setup higher MTU to offset tunnel header and have full size payload.
Can we put a feature request in for that to be configurable, then? Having a settable src-address for SNMP would solve the problem for most people listed on this thread.
it was done to make asymmetrical routing configuration with NAT working. In case you have 2 or more possible WAN connections source address would be wrong for returning packets and they where discarded. This traffic being UDP - it is not possible to do proper routing marks on it.
It is not clear why EoIP tunnel is not suitable. As traffic volume is not that high.
I agree that this behavior is not industry standard. Normally device would answer from the same source IP, but send through whichever interface routing points to. If I have NAT or something else that will break it, then this is clearly my (admin’s) problem to fix, but at least it should try sending the packet and not silently drop it.
Creating EoIP interfaces for the purpose of monitoring is not a “clean” fix and would result in lots of EoIP interfaces on the aggregating router.
Hello, I’d like just to point out that there are other environments in which manual set source interface will be more than desirable, here is one in which I have found this limitation to be a annoying thing:
In a MPLS network we have lots of customers sharing a common network infrastrucuture. We monitor all devices from a separate VRF in which resides a monitoring platform (SolarWinds Orion). In order to avoid some network address overlappings, we’ve chosen a set of public address to assign to all devices as loopback addresses /32. We export those prefixes from all VRF’s (table-maps, export-maps, etc.) to get the SNMP/Syslog/Netflow servers. Thus, the current behavior we find in Mikrotik devices is not suitable, nor practical in environments like this or even more complex ones.
Please: let users to be able to set this parameters manually. This option aims at Mikrotik being regarded as a good choice for MPLS low cost / high quality CE’s.