Metrodata LM1100 User Manual Version 3.9x

Transcription

1 LM1100 User Manual Metrodata LM1100 User Manual Version 3.9x Metrodata Ltd Fortune House Crabtree Office Village Eversley Way Egham Surrey TW20 8RY United Kingdom tel: +44 (0) fax:+44 (0) website: Part No: D

2

3 Metrodata Ltd No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of Metrodata Ltd, Fortune House, Crabtree Office Village, Eversley Way, Egham, Surrey, TW20 8RY, United Kingdom. Tel: +44 (0) Fax: +44 (0) support@metrodata.co.uk www: ftp://ftp.metrodata.co.uk Disclaimer Metrodata Ltd makes no representations or warranties with respect to the contents hereof and specifically disclaims any implied warranties or merchantability or fitness for any particular purpose. Further, Metrodata Ltd reserves the right to revise this publication and to make changes from time to time in the content hereof without obligation of Metrodata Ltd to notify any person of such revision or changes. Trademarks The Trademarks of other Corporations which may be used in this manual are hereby acknowledged. Copyright 2003 by Metrodata Ltd All Rights Reserved

4 CONTENTS 1 INTRODUCTION About this manual Metrodata products by MIB Conventions 4 2 SNMP MANAGEMENT CONCEPTS Management Overview Object Management MIB Definitions Traps 6 3 INITIAL SET-UP LAN Connection 7 4 CONFIGURATION Management Access WAN Port Set-up menus Remote Logon Datalink Management menu Ethernet The Address Translation (AT) table Interface Statistics IP The IP Routing Table IP Statistics UDP UDP Statistics SNMP SNMP Statistics TCP TCP Statistics TCP Connection table Telnet TFTP Ping 37 5 RFC1213 STANDARD MIB (MIB II) RFC1213 System Group RFC1213 Interfaces Group RFC1213 Address Translation (AT) Group RFC1213 IP Group IP Forwarding IP Addressing IP Routing IP Address Translation & Discards RFC1213 The ICMP Group RFC1213 TCP Group TCP Connection table RFC1213 UDP Group RFC1213 EGP Group RFC1213 Transmission Group RFC1213 SNMP Group 54

5 6 RFC1406 MIB NEAR END GROUP Introduction to RFC RFC1406 Near End Config Table RFC1406 Near End Config Entries Near End Config Entry - Line Type Near End Config Entry - Line Coding Near End Config Entry - Send Codes Near End Config Entry - Circuit Identifier Near End Config Entry - Loopback Config Near End Config Entry - Line Status Near End Config Entry - Signal Mode Near End Config Entry - Transmit Clock Source Near End Config Entry - Datalink RFC1406 Config Table Entries for E1 & E2 ATM DSU s RFC1406 Near End Current Table RFC1406 Near End Current Table for E1 & E2 Non-ATM DSU s RFC1406 Near End Current table for E1 & E2 ATM DSU s RFC1406 Near End Interval Table RFC1406 Near End Interval Table for E1 & E2 Non-ATM DSU s RFC1406 Near End Interval Table for E1 & E2 ATM DSU s RFC1406 Near End Total Table RFC1406 Near End Total Table for Non-ATM E1 & E2 DSU s RFC1406 Near End Total Table for E1 & E2 ATM DSU s 75 7 RFC 1406 MIB FAR-END GROUP RFC1406 Far End Current Table for E1 & E2 Interfaces RFC 1406 Far End Current Table for E1 & E2 Non-ATM DSU s RFC 1406 Far End Current Table for E1 & E2 ATM DSU s RFC1406 Far End Interval Table for E1 & E2 Interfaces RFC1406 Far End Interval Table for E1 & E2 Non-ATM DSU s RFC1406 Far End Interval Table for E1 & E2 ATM DSU s RFC 1406 Far End Total table for E1 & E2 interfaces RFC1406 Far End Total Table for E1 & E2 Non-ATM DSU s RFC1406 Far End Total Table for E1 & E2 ATM DSU s 86 8 RFC1406 FRACTIONAL GROUP Introduction to RFC1406 Fractional Group RFC1406 Fractional Tables RFC1406 Fractional Tables 88 9 RFC1407 MIB NEAR END GROUP RFC1407 Near End Config Table RFC1407 Near End Config Entries Near End Config Entry - Line Type Near End Config Entry - Line Coding Near End Config Entry - Send Codes Near End Config Entry - Circuit Identifier Near End Config Entry - Loopback Config Near End Config Entry - Line Status Near End Config Entry - Transmit Clock Source RFC1407 Near End Config Table for Non-ATM DS3/E3 DSU s RFC1407 Near End Config Table for ATM DS3/E3 DSU s RFC1407 Near End Current Table RFC1407 Near End Current Table for DS3/E3 DSU s RFC1407 Near End Interval Table RFC1407 Near End Interval Table for DS3/E3 DSU s RFC1407 Near End Total Table RFC1407 Near End Total Table for Metrodata DS3/E3 DSU s 104

