If I use the rule you stated below then lets follow the logic:
a. user sends email (port 25), other than that there is nothing special identifying email traffic!
b. router looks at traffic coming from LAN and applies the Route rules.
c. It attempts to send the email traffic out WAN1 (distance=1) but the traffic is not accepted.
d. The traffic is dropped.
I agree with you that if the email had a destination in the packets so that the router could then match it to the 3rd Route Rule, then I can understand your thinking.
But to my knowledge its just dummy traffic coming from the email program and that is why I have to tell it specifically to go out a certain WAN port.
My email program is not sending out email IP info or email ISP gateway IP Info for the router to inspect and thus match!!
A destination TCP port 25 identifies SMTP (e-mail sending), that's true. Without combining it with a particular destination address, the rule matches SMTP packets being sent to
any SMTP server in the world, not just your ISP's one.
Now think the other way round, how likely it is that you will need to contact your ISP's SMTP server for any
other communication than sending e-mails? As you've created a special route for that server's IP, I guess you don't want
any SMTP connection to be routed via WAN2 but
only those towards that single server.
Actually your current rules drop any other SMTP traffic than to the ISP's server, because any SMTP traffic gets its own routing table and that routing table only contains a route to the ISP's server, so packets to any other address will be dropped.
Okay perhaps what you mean is that we order the distance of the rules ????
distance = 1 for email rule
distance = 2 ping gateway for WAN1 primary
distance = 3 for WAN2 secondary
That's a common misconception. The
only decides between routes with identical
prefix and
. If you have a route with longer (=more narrow) prefix and
, it beats a route with shorter (=wider) prefix and
, because the routes are first chosen by best match of the prefix and only if several routes with the same prefix legth match, the
is taken into account to choose between them.
However you spoke of efficiency! In the case above every outgoing packet is checked against the first route which is very wasteful?? (IF routes works this way)
The Mangle is done in prerouting which is reasonably efficient and only affects a small miniscule amount of traffic!
This is a valid remark. Inspecting every packet for being a TCP one towards port 25 may be equally CPU consuming as checking one extra route for every packet. I'm not sure how exactly the route matching is done, but I know for sure that the routes once found are cached which makes the routing of second and later packets independent of the number of routes defined.
PS. I read the article and it was interesting. I cannot think of why my ISPs gateway would be up but its connection to the internet down.
Because shit happens
If your ISP uses redundant connections of devices to which subscriber lines are connected, congratulations, yet still if you spend the effort to make your uplink redundant, it seems strange to stay halfway there and only protect yourself against a failure of the last hop if you can do just a little bit more and be protected against ISP's network problems as well.
"Programming" would mean scripting to me in this context, while the recursive routes make scripting unnecessary for the task, configuration is enough.
However I have no ideas why the article created virtual hops and why the author selected the ISP gateways as the IP address for destination?
Because that's how recursive routing works in RouterOS. You must have a route to the monitored element via a physical gateway (the ISP's one), but if you then indicate that monitored element as a gateway in other routes, these other routes determine the address of the physical gateway recursively (so the packets are sent to the MAC address of the physical gateway although the IP address of the "virtual" one is specified in the route), but the availability of these routes is determined by availability of the monitored element.
