CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (06/17/88)
Ed Thierbach has asked the following questions dealing with terminal servers and their behavior during a load request over the Enet. > My company is expanding quite rapidly,, and we're connecting local > Ethernets around the country using Bridge IB/3 bridges. We've run into an > subtlety: when a DECserver 200 generates a load request in our > West Chester office, my 8300 in Washington, DC is the one that ends up > performing the load. > 2 questions: > 1 - Why is the 8300 elected to do this? The DS200 software is installed on > virtually all machines on the (extended) Ethernet, including ones in the > same city as the server. There are several things that go into which CPU will perform the load function for a terminal server in response to a load request. The first is to insure that the systems that have the DS200 software installed on them have 'Service' enabled on the CIRCUIT AND LINE that is used by DECnet to get to Enet. This can be verified by doing the following command: $MCR NCP LIST CIRCUIT xxx CHAR $MCR NCP LIST LINE xxx CHAR where xxx is the interface (ie. UNA-0) that is used on the machine to connect to the Enet. Should you find that SERVICE is not listed for the line, you should enable it with the following command. $MCR NCP DEFINE CIRCUIT xxx SERVICE ENABLED $MCR NCP DEFINE LINE xxx SERVICE ENABLED Note here that the PERMENANT DECnet database is being modified, and for the change to take effect, you have to shut the network down ($MCR NCP SET EXEC STATE OFF) and then start it back up again ($@SYS$MANAGER:STARTNET.COM). The other item to check for is the various terminal server node names in the DECnet database should have the following defined for each. Node Name Ethernet address Load file Dump file This can be verified by doing the following command: $MCR NCP SHOW NODE yyy CHAR where yyy is a terminal server node name. The 'load' file name is inserted into the DECnet database by the MOM$LOAD:DSVCONFIG.COM file that is used to maintain a database of terminal servers and associated information. If the DSVCONFIG.DAT file is simply copied to each node in the network, but the DECnet database is not updated against it, then that node will NOT respond to the load request because the node name, in the nodes volatile DECnet database does not show it as having to do anything for it. It simply records that a new node is available on the network and goes on its merry way doing other things. In order to maintain a 'common' database of terminal servers, I recommend that one version, on a particular CPU, of the database be used by EVERYONE working the servers and that a batch job be run each night to copy this database to all the other nodes that perform load functions for terminal servers. The item to watch here is that in the DSVCONFIG.DAT file, the type of Enet interface, ie. UNA-0, is stored in EACH record of the data file. This will cause problems on any other type of machine that has a DIFFERENT type of Enet interface, ie. BNT-0 for the 8XXX systems. Our nightly job also performs a bulk line mode edit of the file to change the field to match the type of interface on the machine that is being copied to. Then what you want to do as the last step of the nightly batch job is to update the DECnet database from this new DSVCONFIG.DAT file. This can be done with the command '$@MOM$LOAD:DSVCONFIG.COM RESTORE'. > 2 - Is there any way to cause load/dump/etc requests to ba handled by only > "local" nondes (i.e. on the same local Ethernet segment, in the same > city)? This could in fact be another reason why some machines are not doing the load function, given that the items listed above are not the cause of the problem. With some Enet bridges, they can be set to disallow certain 'types' or 'classses' of messages from being passed through them. The result is that some message packets can be isolated to segments between bridges and thus cut down on the overall Enet traffic. The common one to cut out is LAVC traffic from going through the entire Enet. The side benefit here is that conflicts between satallitte/boot nodes in different LAVC clusters is eliminated by this method. You should consult the manuals or call the seller of the bridge, and ask how to check, and/or set, the blocking of different message packet types. By doing this you would accomplish what you asked for in the above question. The one draw back is that should you implement this, and the 'local' node AND terminal servers die, and do not reboot fully, then those people on that segment will have dead terminals for the duration of the outage. Even if the system that they would 'connect' to is not on that segment. I would recommend against doing this as the typical 'load request' function is not used to often, hopefully, and is not that lengthy a process to go through. In all probability, the closest node to the terminal server requesting the load will perform it anyway. The multi-cast addresses for Dump/Load assistance is 'AB-00-00-01-00-00'. The Ethernet protocol packet types are listed below. 60-01 Dump/Load Assistance 60-02 Remote Console 60-03 DECnet 60-04 LAT 60-07 LAVC Hope this helps with the problem. 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.
thierbac@umbc3.UMD.EDU (Ed Thierbach ) (07/09/88)
Many thanks to Paul Clayton for his help with DECserver loading, and for the
Ethernet packet types (those will come in handy for filtering later).
After he sent his reply, I checked into things and foud two items of interest:
1) Service was not enabled in the DECnet databases of all machines; I fixed
that one.
2) DECserver 200 software version 2.0 has added a new parameter to DSVCONFIG:
@DSVCONFIG SET_CIRCUIT <circ-id>, which will allow you to have a central
DECserver database stored in SYS$COMMON:[DECSERVER], and then set the
proper service circuit name for each node in the cluster. For example,
if the service circuit is stored as UNA-0 in DSVCONFIG,DAT, you can use
@MOM$LOAD:DSVCONFIG SET_CIRCUIT BNT-0
to set the proper circuit ID for your BI-based machines.
Thanks again!
-Ed Thierbach-
-Roy F. Weston, Inc.-