6 10 RFC1407 MIB FAR-END GROUP RFC1407 Far End Config Table for DS3/E3 Interfaces RFC1407 Far End Config Entries RFC1407 Far End Current Table RFC1407 Far End Current Table for Metrodata DS3/E3 DSU s RFC1407 Far End Interval Table RFC1407 Far End Interval Table for Metrodata DS3/E3 DSU s RFC1407 Far End Total Table for Metrodata DS3/E3 DSU s RFC1407 MIB FRACTIONAL GROUP FOR DS3/E3 INTERFACES RFC1407 Fractional Tables for DS3/E3 Interfaces RFC1407 Fractional Tables for Metrodata DS3/E3 DSU s RFC1595 Sonet/SDH MIB Metrodata Sonet Products RFC1595 Structure Sonet/SDH Medium Group Medium Table for Sonet/SDH Interfaces Sonet/SDH Section Group Sonet/SDH Section Current table Section Current Table for Sonet/SDH Interfaces Sonet/SDH Section Interval table Section Interval Table for Sonet/SDH Interfaces Sonet/SDH Line Group Sonet/SDH Line Current table Line Current Table for Sonet/SDH Interfaces Sonet/SDH Line Interval table Line Interval Table for Sonet/SDH Interfaces Sonet/SDH Far End Line Group Sonet/SDH Far End Line Current table Far End Line Current Table for Sonet/SDH Interfaces Sonet/SDH Far End Line Interval table Far End Line Interval Table for Sonet/SDH interfaces Sonet/SDH Path Group Sonet/SDH Path Current table Path Current Table for Sonet/SDH Interfaces Sonet/SDH Path Interval table Path Interval Table for Sonet/SDH Interfaces Sonet/SDH Far End Path Group Sonet/SDH Far End Path Current table Far End Path Current Table for Sonet/SDH Interfaces Sonet/SDH Far End Path Interval table Far End Path Interval Table for Sonet/SDH Interfaces Sonet/SDH Virtual Tributary Group Sonet/SDH Virtual Tributary Current table Sonet/SDH Virtual Tributary Interval table Sonet/SDH Far End Virtual Tributary Group Sonet/SDH Far End Virtual Tributary Current table Sonet/SDH Far End Virtual Tributary Interval table 141

7 13 METRODTE MIB (metrodte) for DTE and DCE INTERFACES Metrodata Products Initial definitions The metrodte Table for DTE and DCE interfaces metrodteifindex metrodteline type metrodtespeed metrodte Circuit ID metrodte Loops metrodte Status metrodtetxclock metrodtelinemode metrodterxlinetype metroDteRxSpeed The metrodte Input Signal table metrodte Input Signal Name Inward Signal State The metrodte Output Signal table metrodte Output Signal Name metrodte Output Signal State metrodte Output Signal Control ATM FORUM MIB Metrodata ATM Products Introduction to ATM Forum definitions ATM Object Identifier Definitions ATM Object Identifier definitions - Transmission type ATM Object Identifier definitions - Media type ATM Object Identifier definitions -Traffic Descriptor type ATM MIB UNI Groups The Physical Port Group The ATM Layer Group The ATM Statistics Group The Virtual Path Group The Virtual Channel Group TRAPS Overview RFC1215 Standard Traps Standard Trap definitions Standard Trap status METROTR2 Enterprise Traps METROTR2 Enterprise Trap list SNMP TROUBLESHOOTING TIPS & FAQ s 171

8 INTRODUCTION 1 INTRODUCTION The LM1100 SNMP Enabler is an optional interface card which may be fitted to Metrodata DSU s. It provides the capability to control and monitor the DSU via a 10BaseT Ethernet interface. A typical application for the LM1100 would be the control and management of a WAN (Wide Area Network) from a LAN (Local Area Network) link using a SNMP (Simple Network Management Protocol) NMS (Network Management System). The LM1100 SNMP Enabler supports a variety of Management Information Bases (MIB s) which must be provided to the User s Network Management System (NMS) to provide the NMS with a database of managed objects. The MIB s supported by the LM1100 SNMP Enabler are listed in Figure 1.1. The MIB s have been developed over periods of time under the aegis of the IETF (Internet Engineering Task Force) as RFC s (Request For Comment). The RFC process is an evolutionary one, and hence the MIB structures are correspondingly evolutionary. The MIB s therefore differ in their structures and the hierarchy of their contents. The MIB tables in this manual have been presented in such a way as to try to indicate the MIB structure. Where appropriate, control and configuration variables are shaded to distinguish them from data variables when they appear together in the same tables. This will become obvious as you read the manual. In addition to SNMP statistics which are obtained by polling round the network, SNMP also provides Traps which enable important unsolicited messages relating to the system to be handled on an interrupt basis. The Traps are described in Section 15 of the manual. The LM1100 SNMP Enabler in combination with a Metrodata DSU gives the Network Manager or Administrator extensive visibility and control of the Wide Area link. The ability to monitor performance statistics and network errors from a centralised point enables quick corrective action to be taken thereby enhancing network efficiency, and providing information which can help to diagnose problems and manage even the most complex networks D 1

