I’m using a script to detect a problem with the main gateway and activate a mangle rule to redirect traffic to another good route.
The problem is the script also sends a mail to let me know what it’s doing, but the e-mail tool always uses the “main” routing table, and so the email sending times out.
Anybody know an additional mangle rule (or should I be looking at some other way) that will mark email traffic sent by the mikrotik itself? I’ve tried adding a rule that will mangle tcp port 25 but it didn’t work.
For background I’m using a mangle rule so I can restore the main gateway as soon as it becomes available, with the alternative route in place I can specify the “main” routing table in my test and switch off mangling if successful. None of the scripts made available for use seemed to do that…
In all my failover setups, I set the default gateway, then add the second path as a default gateway with a higher distance.
I then either use check-gateway to automatically disable the “main” route, or have my script change the metric of the “main” route to something higher than the backup link. The advantage to this is all routerboard-generated traffic (including email) always goes out the active path.
I started with that approach, the gateway with the higher distance wasn’t “Active” in the routing table, is that the normal case? Will it automatically become active when the main gateway is down, or is it the case the script MUST alter the distances to make the secondary route active?
In either case, how do you test to see if the main route is available again?
I should clarify - the main gateway being REACHABLE is not sufficient in our situation to ensure internet access as there is second hop from this router to the internet, so I need to test all the way out to the internet (currently using ping to OpenDNS to test…)
The key is putting a specific /32 route for the test point out ISP1. When the ISP1 default route is “active”, it has a lower distance and therefore is used over ISP2. When the script detects the line is down, it can set ISP1’s gateway distance higher than ISP2’s, resulting in ISP2 being used.
Since the specific route is in place to always force our test point out ISP1, netwatch can continue to monitor it.