Edward Pilatowicz wrote: > i can compleatly imagine people trying to do what you describe > below. which is why i requested that the tools fail if a user > tries to setup this configuration. it's not just enough to > document this limitation. > I can't see how punishing the customer is a winning strategy. The proposed implementation supports the scenario that Ken Powell has described. Your proposal doesn't. FYI, these systems are currently being used in critical government installations and the customer has requested an enhancement (which has been escalated) to simplify the administrative complexity. Their current workaround is untenable.
--Glenn > On Wed, Jan 30, 2008 at 03:35:44PM -0500, Ken Powell wrote: > >> Glenn Faden wrote: >> >>> 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 customer I know about has a more complex situation. They have >> multiple physically independent networks, but some of the networks carry >> information for multiple compartments. This indicates multiple zones >> will need to map to the same subnet. I believe in their case, all the >> non-global zones on a given subnet will have the same default route. >> >> Ken >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc at opensolaris.org >>
