Sebastien Roy wrote: > I'm submitting this fast-track for Cathy Zhou, it times out on > 07/17/2009. This case depends on PSARC/2008/693. 2008/693 requested > "micro" release binding, but no incompatible changes are introduced, and > "patch" would be more appropriate (although no backport is planned). As > such, this case both requests "patch" binding, and updates 2008/693 to > have "patch" binding as well.
First of all, "yay!" The new design looks a lot better. I'm not sure, though, if this is really a fast-track. There's a lot of subtlety here, and it's in some areas (interface flags, routing sockets) where we've managed to make some complicated and sometimes "wrong" decisions in the past, and where there are interoperability concerns. > - IFF_NOACCEPT > > When a VRRP router becomes master, if its accept_mode is false, all > the virtual IP addresses will be brought up but with the new > IFF_NOACCEPT flag set by vrrpd. IP will mark all the local IREs > associated with these IFF_NOACCEPT IP addresses to be "no_accept", > and all the received unicast local packets will be dropped, with > the exception of the Neighbor Solicitation packets and Neighbor > Advertisement packets. This allows the Neighbor Unreachability > Detection mechanism work as expected in the false accept_mode. This seems to describe IFF_NOACCEPT as a per-ipif flag. Is that the right granularity? It seems odd to me that we could potentially configure the system to have some addresses that respond and some that do not. The point of "no accept" mode is to behave as a real VRRP system. If you want that, I don't think you'd want it just some of the time, would you? > The IFF_NOACCEPT flag can only be set on a IP addresses if its > IFF_VRRP flag is set. Further, the same SO_VRRP socket option must > be set to change the IFF_NOACCEPT flag over a IP address. What's the rationale for requiring SO_VRRP? Nothing else knows about IFF_NOACCEPT, so (unlike IFF_UP) it can't be set "accidentally" by anyone else. (And you clearly can't *stop* appropriately privileged applications from setting SO_VRRP on their own.) A separate question on the IFF_UP limitations: I'm not sure why that's being controlled by the VRRP daemon. Why not allow IFF_UP to be the normal administrative control on the address, and just have the VRRP daemon control whether the address is "live" on the network (i.e., turning on and off ARP and ND for the address, as well as controlling input and output)? This proposal looks workable, but it still looks a little more complex to administer than I'd expected. > Since the existing PF_ROUTE event opcodes only report the changes > of the set of "UP" IP addresses, and the vrrpd daemon needs to > track all the virtual IP addresses configured over each VRRP router, > regardless the IP address is brought up or not. Therefore, two > new PF_ROUTE event opcodes will be introduced to report the changes > of the IP addresses configuration, including the IP addresses that > have not been brought up: > > - RTM_CHGADDR > > The RTM_CHGADDR event will be generated when a new IP address > is newly configured (added or updated to). > > - RTM_FREEADDR > > The RTM_FREEADDR event will be generated when a IP address is > removed from the configuration. These don't look like messages on other systems. Are there any parallels with existing BSD extensions? (I assume that "configure" means "plumb an ipif" here.) > Note that both events will not report the unspecified (all-zero) > IP addresses. I'm not sure what that means. Why would those need to be special? Or is that just an implementation limitation? Aren't all ipifs constructed with zero address when first plumbed ... ? > Since in some cases, the VRRP configuration is pretty simple and > the administrator would prefer to have one single administrative > tool to configure everything related to a VRRP router. Therefore, > we give the option to an administrator to do that using only > vrrpadm: the optional "-a" option can be used to specify a list > of virtual IP addresses when creating a VRRP router, the "-P" > option can be used to specify the primary IP address that > is used to send VRRP advertisement packets. Further, if the "-f" > option is specified, vrrpadm will create/plumb the VNIC if that > has not been done: > > # vrrpadm create-router -V 12 -l bge1 -A inet -p 100 -o no_accept \ > -a 11.1.1.1/24 -P 11.1.1.100/24 -f vrrp1 When the user does this, where is the information stored? Does "create-router" write the address into /etc/hostname.*, and so on? > - priv_net_rawaccess > > Required to hold the physical data-link (which owns the > primary IP address) and the vnic (which owns the virtual > IP addresses) open to prevent them from being deleted. Why is that necessary? > If an administrator configures either IPv6 autoconfiguration or > DHCP over a VRRP VNIC, since neither in.ndpd or dhcp client sets > the SO_VRRP socket option, the attempt to bring up the > auto-configured IP address will fail, which causes the failure > of the autoconfiguration operation. Shouldn't these things be modified to check for IFF_VRRP and emit reasonable messages and/or just avoid touching them? Relying on SO_VRRP and ioctl failure seems reasonable for protection from third party applications, but I think our own applications should probably do better. > After discussion with the team that potentially would consume > this feature (the ILB team), Note that Quagga routing could consume this feature as well. (Perhaps even sooner than ILB, as we've already got Quagga ...) > we found that this is an > incomplete solution which does not simplify the management > complexity. Ideally, the HA support configuration solution > would be: > > configuring the following on the owner of the virtual IP addresses: > - the virtual IP address(es) > - the VRRP VRID > - the IP addresses of the backup(s) > - the ILB server groups, rules, hc, etc > - some security configiguration (ssh keys) that allow > automatic synchronization of things with the backups > > and all the other configurations and sync up between master and > backup should be automatic. > > Clearly, the protected service support proposed by the old VRRP > design does not help with the ideal world, therefore, we decide > to remove the protected service support. That seems reasonable. Is there some way that SMF or Quagga could be configured to signal VRRP when a routing daemon fails? > /usr/sbin/vrrpd Project Private VRRP daemon Nit: this probably belongs in /usr/lib instead. No user or administrator should be starting VRRP on his own, should he? -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
