On 29/06/2006 09:03, Dr A V Le Blanc wrote:
Many thanks to Graeme Fowler, whose suggestions led to the solution.
1. Remove the VRRP authentication completely (if you feel you can).
I wasn't aware that this worked.
VRRP will work with or without auth, but without it someone could
"poison" your environment. As the basic auth is so trivial to forge it
isn't really worth bothering with, so the comments further down
regarding "protecting" your announcements start to make more sense.
2. You only have a single VRRP instance; you don't need a
vrrp_sync_group. Comment it out.
And I wasn't aware that this was possible either.
The sync group stuff is designed to ensure that all your VRRP instances
change state when one of them does - in an LVS-NAT system, for example,
it means that you can failover the "external" and "internal" interfaces
of a director to make sure that the default gateway for the realservers
ends up with the client-facing VIP (ensuring service continuity). If you
see what I mean.
On Wed, Jun 28, 2006 at 12:43:48PM -0700, Brad Dameron wrote:
Your virtual_router_id on the backup needs to be incremented.
When I follow this advice, it stops working. Apparently the
virtual_router_id needs to be the same on both machines.
Indeed it does. That's how the VRRP instances know what they're talking
about; having different VRIDs means you can have multiple VRRP instances
on the same network not clashing with each other. As you have found out!