On Sun, Sep 27, 2009 at 1:18 PM, James Carlson <carls...@workingcode.com> wrote:
> Stefano Pini wrote:
>> The steps above configure perfectly all the 9 NGZ and they run well.
>> The problem is on the Global Zone:
>> the clients that use GZ to manage the system get diconnected regularly
>> or sometimes can't connect!
>> When that happens, trying traceroute to clients from GZ console seems
>> that it uses a bad defrouter, the one on another vlan, not the right
>> one!!! (for example 10.1.117.254 on bge17000 insted of 10.1.115.254 on
> When you're in the global zone, all of those interfaces, subnets and
> default routes are the same. There's no "special" one reserved only for
> the global zone's use. The global zone can (and will!) use any of them.
> If they're not actually usable by the global zone, then you've got a
> Possible solutions include:
> - Use exclusive stack zones instead. If you do that, though, you
> won't be able to have groups of zones sharing a single interface.
> (You could do something like this with VNICs, but not on S10, as
> S10 doesn't have those.)
> - Direct the traffic originating from the global zone using IP Filter.
> You could filter based on source address and use the "on" keyword to
> direct that traffic to go out via a particular interface, just as
> your desired default route would do (if it worked).
> - Stop using default routes, and use network specific routes. If the
> networks that the global zone must reach are distinct from the ones
> that the non-global zones must reach, then you should be able to
> come up with a set of routes that will direct traffic appropriately
> based on remote address. (A routing protocol may help.)
> - Modify your default routers so that they know how to deal with
> traffic from the global zone.
The standard deployment mechanism that I have been using for 3+ years
involves having the global zone and non-global zones on different
subnets. In my case, I use link-based IPMP and as such there are no
global zone interfaces that are up on the networks that the global
zone is not supposed to use. I have had absolutely no problems like
those described by Stefano with this configuration, despite having a
sizable deployment. As such, I know that either there is a workable
configuration or there is a regression.
Note that I have had problems with this configuration WRT zone
interfaces becoming the primary(? - that is, "not a virtual") IP on a
given NIC. Those problems should no longer be a problem. Also, prior
to the defaultrouter property on zone network interfaces, it also
required some customization to the zone boot process such that after
the first zone on a network plumbed its address, I would then have to
add the new default route.
zones-discuss mailing list