EMU User Guide

Abstract

Preface

• Introduction and history
• Installation
• User guide
• Limitations and further information

EMU (Ethernet Monitoring Utility) is a system that listens to the attached Ethernet and records all addresses appearing on the cable. For each address found it also records the protocols enabled on that address and for selected protocols it can extract information useful for network management purposes. It then uses this database to locate other nodes in the wide area network and initiate monitoring functions.

Some of the basic features of the system follow:

• The system is fully automatic. The system builds and formats the database without operator assistance or intervention. All monitoring and control subfunctions start and run without intervention and in fact, no operator assistance is ever required for normal operation.
• An alert screen provides the operator with timely reports on new addresses appearing and for selected protocols, changes to configuration parameters, fault reports and performance reports.
• A number of system management utilities are provided. These utilities are all menu driven and self explanatory.
• A versatile reporting command allows the operator to extract selected information to a user defined and formatted file.This may be useful for input into other management tools and/or reports.
• A comprehensive query facility allows operators to view the database contents. Nodes can be selected by many criteria.

1. Full automation. The system is designed to assist the user in monitoring and managing the network, not the reverse as in many current systems. All data in the database is derived from the network; there is no user input possible at this level. This ensures data integrity and eliminates the burden on the user.
2. Full integration. The system maintains full cross referencing of all addresses where there is sufficient information. While it is necessary to implement each network as a separate entity, the user sees only single devices attached to many networks, or many networks with devices attached. This arrangement allows the system to more effectively monitor any single device using the multiple protocols it supports and allows more accurate and complete reporting of any device.
3. The system itself should require no maintenance. All processes are self configuring, self monitoring and self tuning.
4. The complexity of the network itself should be hidden. The system should be fully usable by non-network personnel to extract useful information; The simple question "How is the network performing?" should be answered simply, completely and with qualification.
5. The system will acquire and store sensitive information. It is essential that this system incorporates controls that protect this information, or even the fact of it's existence from unauthorised disclosure.

The next stage was to recode the logic into programmes and it was about that time that the major systems that we use today came out (SunNet manager, HP Openview, Netview and DECMCC) and the EMU effort would have ended there had any of these systems adhered to these (to us!) most basic of principles. The time saving achieved by using the system to monitor the network was used up by having to monitor the system itself. A further problem was that while all the manufacturers claimed multivendor capability the claims in some cases were a bit thin and in no case was integration achieved. For example DECMCC had a DECnet module, a TSM (Terminal Servers) and an SNMP module all which worked but internally did not intercommunicate. Thus should a node fail all the individual modules reacted independently without regard for each other. It was apparent at the time that this failure not only complicated the interface and the network manager's task but had this integration been included, the system could then use it's understanding of the various protocols present to enhance it's usefulness. For example, should the DECnet module report a failure on a node, the first action the manager would normally take is to access the node on an alternate protocol to determine if the node is down or if DECnet has failed. As this is a routine effort, this routine should be built into the system so that failures can be reported more completely and in context. This became the third design principle: EMU would take 2 views of the network equally. The network as a collection of devices cooperating on 1 or more networks and as a protocol in which many devices cooperate. It is a subtle but essential distinction.

The first 3 versions became experimental and proof of concept and for version 4 an architecture was drawn up to guide a more formal effort at implementing what was learned so far. Version 4 was successful in that it ran without major change for about 3 years and it even managed some commercial success but changes in the networking world began to overtake it. The most basic flaw was that EMU assumed (accurately at the time) that each device on the network had exactly 1 LAN address and this was used as the key in all databases. As this became less and less true and EMU changed to accommodate, it was clear that the original design was inadequate. A decision to re-engineer the system became an opportunity to re-architect it and remove some of the built in restrictions. Most notable among these restrictions was the over adherence to listening and not talking on the network. It was clear that listening was a good mechanism to build the initial picture but that polling was needed to complete it.

To shorten this narrative to it's essentials, suffice to say that in the 3 years since this decision was taken, 18 months was spend exclusively on the architecture document with the remaining time spend on coding and testing the implementation. The current version implements about 60% of the architecture.

