Had a request from a customer so I have been brainstorming and just wanted to get some input would like to know if what I’m thinking below will work for the purpose and if anyone has any thoughts on optimising.
So I will be managing a router that will connect to the customer’s LAN. That LAN will then connect to another router. These two routers will have VRRP setup for the LANs default gateway IP and my router will always be the master. My router will have its own WAN connection and so will the other router.
My situation is this. I basically want it so that if my WAN fails, the VRRP also fails over to the backup so that the other router’s WAN takes over as the primary. In my head I would just setup a Netwatch that pings out of my WAN and then runs a script OnDown that disables my VRRP interface. OnUp it would then reenable my VRRP interface. Preemption would also be disabled to allow my router to take back over as the master. I’ve tested it in a lab and it works fine just wasn’t sure if anyone could think of any flaws or ways to optimise.
Diagram this out. Are you deploying 2 Tik routers or just 1? Do you have full control of both routers? For a usual VRRP, the VRRP instance needs 3 IPs on that same subnet. 1 for each router, and 1 as the VRRP interface.
Now if you have a singular IP from the ISP, your solution will need to be based on whether its static / dhcp. Either way, you’ll need to use netwatch and run scripts to flip paths.
VRRP on LANs is simple. And I don’t think you need do much with VRRP on WAN-side for this. And if failover is all you need, just make sure DHCP hands out the LAN’s VRRP address for your clients, and the default VRRP priority should steer the traffic to the router with the desired “primary” WAN.
If the “router gets unplugged” etc., your backup router take over, the LAN simply use the WAN already on the “secondary” router. So no WAN VRRP should be need for failover.
A netwatch script that adjust priority would cover the case where the “internet is down but router is up” cases… since VRRP doesn’t help with that. e.g. on each router, run a netwatch script that adjusts the priority so the the primary router’s priority is lower if netwatch fails, and the secondary router’s priority is even lower if netwatch fails.
I’m presuming OP each router has its own/different WAN & and the WANs are not otherwise connected locally. Diagram would help — since if both routers have the same upstream WAN on same subnet OR if two different WANs do exist on both routers via some VLAN/etc… those likely have different answers here…
Image is attached. I didn’t attach one originally since, as you can see, it’s not a complicated setup in the slightest. Also apologies for my drawing. I don’t do network drawings often
I think Amm0 hit the nail on the head. Since posting this I have tested it myself and I think the way I’m going to go is just what I said originally:
VRRP set between Tik and Cisco
Netwatch on Tik with the gateway of its WAN address as the destination rather than Google or Cloudflare etc.
Tik set as highest VRRP priority and no Preemption so it is always master
If Tik WAN goes down but router stays up, Netwatch will disable the Tik VRRP interface so the Cisco takes over
As soon as WAN comes back and Netwatch can ping out, Netwatch reenables the Tik VRRP interface and Tik takes back over as primary
If anyone can see any holes in my plan let me know.
Also both public are addresses are in different subnets because some asked
P.S. The drawing is supposed to show the interfaces from Tik to LAN and Cisco to LAN as the VRRP enabled interfaces but I’m an idiot and forgot to illustrate that…
Sounds reasonable plan to me. Assuming that cisco and RouterOS’s respective VRRP sync – it should, but never tried that…
Only other thing to consider is the DHCP and DNS servers… For VRRP-enabled LANs with two Mikrotik, I just have the DHCP Server listen on VRRP interface, so one DHCP server is always up. Since that’s not possible here (e.g. not sure cisco will enable/disable dhcp based on it’s vrrp status, maybe?). Anyway might consider longer lease times or some other way to deal with DHCP assignment if the down’ed router is also the DHCP server for the VLAN/VLANs… Similar with the DNS in the DHCP assignment…
That’s a good point, if the WAN goes down then DHCP isn’t the end of the world but if the router dies then that’s going to be…interesting to say the least.
I think I’ll have to go back to the drawing board for that one. Thanks for the help!
would like to know if what I’m thinking below will work for the purpose and if anyone has any thoughts on optimising.
