[Info-vax] DECserver/LAT across DECnet areas?

[Stephen Hoffman]

On 2023-07-22 23:53:18 +0000, Robert A. Brooks said:

> In the olden days, a terminal server needed a DECnet address in order 
> to be MOP downline-loaded.
> 
> That is, when an unsolicited MOP request would come in, Phase IV DECnet 
> would search its volatile database looking for a MAC address match with 
> the incoming request.
> 
> If a match was found, and there was a file defined with which that node 
> node could be loaded, then that node would attempt to fulfill the MOP 
> request.

Sort of.

With the DECnet Phase IV design with DECnet and MOP comingled, the 
DECnet address was "merely" the storage address for a database entry 
within an RMS file containing a few boot-related strings.

That MOP implementation "borrowed" persistent storage from DECnet.

And that wad of storage needed an address within the existing DECnet 
database containing DECnet addresses and host names and related details.

When the MOP boot request arrived, each MOP server listening on the 
segment scanned its own local database for a matching MAC address, 
using that MAC to locate the boot-related data, and—if a MAC match was 
found—served up the boot response.

> Later on, the advent of LANCP allowed MOP clients to be defined that 
> had no relationship with DECnet.

At OpenVMS V6.2, as part of the work migrating DECnet Phase IV from an 
integrated to an optional and separately-installed component of OpenVMS.

> I am less familiar with how Phase V sorts out MOP stuff; mercifully, 
> I've never had to debug the Phase V MOP implementation.

A common recommendation back then was to move MOP processing from 
either DECnet to LANCP.

> Neither the DECnet nor LAT protocols have anything to do with how a 
> terminal server is loaded via MOP.

Ayup. Or how an OpenVMS system is loaded via MOP, for that matter.

Apropros of nothing, LAT uses Ethernet 60-04. MOP uses 60-01, and 
60-02. 60-06 is reserved for customer fun and games. Probably also 
60-00, 60-08, and 60-09 now, too.

And apropos of a different MOP-related implementation: 
https://blogs.cisco.com/security/router-spring-cleaning-no-mop-required-again 


-- 
Pure Personal Opinion | HoffmanLabs LLC