Erik Nordmark writes: > However, if the ngz's shares a subnet with some other zone, then the > current logic in the kernel isn't capable of supporting a different > default route for different zones. This is because the kernel check is > whether the gateway field in the default route is on the same subnet as > one of the zone's IP addresses.
There's another problem buried here, which is that the proposed feature doesn't delete the static routes when the zone is shut down. It doesn't delete them because it's trying to cover for the EEXIST case. I think the right thing to do is to remember when the "route add" attempt fails, and conditionally remove the route on zone shutdown. That potentially leaves a zone relying on a duplicate out in the cold, but since it's a misconfiguration anyway, it doesn't seem like a big problem. Needless to say, there are a few sharp edges here for the unwary user. The original design goal of Zones was simply for consolidation on shared networks, not separated ones, and stepping outside of that has been a fairly persistent source of pain. > Would it make sense to somehow restrict this property to the case when > the ngz has IP address(es) that do not have a common subnet with any > other zone on the system? If the "restriction" is in the documentation provided for the feature, then I would agree. Otherwise, I have to agree with Glenn that static checks against the configured zones don't necessarily do the right thing, as users are under no obligation to boot and run all installed zones all of the time. Glenn Faden writes: > I think it is a bad idea for try to verify that items specified via > zonecfg XML files are valid based on the state of the system at the time > the configuration is being generated. If any subnet verification were to > occur it should be at zone boot time. In practice, I don't feel this is > necessary, and adds considerable complexity. If it were to be done, I > think the logic should be in the route command itself. I'm not sure it really belongs there, either. For what it's worth, I've gotten several private messages from users who've been waiting for this feature. If nothing else, it's tapping pent-up demand. I just hope they can make good use of it. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> 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
