Operating System - Tru64 Unix

Tru64 BIND Client won't stay working

 
BrianT_1
Regular Advisor

Tru64 BIND Client won't stay working

I'm using a Tru64 4.0E Alpha that I had to rebuild after a crash. I can't get the BIND client to resolve names. I've used bindconfig to set it up and all the values and files appear correct. rc.config shows BIND is configured as a client and svc.conf shows hosts=local,bind,yp. /etc/hosts contains the correct values. when I try to look up a host, though, it fails and I can't ping any of the name servers. As far as I know, my routes are correct. Could this me a matter of the route daemon not working? I can access the system via telnet and I can telnet out from it as well using IP addresses, but not to all the systems I need to reach, so I think there's something wrong with the routing. How do I check?
6 REPLIES 6
Steven Schweda
Honored Contributor

Re: Tru64 BIND Client won't stay working

> [...] when I try to look up a host, though,
> it fails [...]

Actual command? Actual results?

> hosts=local,bind,yp.

Are you using YP (NIS)?

> As far as I know, my routes are correct.

As a non-psychic with no information from
you, how can I argue?

> Could this me a matter of the route daemon
> not working?

Are you running routed (or whatever), or are
you using static routes?

> [...] I think there's something wrong with
> the routing. How do I check?

netstat -rn
BrianT_1
Regular Advisor

Re: Tru64 BIND Client won't stay working

> Actual command? Actual results?

Node> nslookup something
*** Can't find server name for address 10.32.31.220: No response from server
*** Default servers are not available

> Are you using YP (NIS)?

No, I just accepted the defaults.

> Are you running routed (or whatever), or
> are you using static routes?

routed.

> netstat -rn

Node> netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
Netmasks:
Inet 255.255.192.0
Inet 255.255.255.0

Route Tree for Protocol Family 2:
10.33/18 10.33.1.99 U 29 56257 tu0
127.0.0.1 127.0.0.1 UH 1 0 lo0
192.168.1/24 192.168.1.179 U 1 262 tu1
BrianT_1
Regular Advisor

Re: Tru64 BIND Client won't stay working

I don't see the default gateway in the netstat output, but I know it's defined necause it's in /etc/gateways.

net 10.0.0.0 gateway 10.33.0.11 metric 1 active

and this is in routes

default 10.33.0.11
Steven Schweda
Honored Contributor

Re: Tru64 BIND Client won't stay working

> Route Tree for Protocol Family 2:
> [...]

Ok. And what are the addresses of the name
servers? (Do you have a route (or routes) to
them?)

> I don't see the default gateway [...]

I've never used routed, so I know nothing,
but I wouldn't bet that anyone looks at
/etc/gateways (or any other static route
stuff) if you use routed. Knowing nothing,
I'd need to look at the "rc" scripts to see
who does what when at system start-up.

> 10.33/18 10.33.1.99 U 29 56257 tu0

> default 10.33.0.11

And 10.33.1.99 is not 10.33.0.11.

Again, I've never tried mixing a static route
into a routed situation, but you might try
something like
route add default 10.33.0.11
(or whatever syntax "man route" suggests) to
see if that helps. (See if "netstat -rn"
actually changes, too.)

Do you have any other, similar (working)
systems? How are they configured?
BrianT_1
Regular Advisor

Re: Tru64 BIND Client won't stay working

By using the route command to add the default route manuall, the BIND client started working. While I don't understand why /sbin/init.d/route didn't pick it up from /etc/routes, I at least know what to do if the problem recurs. I can take my time figuring out why the problem occurred. Thanks.
Steven Schweda
Honored Contributor

Re: Tru64 BIND Client won't stay working

> I'd need to look at the "rc" scripts [...]

I can see them now. I see no one looking at
"/etc/gateways":

urtx# pwd
/sbin/init.d
urtx# grep gateways *
urtx#

but "/sbin/init.d/routes" does seem to
consider "/etc/routes". Around here:

urtx# cat /etc/routes
default 10.0.0.1
urtx# cat /etc/gateways
urtx#

urtx# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Fri Mar 20 20:19:48 CDT 2009

Things may have been different in the old
days, of course.