SNMP doesn't work with asymmetric routes?

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?



Thanks :slight_smile:

ryan

i only wish … please mikrotik fix this. let us bind the snmp service to a loopback ip or something. anything …

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

Awesome just what i needed.

Thank you.,

Is there any other posibility to cheat Mikrotik RouterOS?
…EoIPs are not efficient

I found an easier workaround.

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? :slight_smile:

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?

And I thought I was the only one with that problem…

yeah, binding the snmp-service of routeros to a loopback-interface (or bridge) would be awesome.

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.

Any one know how to workaround these problem ?

Is terrible to see why mikrotik devs do not give us a solution for or a src-address or bind to a loopback interface.

Hey Mikrotik, any progress on this? Seems to still be an issue in v6.12 :frowning:

Still present in 6.17 and the changelog up to 6.20 doesn’t mention SNMP at all.

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.

And i is described in the manual.

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.

We should have a way to configure if we want this behavior ou use the normal routing table.

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.

Has anyone come up with a fix/workaround for this that isn’t building tunnels?