9 INTRODUCTION 1. 1 About this manual This user manual describes the installation, commissioning and Management Information Bases (MIB s) of the Metrodata LM1100 SNMP Enabler option. The manual assumes a certain level of knowledge on the part of the reader, especially a familiarity with SNMP. The manual is organised into sections describing each MIB in turn. The parts of the MIB applicable to Metrodata products are tabulated at the rear of each section where this is appropriate, and the information can be presented in an easy to read tabulated form. Section 2 introduces SNMP Management, MIB definitions and Traps. Section 3 describes the initial set-up of the LM1100, together with important safety information. Section 4, describes the configuration and commissioning sequence, with example menu screens to assist you in the procedures. Section 5 defines the RFC1213 Standard MIB (MIBII) which is the basis for all other MIB s in this manual. Sections 6,7 and 8 define the RFC1406 MIB for E1 & E2 Non-ATM DSUs and for some models of ATM SW and ATM CE DSU s. Sections 9,10 and 11 define the RFC1407 MIB for E3 DSU s including the FM4900, ATM SW DSU and ATM CE DSU families. Section 12 defines the RFC1595 MIB for the SONET/SDH interfaces Section 13 defines the metrodte MIB for DTE and DCE interfaces and for asymmetric operation on Metrodata DSU s. Section 14 defines the ATM Forum MIB for ATM UNI interfaces. Section 15 defines the METROTR2 Traps applicable to Metrodata products. Section 16 contains a list of Troubleshooting tips and FAQ s (frequently asked questions) which may be helpful when problems arise commissioning systems. This list is also maintained and updated regularly on the Metrodata Website D

10 INTRODUCTION 1. 2 Metrodata products by MIB The table below lists the MIB s described in this manual and relates the Metrodata products to the appropriate MIB. MIB No Section Interface Type Metrodata Product RFC ALL: This MIB is a basic standard RFC1406 6,7,8 E1 E2 LINE RFC1407 9,10,11 E2 UNI DS3/E3 FM4000, FM4500,FM4800, FM4850, ATMSW DSU, ATMCE DSU FM4900, ATMSW DSU, ATMCE DSU RFC SONET/SDH ATMSW DSU, ATMCE DSU metrodte 13 V.35, X.21 RS449 ATMUNI V SONET/SDH DS3/E3 RFC1215, metrotr2 15 DS1/E1 DS3/E3 SONET/SDH FM4000,FM4200, FM4500, FM4800, FM4850, FM4900, PA1000, L3DSU ATMSW DSU, ATMCE DSU ALL Figure 1. 1 MIB support for Metrodata products Note that there is no MIB for E4 interfaces at present (1998). The basis for an E4 MIB will be MIBII, but there is no further support for E4 available. Section 15.5 defines the handling of Enterprise Traps for E4 interfaces, pending further progress with an E4 MIB D 3

11 INTRODUCTION 1. 3 Conventions Notes are used to provide the reader with either statutory information which must be observed for safety reasons, or additional information which may increase the LM1100's effectiveness. The following conventions are used in the manual and in the screen examples. A pair of arrows around a word indicates a key on the keyboard, such as <space> or <escape>.there are two exceptions to this, which appear on some of the menus: <display> indicates that selecting the option will lead to data being displayed on the screen. <menu> indicates that the option leads to another menu, from which further options may be chosen. Screen displays which contain variable information, such as the current date or time, show the variable in italics, surrounded by square brackets, i.e. [time], or [nodename]. The speechmarks indicate data which is specified by the user when installing the LM1100. Screen examples. The DSU and its associated SNMP Enabler allow you to use one of three options for displaying the menus on a terminal - ANSI, VT100/VT220 or TTY. The screen examples in this manual use VT100/VT220 and are shaded to allow easy identification by the reader. MIB Objects have catalogue labels from RFC1407 onwards. These are shown in { } brackets in the tables D

12 SNMP MANAGEMENT CONCEPTS 2 SNMP MANAGEMENT CONCEPTS 2. 1 Management Overview Management of products is important in reducing maintenance costs in terms of predicting down-time, identifying a fault when it has occurred and minimising the need to dispatch a maintenance engineer to site to maintain a potentially faulty device. With networks becoming increasingly complex the need for effective management is becoming highly significant. SNMP is used to manage systems so that product management may be standardised. Independent vendors of NMS s, networking equipment and SNMP managed products can develop and supply devices with a very high confidence of successful inter-working between the devices Object Management SNMP management is achieved by making an SNMP call to the managed device in order to access a managed object. A managed object may be regarded as a value in a database of managed objects in the device. This database is maintained by the device and is filled with manageable items relevant to the device status, performance and configuration. The SNMP manager must know several things in order to access a managed object in the device: The type of product which is being accessed (usually by model number) so that it can identify : a) whether the product has available the managed object being requested. b) the type of information that the managed object contains. This information is held in the NMS in databases for use when the product is managed. Usually the NMS presents a map to the Network Manager with icons representing the managed objects. When the Manager clicks on the icon the Manager is prompted to define the managed object being requested. Therefore associated with the icon are the device's IP address and the product type. At the point that the Manager requests information from the product the NMS examines a definition of all of the managed objects that may be retrieved from that product type in order to prompt the Network Manager MIB Definitions The database definition is called an MIB (Management Information Base) and is a definition of the format of the database of managed objects within the device. MIB definitions are written using ASN.1 (standard program definition syntax) so that the definitions are standardised. The NMS is usually provided with a copy of the MIB at configuration time so that it has a definition of the database for all product types that will be managed (workstations, file servers, routers and Metrodata multiplexers or DSU s). At the same time the managed device uses a copy of the MIB to provide the managed object information upon request. In the case of the managed device the firmware is coded so that D 5

