James, Really appreciate your review and all the valuable comments ...
James Carlson wrote: >yifan xu writes: > > >>The VRRP project team invites you to review our current design. The document >>could >>be found at: >> >>http://www.opensolaris.org/os/project/vrrp/vrrp_design.pdf >> >> > >I'll skip over most of the SMF instance discussion now happening on >[EMAIL PROTECTED], but I think that thread needs to be redirected >here, so that the networking community can comment on it. The open >review isn't complete without it. (You have my permission to resend >any of my messages on that topic to the list if you need.) > [...] SMF discussion in another sub-thread. > >One high-level issue: this document appears to be mostly a functional >description of the new service and the library. Will there be a >separate detailed design document to discuss the internal data >structures, algorithms, and any locking or lifetime issues, or is >section 7 intended to cover that as well? (Or is it simple enough >that no formal design is needed?) > Actually given the description of the API specification, the internal data structures and algorithms are quite straighforward. The implementions of threading, locking, and network communications are quite simple. We were trying to only list those implementation details that worth mentioning and might raise up issues. But at least the basic architecture description should be added to the document, I think. And also the content of the CLI/API specifications will be appended to the design document: http://www.opensolaris.org/os/project/vrrp/vrrp_cli_spec.txt http://www.opensolaris.org/os/project/vrrp/vrrp_lib_spec.txt > >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: > > [...] we'll have the group discussion in another sub-thread. >Does vrrpd itself send RA messages? If so, why? Shouldn't that be >the responsibility of in.ndpd? (The RFC describes what behaviors are >required for the whole system, but doesn't specify which daemon needs >to take the required actions.) Section 7.6 doesn't describe how the >required behavior will be achieved by the project. > There is a case that in.ndpd cannot satisfy the requirements. When a VRRP Master's Accept_Mode is False, the interface should send/accept ND/RA messages but should not accept packets desinating the associated IP addresses. This is implemented by adding static ND entries without applying the associated IP address on the interface. > >How does the daemon interact with services that need to be protected? >If I'm using VRRP for fail-over in the host-type application scenario, >I'd expect that if the application fails or is administratively >disabled, VRRP would trigger a fail-over to the backup. How does that >happen? If I'm using it for the router-type scenario, then loss of >the routing daemon(s) or disabling forwarding should cause VRRP to >stop. > >At a guess, it appears that vrrpd is expecting those services to call >"vrrpadm startup" when launched and then call "vrrpadm shutdown" when >they fail. If that's correct, then where's the rest of this project? >What project actually inserts those calls into the services that can >be protected with VRRP? Without that linkage, this daemon won't >actually do anything in a production system. > The essential intent is to provide HA for host failures or link failures. It is the basic requirement and in my opinion the protocol is designed mainly for that, because the criteria of triggering fail-over is defined as "not hearing the heartbeat for a while". To trigger fail-over depending on other criteria, the only interfaces we could find in the protocol is the startup/shutdown events, and changing the priority. To make the VRRP service be able to intelligently protect other softwares/services, it needs versatile interfaces. As you mentioned it could be a loss of a daemon or an administrative setting, or other things. I don't think using smf dependency could cover all the potential cases. Thus it is better to just provide the startup/shutdown events and the ability to change priority for flexibility. > >What external things should happen when VRRP changes state? What's >the expected usage case for the registered shell scripts? What >problem do these scripts solve? Examples would be very helpful here. > VRRP changing state means the host is changing its role. Other services utilizing VRRP might want to do some job at this point. For example, a firewall protected by VRRP may want to apply its rule set only when the host becomes Master from Backup. This is just an example and it could be any tasks. > >Section 4.1: the description of the 'INITIALIZE' state appears to be >incomplete. The fact that the RFC describes the state doesn't really >explain how to implement it; "daemon not running" could also be a >plausible representation, and nothing here explains why you'd choose >one implementation over another. > The 'INITIALIZE' state is useful for maintaining instances that are created but inactive. Without this state, a VRRP instance configuration should be either completely removed, or in one of the two states, Master and Backup. "daemon not running" is not suitable for the case that there are multiple instances on a host. > >Worse, the text warns of unspecified problems in operation if all of >the instances are not started at one time, and then presents a >physically impossible solution: starting them all at once violates at >least causality. The necessity of doing this requires some >explanation. Are you really saying that (for example) if one system >has its power removed, then the other cannot be rebooted? That's what >I think is implied here, and it doesn't make sense to me. > >How does a protocol that is intended to solve high-availability >problems end up having complicated failure modes related to >availability? > I am not sure I understand the problems you pointed out. Why those instances couldn't be started one by one. When getting startup, the instance turns into Backup state and then Master state after a while. I don't see any problems here. > >Section 5.6: this part begs a number of questions: > > a. Why are separate registrations needed? In other cases where > we've done this (DHCP eventhook, PPP ip-up), we've simply created > a single well-known path that is invoked by the daemon, and if > there's a user-supplied script there, it runs. > Separate registrations are needed for different instances running on a host. Registering with a specific instance on command/api seems more reasonable than a unified path. > > b. How can a shell script be "unregistered?" There's a registration > function, but the document doesn't describe how anything is > unregistered. (Empty string for the 'file' argument?) > Use different option with the register subcommand. It was in the CLI spec while not in the design doc. We should have included it. Please see above links. > > c. What happens if an existing vrrp_state_trans_t value is set to a > new script? Does the system support multiple scripts per state > transition value, or just one? > Just one. Later registration will override the previous one. > > d. Why isn't the state transition value just an argument to the > script? Why have separate scripts per transition value? What's > the usage model? > Most likely only one or some of the state transitions will have scripts registered. Using argument for one script and having separate scripts seems no difference to me, though. > > e. Why not just specify a set of arguments that will be presented to > the script? I don't understand the value in allowing the client > to specify its own command line. > Argments that users would use are unpredictable. How could the service specify arguments for users? The benefit is the users don't have to write up a script and just use a command line. > >Section 7.1: If I have multiple copies of vrrpd running at once, which >3.2 appears to encourage, then where are the UNIX datagram socket >control interfaces for each one placed? This section documents only >one file path. > No. There would be only one vrrpd running on a host. > >If I have multiple copies of vrrpd running, how do I specify which one >I want to talk to via libvrrp and via the CLI? > >If I can't have multiple copies of the daemon running at once, then >what's the point of section 3.2? Why document a means for the user to >invoke with different command line arguments? > >Section 7.2: can you explain in more detail what IP packets you need >to send that cannot be sent using the existing IP interfaces on >Solaris? Rather than resorting to DLPI, is it possible to fix IP to >allow you to do what you need? > I don't know whether it is feasible to fix IP to send VRRP advertisements. Which utility or ioctl will be used if we change the IP code to support VRRP? > We've done this for DHCP, and it'd be >nice to have VRRP 'fixed' before integration. (For what it's worth, I >think the reference to PF_PACKET is likely out of place here. Solaris >uses DLPI where Linux would use PF_PACKET, but it's unclear to me >whether and wny VRRP needs either of these.) > >Using DLPI outside the context of ifconfig is a bit problematic, as it >inhibits DR. > >Section 7.3: this part talks about command line arguments specifying >interface information. If the daemon itself supports multiple >instances at one time, how do those command line arguments work? > > Each command uses an instance name or group name to manipulate a specific object. Please see the CLI spec. As said above, we will add its content to the design document. >Section 7.5: if Accept_Mode is False (the default), then how do you >prevent the non-owner from accepting and processing packets sent to >the virtual IP address? It looks like what you're doing is setting >static ARP/ND entries and leaving out the VNIC configuration. Is that >correct? > Yes. > If so, then what happens when we get one of those packets? >Won't we be tempted to send an improper ICMP Redirect?nnc > I don't quite understand. What kind of improper ICMP Redirect would be sent? > >Nit: in the last paragraph in this section, I think that "VRIP on the >physical interface" actually refers to the static ARP/ND entries, and >not any physical interface configuration. More importantly, nobody >should be switching between "owner" and "not owner" except by explicit >configuration commands, so the described switch shouldn't be needed. >It's not part of fail-over. > >Section 7.6: how are these changes made? Does something in the system >itself need to change, or is this just an administrative configuration >issue that needs to be documented for users? > The users should designate standard type or a non-router type explictly for a VRRP instance. Yifan _______________________________________________ networking-discuss mailing list [email protected]
