Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!encore!xylogics!loverso From: loverso@Xylogics.COM (John Robert LoVerso) Newsgroups: comp.sys.encore Subject: Re: An Annex by any other nameserver would smell... Message-ID: <654@xenna.Xylogics.COM> Date: 28 Mar 89 16:17:16 GMT References: <68@a.coe.wvu.wvnet.edu> Reply-To: loverso@xylogics.UUCP (John Robert LoVerso) Followup-To: comp.sys.encore Organization: Xylogics, Inc., Burlington MA Lines: 74 [I've limited response to comp.sys.encore] In an article manager@a.coe.wvu.wvnet.edu (Cris Fuhrman) writes: > After [an Annex] boots, one can access nodes outside of our local domain > (i.e. outside of .wvnet.edu). However, after a period of time, if one > tries to access even the same node as before, the address is resolved, and > the internet number is added to the cache hosts table, but the Annex > responds with (an immediate response, i.e. no delay) > > Trying... > CLI: Network is unreachable. This is an IP-level routing problem. I.e., you might have resolved the hostname and gotten an IP address, but that IP addresses lies on a network the Annex does not have a route to. Since you say you can reach this host immediately after the Annex boots, it would seem that you have some routes being prepped by the "gateways" file [from your boot servers /usr/spool/erpcd/bfs directory]. However, you are apparently later loosing these routes, either because they are marked `active' (and no other host is advertising the route using RIP (routed)) or they are marked `passive' but getting deleted and then replaced by some other active RIP agent. The first case would seem more probable. If so, change the route(s) in question to be hardwired (although passive would do). You can check the Annex routing table with the command "n -r" (netstat -r). Passive routes are marked with the "P" flag, hardwired with the "F" flag, and active with neither flag. > As I said, the nameserver features appear to be working, and in fact our > ethernet is working, as I can telnet to remote hosts right after a boot. Just to point this out, a nameserver provides an entirely different service than an IP route. The former allows an name to be associated with an IP address, while the later informs the system which way to send packets destined for a host somewhere on the network. > 1) What's the difference between BIND, IEN_116, and RWOD name servers? > 2) Are the RWOD machines the ones that show up in the hosts table with > a system load factor? `rwhod' [note the spelling] is a broadcast-based status reporting mechanism used in 4BSD UNIX. The Annex listens to these broadcasts and uses the information it collects (including up/down and "load factor") to prep its hosts table. This can be disabled with the "rwhod" per-Annex parameter in R4.0 and later releases. IEN-116 is a spec for a very simple "name server" that just provides a trivial mechanism for looking up hostnames. It is sufficient for providing name service to small-ish networks that are not connected to the Internet. Bind is an implementation of an Internet Domain Name server. It happens to be the one developed at Berkeley that was part of 4.3BSD (and its descendants). It provides a very sophisticated, distributed, name service that is [for almost all hosts] a requirement for participation in the Internet community, and is recommended even if you aren't connected to the Internet. > I have a couple of other minor questions about Annex configurations in > general, and I'd like to pick someone's brain about them if they'd be > willing to exchange some info. I'm sure there are many people who read info-encore [comp.sys.encore] (and soon in "info-annex") who can either help you if you post questions, or would be interested in the responses/discussions. John -- John Robert LoVerso Xylogics, Inc. 617/272-8140 loverso%Xylogics.COM@Encore.COM Annex Terminal Server Development Group encore!xylogics!loverso [formerly of Encore Computer Corp]