13 SNMP MANAGEMENT CONCEPTS management information collected from different parts of the product is concentrated in to a database that is formatted according to the MIB definition. In many cases MIBS for some products or functions are predefined as a result of work performed by a consortia of vendors and placed in the public domain. This activity is supervised by the IETF (Internet Engineering Task Force) who release MIB definitions as RFC s (Request For Comment). RFC s are available from several servers connected to the Internet. MIB s relating to Metrodata products are available from Metrodata if required for parsing into a NMS. Contact Metrodata technical support dept for more information. Product specific support for HP OpenView, Sun NetManager and Castlerock SNMPc is also available. Consult your product supplier for further information. To summarise, the NMS uses a MIB to identify the nature of a managed object within a class of managed device. This information is then used to fetch the contents of the managed object from a specific instance of the managed device found in a given network. The managed device also uses the MIB to present the contents of the managed object upon request. All transactions between NMS and managed device are on the basis of a masterslave relationship where the managed device is not able to issue unsolicited information except in the case of traps Traps Normally transactions between an NMS and a managed device are made where the NMS originates the request and the managed device responds. This strategy is satisfactory where the NMS is obtaining management information periodically on a need to know basis. However there are certain conditions where the managed device must inform the NMS of management information - for example in the case of faults or alarm conditions. It would be possible for the NMS to poll all devices for this information but this is usually unsatisfactory. Apart from the fact that latency is long (and increases in proportion to the number of devices on the network that are being polled) the result is to overload the network with management traffic that is polling devices which for the majority of the time have no useful information to give. SNMP uses a mechanism called a TRAP to accommodate the propagating of unsolicited management information between the managed device and the NMS. In certain predefined conditions the managed device will issue a TRAP to the manager announcing that the given condition has arisen. This process operates similarly to the servicing of CPU interrupts from peripheral devices in a computer system. Standard traps are numbered 0-5 and represent predefined conditions within the managed device. TRAP 6 is reserved for product-specific traps known as ENTERPRISE TRAPS and is used for all other trap activity D

14 INITIAL SET-UP 3 INITIAL SET-UP The SNMP Enabler card is mounted in Metrodata DSU products during manufacture. It may be field fitted as an upgrade by qualified service personnel only, when working in accordance with the appropriate Metrodata Application Notes. Safety Notes: Excessive voltages are present inside the DSU unit. There are no user serviceable parts inside the unit, and the cover should not be removed by unqualified personnel. The DSU and SNMP Enabler must not be exposed to damp or condensing conditions 3. 1 LAN Connection Connection to the LAN is made via the RJ45 connector at the back of the DSU marked MAN PORT. An example rear panel showing this port on an FM series DSU is shown in Figure 2.1 below. Note that if an LM1100 is not fitted in the DSU, the MAN PORT will be covered by a blanking plug VAC/50-400Hz MAN. Metrodata Ltd MANAGED PDH DSU PORT HAZARD WARNING! DO NOT OPEN WITH POWER CONNECTED ALARM EXT. TERMINAL DTE PORT RX LINE TX Figure 3. 1 Metrodata DSU rear panel VAC power supply Note: The Management port is designated SELV (Safety Extra Low Voltage) within the scope of EN This port should only be connected to SELV ports on other equipment in accordance with EN60950 Clause D 7

15 INITIAL SET-UP TheManagement port RJ45 pinouts are as follows : Pin No Signal 1 Tx Data +ve 2 Tx Data -ve 3 Rx Data +ve 4 Not connected 5 Not connected 6 Rx Data -ve 7 Not connected 8 Not connected Figure 3. 2 RJ45 Pinouts The pin numbering for an RJ45 connector is shown below LOCKING TAB Figure 3. 3 RJ45 Pin numbering Pin 1 may be identified by holding the connector with the locking tab down and the front of the connector facing towards from you when Pin 1 will be on the right D

16 CONFIGURATION 4 CONFIGURATION 4. 1 Management Access The MAIN MENU screen and subsequent MANAGEMENT screen are shown below. MANAGEMENT appears as a menu item if the DSU has been fitted with an LM1100 SNMP Enabler. Management via a LAN is configured through the MANAGEMENT option. Options available are described in sub-section 4.5 and onwards. MAIN SET-UP alarm extension General set-up WAN port set-up DTE set-up <menu> <menu> <menu> <menu> V.24 set-up <menu> Management <menu> Remote logon <display> Testing <menu> Special <menu> Performance data <menu> MANAGEMENT Ethernet Data-link IP UDP tcp Snmp Telnet tftp Ping <menu> <menu> <menu> <menu> <menu> <menu> <display> <menu> Figure 4. 1 Main & Management menus REMOTE LOGON is available between two FM4000, FM4200 and FM4500 units and can be used to communicate between two DSUs that are not fitted with LM1100 SNMP Enablers. REMOTE LOGON facilities available are described here for the sake of completeness. Note that the REMOTE LOGON menu item only appears after: Either: a MANAGEMENT TIMESLOT has been allocated from the WAN PORT SET-UP menu for FM4000, FM4200, or FM4500. Or: if the item DATALINK on the WAN PORT SET-UP menu has been set to ON for FM4850 and FM D 9

