Sangeeta Misra writes: > On 10/27/08 10:10, James Carlson wrote: > > I don't think I understand VRRP groups. The design describes in some > > detail how to configure them and some of how they operate, but it > > leaves out three crucial bits of information: > > > > a. Why do we need them? What problem do they solve or what > > necessary feature do they allow us to have? [...] > > The VRRP group concept was devised to handle the failover of primary > loadbalancer that handles multiple virtual services. Rather than > designate master and backup per virtual service, the idea was to have > one master for all the virtual services. So one would invoke a VRRP > instance per virtual service and bind all the the instances to 1 group > and perform failover as a whole.
The question I still have is "why?" What benefit do we get by doing them as a group? Is it expected to be simpler to configure this way? Is the behavior more predictable for some applications? What's the advantage of grouping them versus simply specifying the same master and backup for a list of independent addresses? > The failover from primary to standby > will only occur when the standby fails to hear VRRP advertisements of > *all* instances in that group. That makes it sound like a much bigger protocol change than the design document indicates. I'd like to see some worked-through examples in order to understand how it reacts. For example, suppose I have a single group (let's call it "mygroup") which comprises two instances (we can call these "A" and "B"). The instances each have a virtual IP address (IP-A and IP-B) and an interface -- let's just have them on the same interface to start. Suppose I'm the backup, and I stop hearing announcements for IP-B, but I'm still hearing them for IP-A. Does this mean that I assume that the sender is still master for both IP-A and IP-B, even though I can't hear IP-B, and even though the protocol document says that I should now be master for IP-B? What if it's only IP-B that's broken on the peer? Now suppose that I make a mistake. I've configured one side with a group and the other with independent instances. What happens? Are there any cases where the peers can get confused about who owns which address? If so, how can the user detect that such a mistake has been made? Are there any cases where one instance in a group could attain "master" status while another has "backup," or are all of them tied in lock-step to the group's status? It almost sounds like you want a protocol extension here (one that allows multiple addresses to be transferred at one time), but are declining to do that. If you're changing the protocol anyway -- changing how "master" and "backup" roles are detected is a protocol change -- then why not just add an extension to handle this case, rather than running parallel instances? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
