Erik Nordmark wrote: > > When we talked about this earlier my thinking was limited to the case > when the ngz has a unique subnet (could be on a unique physical, or on > a shared physical). > In that case it works to specify a default router for the zone. > > 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. > > Sorry for not catching this earlier. > > 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? > > I have tried to avoid making this feature only apply to Trusted Extensions, although that is the customer base that is requesting it. For TX customers each zone has its own subnet and its own interface. The primary use of TX is to provide cross-domain services for physically separate networks. Furthermore, the labeling policy provides the separation of routes because each subnet and router is assigned a unique sensitivity label. While it may be less useful for standard Solaris customers, we shouldn't prevent them from taking advantage of this feature. We just need to be clear that it is intended for zones with separate subnets.
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. For the record, I think much of the current verification of possible zone configuration conflicts that is done today in Solaris is counter-productive and is an obstacle to deploying large numbers of zones. The only useful verification is between the currently booting zone and other active zones. Anyone who has tried to boot 1000 zones into the ready state will appreciate what I am saying. It took 3 days of execution time just to verify the zonecfg XML device and network specifications in S10u4 beta! This became a showstopper which delayed the release of S10u4. --Glenn