17 CONFIGURATION 4. 2 WAN Port Set-up menus The menus used for the physical set-up of the MANAGEMENT TIMESLOT and DATALINK are shown below. The path from the MAIN SET-UP menu to WAN PORT SET-UP menu may vary from model to model with the insertion of an intermediate screen (FM4200/4500) to select either the DTE E1 port or the LINE E1 port (WAN port) for set-up action. FM4200/4500 WAN PORT SET-UP FM4000 WAN PORT SET-UP DTE E1 port <menu> Framing G.704(CRC4) Line E1 port <menu> Line coding HDB3 FM4200/4500 Signalling Enabled LINE E1 PORT Timing DTE Framing G.704 (No CRC4) Mgmt timeslot 12 Line coding HDB3 AIS Forwarding Never Signalling Disabled RAI Forwarding Never Timing DTE FM4850/4900 Mgmt timeslot 31 WAN PORT SET-UP AIS Forwarding Never Framing G.742/G.751 RAI Forwarding Never Line coding HDB3 Timing datalink Internal On HIGHLIGHTED letter - select item <escape> - exit menu Figure 4. 2 Management timeslot/datalink set-up paths The set-up options are summarised in the table below: DSU Model Menu item LINE E1 or WAN PORT FM4000 FM4200 FM4500 MGEMT TIMESLOT DSUs must be in framed mode Enter number 1-31, 0=none Setting the item permits REMOTE LOGON to appear on the screen and be used.. FM4850 FM4900 DATALINK DSUs must be in framed mode. Set item to ON. Setting the item permits REMOTE LOGON to appear on the screen and be used. Figure 4. 3 Set-up options for Remote logon D

18 CONFIGURATION 4. 3 Remote Logon On each DSU, the same (number) MANAGEMENT TIMESLOT must be enabled and the DSU must be operating in framed mode. The Management terminal connected to the local unit can then logon to the remote unit via the in-band connection defined by the MANAGEMENT TIMESLOT. Logon is achieved simply by selecting the REMOTE LOGON menu item on the MAIN SET-UP screen. The console telnets to the remote unit and has full acess to all menu screens and set-up functions on the remote unit. The MANAGEMENT TIMESLOT can be set-up on any timeslot providing that it has not been assigned to carry payload. The timeslot is allocated from the WAN PORT SET-UP menu. If the timeslot is already assigned to payload, an attempt to set it up for Management will result in an INVALID ENTRY message on the console screen. If a timeslot has been successfully allocated and subsequently it is re-allocated to payload using the DTE SET-UP menu, then payload will take priority and the MANAGEMENT TIMESLOT will disappear and will need to be set up again using a vacant timeslot.. Timeslot reset action would also need to be taken on the other DSU in order to maintain the same timeslot at each end of the link.. When the REMOTE LOGON is in use, the display will show as below: Metrodata FM4500: Remote connection to [nodename] Figure 4.4 Datalink messages It is advisable to give each unit an unique nodename to make identification easier. To log out of the remote unit and return to the local unit, press: <CTRL> and <]> D 11

19 CONFIGURATION 4. 4 Datalink This item is described separately to the rest of the MANAGEMENT menu, which follows in the next sub-section. If an LM1100 SNMP Enabler is fitted to each unit, then DATALINK can be exploited. Note that the DATALINK facility can only be used between two Metrodata DSU units, and that a MANAGEMENT TIMESLOT must be set-up (via the DTE SET-UP menu) on both the local and the remote units before communication can be established. Selecting the item MANAGEMENT from the MAIN SET-UP screen leads to the MANAGEMENT menu screen, and then to the DATA-LINK screen as seen in the sequence below. The DATALINK screen is used to set up the link between two Metrodata DSUs. In the case of the FM4850/FM4900, the link must be in the UP state for communication to be established. For FM4850 and FM4900, the item DATALINK on the WAN SET-UP menu switches the Datalink STATE as shown on the DATALINK menu to UP or DOWN, as appropriate. MANAGEMENT Ethernet Data-link IP UDP tcp Snmp Telnet tftp Ping <menu> <menu> <menu> <menu> <menu> <menu> <display> <menu> DATA-LINK State Up Far-end IP address stats <display> HIGHLIGHTED letter - select item <escape> - exit menu Figure 4. 5 Management menu The DATA-LINK menu permits the IP adress of the remote unit (FAR-END IP ADDRESS) to be entered. The default value of is a broadcast address. The item STATS allows access to link statistics, which are shown in the table below. See section for interface statistics definitions. Note that the link status must be DOWN before the FAR-END IP ADDRESS can be changed D

20 CONFIGURATION INTERFACE STATISTICS ifinoctets ifinucastpkts ifinnucastpkts ifindiscards ifinerrors ifinunknownprotos ifoutoctets ifoutucastpkts ifoutnucastpkts ifoutdiscards ifouterrors ifoutqlen press any key to continue: Figure 4. 6 Interface statistics 4. 5 Management menu The Management menu provides access to a variety of tools which are essential for integrating Metrodata products into a Network Management System. The network will usually comprise a variety of devices from a variety of suppliers, and the Metrodata items will therefore be only a part of the entire network. The Management menu permit configuration of the items and provides access to relevant statistics associated with those items, as is described in the following subsections. MANAGEMENT Ethernet Data-link IP UDP tcp Snmp Telnet tftp Ping <menu> <menu> <menu> <menu> <menu> <menu> <display> <menu> Figure 4. 7 Management menu D 13

