On Nov 30, 2007 7:37 AM, Paul Van Der Zwan <[EMAIL PROTECTED]> wrote:
> Host 1:
> global zone   bge0 192.168.1.1/24
>                   vni0  10.1.1.254/24
> zone1          vni1  10.1.1.1/24
> zone2          vni2  10.1.1.2/24
> zone3          vni3  10.1.1.3/24

When you try this configuration, go into any zone listed above and try
this (when it is safe to reboot):

nslookup anything.com 10.1.1.100

The 10.1.1.100 address must not be reachable.  The last time I tried
this in Nevada it causes a panic.  The last time I tried it on S10 it
causes one kernel thread to spin (mpstat will show one CPU at 100%
sys).

Through bugs.opensolaris.org I opened a bug (6422863) but now I cannot
see that bug through bugs.opensolaris.org.  Anyone from Sun care to
comment?

My simplified way to trigger this was:

ifconfig vni0 plumb
ifconfig vni0 10.0.0.1 up netmask 255.255.255.0 broadcast +
ifconfig vni0 xmit
nslookup 1.2.3.4 10.0.0.4

Zones were not needed to cause this problem.  However, my purpose for
doing this was to make it so that I had an "internal" communication
path between global and non-global zones.  That is, every global zone
would have vni0 at 10.0.0.1 so that non-global zones could have a
reliable address to reach the global zone at.

I just tried to reproduce on S10U4 + all current patches on a T5120.
As soon as I ran nslookup, the following appeared on the console:

ip: vni0: DL_UNITDATA_REQ failed: DL_UNSUPPORTED

mpstat showed that one strand went to 100% sys and 14 other strands
went to between 9% and 59% sys for a total of 345% sys.  Prior to
running nslookup it was 100% idle.  Overall system utilization went
from 100% idle to 3% user and 6% sys (on a 64 processor system).

When I typed reboot, the console began getting spammed with the same
error message above.  The messages were interspersed, possibly
implying that multiple threads were writing the messages.  I had to
hard reset the system to get back.

Be careful with vni.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to