Gilles Schipper wrote:
>
> Contrary to many previous posts regarding this issue, from my experience it
> is not necessary to permanently enable bridging to support remote DTC
> operations.

I hate to disagree, but...

> The key word here is "permanently".

> The only bridging requirement associated with remote DTC operation occurs
> during DTC download operations originating from a download request from the
> host (either the HP3000 for host-based NM configurations or the OV
> workstation for Openview configurations.).

Even after downloading, AFCP is still a layer-2 only protocol.  You do
not need to configure an IP for your DTSLINK.  Communication occurs at
layer-2, MAC-to-MAC.  To make things interesting, HP invented the PROBE
protocol to avoid IPs altogether and still allow names to be used.
Where ARP broadcasts an IP and listens for the MAC, PROBE broadcasts a
name and listens for a MAC.  No IP at all, in fact, it is (was) all
done with 802.3 framing, not Ethernet.

> So, a very inexpensive and effective remote DTC operation requires the
> enabling of router bridging ONLY during a required DTC download operation,
> after which successful completion can sustain normal terminal and printer
> operations with bridging disabled.

There is a middle ground.  You do need to bridge the DTC MACs over to
the 3000, and the 3000s MAC over to the DTC, but that isn't all.  You
will have to bridge the multicast address as well -- this is how they
find each other.  They use multicast for download requests.  If you
check your DTSLINK you will see this:

> (MANAGER.SYS)# linkcontrol dtslink;status=all
> Linkname: DTSLINK   Linktype: IEEE8023  Linkstate: CONNECTED
> Physical Path:              10/4/0
> Current Station Address:    00-60-B0-20-A5-0F
> Default Station Address:    00-60-B0-20-A5-0F
> Current Receive Filter:     broad(1) any(0) k_pckts(1) x_pckts(0)
> Current Multicast Addresses:
>  09-00-09-00-00-01  09-00-09-00-00-03  09-00-09-00-00-04
>  09-00-09-00-00-06
       [...snip...]

Note the multicast addresses it is listening for.  The original HP MAC
vendor ID was '08-00-09', and the multicast ID is formed by setting
the low-order bit of the first byte to a 1, yielding the 09-00-09
HP-vendor-specific multicast.  That is what makes DTCs tick.  If you
look at your LAN link (whatever you call it):

(MANAGER.SYS)# linkcontrol utcnet;status=all
Linkname: UTCNET    Linktype: 100BT     Linkstate: CONNECTED
Physical Path:              10/4/8
Current Station Address:    08-00-09-BD-51-CA
Default Station Address:    08-00-09-BD-51-CA
Current Multicast Addresses:
 09-00-09-00-00-01

The real TCP link layer only listens to the 00-00-01 multicast (probe)
since it doesn't have to deal with DTC AFCP traffic or downloads, etc.

> However, in a very large majority of environments, it is entirely possible
> to avoid unscheduled DTC downloads, and so enable remote DTCs to operate in
> nornmal "routing" environments, where it would only be necessary to enable
> bridging for brief, known periods of time.

I don't think so on separate subnets unless you do some fancy probe
proxy setup with a knowledgeable device routing between subnets.  You
don't need full bridging, but you will need more than just the 3000 and
associated DTC(s) MACs, you need the multicast and possibly broadcast
packets bridged for downloads and probes.

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *