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

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.,

Awesome just what i needed.

Thank you.,

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

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?

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.

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.

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

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?

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.

So, the reason it works this way is to make things easier on people with remote MikroTiks with two, or more, WAN connections who want to use SNMP to monitor the devices from a central location without a VPN tunnel to each device?

The manual has instructions on using routing marks for ensuring that traffic which comes in a multiply connected NAT situation goes out the interface it came in on.

Are there there really more dual WAN setups out there with admins who need not be bothered with routing marks/rules than there are meshed networks in which routes regularly change due to additions, or failures, or optimizations of network links?

I get SNMP monitoring of all 200 tower sites working, then we add a new fiber connection to help with overloaded wireless paths and I've lost monitoring of some random site. Often the site I've lost is not an endpoint of the new link. When a link fails, I lose monitoring of some other random site. It is very frustrating. The network is too fluid to be changing the monitored IP every time a route changes. If the other common critical UDP service, RADIUS, worked this way, customers would be randomly denied access.

I have 600 routers. None of them are on the far side of a NAT from the monitoring server. Around 40 of them are on the far side of ring path. Ring paths intersect. Capacity of links varies. Demand on paths vary. Route priorities change weekly to maximize the utilization of limited resources.

How many workarounds are reasonable to expect your ISP customers to make? How many of your customers use SNMP to monitor their remote dual WAN connected routers without a VPN tunnel? Which workaround is more work for the user? I don't have the data to be able to know the answer to those questions.

I just know that it seems like the current RouterOS development choice with respect to SNMP is quite a bit of pain for my network. Please, please, please let me bind SNMP process to the IP or interface of my choice, like the mainstream vendors allow, like you allow me to do with RADIUS.

I am grateful to not have to pay as much for MikroTik's devices as I would have to for the mainstream vendors.

you can try to add empty bridge interface, assign SNMP management IP address there. Route that address/subnetwork in your network (OSFP, RIP). See if that improves your situation with the monitoring and ever-chaning network.

At all sites, I monitor the IP on the lan-bridge bridge. If there is a second router at a tower, it is connected via that bridge. onsite laptops also plug into a lan-bridge interface if a tech is onsite. It's pretty close to being a loopback interface. I've also tried a actual /32 on a dedicated loopback bridge without any ports. Neither have been successful.

I currently have a site where the CCR1009 handles backhauls and a RB2011 handles customers off the APs. I am currently unable to get SNMP responces from the lan-bridge IP of the CCR 10.x.y.66/27. SNMP monitoring of the lan-bridge IP of the RB2011, 10.x.y.65/27, works.

I've been too irritated to spend more than 10 minutes trying to fix it this time. If I make the routes work for the monitoring server, customer traffic will be on the wrong path.

We are currently experiencing this issue still,

we are running multiple devices in BGP/OSPF pairs for failover and only the active router is responding to SNMP,

we want to be able to use the loopback addresses to monitor these rather than physical links so if a link goes down we can see which link rather than loosing the whole device.

an option to be able to specify the interface in the SNMP menu would be a prefered option.

Any other fixes that dont involve EoIP tunnels would also be welcomed

Many Thanks

Hi guys,

I would like to share my workaround mechanism.
/interface bridge
add fast-forward=no name=loopback0
/ip address
add address=X.X.X.X.X/32 comment="MGMT/Unnumbered Interface Lo0" interface=loopback0
In SNMP server specify the IP address of the device X.X.X.X loopback address.
As a remedy I used static route for the SNMP server address(/32) faceing the one of the peers. If active link goes down the route that device got from OSPF/BGP(in my case it is iBGP and I receive 2 different default routes from 2 different peers) protocol will handle the path, in case if your network works via Dynamic Routing Protocol.

We have struggled with this issue too. We generally have a /32 IP address on a "loopback" bridge with no interfaces attached and use that for all monitoring, with BGP advertising the address, to handle the multiple paths around our network. The odd thing is, it does work on some devices, but not on others. It is very inconsistent. We have particularly noticed the issue since v6.30 (I can't remember if it was an issue before then), and 6.39.3 (current bugfix) still has the issue. The affected devices are primarily CHR and CCR. The lower end devices tend to not be multihomed as often, which may be why we haven't seen it there.

I have found a kind of workaround... but I don't like it.
I have added a new static route on the device to get back to our monitoring server, using ECMP:
/interface bridge add name=bridge-VLLB-TPRK-TMNO-RT1 protocol-mode=none
/ip address add address=L.L.L.L comment=VLLB-TPRK-TMNO-RT1 interface=bridge-VLLB-TPRK-TMNO-RT1 network=L.L.L.L
/ip route add check-gateway=ping distance=1 dst-address=M.M.M.M/16 gateway=a.a.a.a,b.b.b.b,c.c.c.c,d.d.d.d pref-src=L.L.L.L

ECMP makes it use a loopback address as the source, because the route isn't just out one interface.

The reason I don't like it is that it negates the value of BGP for those management subnets. I'm sure you'll agree that static routes is something you want to avoid for traffic that you want to have failover correctly.

In case anyone at Mikrotik wants to try reproduce this, the most recent case we have is a CCR-1009-8G-1S-1S+ running 6.39.3. We have 4 upstream paths to other Mikrotik routers, using BGP to determine the best path. A bridge and loopback IP is created as per the notes above. With the static route using ECMP, SNMP to the loopback IP works, but when the static route is disabled, SNMP to the loopback fails. I also tried putting in a route filter for the BGP peers that a "preferred source" of the loopback IP to the routes learned via BGP, which made no difference.

@janisk
you mentioned that it works as written in the documentation... but the documentation here:
https://wiki.mikrotik.com/wiki/Manual:SNMP
states: "Note: SNMP will respond to the query on the interface SNMP request was received from forcing responses to have same source address as request destination sent to the router".
I don't know if the outbound interface part works as written, as it doesn't bother me. The source address does, and the documentation says that it uses the same source address as the request destination, which I understand to mean the loopback address in my use case. So this does seem to be a bug, where it's not operating in the way the documentation says it should.

you can use routing prefix filters to add pref-source for the one route back to your snmp monitoring station. its a hack but forces traffic leaving the router to use the pref-source you specified.

I should say - with ospf you have a loopback on each router - use that as the pref-source one that dynamic route.

Hi changeip, thanks for your response. As I mentioned, I used a routing filter to assign the preferred source to the routes, and it made no difference. I'm not using OSPF, only BGP. The Router ID for the BGP instance is the loopback address, which does not appear to have made any difference.

Just another thought... I'm assuming my monitoring system does not match the return traffic with the SNMP request due to the source IP address of the response not matching the destination address of the request. I haven't had a chance to do a packet capture to confirm this.

This appears to be fixed in 6.41 -
set contact=Joey enabled=yes location=XXX src-address=XXX trap-target=0.0.0.0

Setting the src-address variable has fixed this issue for me.

Thanks for the heads up, Joey, that's great news.

It appears to have been released in 6.40, according to the changelog:
*) snmp - added ability to set "src-address"
So it's been available since 21 July 2017, for those happy to use the Current branch of releases.

For me, I'll be waiting for a Bugfix version of 6.40+...

RouterOS 6.40.6 has been released as the latest bugfix, and includes the ability to set the source IP for SNMP responses. I haven't tested it yet, but have confirmed the options are there.

I found another 'workaround' for this in case setting src-address doesn't work for you (perhaps you have an IP through DHCP)

/ip firewall mangle add action=mark-routing chain=output new-routing-mark=main passthrough=yes protocol=udp src-port=161