21 CONFIGURATION 4. 6 Ethernet The ETHERNET option enables the user to configure and control the Ethernet port and allows access to the port statistics. ETHERNET State Up Phys. address C2:00:C0:81: 00: 08 IP address Network mask Broadcast address from bit 1 AT table <display> stats <display> HIGHLIGHTED letter - select item <escape> - exit menu Figure 4. 8 Ethernet menu When in the UP STATE the port is active and in the DOWN STATE the port is disabled. Note that the IP address, Network mask and Broadcast address parameters may only be configured when the Ethernet state is DOWN. The PHYSICAL ADDRESS is the Ethernet address of the Ethernet interface incorporated in the SNMP Enabler. This address is an unique hexadecimal number for every Ethernet interface in the world, and is assigned to an NIC by the manufacturer. The IP ADDRESS of the Ethernet port is configured using the IP option. IP Addresses consist of four groups of decimal numbers with values between 0 and 255, which define the node network address. The NETWORK MASK option defines the mask for the network to which the Ethernet port is connected. The mask is used for the IP address recognition process for incoming messages. BROADCAST ADDRESS defines the first bit of an Ethernet packet header that is used to identify broadcast packets. The AT TABLE and STATISTICS items follow immediately below D

22 CONFIGURATION The Address Translation (AT) table The Address Translation (AT) table is accessed through the AT option. This table shows address mapping between IP and Ethernet addresses. IP address Ethernet address :C0:810:3:1:C C:43:76:00::H7 press any key to continue Figure 4. 9 AT table Note that communication cannot be established between two Ethernet devices until the AT table of each is complete for those devices. A message from the IP layer cannot be transmitted unless the AT table contains the appropriate Ethernet address for the IP address being called. If the physical address is absent from the AT table, an ARP (Address Resolution Protocol) process is initiated. ARP is a low level TCP/IP protocol which is used to get a node s physical address when only its logical IP address is known. The ARP sends an Ethernet broadcast packet and awaits a response containing the Ethernet address from the unit which possesses the broadcast IP address. Products with firmware Version 3.xx or higher have a decaying AT table, whereby the AT table contents decay over a period of approximately 4 hours. This decay process has the effect of causing the AT table to be updated regularly, since an empty AT table (or an absent entry) will cause an ARP to be initiated. Note: Replacing a system object in a network (e.g. a router, DSU or a Network management workstation) will cause an interruption in network communications until the device AT table has been restored D 15

23 CONFIGURATION Interface Statistics INTERFACE STATISTICS provides a dump of packet throughput at the Ethernet driver level of the stack referenced by the SNMP variable name. INTERFACE STATISTICS ifinoctets ifinucastpkts ifinnucastpkts ifindiscards ifinerrors ifinunknownprotos ifoutoctets ifoutucastpkts ifoutnucastpkts ifoutdiscards ifouterrors ifoutqlen press any key to continue: Figure Interface statistics The data variables definitions are listed below. The items on this page do not appear on Metrodata products: Variable ifmtu ifspeed ifphysaddress ifadminstatus IfOperStatus iflastchange Definition The size of the largest datagram which can be sent/received on the interface, specified in octets. An estimate of the interface s current bandwidth in bits/second. The interface s address at the protocol layer immediately below the network layer in the protocol stack. The desired state of the interface. Testing state does not permit operational packets to be passed. The current state of the interface. Testing state does not permit operational packets to be passed. The value of sysuptime at the time the interface entered its current operational state. If the current state was entered before the last system initialisation, the object contains zero value D

24 CONFIGURATION The items below do appear on Metrodata products: Variable ifinoctets ifinucastpkts ifinnucastpkts ifindiscards ifinerrors ifinunknownprotos ifoutoctets ifoutucastpkts ifoutnucastpkts ifoutdiscards ifouterrors ifoutqlen Definition The total number of octets received on the interface, including framing characters. The number of subnetwork-unicast packets delivered to a higher layer protocol. The number of non-unicast packets delivered to a higher-layer protocol. Typically, these may be ARP packets (and IPX packets for mixed IP/IPX environments). The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their delivery to a higher-layer protocol. The number of inbound packets that contained errors preventing their delivery to a higher-layer protocol. The number of packets received by the interface which were discarded because of an unknown or unsupported protocol. The total number of octets transmitted from the interface, including framing characters. The total number of packets that higher-level protocols requested to be transmitted to a subnetwork-unicast address, including those that were discarded or not sent. The total number of packets that higher-level protocols requested to be transmitted to a non-unicast address, including those that were discarded or not sent. The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. The number of outbound packets that could not be transmitted because of errors. The length of the outbound packet queue (in packets). The following item, which is part of the MIB definitions, is not implemented in Metrodata products: ifspecific A reference to MIB definitions specific to the particular media being used to realise the interface. For example, if the interface is realised by an ethernet, the value of this object refers to a document defining Ethernet-specific objects D 17

