On 11/15/12 10:57, Habony, Zsolt wrote:


I have serious problem with routing of non-global zones shared-ip config.

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 10.x.x.x 1500* 0 1 UG 3417722 0
default 10.x.x.x igb0:1 1500* 0 1 UG 1633463 0
default 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 zone traffic.

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 jumpstation:

# 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.

Mike Gerdts
Solaris Core OS / Zones                 http://blogs.oracle.com/zoneszone/

zones-discuss mailing list

Reply via email to