In the event that the DTC loses power or otherwise needs to have its
configuration downloaded (from an HP3000 or HP9000 or Openview/DTC Manager
workstation), this will only work if:
1. bridging is enabled (which is necessary in any case to make the DTC
function across a WAN)
AND
2. filtering is DISABLED.
The problem with this combination is that the network traffic can be
unacceptably high if bridging is enabled without filtering.
The soultion to at least one common - perhaps the most common - problem
(power failures) could be accomodated by ensuring each remote DTC is
protected by a UPS.
If DTC downloads are anticipated, turn off filtering at all associated
routers, effect the download, then re-enable filtering.
That leaves the scenario of unanticipated DTC download requirements not
involving power failures - and I can't think of too many such scenarios.
Nevertheless, the only option in this case (other than dealing with the
situation at the time by trrning off filtering, etc.) appears to be
purchasing a modern DNS-client-capable DTC (such as DTC72) and using (or
purchasing) a DNS server in a Unix, NT, Linux, or some other
DNS-server-capable O/S. Currently the HP3000 is not capable of serving as a
DNS server - unless one of Mark Bixby's recent ports renders that statement
incorrect.
At 02:45 PM 98/06/24 -0400, you wrote:
>We have a DTC on the other side of a FrameRelay link at a remote site.
>For the DTC to download it's code from the HP and to then print, etc.
>bridging is turned on on the subnet the HP is hooked to, the subnet the
>FrameRelay router is hooked to, the FrameRelay routers here and at the
>remote site. Everything was working OK last week (up until Friday) and
>Monday. Now the DTC cannot download code. Here is the sequence of
>events:
>Last Friday: major network problem. Routers and switches lost their
>minds. Network guys worked all day to restore sanity. Late Friday
>everything working locally, remote DTC status: seems OK.
>This weekend: loaded new code onto Excellar switch
>Monday: printers attached to remote DTC working fine
>Tuesday: lost connection to remote site as indicated by loss of IPX
>(Novell) and IP connectivity. Could not ping remote DTC. Various network
>stuff reconfigured, got IPX and IP back, can ping remote DTC. About an
>hour later notified that printers on remote DTC not functioning. Asked
>person at remote site to power DTC off and on. DTC remains at "trying to
>find host" stage, with (DTC16MX/RX) a zero and a flashing period. DTC
>now brain dead, not even smart enough to respond to a ping.
>
>So now we are dealing with vendor support, and these guys are very
>confused by the "off brand" of protocol that the DTC to HP link uses.
>Recently someone posted the name of this protocol, and I printed out the
>message, which I promptly lost. I need to be able to talk about this
>protocol to these guys, and I know very little about it. I assume that
>the DTC throws a packet similar to a UNIX bootp packet out, and if the
>HP receives the packet the HP throws some info at the DTC and then
>starts the code download. When the download is complete, the DTC can
>transmit back and forth to the HP and respond to some IP/UDP requests,
>but the conversation between DTC and HP is not really TCP/IP, is not
>routable, and has to be bridged. Can anyone tell me anything more about
>DTC to HP connectivity?
>
>Thanks.
>
>
---------------------------------------------------------------------------
Gilles Schipper
GSA Inc.
HP3000 & HP9000 System Administration Specialists
300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
Voice: 905.889.3000 Fax: 905.889.3001
Internet: [log in to unmask]
---------------------------------------------------------------------------
|