1. Create the root directory for the EMU system. This can be on any disk at any level. The system resides in various directories under this to a level of 3 max so make sure you do not create the root at a depth greater than 4.
   $CREATE/DIR disk:[emu]
2. The files created in the next section will consume about 75,000 blocks of disk space. The running system will (very dependant on the size of your network) will consume a further 50,000 - 100,000 blocks.
3. Set default to this directory and backup the saveset:
   $BACKUP/LO Tape:[...]*.*;*
4. Edit [.SRC]EMU_LOGICALS.COM and replace the first executable line with the device and directory you created in step 1. Remember to include the final '.' in the directory spec as this will become a rooted logical.
5. Execute EMU_LOGICALS.COM:
   $ @[.SRC]EMU_LOGICALS
6. Ensure you got the expected effect:
   $SHO LOG EMU*
   You should see a list of directories under the directory you created in step 1.
   $DIR EMU5_SRC:
   You should see a list of .MAR files
7. All being well set default to EMU5_SRC: and execute BUILD:
   @BUILD
   Answer 'YES' to the question 'Compile all subroutines (YES/n)'
8. The system will then build the necessary libraries
9. A number of warning messages will be displayed during compilation. These can be ignored as long as the process continues to completion.
10. When finished (Maybe 20 min or so) answer 'YES' to the question
    Compile all programs? (YES/n)
    This will build the system on the current version of VMS on the current architecture.
11. A number of warning messages will be displayed during compilation. These can be ignored as long as the process continues.
12. All EMU processes run under the system account. Ensure this account has the required quotas. A copy of one that works appears at the end of this list.
13. Ensure LAT, DECnet and UCX are all started.
14. Ensure LATCP can see all services:
    $MCR LATCP SET NODE/USER=ENA=0-255
    The LAT processor will see all LAT devices on the net but updates from the local (VMS created) database. If the above is not done, EMU will likely find LAT nodes that VMS knows nothing about.
15. Finally, start the system:
    @EMU_SRC:START_EMU
    You may clear the databases and start fresh each time you start the system by answering 'y' and confirming this to the prompts. For excessive safety, on the first startup, do this.
    You may clear the log files on each startup. Generally a good idea (after review). There is no mechanism to control the size of these files automatically and while generally well behaved can, on occasion become churlish.

Note: EMU enables promiscuous mode on the local Ethernet device and attempts to read every packet on the cable. In most environments this causes very high I/O on the system and often results in significant impact on the node. It is strongly advised to run it on a standalone, dedicated VMS system. Any valid VMS system with a working copy of UCX is adequate.

Figures 3-1 Menu System Schematic

3.3 User Interface

1. Device. This items allows querying and reporting on devices. There are no privileges required to display this item.
2. Network. This items allows querying and reporting on networks. There are no privileges required to display this item. This is not yet implemented.
3. System. This item allows access to the system management/monitoring facilities. If the user does not have OPER privilege, this item is not displayed and access to the underlying facilities is barred.

1. Query. Allows access to the live database. Using a further menu the user selects individual devices to display.
2. Report. Allows access to the reporting subsystem. Here the user may create, define and view device reports. See reporting menu for details.

1. Name. A nodename or any part of a nodename with Wildcards is input. A nodename may be up to 400 printable characters in length.
2. LAN. Either an address or protocol type can be input. In the case of an address the user must input in form:
   xx-xx-xx-xx-xx-xx
   where x is either a hexadecimal digit or wildcard.
   The protocol type query is not yet implemented.
3. IP. An IP address, or any part is input in form:
   ddd.ddd.ddd.ddd
   where ddd is a decimal digit in range 0-255
4. DECnet. A DECnet address or any part is input in form:
   aa.nnnn
   where aa is a decimal number in range 1-63 and nnnn is a decimal number in range 1-1023.

1. Top section displays the device. If a name is known the name is displayed, if not, the address is used.
   The class and device are also displayed. These fields are not yet implemented but in the released version, these will correspond to a user settable field showing relative importance and generic device type such as bridge, host, router etc.
   Once a particular protocol is selected, the time the device was last heard and the time the device was last updated on the selected protocol are displayed.
