Following discussions about ECMP with Masquerade and similar, we have made a new firewall matcher that will allow you more control and hopefully will overcome the previous limitations, read on:
Very cool my friend! Jumping with joy 
Thanks normis.
So next question when is 3.24 going to be released.
i hope this would work on the output chain - ie; connections generated from the router itself. Mainly for l2tp and pptp tunnels in my case.
I vote it to be also in output chain as well!
it’s just one more simple firewall matcher - it will work everywhere =)
maybe any plans for TTL matcher? I’m waiting for it for about 1.5 year…
Well as far as i can see you can use any chain there, so it shouldn’t be a problem.
But overall a very nice addition
If you have some ready setup to test, ask support for a pre-release package.
Any chance of giving the possibility to check another Ip not only the gateway if there is Internet connection through one gateway or not.???
Testing new system right now. So far working great. haven’t seen anything drop so far.
I am watching it though. It seems to act a little more like nth on splitting how it picks which gateway but so far no major issues.
Going to keep testing it more tonight and push it harder with more connections tonight
I second that! The gateway might be up and reachable but internet is down. This is often the case with VSAT connections.
True. For example I could use check-gateway=, instead of “ping” or “arp” !
yep! Netwatch with possibility to set Routing Table like in Ping command would be nice! feature request? somebody who need this, please write to support
I think we should keep all checks limited to the closest network or else it will start to become ridiculous and dangerous.
Imagine half of the country constantly checking your server’s IP address… and what will happen if that address goes down - router willl drop perfectly working connection? I think there is no point even trying to ask for this.
Well it is NTH it is persistent NTH.
Anyone has any other applications to this feature?
Major servers are designed to be checked, they are powerful machines, load balanced by DNS, on powerful connections, can not be DoS attacked, so what I am saying is that we need the feature to ping a further up IP than the gateway and thats final. If your concerns are valid, than that can be avoided by providing a LIST OF IPs to ping to switch between them, if one fails - start ping the other one etc etc. simple logic. Right MikroTik ?
If we look from that point - all ISPs should have OSPF and BGP on their network one way or other, and should have backups, so that only time when you loose connection it should be because your gateway is dead, and this is now eliminated be check-gateway=ping or arp.
le’ts keep this thread on the topic of PCC not server reliability issues.
Woohoo! Thanks normis.
emails support for pre-released package
IMO - wrong!
and here is why - when you ping closest hop, you know this hop is working or not - if it is, then you do not have to worry about that. But in this case your owner of gateway should worry and supply you with route to network if links of gateway by any chance is down.
and most interesting part, if you are pinging some outer address, when route goes down, you adjust your routes and host is available again, your automatic configuration switches to previous configuration and no ping again - so, infinite loop of switching gateways.
and one more thing - do not hijack other threads and stay on topic in this case PCC
You do understand that check-gateway=ping,arp is not enough to know whether a route is OK, right? You know that we need to know if an ISP gateway is up in the case we have a CPE before the MirkoTik Router, right? We can not ping 192.168.1.1 we need to ping the Internet IP of the ISP gateway.
So get to work my friends, I’m sure you can do it and make it in a way that is a problem-free (no loops etc).