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 on bge17000 insted of on
>> bge15000)
> 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
> problem.
> 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.

Mike Gerdts
zones-discuss mailing list

Reply via email to