On 11/15/12 10:57, Habony, Zsolt wrote:
I have serious problem with routing of non-global zones
If I define a "defrouter" for a local zone, its route pops up in the global
routing table, and global zone really starts to use it !!
Though my intention is obviously to route a local-zone traffic to specific
network, it breaks the functionality of the global zone.
# netstat -rvn
IRE Table: IPv4
Destination Mask Gateway Device Mxfrg Rtt Ref Flg Out In/Fwd
-------------------- --------------- -------------------- ------ ----- -----
--- --- ----- ------
default 0.0.0.0 10.x.x.x 1500* 0 1 UG 3417722 0
default 0.0.0.0 10.x.x.x igb0:1 1500* 0 1 UG 1633463 0
default 0.0.0.0 139.x.x.x nxge1 1500* 0 1 UG 201645 0
I have found an earlier post, and would like to know if it is still the case:
That post is still correct.
In my case, we have a jumpstation, to administer the servers, and since I
installed the local zone wiht a defrouter to the external network, my
connection to global zone from jumpstation hangs, and then breaks. snoop
shows, that e.g. pinging from jumpstation works for a while, then responses
suddenly directed to the new default route, which is obviously not for global
There are some very complex workarounds mentioned in the previous posts, is
there a better one available now ?
The easiest solution for your case would be to add a static route to the
# route -p add jumpstation router_to_jumpstation
I question whether that is really what you want, though. That would make it so
that processes running in the zone would be able to connect to the jumpstation,
unless there are firewall rules in place to prevent it.
The most common reason for using shared-stack in Solaris 10 is because exclusive
stack requires dedicated hardware. The Solaris 11 networking stack removes that
limitation - exclusive stack can be used in a way that multiple network stacks
are associated with a single physical nic. Because of this new capability,
exclusive stack is the default in Solaris 11.
Solaris 11 also introduces the solaris10 brand. The combination of exclusive
stack improvements and the solaris10 brand would likely be good for your
scenario. You could install Solaris 11 on a server and migrate your Solaris 10
native zone from where it is at to the new server as a solaris10 branded zone.
Of course, if your application is supported on Solaris 11, there is no need to
use the solaris10 brand - you could just use the "solaris" brand, which is the
default in Solaris 11 and as such does no emulation.
Solaris Core OS / Zones http://blogs.oracle.com/zoneszone/
zones-discuss mailing list