actually this is my problem ...the pc getting broken internet and then get internet again from new source...
the solution i am searching for is i dont want to have this stop when i change the source of internet!!
for example if i change the source from dsl1 to dsl2 dont stop this 20 second... maybe i should put a rule to keep pingin for internet so when i change the pc should be prepared or something like this ...sorry maybe this is a silly solution but i am new with mikrotik ..
and thanks for helping ..you guys are amazing!
Initially I understood that you were switching over to the other routing-mark through configuration; from what you wrote now it seems that you had in mind that the Mikrotik started using the other routing-mark because the primary WAN has failed. Which understanding is correct?
In any case, with two uplinks with public IP addresses assigned by the respective ISPs you will always lose existing connections unless you'd have a virtual machine in some data center. The reason is that TCP and UDP sessions are identified by remote participant's IP, so the server in the internet to which your PC has established a session cannot recognize that a packet coming from the address of your WAN 2 belongs to the same session like the packets which were coming from the address of your WAN 1. Or, if you continue sending via WAN 2 with address of WAN 1 and the ISP 2 doesn't drop those packets, the server will match the packets to the session but it will send responses to address of WAN 1 which is down, so the responses won't ever arrive. So in either case the existing sessions via WAN 1 will time out, and this takes tens of seconds. Only sessions established after the failure of WAN 1 has been detected and a failover to WAN 2 has been done will come through. So the time it takes to find out that WAN 1 is down is also important.
Now the check-gateway process checks the availability of a gateway every 10 seconds, so if you use the scripting-free failover method
, it takes up to 10 seconds before the routing detects the failure. With scripting the same behaviour yourself, you can lower the detection time to around 2 seconds, because you need to run a script periodically and the scheduler uses a 1 second resolution. But given the session failure detection time, lowering the uplink failure detection time from 10 s to 1 s doesn't help you much.
If you would want to prevent the existing sessions from breaking, you would need an x86 or CHR running as a virtual machine somewhere in a data center, create tunnels between your home Mikrotik and the one in the DC via both your uplinks, and use OSPF to control the failover between the tunnels. In this case, the public IP seen by the remote servers would be the one of the VM in the DC, so the sessions of your PCs wouldn't break if one of your uplinks failed because there would be no NAT between the PC and the VM in the DC, so just a couple of packets would get lost before the OSPF would detect the failure and switch over to the working path.
In this arrangement, the Single Points of Failure (SPOFs) become the two Mikrotiks, but the physical one is a SPOF in any arrangement so it doesn't really make things worse.
And yes, you can also use a "butterfly" setup with two machines at home and two machines in the DC, but it requires that you have your own IP subnet (not one assigned by an ISP) and thus can use BGP to inform the world how to route towards it, so that your IP address is not bound to any SPOF and can migrate between them.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.