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%
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
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 18.104.22.168 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.
zones-discuss mailing list