[brandz-discuss] lx brandz on intel: nslookup/dig failures

[Nils Nieuwejaar]

On Fri 08/04/06 at 23:03 PM, eric.enright at gmail.com wrote:
> On 8/4/06, Wolfgang Engelien <woe2001 at med.cornell.edu> wrote:
> >At 11:25 PM 8/3/2006, Eric Enright wrote:
> >>Ping works for me, but nslookup and dig both give me this:
> >>
> >>$ nslookup google.ca
> >>;; reply from unexpected source: 192.168.0.1#53, expected 192.168.0.1#53
> >>;; reply from unexpected source: 192.168.0.1#53, expected 192.168.0.1#53
> >After these two lines I get
> >
> >;; connection timed out; no servers could be reached
> 
> I think I got something similar with dig; it had a little more output
> than nslookup.

We have found the bug (in our emulation of recgmsg()) and it is fixed in
our internal tree.  It takes a while for these fixes to propagate to
OpenSolaris.org, but rest assured that it is coming.  In the meantime, NIS
is working properly, if that's an option for you.

> It is CentOS 3.5, installed from the tarball available on the brandz
> site.  I don't know if it's been updated or anything, I downloaded it
> when brandz was first released.

We have a new(ish) tarball available now, based on CentOS 3.7.  If the old
one is working for you, there's no need to update it.

> >>My zone is configured to be on the same subnet as the global zone,
> >>however.  If you create your own private one for zones, then the
> >>routing becomes a bit more complicated and you need to play with
> >>ipfilter.  Which setup do you have?
> >
> >My zone is actually on a different subnet. I will put it on the same
> >subnet to check if it makes a difference.
> 
> Hopefully that will help.  But I am unsure if this is "correct" or not
> as I now get a LOT of syslog warnings with this message:

It is much easier to have your non-global zones on the same subnet as your
global zone.  When configured that way, everything should Just Work.  If
you try to configure a private subnet just for your non-global zones, there
is some manual routing magic required to allow them to reach the outside
world.

> ip: [ID 903730 kern.warning] WARNING: IP: Hardware address
> '00:0e:35:13:31:45' trying to be our address 192.168.000.050!
> 
> and for 192.168.0.101.
> 
> Perhaps someone else can comment on this?

This means that the IP address you gave to your zone is already in use by
another machine on your subnet.  You just need to use zonecfg to give it an
address that isn't currently in use.

Nils