Van Der Hart, Kevin wrote:
This is in S10. We had applied host route reject rules to keep zones
from talking to each other. This is what was causing the problem
although I am not sure why. The rule creates a host route from the
global zone to the non-global zone with a -interface -reject. The
connection that is failing is from the non-global zone to the non-global
zone. However, removing the reject route fixed the problem.
That is consistent with the CR below.
The TCP reset generation is done in the kernel and prior to fixing that
CR the result is that this internally generated packet is sent as if
originated from the global zone.
With your reject routes that packet would be dropped.
Erik
Thanks,
Kevin
-Original Message-
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 1:24 PM
To: Van Der Hart, Kevin
Cc: zones-discuss@opensolaris.org
Subject: Re: [zones-discuss] Problem with lack of closed port response
on zones
Kevin Van Der Hart wrote:
When I telnet to any non-listening port on a global zone, I get
connection refused. When I telnet to any non-listening port on a
local zone that has a virtual address on the same NIC as the global
zone, I get connection refused. When I telnet to any non-listening
port on a local zone that has a virtual address on an alternate NIC
that is on a different physical network, I get no response and have
to wait for a long timeout. Performing a telnet to a port that has a
service listening responds normally. I have been able to recreate
this problem on multiple servers, different hardware platforms (280R,
T2000).
Oracle Application server requires being able to verify ports that
are not in use.
Any idea why I don't get connection refused only on zones on
alternate NICs? Any way to change this?
This might be related to CR 6453678 'TCP RST are routed as if they were
sent by the global zone'.
Do you see this in S10, or on Nevada/OpenSolaris? If on the latter,
which build?
Erik
___
zones-discuss mailing list
zones-discuss@opensolaris.org
