I’m setting up a redundant solution and I’m looking the best path forward. I’m using vrrp and no routing protocols, just a default route to our ISP. I start a ping from 192.168.50.10 to X.Y.207.4 and its working great flowing in the below path.
When I disable the WAN port (ether1) on R1, the backup router R2 assumes master role of the wan port vrrp. This makes sense because for 192.168.50.10, R1 is by default its default gateway and R1 doesn’t currently have a path to the WAN gateway so the echo request dies.
Its only when I disable R1 ether2, do pings resume.
I need some advice on the best route to take. Do I use netwatch, do I setup ospf on these two routers?
Thank you,
Ken
I created a netwatch to ping the IP address of the ISP. When down, it disables the LAN ports, when UP, it enables the LAN ports. The ISP itself is using vrrp so this is really for physical failure.
any thoughts on this would be helpful or is disabling the lan port the best route?
One thing to note - you don’t need VRRP on the WAN side of your routers because the NAT state isn’t going to move from router1 to router2 in the event of a failure. You may as well let router1 masquerade with its own WAN address, and router2 likewise. This will also let you be able to notice what IP you’re being natted to…
I would also suggest that you not enable preemtion - so if router2 goes active, it stays active even if router1 comes back - that way, you’re not breaking everyone’s sessions just to go back to router1.
I think disabling the LAN is probably the best thing to do with your netwatch, so that VRRP will kick over to the other router.
The other solution would be to use a floating-static backup default GW over the direct router-to-router connection.
You could even do some clever things with this using policy routing and connection marking - so that when R1’s default GW fails, instead of dropping LAN1 interface, it simply starts forwarding to R2 over the private link. Any connections forwarded over the private link could get connection-marked and policy routed via this private link, so that if the WAN connectivity for R1 is restored, it will continue to forward existing connections to R2 so the users don’t get kicked out of their sessions, but new sessions will go directly to the WAN…