25 CONFIGURATION 4. 7 IP The IP menu is used to configure the stack Level 2 settings and view statistics for the packet activity at that level. IP default TTL 32 Max reassy time Routing table Forwarding Stats 5 sec <display> Disabled <display> Figure IP Menu DEFAULT TTL defines the IP packet TIME TO LIVE value in number of hops. If the value is exceeded, the packet will be destroyed on the assumption that it has become lost. MAXIMUM REASSEMBLY TIME defines the maximum time permitted for re-assembly of IP message fragments being received at the interface. The ROUTING TABLE and its use is described in Section below FORWARDING is either enabled or disabled. In the disabled state, which is usually selected, the node will simply discard IP messages which are not addressed to it. In the enabled state, the node will attempt to forward IP messages which it cannot process D

26 CONFIGURATION The IP Routing Table The ROUTING TABLE is used to determine the optimum route to be taken by IP packets arriving for transmission at the IP layer. The screen display shows the IP destination and next hop addresses, IP address mask and protocol/connection information. A typical routing table is shown below. The routes shown are known as NORMAL, SPECIFIC and DEFAULT routes. These will be explained later. Destination Next hop I/face Type Prot Age Mask Route type Enet direct local Normal direct Enet indirect local Normal indirect Enet direct local Specific Enet indirect local Default Figure Routing table display Definitions of the table contents are: Destination is the IP address of the route s ultimate Destination. Next Hop is the IP address of the next node on the route to the Destination. I/f is the interface that this route uses. Type describes the type of connection needed to pass the message to the next hop location. Protocol is a description of the protocol used. Age is the age in seconds of this route on the system. Mask is a pattern of bits used as a tool to match IP addresses and hence to define routes for messages D 19

27 CONFIGURATION The routing table is shown again below, and is processed in the sequence described: Destination Next hop I/face Type Prot Age Mask Route type Enet direct local Normal direct Enet indirect local Normal indirect Enet direct local Specific Enet indirect local Default Figure Routing table display An incoming IP packet carries an IP destination address. This Packet Address and the routing table Destination addresses are ANDed in turn against the mask. In this case let us assume that the packet IP address is A match exists if the AND results are the same for the Packet address and the Table address. Routing Table first row: a) Let us examine and AND the numbers in the IP packet address and the first row mask: AND result b) Now let us do the same for the first Table address in the routing table and the first row mask: AND result The AND produces non-matching results, and therefore this is not an acceptable route. In fact only IP addresses between 0 and 127 will be passed by this mask, and IP addresses between 128 and 255 exist on a different sub-network D

28 CONFIGURATION Routing Table second row: a) Let us examine and AND the numbers in the IP packet address and the second row mask: AND result b) Now let us do the same for the second Table address in the routing table: AND result d) The AND returns the same (matching) result for both the IP Packet address and the Table address. Therefore the route with destination is a feasible route for the packet. e) Further examination of the AND indicates that the mask being used will pass addresses from to The implication of this is that we have a NORMAL route for a range of IP packet addresses. Routing Table third row: Let us now do the same for the third row of the routing table, with the same IP packet address as previously, but with the mask from the third row: a) Let us examine and AND the numbers in the IP packet address: AND result b) Now let us do the same for the third Table address in the routing table: AND result The AND results match, and therefore we have an acceptable route. c) Further examination of the AND indicates that the mask being used will pass only the address This is known as a SPECIFIC route, which will pass only a single packet address D 21

29 CONFIGURATION Routing Table fourth row: Let us now do the same for the fourth row of the routing table, with the same IP packet address as previously, but with the mask from the fourth row: a) Let us examine and AND the numbers in the IP packet address with the fourth row mask: AND result b) Now let us do the same for the fourth Table address in the routing table: AND result The AND results match, and therefore we have an acceptable route. Further examination of the AND indicates that the mask being used will pass all IP packet addresses. This is known as a DEFAULT route Most Specific Route: It is common for the AND to pass several Table addresses, thus producing several possible routes. In this case, the associated masks are compared in order to select the most specific matching route, which is then used for the IP packet. The most specific route is defined as the mask which has the first zero in the least significant bit position. The next task is to select the Most Specific matching route, which should be the most efficient way to the ultimate destination. From the examples above for the packet IP address , a match was produced from the AND for the following masks: Table Address Mask Mask Binary The Most Specific route is defined as the route with the mask which has the first zero in the least significant position. In this case, it is mask , since this has no zeros. Note that this mask passes only IP messages which are the Table IP address. Mask is a NORMAL route, which passes a range of IP addresses, and mask is a DEFAULT route which passes all IP addresses. Notes: 1) If there is no match with any of the Table Destination address entries, an ipnoroute situation exists, and the packet is discarded. The ipnoroute counter is then incremented to log the occurrence. A NO MATCH situation implies that the routing table does not have a default route in it. 2) If only a single match is found, the packet is forwarded to the next hop destination without further processing to determine the most specific route D