2. Control menu. 2 fixed items are followed by the list of supported protocols this device runs. The two fixed items are:
   Next. Display the next device matching the search string.
   Previous. Display the previous device matching the search string.
   Protocol list. For each EMU supported protocol this device runs, a menu item is displayed. Selecting any protocol item displays either the parameters for this protocol or a further menu of the tables in this protocol. The number of parameters in some protocols can be quite large so EMU defines each parameter as belonging to a table. Selecting any table displays the parameters associated with it.
3. Main Section. The parameters are formatted and displayed here in standard format: Parameter name : Parameter value

• Security. Each parameter has associated with it the VMS privilege required to view it. If the user does not have the requires privilege, the parameter is not displayed.
• Level. Each parameter is defined as a 'level of interest' in range 0-5 (0 being most interesting and 5 being least). A hidden menu (described in next section) controls the level of reporting. Any parameter below the current 'level of interest' is not displayed.
• Parameter name and formatting are predefined but you are free to change this with the PARAMTBL utility. (which see)

• Logging. A prompt for file name appears at the bottom of the screen and all further data to screen is also written to this file. This is a 'flip-flop' selection; If logging is on and this is selected it is turned off, if it is off and then selected, it is turned on. Note that each time it is turned on, a new file is created.
• Report level. You can set the 'level of interest' described above here. Selecting the 2nd item displays a further menu used to set the level:
  1. Summary. The lowest level. Only those parameters defined as 'most interesting' are displayed. Generally this would include only names and addresses.
  2. Brief. Names, addresses and those considered major parameters are displayed.
  3. Normal. All but the most obscure parameters are displayed.
  4. Full. All parameter that can be formatted are displayed.
  5. Verbose. All parameters are displayed. If there is no formatting available for a parameter, a default translation is applied. Note that the level any parameter is defined in can be changed with the PARAMTBL utility.
• Update. Normally whenever a node is updated, it is then set to update again in 3 days. Once a display is started, selecting this forces this node to be updated on this protocol on the next cycle. In the case of LAN (MOP, LAT, SCS, IPX) protocols this will most likely happen within 10 - 15 seconds. In the case of WAN protocols (IP, DECnet, OSI) this may take as long as 30 - 45 minutes.
  

  3.3.6 Reporting menu

  The reporting menu allows the user to define, create and display reports. Reports are generated from report parameter files created by the user and formatted as a 'spreadsheet' where all matching parameters are in columns. For example: A parameter file specifying IP address and DECnet address finds 3 nodes and would format as follows:

  Table 3-1 Report Output

  IP Address	Decnet Address
  1.2.3.4	50.1¹
  1.2.3.5
  1.2.3.6
  1.4.5.6	50.3²
  1.4.5.7	50.2³
  1.4.5.8

  1. This node 1 has 3 IP addresses and 1 Decnet address
  2. This node 2 has 1 IP addresses and 1 Decnet address
  3. This node 3 has 2 IP addresses and 1 Decnet address
  The items in the reporting menu are as follows:
  1. Display Reports. Displays a menu of previously created reports. Selecting any item causes the selected report to be displayed in the TPU editor. The report may be edited using all standard TPU features. A new version is always created. Upon exit from TPU, the user may elect any combination of keeping or discarding the new version and purging or not all old versions.
     Note: The call to TPU always creates a new file unless the user explicitly 'quits' out of the editor. For this reason the system assumes a new version is always created. If you quit out of an editing session be very careful how you answer the delete and purge questions!
  2. Load Saved List. Displays a menu of all previously created report parameter files. These files define the contents of any report.
  3. Create new list. Created report parameter files. Menus of EMU supported protocols, their tables and parameters are displayed. Selecting a parameter adds it to the list. Selecting a parameter already in the list removes it from the list.
  4. Save Current. Saves the currently loaded report parameter list to a file. The user is asked for a report name. Enter ONLY a file name (no type or extension). These files can then be LOADed.
  5. Create Report. A report is created using the currently LOADed parameter file. A parameter file must have been previously created or loaded.
  
  

  ---

  Next page... | Contents