CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (07/01/88)
I must not have gotten the original message about the LAVC and router versus end node configuration that has been referenced recently. But I wish to add further information to this situation. Lets list the items that are known, either by materials (documentation and fiche) and line monitors. 1. The Ethernet protocol types that are defined for DEC are listed below. 60-01 dump assistance 60-02 remote console 60-03 decnet 60-04 lat 60-07 lavc This type is contained in every message packet going over Enet. The item to note here is that LAVC, LAT and DECnet have DIFFERENT ids. 2. In going over the fiche, a 'Fast Function Interface' (FFI) is part of the Enet driver code to enable very quick generation of the appropiate protocol packet depending on the originator of the message, either DECnet or LAVC for example. This also enables the Enet driver to 'divert' the incoming packets to the appropiate system, such as DECnet or LAVC. One does not know of, or care about the other. 3. The information in the DECnet database that is used for booting a LAVC node contains the Enet address, the disk and root to use and the initial botostrap loader routine. The load request at boot time is sent out with the Enet address. If the node has 'SERVICE' enabled on the Enet line/circuit, and the Enet address MATCHES one in its DECnet database, that node will respond, as best it can, to the load request and attempt to boot the LAVC node. This is a function of DECnet and is NOT limited to routers or end-nodes. It is a function of having 'SERVICE' enabled. There are checks made after the fact on its 'legal membership' based on passwords and group numbers, but this does not stop DECnet from trying to do the load. There IS an assumption here that the node that is responding to the load request is the 'boot node' for the LAVC, but the disk that is referenced in the DECnet database does NOT have to the same as the system disk for the boot node. In other words more then one disk can be used by the boot node for the purpose of storing the [SYS...] directory structure(s) needed to boot VMS. This is how the LARGE LAVC/CI clusters will get the needed directory structures. 4. After the load process is complete and the node forms/joins a LAVC, DECnet is not needed for the specific purpose of VMS operation in a LAVC. In point of fact, you do not have to have DECnet up on a satallite to use the VMS system. The limiting factor here is that you are limited to the capabilities of a single node processor and can not '$SET HOST' for example. You are NOT stopped from accesing SHARED disks, which are MSCP served, when DECnet is down. Once again, the MSCP information is going over Enet with the LAVC protocol packet type, NOT DECnet. The bottom line, from my point of view then, is that the only purpose for having a 'router' node in a LAVC is for the purpose of having a DECnet 'Cluster Alias'. This is a VERY nice feature of DECnet and not one to discarded lightly. With this feature, you can essentially define two (2) node names, and addresses, for a single node, and have DECnet respond to both of them. I have just worked on a LAVC which started life as two 3600 systems, with both defined as DECnet end-nodes. EVERYTHING worked fine, EXCEPT 'Cluster Alias'. There was NO tricks to be pulled on the boot or afterwards for this to work. One other item to keep in mind here. There is a SECOND type of 'Cluster Alias' in the DEC world and it belongs to the LAT system. A number of clusters, both CI and NI, have more then one 'service' named defined per CPU that terminal servers can 'CONNECT' to. Typically one service name is the name of the processor, and the second is the 'alias' that is used to get to ANY of the processors without regard to which one specifically. The LAT 'alias' is also, typically, the same as the DECnet 'alias' to avoid confusion. The VMS systems in the cluster have NO problems keeping these two seperate, due to having different Enet protocol types for both LAT and DECnet. Hope this helps with the question of 'to be a router or not to be'. :-) pdc Paul D. Clayton Address - CLAYTON%XRT@CIS.UPENN.EDU Disclaimer: All thoughts and statements here are my own and NOT those of my employer, and are also not based on, or contain, restricted information.