30 CONFIGURATION IP Statistics The IP STATISTICS display gives a dump of the packet activity at the IP layer (layer 2) referenced by the SNMP variable name. IP Statistics ipinreceives icmpinmsgs icmpoutechos ipinhdrerrors icmpinerrors icmpoutechoreps ipinaddrerrors icmpindestunreachs icmpouttimestamps ipforwdatagrams icmpintimeexcds icmpouttimestampreps ipinunknownprotos icmpinparmprobs icmpoutaddrmasks ipindiscards icmpinsrcquenchs icmpoutaddrmaskreps ipindelivers icmpinredirects ipoutrequests icmpinechos ipoutdiscards icmpinechoreps ipoutnoroutes icmpintimestamps ipreasmreqds icmpintimestampreps ipreasmoks icmpinaddrmasks ipreasmfails icmpinaddrmaskreps ipfragoks icmpoutmsgs ipfragfails icmpouterrors ipfragcreates icmpoutdestunreachs iproutingdiscards icmpouttimeexcds icmpoutparmprobs icmpoutsrcquenchs icmpoutredirects press any key to continue: press any key to continue: press any key to continue: Figure IP Statistics display D 23

31 CONFIGURATION The data definitions are given below: Variable ipinreceives ipinhdrerrors ipinaddrerrors ipforwdatagrams ipinunknownprotos ipindiscards ipindelivers ipoutrequests ipoutdiscards ipoutnoroutes ipreasmtimeout ipreasmreqds ipreasmoks ipreasmfails ipfragoks ipfragfails ipfragcreates Definition The total number of input datagrams received by the IP layer, including those received in error. The number of input datagrams discarded due to errors in their IP headers. The number of input datagrams discarded because the IP address in their IP header s destination field was not a valid address to be received at this entity. The number of input datagrams for which this entity was not their final IP destination, and as a result of which an attempt was made to find a route to forward them to that final destination. The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol. The number of locally-addressed datagrams for which no problems were encountered to prevent their continued processing, but which were discarded. This counter excludes any datagrams discarded whilst awaiting re-assembly. The total number of input datagrams successfully delivered to IP user-protocols (including ICMP) The total number of IP datagrams which local IP user-protocols (incl ICMP) supplied to IP in requests for transmission. This counter excludes any counted in ipforwdatagrams. The number of output IP datagrams for which no problem was found to prevent their transmission, but which were discarded. The number of IP datagrams discarded because no route could be found to transmit them to their destination. This counter includes any packets counted in ipforwdatagrams which meet the no route criterion. The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity The number of IP fragments received which needed to be reassembled at this entity. The number of IP datagrams successfully reassembled. The number of failures detected by the IP re-assembly algorithm. This may not equal the number of discarded IP fragments because some algorithms combine fragments on receipt. The number of IP datagrams that have been successfully fragmented at this entity. The number of IP datagrams that have been discarded because they needed to be fragmented, but could not be, e.g. because their Don t fragment flag was set. The number of IP datagram fragments that have been generated as a result of fragmentation at this entity D

32 CONFIGURATION Variable icmpinmsgs icmpinerrors icmpindestunreachs icmpintimeexcds icmpinparmprobs icmpinsrcquenchs icmpinredirects icmpinechos icmpinechoreps icmpintimestamps icmpintimestampreps icmpinaddrmasks icmpinaddrmaskreps icmpoutmsgs icmpouterrors icmpoutdestunreachs icmpouttimeexcds icmpoutparmprobs icmpoutredirects icmpoutechos icmpoutechoreps icmpouttimestamps Definition The total number of ICMP messages which the entity received, including those counted by icmpinerrors The number of ICMP messages which the entity received but determined as having ICMP-specific errors. The number of ICMP Destination Unreachable messages received. The number of ICMP Time Exceeded messages received. The number of ICMP Parameter Problem messages received. The number of ICMP Source Quench messages received. The number of ICMP Redirect messages received. The number of ICMP Echo Request messages received. The number of ICMP Echo Reply messages received. The number of ICMP Timestamp Request messages received. The number of ICMP Timestamp Reply messages received. The number of ICMP Address Mask Request messages received. The number of ICMP Address Mask Reply messages received. The total number of ICMP messages which this entity attempted to send, including those counted by icmpouterrors. The number of ICMP messages which this entity did not send owing to problems within ICMP such as lack of buffers. Errors arising outside ICMPare not included. The number of ICMP Destination Unreachable messages sent The number of ICMP Time Exceeded messages sent. The number of ICMP Parameter Problem messages sent. The number of ICMP Redirect messages sent The number of ICMP Echo Request messages sent. The number of ICMP Echo Reply messages sent. The number of ICMP Timestamp Request messages sent. icmpouttimestampreps The number of ICMP Timestamp Reply messages sent. icmpoutaddrmasks The number of ICMP Address Mask Request messages sent. icmpoutaddrmaskreps The number of ICMP Address Mask Reply messages sent D 25

33 CONFIGURATION 4. 8 UDP The UDP menu gives access to the UDP stack layer. UDP Port number 161 Trap port 162 Stats Figure UDP menu The PORT NUMBER and TRAP PORT number are predefined by SNMP and are for information only UDP Statistics The UDP STATISTICS display gives access to the packet activity at this stack layer referenced by the SNMP variable name. UDP Statistics udpindatagrams udpnoports udpinerrors udpoutdatagrams press any key to continue: Figure UDP statistics The data definitions of items listed on the screen are: <display> Variable udpindatagrams udpnoports udpinerrors udpoutdatagrams Definition The total number of UDP datagrams delivered to UDP users. The total number of received UDP datagrams for which there was no application at the destination port. The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port. The total number of UDP datagrams sent from this entity D