Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!bloom-beacon!bu.edu!bu-it.bu.edu!kwe
From: kwe@bu-it.bu.edu (Kent England)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: U-B NIU's resolving names across cisco Router
Message-ID: <71989@bu.edu.bu.edu>
Date: 10 Jan 91 18:45:34 GMT
References: <31375@boulder.Colorado.EDU>
Sender: news@bu.edu.bu.edu
Reply-To: kwe@bu.edu
Organization: Boston University Information Technology
Lines: 39

In article <31375@boulder.Colorado.EDU>,
 Tim.Raymond@UVM.EDU (Tim Raymond) writes:
> 
> We have many Ungerman Bass NIUs sitting on subnets.  The subnets are
> connected by a cisco AGS router.  We have the NIUs configured to
> resolve names using DNS.  We are running UB Netone Software Ver. 16.1.
> Our AGS is running 8.0(13) -- soon to be 8.2(1).
> 
> The problem:
> 	For names in the DNS db, all is well (the correct address is found).
> 	For names not in DNS:
> 		For two NIUs on the same subnet, all is well (the correct
> 						address is found.)
> 		For two NIUs not on same subnet, the name
> 			is not resolved to an address.
> 
> Whatever UB NIUs send out to resolve names is not getting passed by
> the cisco box.

	You are correct.  Before TCP, U-B used their own variant of
XNS.  When they offered TCP/IP, they did not convert all of their s/w
to TCP from XNS.  Obviously, you can't boot an NIU from pre-TCP PROMs
using TFTP.

	One of the features U-B left in their TCP s/w was their old
name resolution protocol.  Since this is a non-IP protocol, the cisco
will not pass it across subnets.  Within a subnet, the old name
resolution protocol works just fine.  I believe 16.1 tries DNS first
and then U-B resolution.  This means your local collection of NIUs
does not need a PC based name server to interoperate amongst
themselves.  Neat.

	cisco XNS may be compatible with U-B XNS, in which case you
could assign XNS addresses and route XNS on your multiprotocol net.
Or you can find out what the Ethernet type code of the U-B name query
is and bridge that across the ciscos.  Beware, it's an Ethernet
broadcast query.

	--Kent