MFRAP-MIB: View SNMP OID List / Download MIB

A textual description of the system model identifier. for example: SYNC-MFRAP

Displays the Software Revision of the application code installed in this node.

Displays the Hardware Revision of the node.

The number of Wide Area Network (T1) ports that are installed. There is 1 on the MFRAP.

The number of user serial data channels (DTE) that are installed. There is 1 on the MFRAP.

The number of Async Maintenance/Comm (console ports that are installed. There are 2 on the MFRAP: one for the console interface and one for SLIP management.

The user supplied name of the node. This object does not affect operation, but may be useful for network management.

The serial number of the board.

Command to reset the node. NODE WILL BE OFF-LINE AND USER DATA WILL BE INTERRUPTED FOR APPROXIMATELY 15 SECONDS. Full network recovery may take longer. Enumeration: 'reset-node': 321.

The amount of memory (RAM) installed (in megabytes).

The user supplied location of the node. This object does not affect operation, but may be useful for network management.

The user supplied contact information for the node. This object does not affect operation, but may be useful for network management.

Configurable Command Line Interface (CLI) prompt. CLI is the User Interface protocol used for directly attached VT100 terminal access and for remote access via Telnet.

Displays the Software Revision of the Bootstrapping code installed in this node.

The user supplied name of the nest where this card resides. This can be used to group all cards from the same nest together for network management. Note an MFRAP standalone unit will not allow this to be 'set' and will return the string 'standalone'.

Shows whether the unit has SLIP (Serial Line IP) capability. SLIP is a method for out-of-band management that connects through the asynchronous terminal port.

Shows whether the unit has PPP (Point to Point protocol) capability. PPP is a method for out-of-band management that connects through the asynchronous terminal port.

Shows whether the unit has Remote Dial Out capability.

Shows whether the unit has Ethernet capability.

Shows whether the unit has Token Ring capability.

Shows whether the unit has External Timing capability.

Shows whether the unit has BRI (ISDN Basic Rate) capability.

Shows whether the unit has a Selectable DTE interface.

Shows whether the unit supports MLs (out-of-band management links).

Shows how many DLCIs can be monitored for Short Term Statistics.

Shows how many DLCIs can be specified in the Long Term Statistics Filter.

Shows how many protocols can be specified in the Long Term Statistics Filter.

Shows how many protocols can be defined by the user. The user configures TCP/UDP ports which can be monitored as protocols. They are available for short term or long term statistics monitoring.

Shows how many SNMP managers can be programmed in the table mfrapCfgSnmpMngrTable. These managers are sent TRAPs if configured to do so.

Shows how many DLCI names can be defined by the user in the table mfrapCfgFrPerfDlciNamesTable.

The IP address for this node. This address will be unique to the IP network and is required for in-band or out-of-band ip and SNMP management.

This parameter is not used internally by the unit. It is intended to identify either the device directly connected to the SLIP port or, in Frame Relay applications, the address of the primary network management station. This should always be non-zero.

The IP Network Mask (eg 255.255.255.0).

The Maximum Transmission Unit is the size of the largest IP packet supported. This value should be set to the lowest value supported by any equipment in the transmission path. A size of 1006 (including header) is suggested.

This is the method by which IP traffic is being carried. Either via the SLIP port or a DLCI. This is how your InBand Managenent scheme is set up. Enumeration: 'none': 1, 'in-band-dlci': 3, 'slip-port': 2.

Enables/Disables the telnet feature. Valid values are enable-telnet (1) and disable-telnet (2). Enumeration: 'enable-telnet': 1, 'disable-telnet': 2.

Enables/Disables the telnet auto-logout, logging out the user after a certain length of idle time. Valid values are disable-autologout (2), and a number of timeout intervals including autologout-at-15-minutes (1), autologout-at-3-minutes (3), and the default autologout-at-5-minutes (5). Enumeration: 'autologout-at-30-minutes': 30, 'disable-autologout': 2, 'autologout-at-10-minutes': 10, 'autologout-at-60-minutes': 60, 'autologout-at-5-minutes': 5, 'autologout-at-15-minutes': 1, 'autologout-at-3-minutes': 3.

After setting the other TFTP parameters, start the TFTP Flash ROM upgrade by entering the TFTP password.

The IP address of the TFTP host from which to retrieve the Flash ROM image.

The filename of the new ROM Image on the TFTP host.

The interface on which TFTP data passes. This is only used for in-band management modes. When a unit is in SLIP mode, this object is not applicable. A 'get'will return a value of '3' and set is ignored. (1) dte-interface (2) t1-interface (3) Not applicable Enumeration: 'dte-interface': 1, 't1-interface': 2, 'slip-interface': 3.

The DLCI on which the TFTP host can be found. A value of -1 signifies not-applicable.

The status of current or most recent TFTP operation. Download can be canceled by a Set to inactive. Enumeration: 'invalid-file': 8, 'requested': 2, 'host-no-reply': 6, 'transferring': 3, 'programming': 4, 'corrupt-file': 9, 'successful': 10, 'inactive': 1, 'file-not-found': 7, 'transfer-aborted': 5.

The number of Bytes from the ROM image that have been TFTP'd to the unit

Controls whether or not the Frame Relay DLCI status change traps are issued. These traps are dfrapDLCIActiveTrap and dfrapDLCIInactiveTrap. (1) FR Trap enabled - a trap will be sent each time an individual DLCI changes status between active and inactive. (2) FR Trap disabled - DLCI state change traps are not sent. Enumeration: 'disabled': 2, 'enabled': 1.

The table of IP addresses of SNMP managers to receive this node's TRAPs.

The IP address of a SNMP manager to receive this node's TRAPs.

The index to the list of SNMP managers receiving TRAPs.

The IP address of a SNMP manager to receive this node's TRAPs. Setting this value to 0.0.0.0 will disable the issuance of traps to the indexed manager.

The interface out which the indexed trap manager can be reached. This entry is required in Piggyback and Bi-directional in-band managed applications. In Local, Remote and SLIP-based applications, the interface is known and this parameter is ignored. (1) Traps sent out DTE interface for this manager (2) Traps sent out T1 interface for this manager (3) Traps sent out SLIP interface (async maint port) When the node is configured for SLIP, a GET on this MIB object will return slip-interface(3) and a SET of this MIB object to slip-interface(3) is allowed but unnecessary. When the node is not configured for SLIP, this MIB object can be SET to dte-interface(1) or t1-interface(2); slip-interface(3) would be rejected. Enumeration: 'dte-interface': 1, 't1-interface': 2, 'slip-interface': 3.

The DLCI to use to send TRAPs to this SNMP manager.

Controls whether TRAPs are sent or muted. A value of 0 allows TRAPs to be sent. If not 0, the value represents the interval (minutes) at which to send the MutingActive trap. It is the only trap sent during muting. The valid range for the interval is 30 to 10080 (a week).

Enables or disables the sending of traps for fan and/or power supply alarms. Note an MFRAP standalone unit will not allow this to be 'set' and will return the 'disable'. Enumeration: 'enable': 1, 'disable': 2.

Enables or disables the sending of traps for the Drop and Insert port. (1) enable the sending of traps (2) disable the sending of traps Enumeration: 'enable': 1, 'disable': 2.

Enables or disables the sending of per-DLCI utilization traps. (1) enable utilization traps (2) disable utilization traps Enumeration: 'enable': 1, 'disable': 2.

Deletes the number of entries in the mfrapCfgSnmpMgrTable indicated by the value. If the value is a positive number the entries will be deleted starting from the first entry. If the value is negative the entries will be deleted starting from the last entry.

The protocol running on the Maintenance port. VT100 (1), for the User Interface, SLIP (2) for the SNMP support, MODEM(3) for remote VT100 support. Enumeration: 'modem': 3, 'slip': 2, 'vt100': 1.

Asynchronous baud rate for the Maintenance/Comm port (Console). This must be configured to match either the VT100 compatible terminal, MODEM support or the SLIP Terminal Server depending upon the Comm port mode. (2) baud-2400 (4) baud-9600 (5) baud-19200 (6) baud-38400 Enumeration: 'baud-9600': 4, 'baud-19200': 5, 'baud-2400': 2, 'baud-38400': 6.

Databits for this Communication port. Values are databits-7 (1) and databits-8 (2). Enumeration: 'databits-7': 1, 'databits-8': 2.

Number of Stopbits for this Communication port. Values are stopbits-1 (1), stopbits-1-5 (2), and stopbits-2 (3). Enumeration: 'stopbits-1-5': 2, 'stopbits-1': 1, 'stopbits-2': 3.

Parity for this Communication port. Values are no-parity (1), odd-parity (2), even-parity (3). Enumeration: 'even-parity': 3, 'no-parity': 1, 'odd-parity': 2.

Flow Control for this Communication port. Values are no-flow-control (1). Enumeration: 'no-flow-control': 1.

Enables or disables the auto detection of RS-232 data on the front MAINT port. When enabled, and data detected, the unit will temporarily convert to VT100 mode to allow a local user access when the unit is in SLIP or MODEM mode. (1) enable COMM-MAINT port auto detect (2) disable COMM-MAINT port auto detect Enumeration: 'enable': 1, 'disable': 2.

Shows the mode that DLCI In-band Management is set up for - inactive (1) - Inband management is not enabled; local (2) - Inband managed using a dedicated private PVC with access exclusively through the DTE interface; remote (3) - Inband managed using a dedicated private PVC with access exclusively through the WAN interface; bidirectional (4) - Inband managed using a dedicated private PVC with access supported through either interface; piggyback (5) - Inband managed using any provisioned PVC, statistically multiplexed with user data; fixedDCE (6) - Inband managed mode similar to piggyback mode except for LMI behavior; The unit will always source LMI Responses separately on each interface (emulating a Frame Relay DCE device). A single PVC will be provisioned and is used for both user data and management traffic. This mode of operation is useful in an environment that does not include a Frame Relay switch but does include a pair of interconnected Frame Relay FRADs or Routers which can only be configured as a Frame Relay DTE device. Enumeration: 'remote': 3, 'fixedDCE': 6, 'piggyback': 5, 'inactive': 1, 'bidirectional': 4, 'local': 2.

The DLCI identifier, the value of the DLCI field in the frame.

This is the protocol used for enacapsulating and formatting ip data for Frame Relay transmission. This setting is specific to management data to and from the unit. (1) RFC1490 - per IETF standard with Network Level Protocol ID (NLPID) set for IP encapsulation. (2) RFC1490 SNAP/IP - per IETF standard with NLPID set for Sub-Network Access Protocol (SNAP). (3) auto - adjusts to either of these encapsulation techniques as required. (4) Cisco - proprietary encapsulation (4-byte header). Enumeration: 'rfc1490': 1, 'auto': 3, 'cisco': 4, 'rfc1490snap': 2.

Provides user control over the state of the Frame Relay Discard Eligibility bit of all management frames generated by the unit. Frames marked DE=1 are more likely to be dropped in a congested Frame Relay network than those that are DE=0. Heavily congested circumstances can cause both to be dropped. Additionally, frames marked DE=0 may get re-marked to DE=1 by intervening equipment. (1) DE bit cleared to 0: frame is not discard eligible (2) DE bit set to 1: frame is discard eligible Enumeration: 'no-DE-bit-0': 1, 'yes-DE-bit-1': 2.

Default timing, or clock, source. There must be only one source on a T1 line. Node should always be network (2) timed on a point-to-network application. Line Driver applications need one node as internal (1), one as network (2). Options are given to source the clock from the DTE port or the D&I port. Enumeration: 'internal': 1, 'drop-and-insert': 4, 'network': 2, 'dte': 3.

Circuit identifier provided by the service provider.

Indicates type of service purchased on the attached network line T1. Valid selections are dedicated (1) and Frame Relay (2). Enumeration: 'frame-relay': 2, 'dedicated': 1.

Refer to Application Type. Frame Relay is based upon HDLC framing. To operate in a Frame Relay application the Format must be set for HDLC. To operate in a protocol-independent application the Format must be set for Constant Bit Operation (CBO). Note - changing this value will automatically change the Application Type setting and vice versa (1) CBO: protocol-independent transparent DSU/CSU (2) HDLC: Frame and protocol aware DSU/CSU Enumeration: 'cbo': 1, 'hdlc': 2.

The amount of time a loopback may run before timing out and automatically terminating. The timeout is in minutes and a value of 0 means no timeout.

This value represents the throttling mechanism used to determine the optimum level of statistical processing versus managability of the unit. The lower the value (1 - 128), the unit becomes more responsive to management commands during very heavy utilization at the possible expense of statistical accuracy. The larger the value (129 - 512), the more accurate the MFRAP performs statistical analysis of the frames but management may seem slow or unresponsive during periods of very heavy link utilization. NOTE: A value of 0 disables statistical processing entirely.

Type of Framing on this T1 Line. Check with your service provider to determine value. (1) D4 - also known as Superframe or SF. (2) ESF 54016 - Extended Superframe supporting the Facility Data Link per AT&T pub 54016. ESF provides enhanced performance monitoring capabilities over the FDL. (3) ESF ANSI - Extended SuperFrame supporting the Facility Data Link per ANSI T1.403 standard. ESF provides enhanced performance monitoring capabilities over the FDL. Enumeration: 'd4': 1, 'esf-54016': 2, 'esf-ansi': 3.

T1 interface bipolar encoding scheme. Check with your service provider to determine value. B8ZS, which inherently provides ample 'ones-density', is recommended. AMI users must pay special attention to the 'ones-density' requirements of the service provider. (1) B8ZS - intercepts and encodes streams of 8 consecutive zeros and transmits them as a special pattern including Bipolar or Line Code Violations. Function not supported on certain networks. (2) AMI - Alternate Mark Inversion - sends the user data without introducing controlled BPVs. Enumeration: 'ami': 1, 'b8zs': 2.

CSU 'ones density' monitor. Defines the maximum number of consecutive zeros that can be transmitted to the WAN. If density monitoring is enabled, the composite signal is guaranteed to meet the selected density threshhold at the expense of user data. (1) No Density Monitoring - unit will transparently transmit user data without regard for ones density. Recommended for use in B8ZS applications, in nx56K applications where bit-7 stuffing is configured for DTE Channel Density, and when an external CSU is used. (2) 12.5% - unit will maintain a sliding window and will assure a minumum of 12.5% or an average of 1 in 8 ones. (3) 1 in 16 - unit will guarantee that no more than 15 consecutive zeros will be transmit to the WAN. (4) 1 in 64 - unit will guarantee that no more than 63 consecutive zeros will be transmit to the WAN. Enumeration: 'twelve-half-percent': 2, 'no-density': 1, 'one-in-16': 3, 'one-in-64': 4.

Enables the unit's internal CSU functionality. Typical network access requires a CSU to condition the WAN signal, guard against network hazards, and provide access to service personnel for network maintenance. (1) Disables internal CSU and unit operates as a DSX-1 cross connect device. This should be the setting if the unit is cabled to an external CSU device providing network access. CSU. (2) Enables internal CSU and corresponding feature set which includes density monitoring, line build-out pulse shaping, ESF facility data link, and certain diagnostic functions. This should be the seting if the unit is directly cabled to the service provider's equipment (such as a smart jack). Enumeration: 'cs': 2, 'dsx-1': 1.

CSU Line Build Out (LBO). This feature provides selectable output signal strength. Consult service provider for proper setting. Signal may require attenuation to equalize it with neighboring equipment or under certain cabled access conditions. Not applicable if CSU functions are diabled (interface type = dsx-1) (1) 0dB - standard output signal (2) -7.5dB - standard output signal attenuated by 7.5dB (3) -15dB - standard output signal attenuated by 15 dB. Enumeration: 'n15-db': 3, 'n7-5-db': 2, 'zero-db': 1.

Sets the electrical interface for the DTE port. (3) V.35 interface (4) RS-449 interface (not supported) Enumeration: 'intf-v35': 3.

Inverts the DTE data for transfer across the WAN. Can make some applications, particularly HDLC-based protocols, meet density requirements even across clear channel DS0s in AMI mode. Enumeration: 'data-normal': 1, 'data-invert': 2.

This selection controls how the unit internally latches the transmit data from the DTE. Normal will sample data with the rising edge of the selected TX Clock, Invert will sample data with the falling edge of the selected TX Clock. The TX Clock is selected using CfgDteTiming. This clock invertion is most useful when loop-2 timing is used - particularly at higher rates and with long cable runs. Only in rare circumstances will clock-invert be used with loop-1 timing. If the DTE Interface TX statistics are indicating excessive crc errors or aborts then changing this setting may have some benefit. (1) normal (2) invert Enumeration: 'clock-invert': 2, 'clock-normal': 1.

Serial DTE Transmit Timing mode. Loop-1 (1) uses the clock returned from the DTE (TT/TCE) to sample tx data, Loop-2 (2) uses the clock (ST/TC) generated by the node to sample tx data. Enumeration: 'loop-2': 2, 'loop-1': 1.

Serial DTE Data Rate in bits per second. Valid rates depend upon channel density selection: nX56K for bit-7-stuffing, and nX64K for clear-channel (n is an integer 1-24 inclusive). This read-only value is the value which was most recently set through CfgDteConnRate; in the event of a connection failure, this field should be examined along with CfgDteChannelDensity and CfgDteStartDso to determine the parameter mismatch that caused the connection failure.

Packing of serial data into T1 DS0's. Bit-7-stuff supports DTE rates of nX56Kb/s (from 56K to 1344K) and provides sufficient ones-density on any circuit. Clear-channel allows DTE rates of nX64Kb/s (from 64K to 1.536M) and may require an additional means of density enforcement (eg, B8ZS). This read-only value is the value which was most recently set through CfgDteConnDensity; in the event of a connection failure, this field should be examined along with CfgDteLineRate and CfgDteStartDso to determine the parameter mismatch that caused the connection failure. Enumeration: 'bit-7-stuff': 56, 'clear-channel': 64.

T1 WAN includes 24 DS0's available for user data. Each DS0 carries either 56Kbit/sec (bit-7-stuffing) or 64KBit/sec (clear-channel). This value is the starting DS0 used by the node to allocate DS0s to match the DTE's data rate. Sequential, contiguous DS0s are assigned as required. The number of DS0s required is based upon the DTE Data Rate and DTE Channel Mapping. This read-only value is the value which was most recently set through DteCfgConnStartDs0; in the event of a connection failure, this field should be examined along with CfgDteLineRate and CfgDteChanelDensity to determine the parameter mismatch that caused the connection failure. Enumeration: 'ds0-19': 19, 'ds0-18': 18, 'ds0-13': 13, 'ds0-12': 12, 'ds0-11': 11, 'ds0-10': 10, 'ds0-17': 17, 'ds0-16': 16, 'ds0-15': 15, 'ds0-14': 14, 'no-current-connections': 40, 'non-continuous-ds0s': 41, 'ds0-22': 22, 'ds0-23': 23, 'ds0-20': 20, 'ds0-21': 21, 'ds0-08': 8, 'ds0-09': 9, 'ds0-24': 24, 'ds0-04': 4, 'ds0-05': 5, 'ds0-06': 6, 'ds0-07': 7, 'ds0-01': 1, 'ds0-02': 2, 'ds0-03': 3.

The current status of the WAN to DTE mappings. (1) connections valid and DS0s allocated to DTE data. (4) no connections configured between WAN and DTE. Enumeration: 'connections-valid': 1, 'no-current-connections': 4.

T1 WAN includes 24 DS0's available for user data. Each DS0 carries either 56Kbit/sec (bit-7-stuffing) or 64KBit/sec (clear-channel). This value is the starting DS0 used by the node to allocate DS0s to match the DTE's data rate. Sequential, contiguous DS0s are assigned as required. The number of DS0s required is based upon the DTE Data Rate and DTE Channel Mapping. Consult WAN service provider for the appropriate setting here in a fractional T1 application. Enumeration: 'ds0-19': 19, 'ds0-18': 18, 'ds0-13': 13, 'ds0-12': 12, 'ds0-11': 11, 'ds0-10': 10, 'ds0-17': 17, 'ds0-16': 16, 'ds0-15': 15, 'ds0-14': 14, 'no-current-connections': 40, 'non-continuous-ds0s': 41, 'ds0-22': 22, 'ds0-23': 23, 'ds0-20': 20, 'ds0-21': 21, 'ds0-08': 8, 'ds0-09': 9, 'ds0-24': 24, 'ds0-04': 4, 'ds0-05': 5, 'ds0-06': 6, 'ds0-07': 7, 'ds0-01': 1, 'ds0-02': 2, 'ds0-03': 3.

Serial DTE Data Rate in bits per second. Valid rates depend upon channel density selection: nX56K for bit-7-stuffing, and nX64K for clear-channel (n is an integer 1-24 inclusive). Rates are entered in bits/sec, for example, 128000 for a 128Kbit/sec DTE data rate.

Packing of serial data into T1 DS0's. Bit-7-stuff supports DTE rates of nX56Kb/s (from 56K to 1344K) and provides sufficient ones-density on any circuit. Clear-channel supports DTE rates of nX64Kb/s (from 64K to 1.536M) and may require an additional means of density enforcement (eg, B8ZS). (56) Bit 7 Stuffing (nx56K data rate, n=1-24) (64) Clear Channel (nx64K data rate, n=1-24) Enumeration: 'bit-7-stuff': 56, 'clear-channel': 64.

The number of DS0s required by the node's DTE port. This is based upon the DTE data rate and channel density selections.

There's a tight correlation among DTE data rate, starting DS0, and channel density. This read-only parameter reports the status of the most recent change to any of these connection parameters. If the connection request is not valid a mismatch among DteLineRate, DteStartDs0, and DteChannelDensity must be resolved (1) and (3) configuration valid - the previous connections profile is accepted and activated (2) and (4) connections profile invalid, previous configuration remains. Enumeration: 'configuration-valid': 1, 'invalid-cfg-no-update': 4, 'configuration-invalid': 2, 'valid-config-updated': 3.

Updates the connection-critical parameters: line rate, channel density and starting ds0; drops the currect connection; and initiate the new connection. Following the issuance of this command, DteAutoStatus should be queried to verify the update was successful. The setting of this object updates the mfrapCfgEditTable. In order for the changes to take effect in the system, the mfrapCfgConnUpdateCmd must subsequently be set. Enumeration: 'config-and-connect': 1.

Selects whether the RTS signal is external-from-dte (2) or internal-held-active (1). Enumeration: 'internal-held-active': 1, 'external-from-dte': 2.

Selects whether the DTR signal is external-from-dte (2) or internal-held-active (1). Enumeration: 'internal-held-active': 1, 'external-from-dte': 2.

Specifies the behavior of this control signal generated by the M-FRAP towards the DTE. inactive-always (1) - signal is permanently INACTIVE. active-always (2) - signal is permanently ACTIVE. reflect-carrier (3) - signal echoes the carrier signal status from the WAN. inactive-with-test-mode (4) - signal is ACTIVE during normal data transfer and INACTIVE during diagnostic conditions that interfere with data transfer from the DTE to the WAN. follow-RTS (5) - signal echoes the status of RTS as processed from the DTE. reflect-carrier-and-RTS (6) - signal is a logical AND between RTS processed from the DTE and the carrier signal status from the WAN. No signal from the WAN or RTS INACTIVE will cause this control signal to be asserted INACTIVE. reflect-sync-and-RTS (7) - signal is a logical AND between RTS processed from the DTE and the frame synchronization with the WAN. Red Alarm defines the threshold for declaring synchronization. reflect-LMI-and-carrier-and-RTS (8) - signal is a logical AND between RTS processed from the DTE and the carrier signal status from the WAN and LMI. If the unit is in an LMI passthrough state then LMI is considered Active. LMI Inactivity timer must be non-zero for LMI to be declared Inactive. Note that there is a separate parameter for how the unit processes RTS that is related to this function if options (4), (5), (6), or (7) is selected, see CfgDteRts. Enumeration: 'follow-sync-rts': 7, 'signal-off': 1, 'follow-test': 4, 'follow-carrier': 3, 'follow-lmi-carr-rts': 8, 'follow-rts': 5, 'follow-carrier-rts': 6, 'signal-on': 2.

Specifies the behavior of this control signal generated by the M-FRAP towards the DTE. inactive-always (1) - signal is permanently INACTIVE. active-always (2) - signal is permanently ACTIVE. reflect-carrier (3) - signal echoes the carrier signal status from the WAN. inactive-with-test-mode (4) - signal is ACTIVE during normal data transfer and INACTIVE during diagnostic conditions that interfere with data transfer from the DTE to the WAN. follow-RTS (5) - signal echoes the status of RTS as processed from the DTE. reflect-carrier-and-RTS (6) - signal is a logical AND between RTS processed from the DTE and the carrier signal status from the WAN. No signal from the WAN or RTS INACTIVE will cause this control signal to be asserted INACTIVE. reflect-sync-and-RTS (7) - signal is a logical AND between RTS processed from the DTE and the frame synchronization with the WAN. Red Alarm defines the threshold for declaring synchronization. reflect-LMI-and-carrier-and-RTS (8) - signal is a logical AND between RTS processed from the DTE and the carrier signal status from the WAN and LMI. If the unit is in an LMI passthrough state then LMI is considered Active. LMI Inactivity timer must be non-zero for LMI to be declared Inactive. Note that there is a separate parameter for how the unit processes RTS that is related to this function if options (4), (5), (6), or (7) is selected, see CfgDteRts. Enumeration: 'follow-sync-rts': 7, 'signal-off': 1, 'follow-test': 4, 'follow-carrier': 3, 'follow-lmi-carr-rts': 8, 'follow-rts': 5, 'follow-carrier-rts': 6, 'signal-on': 2.

Specifies the behavior of this control signal generated by the M-FRAP towards the DTE. inactive-always (1) - signal is permanently INACTIVE. active-always (2) - signal is permanently ACTIVE. reflect-carrier (3) - signal echoes the carrier signal status from the WAN. inactive-with-test-mode (4) - signal is ACTIVE during normal data transfer and INACTIVE during diagnostic conditions that interfere with data transfer from the DTE to the WAN. follow-RTS (5) - signal echoes the status of RTS as processed from the DTE. reflect-carrier-and-RTS (6) - signal is a logical AND between RTS processed from the DTE and the carrier signal status from the WAN. No signal from the WAN or RTS INACTIVE will cause this control signal to be asserted INACTIVE. reflect-sync-and-RTS (7) - signal is a logical AND between RTS processed from the DTE and the frame synchronization with the WAN. Red Alarm defines the threshold for declaring synchronization. reflect-LMI-and-carrier-and-RTS (8) - signal is a logical AND between RTS processed from the DTE and the carrier signal status from the WAN and LMI. If the unit is in an LMI passthrough state then LMI is considered Active. LMI Inactivity timer must be non-zero for LMI to be declared Inactive. Note that there is a separate parameter for how the unit processes RTS that is related to this function if options (4), (5), (6), or (7) is selected, see CfgDteRts. Enumeration: 'follow-sync-rts': 7, 'signal-off': 1, 'follow-test': 4, 'follow-carrier': 3, 'follow-lmi-carr-rts': 8, 'follow-rts': 5, 'follow-carrier-rts': 6, 'signal-on': 2.

Defines the size of the DLCI address field of the Frame Relay header. This setting must correspond to the Frame Relay transmission format; typically Two bytes. (1) two byte DLCI address field (2) three byte DLCI address field (3) four byte DLCI address field Enumeration: 'threebytes': 2, 'twobytes': 1, 'fourbytes': 3.

This defines the manner in which the unit handles HDLC protocol errors (crc errors) in a Frame Relay application. If Discard is selected the unit will respond to an errored frame by aborting the frame if transmission has begun; or simply discarding it if transmission has not begun. If Passthru is selected the unit will transmit the entire frame but will place an incorrect crc in it to preserve the error indication. (1) discard (2) passthru Enumeration: 'passthr': 2, 'discard': 1.

The LMI type used in a Frame Relay application. This setting must match the attached Frame Relay device configuration. Annex-A and Annex-D use DLCI 0, and Type 1 uses DLCI 1023. Type 1 is alternatively referred to as Cisco, Group of four, or simply LMI. Annex-D may be referred to as ANSI T1.617. Annex-A may be referred to as ITU or CCITT Q.933. Auto-sense will either use the most recently detected LMI type or, in the absence of any LMI, will attempt to instigate LMI communications using each protocol. (1) Annnex-A: conforms to ITU (CCITT) Q.933 annex A (2) Annnex-D: conforms to ANSI T1.617 annex D (3) Type 1: conforms to the original LMI as developed by the Group of Four (4) Auto-sense: unit will attempt to detect and synchronize to the LMI type of the attached equipment. Enumeration: 'autosense': 4, 'annexa': 2, 'type1': 3, 'annexd': 1.

Timer used by the unit to determine that an attached device is not participating in the LMI protocol and that the unit should attempt to source LMI. This timer also controls the length of time that the LMI sourcing state machine remains in a particular state as it attempts to locate an LMI peer. (0) LMI Sourcing disabled (2-255) LMI Inactivity timeout

Timer used by the unit to determine the frequency at which Status Enquiries are issued during LMI sourcing states where the unit is emulating a Frame Relay DTE device. (2-255) length of time between sending enquiries (in seconds)

Enable ARP (2), INARP (3), both (4), or neither (1). Enumeration: 'arp': 2, 'both': 4, 'inactive': 1, 'inarp': 3.

The frequency at which the unit issues INARP requests (in seconds) from 5 to 86400 (24 hours).

Timer used by the unit to determine if an LMI Full Status Report is missing. In the absence of a Full Status report for the duration defined by this timer, the unit will declare all DLCI's status INACTIVE and begin logging down time. Data passage is not interfered with. (0) Full Status Timer is disabled (20-3600) Full Status Report Timeout in seconds.

Address Resolution Dlcis determines which dlcis are used for address resolution. Multiple DLCI support only applies to piggyback mode; in other management modes, only the configured default dlci is used (1) Support the configured Address Resolution protocol(s) out both ports on the single configured default DLCI only (CfgFrDLCIValue). (2) Support the configured Address Resolution protocol(s) out both ports on all active DLCIs (per LMI). (3) Support the configured Address Resolution protocol(s) out the WAN on all active DLCIs (per LMI) and out the DTE on only the single default DLCI (CfgFrDLCIValue). (4) Support the configured Address Resolution protocol(s) out the DTE on all active DLCIs (per LMI) and out the WAN on only the single default DLCI (CfgFrDLCIValue). Enumeration: 'dtemulti': 4, 'single': 1, 'multiple': 2, 't1multi': 3.

This setting configures the unit for VNIP topology support on a per-interface basis. Establishing a VNIP topology is a fundamental prerequisite to applying the VNIP feature set which includes PVC-based delay measurement, diagnostics, and congestion monitoring. With VNIP enabled on an interface the unit will attempt to locate VNIP peers out that port. As peers are discovered and logged the unit will report the topology it has learned on its opposite interface. If VNIP is inactive on one interface it will not engage in any VNIP dialog; however it will continue to listen for topology messages on the inactive interface and will reflect these messages out the opposite interface if VNIP is enabled. With VNIP inactive on both interfaces the unit will transparently pass all VNIP messages. The topology database includes ip addresses, DLCI values, and the number of VNIP hops in between. (1) Topology Inactive: VNIP messages pass through unit (2) Topology Enabled on DTE only: unit logs VNIP peers seen out the DTE interface. Unit listens for topology reports from the WAN but doesn't generate any towards the WAN. Will report learned WAN topology towards the DTE. (3) Topology Enabled on WAN only: unit logs VNIP peers seen out the WAN interface. Unit listens for topology reports from the DTE but doesn't generate any towards the DTE. Will report learned DTE topology towards the WAN. (4) Topolgy Enabled on Both DTE and WAN: Unit logs VNIP peers seen out both interfaces and generates DTE topolgy reports towards the WAN and vice versa. Enumeration: 'both': 4, 'inactive': 1, 'dte': 2, 't1': 3.

The frequency of hello messages sent during initialization in seconds from 5 seconds to 86400 seconds (24 hours).

This is the frequency that topology reports are issued out any interface that has VNIP enabled. Once a Hello exchange occurs, the unit will periodically issue a VNIP message which reflects the topology it has learned on the opposite interface. This Keep Alive timer must be less than any peer unit's Inactivity timer. (5-86400) VNIP Topology Update frequency (in seconds)

The length of time to wait before dropping a VNIP peer from the database and attempting tp reestablish communications by issuing the VNIP Hello message. If this timer expires then the entire topology database is reset. The Inactivity timers of any unit participating in a VNIP topology must be greater than the highest Keep Alive timer in the topology. (5- 86400) VNIP Hello frequency (in seconds)

Transit Delay measurements may be enabled between any DLCI peers that have been logged through the topology protocol. Delay messages are issued at this frequency and results are recorded. Transit delay measures the round-trip network delay between two VNIP peers (internal unit latencies are not part of the measurement). Traps may be optionally generated if a delay threshold is exceeded. (15-86400): Transit Delay message frequency (in seconds)

The table defining the transit delay measurement profile for each of the learned VNIP peers. As peers are located and logged into the topology database, a default transit delay profile is assumed. The default is to enable transit delay to all hops located out the interface. A DLCI's transit delay profile cannot be modified unless the DLCI has been discovered through the VNIP topology protocol.

A VNIP Transit Delay configuration entry for a particular DLCI on a particular interface. A DLCI's transit delay profile cannot be modified unless the DLCI has been discovered through the VNIP topology protocol

This is the interface being configured for VNIP Transit Delay. If topology is enabled, each interface will contain a database of VNIP peers organized by DLCI value and Number of Hops. (1) DTE Interface (2) DDS Interface Enumeration: 'dte-interface': 1, 't1-interface': 2.

This is the DLCI being configured for VNIP Transit Delay. If topology is enabled, each interface will contain a database of VNIP peers organized by DLCI value and Number of Hops.

VNIP topolgy may include multiple units on a given DLCI/interface. The topology logs the number of intermediate VNIP peers between units (Hops). This setting determines which peers on a DLCI are participating in delay measurements. (0) All hops (1-254) individually addressable delay measurement between any two peers. (255) Furthest hop only

Controls the Receive Summary Cancellation feature of VNIP Transit Delay on this interface/DLCI. Every Transit Delay measurement exchange includes a follow-up message from the initiator with the delay results. If RSC is enabled, a unit will log results based upon this summary message and will not issue its next scheduled delay measurement. With RSC disabled, the unit will not use the summary message and will always issue its regularly scheduled message based on the delay frequency timer. The purpose of this feature is to reduce traffic introduced by VNIP. In a typical peer-to-peer transit delay measurement where both ends are concurrently conducting transit delay measurements it's recommended that one end have RSC enabled and one end disabled. Enumeration: 'disable-rsc': 2, 'enable-rsc': 1.

Specifies a transit delay threshold for this DLCI/interface. When the transit delay exceeds the threshold, a TRAP is sent. The threshold may be set from one millisecond to 24 hours. A value of 0 will prevent a TRAP from being sent. (0): Transit delay threshold trap disabled for this DLCI/interface (1-86400000): delay threshhold. Any delay measurements exceeding this result will generate a trap.

The table allows the user to disable transit delay measurements for a specific DLCI on a particular interface.

Disables VNIP Transit Delay for a particular interface and DLCI.

Transit delay can be disabled for a given DLCI on either interface. This indexes the interface. Setting this index and the associated DLCI index will disable transit delay on that combination. Enumeration: 'dte-interface': 1, 't1-interface': 2.

Transit delay can be disabled for a given DLCI on either interface. This indexes the DLCI. Setting this index and the associated interface index will disable transit delay on that combination.

The mfrapCfgTransitDelayTable is cleared. (1) clear the table Enumeration: 'clear-table': 1.

This table allows the user to configure DLCI specific parameters such as Names, CIR, and EIR. Additionally, any DLCIs configured with these parameters will be added into the Short Term statistics database next time its cleared.

A table entry indexed by DLCI, containing a DLCI, a DLCI name, a CIR, and how the CIR value was obtained.

A DLCI selected for customized configuration and to be added to short term statistics collection (if it wasn't already there).

A user-specifiable name for an individual DLCI.

The CIR value for an individual DLCI. This value is used in the calculation utilization as a percentage of CIR. If the CIR is reported in the LMI message then the reported value will override this configured entry. In the absence of LMI CIR and a configured CIR, the unit will assume that the CIR is the DTE Line Rate.

The source of the CIR value for this DLCI. If CIR for a DLCI is part of the LMI message then this LMI supplied CIR will override any defined CIR. If CIR is not part of LMI and has not been explicitly defined by the user it will default to the DTE Line Rate. (1) CIR reported in LMI Full Status message (2) CIR configured by user (3) CIR defaulted to DTE Line Rate Enumeration: 'cir-configured-by-user': 2, 'cir-acquired-from-lmi': 1, 'cir-is-datarate': 3.

The threshold for generating a utilization threshold trap as a percentage of the CIR. If the utilization percentage is above this threshold for more than mfrapCfgFrPerfDlciUtilThreshold number of mfrapCfgFrPerfTimersSTInterval's a mfrapPvc(Rx/Tx)UtilizationExceeded trap will be issued. If the If the utilization percentage falls below this threshold for more than mfrapCfgFrPerfDlciUtilThreshold number of mfrapCfgFrPerfTimersSTInterval's a mfrapPvc(Rx/Tx)UtilizationExceeded trap will be issued.

The EIR value for an individual DLCI. In the absence of a configured EIR, the unit will assume that the EIR is the DTE Line Rate.

Setting this object with a specific DLCI value will remove the DLCI from the DLCI-specific parameters database.

Short term statistics maintain cumulative counts, and counts for the current and previous short term windows. This value is the window size for the short term statistics intervals. (3-60): short term statistics collection interval

Long term statistics maintain 96 contiguous intervals of configurable protocol per DLCI statistics. This value is the window size of each interval. Adjusting this value will change the overall length of time that the 96 intervals will span. (4-3600): long term statsistics collection interval

This table allows the user to select TCP/UDP ports for statistics collection. Tx and Rx byte counts will collected on the specified ports. These ports are selectable as protocols in the long term statistics filter and are displayed with the other protocols in the short term statistics.

An index and TCP/UDP port number pair.

An index. Beginning with index 1, the range is defined in SysNumUserProtocols

Tx and Rx byte counts will be collected on the user-specifiable TCP/UDP port number. (0) port not defined (1-65535): IP TCP/UDP protocol port number.

Long term statistics can only be collected on a limited number of DLCIs. The value of SysLTFNumDlcis defines the maximum number of DLCIs that can be included in the Long Term Statistics. Once one or more DLCIs are added to Long Term Stats, the user may assign a set of protocols that will be monitored across all of the Long Term DLCIs.

An index and DLCI number pair.

An index. Beginning with index 1, the maximum is defined by the value of SysLTFNumDlcis.

Setting a DLCI value here will add that DLCI into the Long term statistics database (associated with its index) and it will be monitored for the protocol activity defined in the Long Term Protocol filter.

Long term statistics can only be collected on a limited number of protocols. The maximum number of Long Term Protoocls are defined by SysLTFNumProtocols. This table allows the user to configure those protocols.

An index and protocol pair.

An index. Beginning with index 1, the maximum is defined by the value of SysLTFNumProtocols.

Long term statistics will be collected on the user-specifiable protocol. Setting a -1 remove the indexed protocol from the filter. Enumeration: 'gp-mem-report-icmp-ip-tx-bc': 69, 'addr-mask-req-icmp-ip-rx-bc': 62, 'src-quench-icmp-ip-tx-bc': 47, 'thru-becn-tx-bc': 133, 'lmi-full-enq-tx-bc': 159, 'gp-mem-query-icmp-ip-tx-bc': 67, 'other-ip-tx-bc': 75, 'annex-g-rx-bc': 172, 'snmptrap-udp-ip-rx-bc': 38, 'thru-fecn-rx-bc': 132, 'user-defined-2-rx-bc': 122, 'lmi-livo-stat-rx-bc': 158, 'icmp-ip-tx-bc': 41, 'sna-appn-rx-bc': 112, 'spx-ipx-rx-bc': 80, 'thru-byte-rx-bc': 128, 'icmp-ip-rx-bc': 42, 'cir-percent-range7-tx-bc': 149, 'netbios-ssn-tcp-ip-rx-bc': 16, 'netbios-ipx-rx-bc': 88, 'dest-unr-icmp-ip-rx-bc': 46, 'tftp-udp-ip-rx-bc': 30, 'snmp-udp-ip-rx-bc': 36, 'cir-percent-range4-rx-bc': 144, 'cir-percent-range2-rx-bc': 140, 'echoreq-icmp-ip-tx-bc': 51, 'telnet-tcp-ip-tx-bc': 7, 'cir-percent-range1-tx-bc': 137, 'lmi-rx-bc': 154, 'user-defined-1-rx-bc': 120, 'udp-ip-rx-bc': 22, 'param-prob-icmp-ip-rx-bc': 56, 'vnip-tx-bc': 169, 'user-defined-4-rx-bc': 126, 'addr-mask-req-icmp-ip-tx-bc': 61, 'ncp-ipx-rx-bc': 82, 'ftp-tcp-ip-rx-bc': 6, 'rarp-rep-rx-bc': 100, 'cir-percent-range3-tx-bc': 141, 'sna-netbios-tx-bc': 113, 'smtp-tcp-ip-tx-bc': 9, 'netbios-ipx-tx-bc': 87, 'snmp-udp-ip-tx-bc': 35, 'gp-mem-reduct-icmp-ip-rx-bc': 72, 'ip-rx-bc': 2, 'dest-unr-icmp-ip-tx-bc': 45, 'cir-percent-range2-tx-bc': 139, 'inarp-req-tx-bc': 101, 'arp-req-tx-bc': 93, 'addr-mask-rep-icmp-ip-rx-bc': 64, 'cisco-rx-bc': 116, 'rarp-rep-tx-bc': 99, 'redirect-icmp-ip-tx-bc': 49, 'other-ipx-rx-bc': 90, 'spx-ipx-tx-bc': 79, 'echorep-icmp-ip-tx-bc': 43, 'param-prob-icmp-ip-tx-bc': 55, 'ospf-ip-tx-bc': 73, 'echorep-icmp-ip-rx-bc': 44, 'redirect-icmp-ip-rx-bc': 50, 'lmi-tx-bc': 153, 'http-tcp-ip-tx-bc': 13, 'cir-percent-range8-tx-bc': 151, 'sap-ipx-rx-bc': 84, 'sna-tx-bc': 105, 'other-ipx-tx-bc': 89, 'cir-percent-range4-tx-bc': 143, 'ipx-tx-bc': 77, 'echoreq-icmp-ip-rx-bc': 52, 'other-rx-bc': 118, 'cir-percent-range1-rx-bc': 138, 'smtp-tcp-ip-rx-bc': 10, 'total-downtime': 166, 'addr-mask-rep-icmp-ip-tx-bc': 63, 'vnip-rx-bc': 170, 'arp-rep-rx-bc': 96, 'user-defined-2-tx-bc': 121, 'annex-g-tx-bc': 171, 'rip-udp-ip-rx-bc': 40, 'arp-rx-bc': 92, 'src-quench-icmp-ip-rx-bc': 48, 'rip-ipx-tx-bc': 85, 'user-defined-3-tx-bc': 123, 'cir-percent-range3-rx-bc': 142, 'lmi-other-tx-bc': 163, 'lmi-full-enq-rx-bc': 160, 'user-defined-3-rx-bc': 124, 'igrp-rx-bc': 168, 'sna-periph-rx-bc': 110, 'arp-rep-tx-bc': 95, 'rip-udp-ip-tx-bc': 39, 'other-ip-rx-bc': 76, 'tftp-udp-ip-tx-bc': 29, 'netbios-dgm-udp-ip-tx-bc': 33, 'rarp-req-tx-bc': 97, 'lmi-other-rx-bc': 164, 'timestamp-rep-icmp-ip-rx-bc': 60, 'snmptrap-udp-ip-tx-bc': 37, 'pkt-too-big-icmp-ip-tx-bc': 65, 'thru-fecn-tx-bc': 131, 'cir-percent-range6-tx-bc': 147, 'cir-percent-range7-rx-bc': 150, 'lmi-livo-stat-tx-bc': 157, 'sna-netbios-rx-bc': 114, 'ip-tx-bc': 1, 'pkt-too-big-icmp-ip-rx-bc': 66, 'ncp-ipx-tx-bc': 81, 'user-defined-4-tx-bc': 125, 'lmi-livo-enq-tx-bc': 155, 'gp-mem-query-icmp-ip-rx-bc': 68, 'gp-mem-report-icmp-ip-rx-bc': 70, 'user-defined-1-tx-bc': 119, 'thru-becn-rx-bc': 134, 'ospf-ip-rx-bc': 74, 'tcp-ip-rx-bc': 4, 'lmi-livo-enq-rx-bc': 156, 'udp-ip-tx-bc': 21, 'cisco-tx-bc': 115, 'rip-ipx-rx-bc': 86, 'arp-req-rx-bc': 94, 'sna-appn-tx-bc': 111, 'http-tcp-ip-rx-bc': 14, 'gp-mem-reduct-icmp-ip-tx-bc': 71, 'other-tx-bc': 117, 'igrp-tx-bc': 167, 'timestamp-req-icmp-ip-rx-bc': 58, 'timestamp-rep-icmp-ip-tx-bc': 59, 'time-excd-icmp-ip-rx-bc': 54, 'thru-de-rx-bc': 136, 'lmi-full-stat-tx-bc': 161, 'timestamp-req-icmp-ip-tx-bc': 57, 'ftp-tcp-ip-tx-bc': 5, 'netbios-ssn-tcp-ip-tx-bc': 15, 'time-excd-icmp-ip-tx-bc': 53, 'thru-de-tx-bc': 135, 'thru-frame-tx-bc': 129, 'sna-periph-tx-bc': 109, 'sna-subarea-rx-bc': 108, 'telnet-tcp-ip-rx-bc': 8, 'netbios-dgm-udp-ip-rx-bc': 34, 'thru-byte-tx-bc': 127, 'lmi-full-stat-rx-bc': 162, 'inarp-req-rx-bc': 102, 'delete-entry': -1, 'arp-tx-bc': 91, 'tcp-ip-tx-bc': 3, 'rarp-req-rx-bc': 98, 'inarp-rep-rx-bc': 104, 'cir-percent-range5-rx-bc': 146, 'thru-frame-rx-bc': 130, 'ipx-rx-bc': 78, 'sna-subarea-tx-bc': 107, 'cir-percent-range5-tx-bc': 145, 'cir-percent-range6-rx-bc': 148, 'inarp-rep-tx-bc': 103, 'sna-rx-bc': 106, 'total-uptime': 165, 'sap-ipx-tx-bc': 83, 'cir-percent-range8-rx-bc': 152.

The default threshold for generating a utilization threshold trap as a percentage of the CIR. This value is used for mfrapCfgFrPerfDlciNamesUtilThreshold when a DLCI is first discovered.

The number of Short Term Intervals that a DLCI's utilization as a percentage of CIR must be above or below the value of mfrapCfgFrPerfDlciUtilThreshold before a mfrapPvc(Rx/Tx)UtilizationExceededTrap or mfrapPvc(Rx/Tx)UtilizationClearedTrap is issued.

Clears the smperCfgFrPerfDlciNamesTable (1) clear the table or (2) clear the table but don't remove the dlcis from the short term statistics. Enumeration: 'clear-table-keep-stats': 2, 'clear-table': 1.

Clears the mfrapCfgFrPerfUserProtocolsTable (1) clear the table Enumeration: 'clear-table': 1.

Clears the mfrapCfgFrPerfLTDlciFilterTable (1) clear the table Enumeration: 'clear-table': 1.

Clears the mfrapCfgFrPerfLTProtocolFilterTable (1) clear the table Enumeration: 'clear-table': 1.

Delete all unprovisioned and Not-In-LMI dlcis (1) delete all unprovisioned Enumeration: 'delete-unprov': 1.

The password needed to start a CLI (Command Line Interface), Telnet or LCD session.

The password needed to initiate a TFTP download.

OBSOLETE: The Telnet, CLI and LCD passwords are one and the same. Use the above mfrapCfgTelnetCliLcdPassword to log into the CLI (Command Line Interface).

OBSOLETE: The Telnet, CLI and LCD passwords are one and the same. Use the above mfrapCfgTelnetCliLcdPassword to log into the LCD Interface.

The community string for doing SNMP GETs. The unit will respond to GETs that use either this string or the SET community string. All others will be rejected and a trap will be generated. String is case sensitive.

The community string for doing SNMP SETs. The unit will reject SETs with any other coimmunity string and will generate a trap. String is case sensitive.

This selection controls whether a password is necessary to use the LCD interface. Enumeration: 'enable-lcd-pswd': 1, 'disable-lcd-pswd': 2.

OBSOLETE.

Retrieves node's active connections assignments for display only. To edit connections, use the mfrapCfgDteTable and/or mfrapCfgEditConnTable.

An entry in the Current Connections Table.

Index to Destination port of interest. M-FRAP currently only supports the Network port (1) as the destination Enumeration: 'port1-t1': 1.

DS0 number 1 through 24 corresponding to the destination port index

DS0 assignment for Destination port. After making any adjustments to the connections, the mfrapCfgConnUpdateCmd must be sent. Node software does not permit a port connection to itself. Enumeration: 'port2-dandi': 2, 'port3-dte': 3, 'not-connected': 33.

DS0 number 1 through 24 corresponding to the sourced port Enumeration: 'ds0-19': 19, 'ds0-18': 18, 'ds0-13': 13, 'ds0-12': 12, 'ds0-11': 11, 'ds0-10': 10, 'ds0-17': 17, 'ds0-16': 16, 'ds0-15': 15, 'ds0-14': 14, 'ds0-22': 22, 'ds0-23': 23, 'ds0-20': 20, 'ds0-21': 21, 'ds0-08': 8, 'ds0-09': 9, 'ds0-24': 24, 'ds0-04': 4, 'ds0-05': 5, 'ds0-06': 6, 'ds0-07': 7, 'ds0-01': 1, 'ds0-02': 2, 'ds0-03': 3, 'no-connection': 40.

Defines the type of traffic being transported. Enumeration: 'frame-relay': 3, 'voice': 1, 'not-connected': 33, 'transparent': 2.

Fill the edit buffer with the node's current active connections. Enumeration: 'copy-current': 1.

Clear all connections from the edit buffer. Enumeration: 'clear-edit': 1.

Edits current DS0 assignment. This table is also updated by the mfrapCfgDteTable. After making any adjustments to the connections, the mfrapCfgConnUpdateCmd must be sent.

An entry in the Edit Connections table.

Index to destination port of interest. M-FRAP currently only supports the Network port (1) as the destination. Enumeration: 'port1-t1': 1.

DS0 number 1 through 24 corresponding to the Destination port index

DS0 assignment for indexed destination port. The value not-connected may not be written; to clear a connection, use the mfrapCfgEditDisconnect table element. Setting mfrapCfgEditDisconnect to disconnect will cause this element to return not-connected for a get. Currently, M-FRAP will not allow setting this value to 3. Connections defined by the mfrapCfgDteTable will be reflected in reads of this object. After making any adjustments to the connections, the mfrapCfgConnUpdateCmd must be sent. Node software does not permit connections between a port and itself. Enumeration: 'port2-dandi': 2, 'port3-dte': 3, 'not-connected': 33.

DS0 number 1 through 24 corresponding to the sourced port index. The value no-connection may not be written. To clear a connection use the mfrapCfgEditDisconnect table element. Setting mfrapCfgEditDisconnect to disconnect will cause this element to return no-connection for a get. Enumeration: 'ds0-19': 19, 'ds0-18': 18, 'ds0-13': 13, 'ds0-12': 12, 'ds0-11': 11, 'ds0-10': 10, 'ds0-17': 17, 'ds0-16': 16, 'ds0-15': 15, 'ds0-14': 14, 'ds0-22': 22, 'ds0-23': 23, 'ds0-20': 20, 'ds0-21': 21, 'ds0-08': 8, 'ds0-09': 9, 'ds0-24': 24, 'ds0-04': 4, 'ds0-05': 5, 'ds0-06': 6, 'ds0-07': 7, 'ds0-01': 1, 'ds0-02': 2, 'ds0-03': 3, 'no-connection': 40.

Defines the type of traffic being transported. The value not-connected may not be written. To clear a connection use the mfrapCfgEditDisconnect table element. Setting mfrapCfgEditDisconnect to disconnect will cause this element to return not-connected for a get. Enumeration: 'frame-relay': 3, 'voice': 1, 'not-connected': 33, 'transparent': 2.

Setting this object to disconnect will cause the state of the Src and Type objects for this destination port and ds0 to be set to not-connected. When connections are updated, the connection between the source and destination will be terminated. Enumeration: 'disconnect': 1.

The status of the last set of an mfrapCfgEditConnTable object. Invalid-dte-bandwidth is returned if the set reduces the number of ds0's assigned to a DTE port to less than the number required for the port's bandwidth and density. Bandwidth-conflict is returned if an attempt is made to change the source port without first disconnecting the existing connection. Ds0s-not-ascending is returned if the source ds0 being set is not in ascending order with the other ds0's for that source port. Enumeration: 'set-valid': 1, 'bandwidth-conflict': 3, 'illegal-value': 8, 'invalid-dte-bandwidth': 2, 'ds0s-not-ascending': 4.

Displays the status of the connections in the edit buffer. This object should be read before setting the mfrapCfgConnUpdateCmd. Incorrect-dte-bandwidth is returned if there are not enough DS0's starting with the mfrapCfgDteConnStartDs0 to accommodate the mfrapCfgDteConnDs0Required. Incomplete-entry is returned if the source port, source ds0 and/or connection type has not been set for a connection (and at least one of them has been set for that connection). Inconsistent-edit-buffer is returned if there is an internal inconsistency in the edit buffer; in this case, an mfrapCfgEditConnCopyCurrtoEdit or mfrapCfgEditClearEdit set should be performed before proceeding. Bad-connection-type is returned if the connection type is not consistent with the source and destination ports. Enumeration: 'ds0s-not-ascending': 4, 'no-current-connections': 99, 'inconsistent-edit-buff': 6, 'incomplete-entry': 5, 'connections-valid': 1, 'invalid-dte-bandwidth': 2, 'bad-connection-type': 7.

Updates the connections with the edit buffer if the connections are all valid. The edit buffer is comprised of any changes sent (set) from the mfrapCfgEditConnTable or the mfrapCfgDteTable. Note that if changes are made to the mfrapCfgDteTable, the mfrapCfgConnAutoUpdate object must be set before the mfrapCfgConnUpdateCmd in order for the changes to take effect. Enumeration: 'config-and-connect': 1.

Type of Framing on this D&I Line. Check with your service provider to determine value. D4 is also known as 'SuperFrame', ESF is 'Extended SuperFrame'. ESF provides enhanced performance monitoring capabilities. Enumeration: 'esf': 2, 'd4': 1.

D&I interface bipolar encoding scheme. Check with your service provider to determine value. B8ZS, which inherently provides ample 'ones-density', is recommended. AMI users must pay special attention to the 'ones-density' requirements of the service provider. Enumeration: 'ami': 1, 'b8zs': 2.

Request to start configuration download and lock out any other means of configuring the unit. The integer passed in represents the time out period in seconds between sets. A set to this object will fail if the unit is already in a configuration locked state.

Returns the IP Address of the management station currently in control of configuration. A unit that is not in a configuration locked state will return 0.0.0.0

A read of this object returns the Current Configuration ID string. A write sets the Configuration ID string. The string contains a starting character to indicate the last configuration source C = Envisage N = CLI/TELNET L = LCD S= other SNMP management station and a unique 7 integer value to differentiate configurations between common sources. A value of *STARTUP indicates the configuration has been defaulted. A write will only be accepted from the management station that has successfully obtained the configuration lock

The status of a configuration install is reported here. On startup, a status of success will be reported. (1) The configuration has been locked and an update or unlock command has not been received. (2) An update command has been received and the configuration has been validated as consistent; . (3) An update command has been received but the DTE port datarate is not compatible with the density. (4) An update command has been received but the number of channels to be allocated will not fit in the available channels. (5) An update command has been received but there is an error in the configuration that is not a datarate-density-conflict or bandwidth-allocation-error. (6) The time between consecutive set requests exceeded the timeout sent with the tfrapCfgLock command. (7) The user sent a tfrapCfgUnlock command before a tfrapCfgUpdate command. This usually means that one of the sets in the configuration failed. Enumeration: 'aborted-by-user': 7, 'success': 2, 'in-progress': 1, 'datarate-density-conflict': 3, 'general-error': 5, 'timeout': 6, 'bandwidth-allocation-error': 4.

The management station sets this variable to complete the configuration install process. Un-lock (1) notifies the agent to remove the lock on configuring the unit without updating the configuration. Enumeration: 'un-lock': 1.

The management station sets this variable to complete the configuration install process. Update (1) notifies the agent to start the update process within the unit. Enumeration: 'update': 1.

Controls a bi-directional unit loopback. Data is received from either the DTE or Network interface, processed, and transmitted back towards the same interface. When configured for Frame Relay operation the unit will preserve the LMI path and maintain managed access during this loopback. In Frame Relay mode, only valid HDLC frames are looped back (pseudorandom test patterns will be dropped). Data received on the Drop & Insert is not affected by this loopback mode. (1) enable unit loopback (2) disable unit loopback Enumeration: 'enable-loopback-mode': 1, 'disable-loopback-mode': 2.

Enables the operator to remotely cause a software reset on the unit. Using this command will cause the unit to terminate all its connections and drop data. (1) Reset Unit. Enumeration: 'reset-unit': 1.

The remaining time on the active loopback before the loopback times out and disables itself. The time is in hundredths of seconds (TimeTicks).

Controls local network loopback. All data (including framing and line errors) received from the WAN, regardless of format or content, is transmitted back out to the WAN (line interface loopback) while still being passed through to the DTE. In Frame Relay applications the unit will not preserve the LMI path during this diagnostic and in-band management may not operate. (1) disable line loopback (2) enable line loopback Enumeration: 'line-lpbk-disable': 1, 'line-lpbk-enable': 2.

Controls network payload loopback. All data received from the WAN is terminated, reframed and sent back towards the WAN. Framing errors and Line Code Violations are corrected. Network contact via ESF Facility Data Link is preserved during this loopback state. All user data regardless of format or content, is transmitted back out while all Ones are sent to the DTE. In Frame Relay applications the unit will not preserve the LMI path during this diagnostic and in-band management may not operate. (1) disable payload loopback (2) enable payload loopback Enumeration: 'pyl-lpbk-enable': 2, 'pyl-lpbk-disable': 1.

Controls Local Aggregate Loopback. All data received from the DTE and Drop & Insert ports is framed, formatted and transmitted towards the WAN while being looped back towards the respective port (DTE or Drop & Insert). The loopback path covers the entire digital data path within the device. In Frame Relay mode, only error-free HDLC frames will pass through the loopback path. Additionally, in Frame Relay applications the unit will not preserve the LMI path during this loopback and in-band management may not operate. (1) disable local aggregate (digital) loopback (2) enable local aggregate (digital) loopback Enumeration: 'aggr-lpbk-disable': 1, 'aggr-lpbk-enable': 2.

Status of Remote Loopback commands sent or received on the WAN. (1) no remote loopbacks are active. (2) csu loopback from remote - indicates the node is in a Network Line Loopback state due to the reception of the standard CSU Loop-up pattern from the WAN. (3) dsu loopback from remote - indicates the node is in a Network Line Loopback state due to the reception of the Sync Research proprietary Loop-up pattern from a remote node. (4) payload loopback from remote - indicates the node is in a Payload Loopback state due to the reception of the ESF Facility Data Link's Loop-up pattern from the network. (5) csu loopback sent to remote - indicates the node has sent a csu loop up pattern towards the WAN. A device terminating the WAN's physical link is expected to enter a Line Loopback. The initating unit doesn't know if the loopback was accepted by the remote unit. (6) dsu loopback sent to remote - indicates the node has sent a dsu loop up pattern to a remote Sync unit out the WAN. A compatible device detecting this pattern is expected to enter a Line Loopback. The initating unit doesn't know if the loopback was accepted by the remote unit. Enumeration: 'csu-lpbk-sent-to-remote': 5, 'no-remote-lpbks': 1, 'csu-lpbk-from-remote': 2, 'dsu-lpbk-sent-to-remote': 6, 'pyl-lpbk-from-remote': 4, 'dsu-lpbk-from-remote': 3.

Remote loopback commands are intended to place compatible external equipment into a loopback state. The initiating unit will maintain normal data flows during these tests. (1) csu loop up - commands the node to send a standard in-band csu loop up pattern towards the WAN. This is a repetetive framed T1 signal consisting of four 'zeros' followed by one 'one' persisting for a few seconds in place of all T1 data. A device terminating the WAN's physical link is expected to enter a Line Loopback condition upon recognition of this pattern. The initating unit doesn't know if the command was accepted by the remote unit. (2) csu loop down - commands the node to send a standard in-band csu loop down pattern towards the WAN. This is a repetetive framed T1 signal consisting of two 'zeros' followed by one 'one' persisting for a few seconds in place of all T1 data. A device terminating the WAN's physical link is expected to clear any Line Loopback condition upon recognition of this pattern. The initating unit doesn't know if the commad was accepted by the remote unit. (3) dsu loop up - commands the node to send a proprietary in-band dsu loop up pattern towards the WAN. This is a repetetive framed T1 signal consisting of a pseudorandom pattern persisting for a few seconds in place of all T1 data. A compatible device terminating the WAN's physical link is expected to enter a Line Loopback condition upon recognition of this pattern. The initating unit doesn't know if the command was accepted by the remote unit. (4) dsu loop down - commands the node to send a proprietary in-band dsu loop down pattern towards the WAN. This is a repetetive framed T1 signal consisting of a pseudorandom pattern persisting for a few seconds in place of all T1 data. A compatible device terminating the WAN's physical link is expected to clear any Line Loopback condition upon recognition of this pattern. The initating unit doesn't know if the command was accepted by the remote unit. Enumeration: 'rmt-dsu-lpbk-loopdown': 4, 'rmt-dsu-lpbk-loopup': 3, 'rmt-csu-lpbk-loopup': 1, 'rmt-csu-lpbk-loopdown': 2.

The remaining time on the active loopback before the loopback times out and automatically clears itself to restore the unit to normal operation. The time is in hundredths of seconds (TimeTicks).

Status of the Request to Send (RTS) signal from the DTE port. (1) RTS Active (2) RTS Inactive Enumeration: 'rts-signal-on': 1, 'rts-signal-off': 2.

Status of the Data Terminal Ready (DTR) signal from the DTE port. (1) DTR Active (2) DTR Inactive Enumeration: 'dtr-signal-off': 2, 'dtr-signal-on': 1.

Controls the DTE loopback state. This is a bi-directional loopback state where both the DTE and WAN ports are placed in line loopback. All data received on each interface is sent back out the respective interface regardless of format or content. In Frame Relay applications the unit will not preserve the LMI path during this diagnostic and in-band management will not operate. (1) enable payload loopback (2) disable payload loopback Enumeration: 'enable-loopback-mode': 1, 'disable-loopback-mode': 2.

This reports the status of any local V54 testing initiated by a remote unit. Remote V54 loopback commands are intended to place this unit into a loopback state. The initiating unit will maintain normal data flows during these tests. (1) V54 loop up received - indicates the node has received a standard in-band loop up pattern from the WAN per ITU V.54. This is a framed T1 signal consisting of a pseudorandom signal in place of all user data (that is only in the DS0s assigned to the DTE). This unit has entered a bi-directional DTE Loopback condition. (2) V54 loop down received - indicates the node has received a standard in-band loop down pattern from the WAN per ITU V.54. This is a framed T1 signal consisting of a pseudorandom signal in place of all user data (that is only in the DS0s assigned to the DTE). This unit has cleared the bi-directional DTE Loopback condition. Enumeration: 'loopback-enable': 1, 'loopback-disable': 2.

Remote V54 loopback commands are intended to place compatible external equipment into a loopback state. The initiating unit will maintain normal data flows during these tests. (3) Transmit V54 loop up - commands the node to send a standard in-band loop up pattern towards the WAN per ITU V.54. This is a framed T1 signal consisting of a pseudorandom signal in place of all user data (that is only in the DS0s assigned to the DTE). A device terminating the fractional T1 data is expected to enter a bi-directional DTE Loopback condition upon recognition of this pattern. The initating unit doesn't know if the command was accepted by the remote unit. This pattern will not traverse a typical frame relay network and is designed for circuit-switched diagnostics. (4) Transmit V54 loop down - commands the node to send a standard in-band loop down pattern towards the WAN per ITU V.54. This is a framed T1 signal consisting of a pseudorandom signal in place of all user data (that is only in the DS0s assigned to the DTE). A device terminating the fractional T1 data is expected to clear a bi-directional DTE Loopback condition upon recognition of this pattern. The initating unit doesn't know if the command was accepted by the remote unit. Enumeration: 'transmit-code-disable': 4, 'transmit-code-enable': 3.

The remaining time on the active loopback before the loopback times out. The time is in hundredths of seconds (TimeTicks).

The unit is capable of sending a pseudorandom test pattern (511 or QRSS) out the WAN and monitoring the WAN received data for the same pattern. The BERT pattern may be selected to occupy the full T1 payload, only the bandwidth allocated to the DTE, only the bandwidth allocated to the Drop & Insert or only the bandwidth allocated to the DTE and the Drop & Insert (fractional T1). When a unit is sending this BERT, the receiver will monitor and characterize the incoming signal for the same BERT pattern. In Frame Relay applications the unit will not preserve the LMI path during this diagnostic and in-band management may not operate. This test may be ineffective in certain frame relay environments as pseudorandom data lacks appropriate framing. Refer to VLOOP and VBERT for PVC-based error-rate testing in a live frame relay network. (1) Start a BERT test on full T1 - replaces entire T1 payload with the configured BERT pattern while monitoring the full T1 bandwidth (1.536M) for the presence of the BERT pattern. (2) Start a BERT test on the DTE bandwidth - replaces only the portion of the T1 payload that has been allocated to the DTE with the configured BERT pattern while monitoring the same T1 bandwidth (DTE Data Rate) for the presence of the BERT pattern. (3) Stop a BERT test. (4) Inject a single bit error into the outgoing pattern. (5) Clear current BERT results. (6) Starts a BERT test on the Drop & Insert bandwidth - replaces only the portion of the T1 payload that has been allocated to the Drop & Insert with the configured BERT pattern while monitoring the same T1 bandwidth (D&I DS0's) for the presence of the BERT pattern. (7) Starts a BERT test on the DTE & D&I bandwidth (fractional T1) - replaces only the portion of the T1 payload that has been allocated to the DTE or the Drop & Insert with the configured BERT pattern while monitoring the same T1 bandwidth for the presence of the BERT pattern. Enumeration: 'start-bert-test-fractional-t1': 7, 'inject-error-bert-test': 4, 'stop-bert-test': 3, 'start-bert-test-dte': 2, 'clear-error-bert-test': 5, 'start-bert-test-dandi': 6, 'start-bert-test-t1': 1.

Displays the current BERT test sync status. (1) BERT is not running (2) BERT is running but is not in sync (3) BERT is running and has detected a received BERT Enumeration: 'bert-out-of-sync': 2, 'bert-off': 1, 'bert-in-sync': 3.

Displays the number of errors detected in Bert Test.

Displays the number of seconds containing 1 or more errors in BERT Test.

Elapsed time since BERT test was started or cleared.

Displays the number of times BERT test has synched up on the pattern. The BERT will attempt to resynchronize in response to excessive errors. A running count here indicates that a clean BERT is not being received.

The type of pseudorandom BERT pattern used. (1) 511: 9-bit pseudorandom pattern (2) QRSS: 20-bit pseudorandom pattern with no more than 14 consecutive zeros Enumeration: 'five11-pattern': 1, 'qrss': 2.

Table of Diagnostics performed with the VNIP protocol

VNIP VLOOP and VBERT diagnostic profile. Initiating these tests require an established and stable VNIP topology on an interface. Once the topology is in place, the user can execute a PVC-based diagnostic between this unit and any indexed entry in the topology table. The index into the topology table for a particular interface is required.

The interface out which a PVC-based VNIP diagnostic will be run. This must be an interface with a valid and stable VNIP topology for a VNIP Diagnostic. Enumeration: 'dte-interface': 1, 't1-interface': 2.

The index to the external VNIP peer as presented by the VNIP topology database for the given interface. Refer to VnipTopologyTable to determine the index of the remote peer.

This is the DLCI value for the given interface/index combination. This comes from the VniptTopologyTable.

This is the ip address for the given interface/index combination. This comes from the VniptTopologyTable.

Controls execution of the Vnip Logical Loopback (VLOOP) test. VLOOP is designed as an intrusive test and customer data on the DLCI-under-test will be discarded. The VLOOP test includes a timed VBERT test and is run using the profile configured within this table. (1) start VLOOP test (2) stop VLOOP test (override VBERT test duration) Enumeration: 'stop-test': 2, 'start-test': 1.

Controls execution of the Vnip Virtual Bit Eror Rate (VBERT) test. VBERT is designed to be a non-intrusive test and will attempt to statistically multiplex VBERT test data and customer data on the DLCI-under-test. However, VBERT data is given priority over customer data when the selected VBERT volume causes internal congestion. The test is run using the profile configured within this table. (1) start test (2) stop test (override VBERT test duration) Enumeration: 'start': 1, 'stop': 2.

Specifies the throughput bit rate applied by VBERT or VLOOP to the DLCI-under-test. For DTE Rates or configured CIR up to 64K the maximum VBERT rate is either the DTE data rate or 110% of CIR (which ever is less). For DTE Rates or configured CIR greater than 64K, the maximum VBERT rate is 75% of the DTE data rate or 110% of CIR (which ever is less). Note that selecting rates that approach line rate will impact neighboring PVCs. (8000-1152000): VBERT/VLOOP data rate (in bits per second).

Specifies the size of framed data that will be used during the VBERT test, measured in Bytes. (64) 64-byte frames (128) 128-byte frames (256) 256-byte frames (512) 512-byte frames (1024) 1024-byte frames (2048) 2048-byte frames

Specifies percentage of VBERT packets that will have the Frame Relay Discard Eligibility bit set. Frames with this bit set may be more likley to get dropped in a congested network. (0) 0% of the test frames are marked discard eligible (25) 25% of the test frames are marked discard eligible (50) 50% of the test frames are marked discard eligible (75) 75% of the test frames are marked discard eligible (100) 100% of the test frames are marked discard eligible Enumeration: 'twentyFive-percent': 1, 'zero-percent': 0, 'seventyFive-percent': 3, 'oneHundred-percent': 4, 'fifty-percent': 2.

Specifies the duration of a VBERT test. Note that VBERT is subjected to the unit's Loopback Timer and will be terminated by whichever timer expires first. (10-1440): VBERT time duration in seconds

Local Line Loopback on the Drop & Insert port. Data and framing received at the D & I port is transmitted back out the D & I port (1) disable line loopback (2) enable line loopback Enumeration: 'line-lpbk-disable': 1, 'line-lpbk-enable': 2.

Local Payload Loopback on the Drop & Insert port. Data (NOT framing) received at the T1 port is looped back at the D&I port and reframed and transmitted back out the T1 port. (1) disable line loopback (2) enable line loopback Enumeration: 'pyl-lpbk-enable': 2, 'pyl-lpbk-disable': 1.

The remaining time on the active loopback before the loopback times out. The time is in hundredths of seconds (TimeTicks).

Status of allocation of T1 bandwidth to the DTE port data. (1) no connections - indicates the DTE port has no connections to the WAN. (2) Active - indicates DTE data rate has been assigned T1 DS0s and is in a normal data mode. (3) Test - indicates DTE data rate has been assigned T1 DS0s but is in a diagnostic condition. Enumeration: 'active': 2, 'test': 3, 'no-connections': 1.

Status of the signal received from the WAN (1) In Sync - unit has detected a properly framed T1 signal and is not experiencing any error conditions. (2) In Sync with Errors - unit has detected a properly framed T1 signal but is experiencing some error conditions. Refer to T1 current performance results for details. (3) Signal Detected without Frame Sync - while a signal is present from the WAN it does not contain the framing pattern defined for this unit. This could be either incorrectly configured T1 Frame type or the presence of an alarm condition on the WAN. (4) No Carrier - there is no signal detected from the WAN. (5) Not Applicable. Enumeration: 'signal-present-without-frame-sync': 3, 't1-frame-sync-okay': 1, 'signal-not-present': 4, 't1-frame-sync-with-errors': 2, 'not-applicable': 5.

Alarms present at the T1 port. (1) No alarm conditions present. (2) Red Alarm Declared - Unit has experienced loss of frame synchronization with the signal received from the WAN for an extended time and is reporting an alarm condition that severely impairs normal operation. During this Red Alarm condition the unit will transmit Yellow alarm back to the WAN. If this condition persists consult your service provider. (3) Yellow ALarm Detected - Unit is receiving a yellow alarm indication from the wide area network. Detection of yellow alarm implies that the attached device is in a red alarm conditon. Red alarm is declared due to the extended absence of a properly framed signal. If this condition persists consult your service provider. (4) Unframe All Ones Detected - Unit is receiving unframed all ones from the wide area network (AIS, blue alarm). Detection of AIS implies that the attached device is reporting an alarm condition from an upstream device. If this condition persists consult your service provider. Enumeration: 'no-alarms': 1, 'red-alarm-declared': 2, 'yellow-alarm-detected': 3, 'unframed-all-ones-detected': 4.

VNIP topology is a feature that, for each interface, maps all compatible VNIP peers, their DLCI value, ip address and relative location. The topology is a fundamental prerequisite to applying the VNIP feature set which includes PVC-based delay measurement, diagnostics, and congestion monitoring. With VNIP enabled on an interface the unit will attempt to locate VNIP peers out that port. As peers are discovered and logged the unit will report the topology it has learned on its opposite interface. If VNIP is inactive on one interface it will not engage in any VNIP dialog; however it will continue to listen for topology messages on the inactive interface and will reflect these messages out the opposite interface if VNIP is enabled. With VNIP inactive on both interfaces the unit will transparently pass all VNIP messages. The topology database includes the interface, local DLCI value, remote peer DLCI value, remote peer ip address, and the number of VNIP hops in between. This table also reports the status of other VNIP features as well.

The DLCI, IP address, and number of hops for a particular peer, discovered off of an interface (DTE or T1).

The interface off of which the peer was discovered. Topology is discovered by sending VNIP messages out each interface. Units discovered via a particular interface are kept in a list associated with that interface. (1) VNIP peers and status out DTE interface (2) VNIP peers and status out WAN interface Enumeration: 'dte-interface': 1, 't1-interface': 2.

The number of this discovered peer in the list of nodes for this interface. For each interface, the nodes are numbered 1 through n. This index is required when disabling or enabling VBERT/VLOOP to a particular peer.

The DLCI of the discovered neighboring peer. This may be different from the local DLCI.

The IP address for the discovered peer.

The discovered peer is this number of hops away. Each hop is a VNIP peer.

The DLCI of this node over which the neighboring peer was discovered.

The number of transit delay samples collected.

The average transit delay between this unit and the remote peer (in milliseconds).

The maximum transit delay between this node and the remote peer (in milliseconds).

The minimum transit delay between this node and the remote peer (in milliseconds).

The most recent transit delay measured between this node and the remote peer (in milliseconds).

This selection displays the status of the VNIP PVC Loopback for this entry. This loopback is initiated by the remote node through the VLOOP utility, causing this node to loop data back to the remote node. (1) Virtual Loopback path present on this PVC due to command received from remote unit. All data received on this DLCI will be looped back out the same interface. (2) No active VLOOP test on this Enumeration: 'loopback-enable': 1, 'loopback-disable': 2.

Displays the current status of the VBERT/VLOOP test. (1) Off: no test has run or the entry has been cleared (2) Testing: the entry is generating VBERT test frames (3) Test Failed: the request for a test on this entry failed (4) Test Completed: a test has run and is finished results are complete (5) In Test: the entry is on the receiving end of VBERT packets Enumeration: 'test-failed': 3, 'test-completed': 4, 'testing': 2, 'off': 1, 'in-test': 5.

Displays the number of Frames transmitted during VBERT Test that had the Discard Eligibility indicator bit set.

Displays the number of Frames received during VBERT Test that had the Discard Eligibility indicator bit set.

Displays the number of Frames transmitted during VBERT Test that had the Discard Eligibility indicator bit cleared.

Displays the number of Frames received during VBERT Test that had the Discard Eligibility indicator bit cleared.

The maximum transit delay between this node and the remote peer during the VBERT test. This delay measurement will include internal device latencies. This result may differ from the VNIP transit delay measurement which accounts for internal latencies.

The average transit delay between this node and the remote peer during the VBERT test. This delay measurement will include internal device latencies. This result may differ from the VNIP transit delay measurement which accounts for internal latencies

Elapsed time since VBERT/VLOOP test was started or cleared (in seconds).

The calculated percent of CIR utilization during a VBERT test, this value is only valid after a test is complete not during.

The calculated percent of EIR utilization during a VBERT test, this value is only valid after a test is complete not during.

This is the method in which the unit is configured for SNMP management access. (1) None: SNMP management disabled (2) SLIP: out-of-band management via asynchronous Serial Line IP (3) Private DLCI: in-band management using a private DLCI that is dedicated solely to this unit's management. (4) Piggyback DLCI: in-band management using any DLCI optionally multiplexing both management and user data. Enumeration: 'none': 1, 'piggyback-dlci': 4, 'private-dlci': 3, 'slip': 2.

This is the port(s) on which the management traffic will appear. (1) Async Maintenance(Comm)/Console port - SLIP mode (2) Local DTE interface: unit is configured for Private Local DLCI mode (3) Remote WAN Interface: unit is confiogured for Private Remote DLCI mode (4) DTE and WAN Interfaces: unit is configured for either Piggyback Bidirectional mode. Enumeration: 'comm': 1, 'dte-and-t1': 4, 'dte': 2, 't1': 3.

This is the status of the port(s) on which the management traffic will appear. (1) Active: port or DLCI is configured and status is okay (2) Inactive: port or DLCI is declared out of service (3) Alarm: port or DLCI is experiencing an alarm condition that may interefere with management access Enumeration: 'active': 1, 'alarm': 3, 'inactive': 2.

This is the DLCI for the PVC that is defined for the Management port. All traffic using this DLCI in the Frame Replay packet will be destined for the InBand Management task.

This is the status of the default management DLCI. (1) not applicable: SLIP mode or management is disabled (2) DLCI Active: default DLCI is active in the LMI full status response. (3) DLCI Inactive: default DLCI is not active in the LMI full status response. Enumeration: 'dlci-active': 2, 'na': 1, 'dlci-inactive': 3.

Status of the DTE Mode LED. (1) DTE Mode LED off: Missing control signals (2) DTE Mode LED green: Normal (3) DTE Mode LED yellow: Test Mode Enumeration: 'redLED-no-active-WAN-connection': 4, 'offLED-DTE-inactive': 1, 'greenLED-normal': 2, 'yellowLED-test-mode': 3.

Status of the DTE Status LED. (1) DTE Status LED off: no connections to WAN (2) DTE Status LED green: normal Enumeration: 'greenLED-active': 2, 'offLED-inactive': 1.

Status of the DTE Tx Data LED. In Frame Relay mode, this LED is ON (green) when the DTE is not sending HDLC Flags and is OFF when HDLC flags are being transmit. In CBO mode, the LED is ON (green) for a SPACE and OFF for a MARK. (1) DTE Transmit LED OFF: inactive (HDLC flags or CBO marks) (2) DTE Transmit LED ON: active (HDLC frames or CBO spaces) Enumeration: 'greenLED-tx-data-transmitting': 2, 'yellowLED-disabled': 3, 'offLED-inactive': 1.

Status of the DTE Rx Data LED. In Frame Relay mode, this LED is ON (green) when the WAN is receiving HDLC Flags and is OFF when HDLC flags are being received. In CBO mode, the LED is ON (green) for a SPACE and OFF for a MARK. (1) DTE Receive LED OFF: inactive (HDLC flags or CBO marks) (2) DTE Receive LED ON: active (HDLC frames or CBO spaces) Enumeration: 'yellowLED-disabled': 3, 'greenLED-rx-data-receiving': 2, 'offLED-inactive': 1.

Status of the WAN Mode LED. (1) WAN Mode LED is green: normal data mode (2) WAN Mode LED is yellow: test mode Enumeration: 'greenLED-normal': 2, 'yellowLED-test-mode': 3.

Status of the WAN Status LED. (1) Off - no signal detected from WAN. (2) Green - framed signal detected with no errors (normal operation) (3) Yellow - remote alarm condition detected (yellow or AIS alarms) (4) Red - unit has declared Red Alarm due to the presence of an improperly framed signal from the WAN. (5) Blinking Red and Off - unit has declared Red Alarm due to the absence of a signal from the WAN. (6) Blinking Green and Red - unit is receiving a properly framed signal from the WAN but has detected a transient error condition. Possible Line Code Violations or ESF CRC errors indicating errored data bits. (7) Blinking Red and Yellow - unit is receiving an unframed all ones (AIS) from the WAN. This is indicative of an upstream alarm condition on the WAN. Enumeration: 'greenLED-normal': 2, 'blinking-red-greenLED-transient-error': 6, 'blinking-red-yellowLED-AIS': 7, 'offLED-T1-no-signal': 1, 'yellowLED-remote-alarm': 3, 'redLED-red-alarm': 4, 'blinking-redLED-no-carrier-red-alarm': 5.

Status of all six MFRAP LEDs, encoded in a string. 'F' off '5' green '0' yellow 'A' red '7' blinking green and off '3' blinking yellow and off 'B' blinking red and off '4' blinking green and yellow '6' blinking green and red '8' blinking yellow and red Positionally, the 8 letters are DTE Mode, DTE status, Dte Tx, Dte Rx, PBX Mode, PBX Status, T1 Mode, and T1 Status. For example, '55555556' would mean: DTE in normal mode, active status, transmitting and receiving PBX in normal mode with normal status and T1 normal with transient errors.

Status of the Drop & Insert Mode LED. (1) Drop & Insert Mode LED is green: normal data mode (2) Drop & Insert Mode LED is yellow: test mode Enumeration: 'greenLED-normal': 2, 'yellowLED-test-mode': 3.

Status of the Drop & Insert Status LED. (1) Off - no signal detected from Drop & Insert port. (2) Green - framed signal detected with no errors (normal operation) (3) Yellow - remote alarm condition detected (yellow or AIS alarms) (4) Red - unit has declared Red Alarm due to the presence of an improperly framed signal from the Drop & Insert port. (5) Blinking Red and Off - unit has declared Red Alarm due to the absence of a signal from the Drop & Insert port. (6) Blinking Green and Red - unit is receiving a properly framed signal from the Drop & Insert port but has detected a transient error condition. Possible Line Code Violations or ESF CRC errors indicating errored data bits. (7) Blinking Red and Yellow - unit is receiving an unframed all ones (AIS) from the Drop & Insert port. This is indicative of an upstream alarm condition on the Drop & Insert port. Enumeration: 'greenLED-normal': 2, 'blinking-red-greenLED-transient-error': 6, 'blinking-red-yellowLED-AIS': 7, 'offLED-Dandi-no-signal': 1, 'yellowLED-remote-alarm': 3, 'redLED-red-alarm': 4, 'blinking-redLED-no-carrier-red-alarm': 5.

Allows the user to clear all the VNIP Transit Delay data collected in the VNIP topology database. (1) Clear entire Transit Delay results database Enumeration: 'clear-transit-delay': 1.

If configured for Frame Relay with a non-zero LMI inactivity timer the unit will monitor the status of LMI and, if proper messaging is not detected, will attempt to emulate either Frame Relay DTE or DCE devices in attempt to restore LMI to any attached equipment and provide managed access for diagnostic purposes. Typically frads/routers are Frame Relay DTE while switches are Frame Relay DCE but this model may vary. In the absence of full-duplex LMI, the unit will cycle through various states in attempt to adapt to an LMI partner. The unit will try each state for the duration of the LMI Inactivity timer and then advance to the next one if satisfactory handshaking is not established. While in any of these states if full-duplex LMI handshaking does appear, the unit will immediately revert to the passthrough state. (1) initializing (2) Passthrough: not sourcing any LMI messages. (3) Status Enquiries out DTE interface: unit is emulating a Frame Relay DTE device out the its (physical) DTE interface. (4) Status Enquiries out WAN interface: unit is emulating a Frame Relay DTE device out the its WAN interface. (5) Status Responses out the DTE interface: unit is emulating a Frame Relay DCE device out the its (physical) DTE interface (provisioning the single default management DLCI). (6) Status Responses out the WAN interface: unit is emulating a Frame Relay DCE device out the its WAN interface (provisioning the single default management DLCI). (7) Disabled - LMI Inactivity timer is zero or unit not configured for a Frame Relay application. (8) Status Responses out both DTE and WAN interfaces: unit is configured for Fixed DCE mode of management and emulates a Frame Relay DCE independently on both ports (provisioning the single default management DLCI). Enumeration: 'network-t1': 6, 'user-dte': 3, 'passthrough': 2, 'disabled': 7, 'initializing': 1, 'both-ports': 8, 'user-t1': 4, 'network-dte': 5.

Status of allocation of T1 bandwidth to the DTE port data. (1) no connections - indicates the DTE port has no connections to the WAN. (2) Active - indicates DTE data rate has been assigned T1 DS0s and is in a normal data mode. (3) Test - indicates DTE data rate has been assigned T1 DS0s but is in a diagnostic condition. Enumeration: 'active': 2, 'test': 3, 'no-connections': 1.

Status of the Request to Send (RTS) signal from the DTE port. (1) RTS Active (2) RTS Inactive Enumeration: 'on': 1, 'off': 2.

Status of the Data Terminal Ready (DTR) signal from the DTE port. (1) DTR Active (2) DTR Inactive Enumeration: 'on': 1, 'off': 2.

Status of the Data Carrier Detect (DCD) signal driven by this unit towards the DTE port (1) DCD Active (2) DCD Inactive Enumeration: 'on': 1, 'off': 2, 'na': 3.

Status of the Data Set Ready (DSR) signal driven by this unit towards the DTE port. (1) DSR Active (2) DSR Inactive Enumeration: 'on': 1, 'off': 2, 'na': 3.

Status of the Clear to Send (CTS) signal driven by this unit towards the DTE port (1) CTS Active (2) CTS Inactive Enumeration: 'on': 1, 'off': 2, 'na': 3.

This indicates the current status of LMI Auto Sensing if it's enabled. (1) Disabled: LMI is configured as Type 1, Annex-D, or Annex-A (2) Searching: unit is attempting to determine the LMI type of the attached equipment by issuing LMI messages of each LMI type and searching for responses. (3) Learned Annex-D: unit has successfully detected Annex-D LMI (ANSI T1.617 Annex D) (4) Learned Annex-A: unit has successfully detected Annex-A LMI (ITU/CCITT Q.933 Annex A) (5) Learned Type 1: unit has successfully detected Type 1 LMI (Cisco, Group of four, LMI) Enumeration: 'disabled': 1, 'learned-annex-a': 4, 'learned-type1': 5, 'learned-annex-d': 3, 'searching': 2.

The status of the chasis fan 1. (1) Fan is operating normally (2) Fan is in alarm state (3) Fan alarm is not applicable Enumeration: 'fan-ok': 1, 'na': 3, 'fan-alarm': 2.

The status of the chasis fan 2. (1) Fan is operating normally (2) Fan is in alarm state (3) Fan alarm is not applicable Enumeration: 'fan-ok': 1, 'na': 3, 'fan-alarm': 2.

The status of the chasis power supply. (1) The nest power supply is operating normally (2) The nest power supply is in alarm state (3) A standalone unit will return 'na' Enumeration: 'power-supply-alarm': 2, 'power-supply-na': 3, 'power-supply-ok': 1.

The chassis slot number (1-16) occupied by the MFRAP nest card. A standalone unit will return a '0'.

Status of allocation of T1 DS0s to the Drop & Insert port DS0s. (1) no connections - indicates the Drop & Insert port has no connections to the WAN. (2) Active - indicates that at least one Drop & Insert DS0 has been assigned to a T1 DS0. (3) Test - indicates that at least one Drop & Insert DS0 has been assigned to a T1 DS0 but is in a diagnostic condition. Enumeration: 'active': 2, 'test': 3, 'no-connections': 1.

Status of the signal received from the Drop & Insert port. (1) In Sync - unit has detected a properly framed T1 signal and is not experiencing any error conditions. (2) In Sync with Errors - unit has detected a properly framed T1 signal but is experiencing some error conditions. Refer to T1 current performance results for details. (3) Signal Detected without Frame Sync - while a signal is present from the Drop & Insert port, it does not contain the framing pattern defined for this unit. This could be either incorrectly configured T1 Frame type or the presence of an alarm condition on the network. (4) No Carrier - there is no signal detected from the WAN. (5) Not Applicable. Enumeration: 'signal-present-without-frame-sync': 3, 't1-frame-sync-okay': 1, 'signal-not-present': 4, 't1-frame-sync-with-errors': 2, 'not-applicable': 5.

Alarms present at the T1 port. (1) No alarm conditions present. (2) Red Alarm Declared - Unit has experienced loss of frame synchronization with the signal received from the Drop & Insert port for an extended time and is reporting an alarm condition that severely impairs normal operation. During this Red Alarm condition the unit will transmit Yellow alarm back to the Drop & Insert port. If this condition persists consult your service provider. (3) Yellow ALarm Detected - Unit is receiving a yellow alarm indication from the Drop & Insert port. Detection of yellow alarm implies that the attached device is in a red alarm conditon. Red alarm is declared due to the extended absence of a properly framed signal. If this condition persists consult your service provider. (4) Unframe All Ones Detected - Unit is receiving unframed all ones from the Drop & Insert port (AIS, blue alarm). Detection of AIS implies that the attached device is reporting an alarm condition from an upstream device. If this condition persists consult your service provider. Enumeration: 'no-alarms': 1, 'red-alarm-declared': 2, 'yellow-alarm-detected': 3, 'unframed-all-ones-detected': 4.

The T1 physical layer performance numbers for the current 15 minute interval. These are defined and accumulated per ANSI specification T1.403 and AT&T publication 54016. Depending upon the configured T1 Framing mode, these results may be retrieved via ESF facility data link by service personnel.

An entry in the T1 Current Perf table.

The index value which uniquely identifies the T1 interface to which this entry is applicable. The Drop & Index port has its own Current Performance Table, so the index will always be 1.

Count of CRC errors detected on an ESF framed circuit. In ESF framing a CRC is generated at the source, based upon the composite data. A CRC error indicates the presence of at least one bit error in an ESF superframe. This field is a free-running accumulation of CRC errors and IS NOT reset when the current 15 minute interval expires. It can be reset with the performance command mfrapT1PerfClearEvents. Not applicable if D4/SF framing is selcted.

Count of Out-of-Frame events on a T1 circuit. An out-of- frame event occurs when the frame synchronization criteria is lost and a resynchronization must occur. Data is interrupted during frame resynchronization. This field is a free-running accumulation of OOF transitions and IS NOT reset when the current 15 minute interval expires. It can be reset with the performance command mfrapT1PerfClearEvents.

The number of Errored Seconds, encountered by a T1 interface in the current 15 minute inter- val. An errored second is a one-second interval with CRC errors or a loss of frame sync occurred.

The number of Severely Errored Seconds encountered by a t1 interface in the current 15 minute interval. A severely errored second is a one second interval with more than 320 CRC errors or one or more frame sync losses.

The number of Severely Errored Framing Seconds encountered by a t1 interface in the current 15 minute interval. A SEFS is a one second interval with one or more frame sync losses.

The number of Unavailable Seconds encountered by a t1 interface in the current 15 minute in- terval. A UAS is a one second interval during which the received signal is classified as 'unavailable due to excessive errors'. A signal is unavailable after receiving ten consective severely errored seconds and stays unavailable until ten seconds without a severely errored second occur.

The number of Controlled Slip Seconds encoun- tered by a t1 interface in the current 15 minute interval. A controlled slip is the replication or deletion of a T1 frame at the receiver. These events often indicate a T1 network timing problem.

The number of Bursty Errored Seconds (BESs) encountered by a DS1 interface in the current 15 minute interval. A BES is a one second interval with more than one and less than 320 CRC errors.

The number of Line Code Violations (LCVs) en- countered by a DS1 interface in the current 15 minute interval. LCVs are non-B8ZS related violations of the alternate mark inversion protocol. An excessive count usually indicates a B8ZS/AMI configuration mismatch in the T1 network.

The DS1 Interval table. A history of physical layer performance results are maintained and represented as 96 15-minute intervals. These are defined and accumulated per ANSI specification T1.403 and AT&T publication 54016. Depending upon the configured T1 Framing mode, these results may be retrieved via ESF facility data link by service personnel

An entry in the DS1 Interval table.

The index value which uniquely identifies the t1 interface to which this entry is applicable. Since there is a separate Drop & Insert Performance Intervals Table, the value of this index will always be 1, referring to the WAN port.

A number between 1 and 96, where 96 is the most recently completed 15 minute interval and 1 is the least recently completed 15 minutes inter- val which occured 24 hours ago (assuming that all 96 intervals are valid).

The number of Errored Seconds encountered by a t1 interface in one of the previous 96, indi- vidual 15 minute, intervals. An errored second is a one-second interval with CRC errors or a loss of frame sync occurred.

The number of Severely Errored Seconds encoun- tered by a t1 interface in one of the previous 96, individual 15 minute, intervals. A severely errored second is a one second interval with more than 320 CRC errors or one or more frame sync losses.

The number of Severely Errored Framing Seconds encountered by a t1 interface in one of the previous 96, individual 15 minute, intervals. A SEFS is a one second interval with one or more frame sync losses.

The number of Unavailable Seconds encountered by a t1 interface in one of the previous 96, individual 15 minute, intervals. A UAS is a one second interval during which the received signal is classified as 'unavailable due to excessive errors'. A signal is unavailable after receiving ten consective severely errored seconds and stays unavailable until ten seconds without a severely errored second occur.

The number of Controlled Slip Seconds encoun- tered by a t1 interface in one of the previous 96, individual 15 minute, intervals. A controlled slip is the replication or deletion of a T1 frame at the receiver. These events often indicate a T1 network timing problem.

The number of Bursty Errored Seconds (BESs) encountered by a t1 interface in one of the previous 96, individual 15 minute, intervals. A BES is a one second interval with more than one and less than 320 CRC errors.

The number of Line Code Violations (LCVs) en- countered by a DS1 interface in the current 15 minute interval. LCVs are non-B8ZS related violations of the alternate mark inversion protocol. An excessive count usually indicates a B8ZS/AMI configuration mismatch in the T1 network.

The T1 Total table cumulative physical layer performance results from the past 24 hours. These are defined and accumulated per ANSI specification T1.403 and AT&T publication 54016. Depending upon the configured T1 Framing mode, these results may be retrieved via ESF facility data link by service personnel.

An entry in the T1 Physical Layer Measurement Totals table.

The index value which uniquely identifies the t1 interface to which this entry is applica- ble. Since there is a separate Drop & Insert Performance 24 Hour Table, the value of this index will always be 1, referring to the WAN port.

The number of Errored Seconds encountered by a t1 interface in the previous 24 hour interval. An errored second is a one-second interval with CRC errors or a loss of frame sync occurred.

The number of Severely Errored Seconds encoun- tered by a t1 interface in the previous 24 hour interval. A severely errored second is a one second interval with more than 320 CRC errors or one or more frame sync losses.

The number of Severely Errored Framing Seconds 24 hour interval. A SEFS is a one second interval with one or more frame sync losses.

The number of Unavailable Seconds encountered by a t1 interface in the previous 24 hour in- terval. A UAS is a one second interval during which the received signal is classified as 'unavailable due to excessive errors'. A signal is unavailable after receiving ten consective severely errored seconds and stays unavailable until ten seconds without a severely errored second occur.

The number of Controlled Slip Seconds encoun- tered by a t1 interface in the previous 24 hour interval. A controlled slip is the replication or deletion of a T1 frame at the receiver. These events often indicate a T1 network timing problem.

The number of Bursty Errored Seconds (BESs) encountered by a t1 interface in the previous 24 hour interval. A BES is a one second interval with more than one and less than 320 CRC errors.

The number of Line Code Violations (LCVs) en- countered by a t1 interface in the current 15 minute interval. LCVs are non-B8ZS related violations of the alternate mark inversion protocol. An excessive count usually indicates a B8ZS/AMI configuration mismatch in the T1 network.

This command halts the node's performance monitoring and freezes the current, interval, and total performance register values. Enumeration: 'unfreeze-reg': 2, 'freeze-reg': 1.

This command resets all of the (user's) error event registers. This includes the CRC6 and Out-of-Frame counts. It does not affect the interval or 24 hour performance totals. Enumeration: 'clear-events': 1.

This command resets all of the (user's) performance registers. Enumeration: 'clear-all': 1.

The T1 physical layer performance numbers for the current 15 minute interval. These are defined and accumulated per ANSI specification T1.403 and AT&T publication 54016. Depending upon the configured T1 Framing mode, these results may be retrieved via ESF facility data link by service personnel.

An entry in the D&I Current Perf table.

The index value which uniquely identifies the D&I interface to which this entry is applica- ble. Enumeration: 'dandi-port1': 2.

Count of CRC errors detected on an ESF framed circuit. In ESF framing a CRC is generated at the source, based upon the composite data. A CRC error indicates the presence of at least one bit error in an ESF superframe. This field is a free-running accumulation of CRC errors and IS NOT reset when the current 15 minute interval expires. It can be reset with the performance command mfrapDandiPerfClearEvents. Not applicable if D4/SF framing is selcted.

Count of Out-of-Frame events on a D&I circuit. An out-of- frame event occurs when the frame synchronization criteria is lost and a resynchronization must occur. Data is interrupted during frame resynchronization. This field is a free-running accumulation of OOF transitions and IS NOT reset when the current 15 minute interval expires. It can be reset with the performance command mfrapDandiPerfClearEvents.

The number of Errored Seconds, encountered by a D&I interface in the current 15 minute inter- val. An errored second is a one-second interval with CRC errors or a loss of frame sync occurred.

The number of Severely Errored Seconds encountered by a D&I interface in the current 15 minute interval. A severely errored second is a one second interval with more than 320 CRC errors or one or more frame sync losses.

The number of Severely Errored Framing Seconds encountered by a D&I interface in the current 15 minute interval. A SEFS is a one second interval with one or more frame sync losses.

The number of Unavailable Seconds encountered by a D&I interface in the current 15 minute in- terval. A UAS is a one second interval during which the received signal is classified as 'unavailable due to excessive errors'. A signal is unavailable after receiving ten consective severely errored seconds and stays unavailable until ten seconds without a severely errored second occur.

The number of Controlled Slip Seconds encoun- tered by a D&I interface in the current 15 minute interval. A controlled slip is the replication or deletion of a D&I frame at the receiver. These events often indicate a D&I network timing problem.

The number of Bursty Errored Seconds (BESs) encountered by a DS1 interface in the current 15 minute interval. A BES is a one second interval with more than one and less than 320 CRC errors.

The number of Line Code Violations (LCVs) en- countered by a DS1 interface in the current 15 minute interval. LCVs are non-B8ZS related violations of the alternate mark inversion protocol. An excessive count usually indicates a B8ZS/AMI configuration mismatch in the D&I network.

The DS1 Interval table. A history of physical layer performance results are maintained and represented as 96 15-minute intervals. These are defined and accumulated per ANSI specification T1.403 and AT&T publication 54016. Depending upon the configured T1 Framing mode, these results may be retrieved via ESF facility data link by service personnel

An entry in the DS1 Interval table.

The index value which uniquely identifies the D&I interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value as a NetwLineIndex object instance. Enumeration: 'dandi-port1': 2.

A number between 1 and 96, where 1 is the most recently completed 15 minute interval and 96 is the least recently completed 15 minutes inter- val (assuming that all 96 intervals are valid).

The number of Errored Seconds encountered by a D&I interface in one of the previous 96, indi- vidual 15 minute, intervals. An errored second is a one-second interval with CRC errors or a loss of frame sync occurred.

The number of Severely Errored Seconds encoun- tered by a D&I interface in one of the previous 96, individual 15 minute, intervals. A severely errored second is a one second interval with more than 320 CRC errors or one or more frame sync losses.

The number of Severely Errored Framing Seconds encountered by a D&I interface in one of the previous 96, individual 15 minute, intervals. A SEFS is a one second interval with one or more frame sync losses.

The number of Unavailable Seconds encountered by a D&I interface in one of the previous 96, individual 15 minute, intervals. A UAS is a one second interval during which the received signal is classified as 'unavailable due to excessive errors'. A signal is unavailable after receiving ten consective severely errored seconds and stays unavailable until ten seconds without a severely errored second occur.

The number of Controlled Slip Seconds encoun- tered by a D&I interface in one of the previous 96, individual 15 minute, intervals. A controlled slip is the replication or deletion of a D&I frame at the receiver. These events often indicate a D&I network timing problem.

The number of Bursty Errored Seconds (BESs) encountered by a D&I interface in one of the previous 96, individual 15 minute, intervals. A BES is a one second interval with more than one and less than 320 CRC errors.

The number of Line Code Violations (LCVs) en- countered by a DS1 interface in the current 15 minute interval. LCVs are non-B8ZS related violations of the alternate mark inversion protocol. An excessive count usually indicates a B8ZS/AMI configuration mismatch in the D&I network.

The T1 Total table cumulative physical layer performance results from the past 24 hours. These are defined and accumulated per ANSI specification T1.403 and AT&T publication 54016. Depending upon the configured T1 Framing mode, these results may be retrieved via ESF facility data link by service personnel.

An entry in the D&I Total table.

The index value which uniquely identifies the D&I interface to which this entry is applica- ble. The interface identified by a particular value of this index is the same interface as identified by the same value as a NetwLineIndex object instance. Enumeration: 'dandi-port1': 2.

The number of Errored Seconds encountered by a D&I interface in the previous 24 hour interval. An errored second is a one-second interval with CRC errors or a loss of frame sync occurred.

The number of Severely Errored Seconds encoun- tered by a D&I interface in the previous 24 hour interval. A severely errored second is a one second interval with more than 320 CRC errors or one or more frame sync losses.

The number of Severely Errored Framing Seconds 24 hour interval. A SEFS is a one second interval with one or more frame sync losses.

The number of Unavailable Seconds encountered by a D&I interface in the previous 24 hour in- terval. A UAS is a one second interval during which the received signal is classified as 'unavailable due to excessive errors'. A signal is unavailable after receiving ten consective severely errored seconds and stays unavailable until ten seconds without a severely errored second occur.

The number of Controlled Slip Seconds encoun- tered by a D&I interface in the previous 24 hour interval. A controlled slip is the replication or deletion of a D&I frame at the receiver. These events often indicate a D&I network timing problem.

The number of Bursty Errored Seconds (BESs) encountered by a D&I interface in the previous 24 hour interval. A BES is a one second interval with more than one and less than 320 CRC errors.

The number of Line Code Violations (LCVs) en- countered by a D&I interface in the current 15 minute interval. LCVs are non-B8ZS related violations of the alternate mark inversion protocol. An excessive count usually indicates a B8ZS/AMI configuration mismatch in the D&I network.

This command halts the node's performance monitoring and freezes the current, interval, and total performance register values. Enumeration: 'unfreeze-reg': 2, 'freeze-reg': 1.

This command resets all of the (user's) error event registers. This includes the CRC6 and Out-of-Frame counts. It does not affect the interval or 24 hour performance totals. Enumeration: 'clear-events': 1.

This command resets all of the (user's) performance registers. Enumeration: 'clear-all': 1.

The count of all octets associated with received frames that are specifically addressed as management packets for this unit. Same as ifInOctets in mib-2.

The count of packets associated with received frames that are specifically addressed as management packets for this unit which could not be handled because of errors. Same as ifInErrors in mib-2.

The count of all octets associated with generated frames that are specifically addressed as management packets from this unit. Same as ifOutOctets in mib-2. Same as ifOutOctets in mib-2.

The current operational state of the management interface. Same as ifOperStatus in mib-2. (1) Interface Up (2) Interface Down (3) Interface in Test Enumeration: 'down': 2, 'testing': 3, 'up': 1.

The count of all ip datagrams received which are specifically addressed as management frames for this unit. Same as ipInReceives in mib-2.

The count of ip datagrams received which are specifically addressed as management frames for this unit that were discarded because of errors in their IP headers. Same as ipInHdrErrors in mib-2.

The count of ip datagrams received which are specifically addressed as management frames for this unit that were discarded because unexpected or invalid IP addresses in their IP headers. Same as ipInAddrErrors in mib-2.

The count of ip datagrams received which are specifically addressed as management frames for this unit that were discarded because of unsupported protocols. Same as ipInUnknownProtos in mib-2.

The count of datagrams received which are specifically addressed as management frames for this unit that were discarded for reasons other than a problem with the datagram. Same as ipInDiscards in mib-2.

The count ofip datagrams received which are specifically addressed as management frames for this unit that were delivered to IP client protocols. Same as ipInDelivers in mib-2.

The count of all outgoing datagrams generated by this unit which are specifically addressed as management frames. Same as ipOutRequests in mib-2.

The count of outgoing datagrams generated by this unit which are specifically addressed as management frames that were discarded for reasons other than a problem with the datagram. Same as ipOutDiscards in mib-2.

The count of outgoing datagrams generated by this unit which are specifically addressed as management frames that were discarded because no route could be found for transmission. Same as ipOutNoRoutes in mib-2.

The count of all ICMP messages received which are addressed to this unit. Same as icmpInMsgs in mib-2.

The count of ICMP messages received which are addressed to this unit but contain errors. Same as icmpInErrors in mib-2.

The count of ICMP Destination Unreachable messages received which are addressed to this unit. Same as icmpInDestUnreachs in mib-2.

The count of ICMP Time Exceeded messages received which are addressed to this unit. Same as icmpInTimeExcds in mib-2.

The count of ICMP Parameter Problem messages received which are addressed to this unit. Same as icmpInParmProbs in mib-2.

The count of ICMP Redirect messages received which are addressed to this unit. Same as icmpInRedirects in mib-2.

The count of ICMP Echo messages received which are addressed to this unit. Same as icmpInEchos in mib-2.

The count of ICMP Echo Reply messages received which are addressed to this unit. Same as icmpInEchoReps in mib-2.

The count of all outgoing ICMP messages originating from this node. Same as icmpOutMsgs in mib-2.

The count of outgoing ICMP messages generated by this unit which are not transmitted due problems found by the ICMP layer. Same as icmpOutErrors in mib-2.

The count of outgoing ICMP Destination Unreachable messages generated by this unit. Same as icmpOutDestUnreachs in mib-2.

The count of outgoing ICMP Parameter Problem messages generated by this unit. Same as icmpOutParmProbs in mib-2.

The count of outgoing ICMP Redirect messages generated by this unit. Same as icmpOutRedirects in mib-2.

The count of outgoing ICMP Echo messages generated by this unit. Same as icmpOutEchos in mib-2.

The count of outgoing ICMP Echo Reply messages generated by this unit. Same as icmpOutEchoReps in mib-2.

The count of all UDP datagrams received that are addressed as management frames for this unit. Same as udpInDatagrams in mib-2.

The count of all UDP datagrams generated by this unit. Same as udpOutDatagrams in mib-2.

The count of all UDP datagrams received that are addressed as management frames for this unit with no application at the destination port. Same as udpNoPorts in mib-2.

The count of the times TCP connections specific to this unit have made a direct state transition from CLOSED to SYN-SENT. Same as tcpActiveOpens in mib-2.

The count of the times TCP connections specific to this unit have made a direct state transition from CLOSED to SYN-RCVD. Same as tcpPassiveOpens in mib-2.

The count of the times TCP connections specific to this unit have made a direct state transition from SYN-SENT or SYN-RCVD to CLOSED state, plus the count of the times TCP connections have made a direct state transition from SYN-RCVD to LISTEN. Same as tcpAttemptFails in mib-2.

The count of the TCP connections specific to this unit in state ESTABLISHED or CLOSE-WAIT. Same as tcpCurrEstab in mib-2.

The count of all the segments received that are addressed as management frames for this unit. Same as tcpInSegs in mib-2.

The count of all the segments generated from this unit. Same as tcpOutSegs in mib-2.

The throughput per interface table. These values are accumulated across all DLCIs.

An entry in the throughput per interface table.

Interface for which the statistics apply. (1) DTE interface (2) T1 interface Enumeration: 'dte': 1, 't1': 2.

The number of bytes that have been counted on this interface.

The number of bytes that have been counted on this interface.

The number of frames that have been counted on this interface.

The number of frames that have been counted on this interface.

The number of frames with CRC errors received on this interface.

The number of aborted frames received on this interface.

Layer 2 statistics on a per-DLCI basis. Transmit direction is from DTE to WAN and receive direction is from the WAN towards the DTE.

The Statistics for a particular Data Link Connection Management Interface (DLCI).

This value must be in the range 1-3. Other than that, this value is ignored as all three will return the same result.

The DLCI value in which the Statistics are associated.

The amount of time elapsed since this DLCI was first detected through traffic sensing or in an LMI message (in seconds).

The amount of elapsed time since this DLCI last changed state from active to inactive or vice versa (in seconds).

The number of bytes that have been received from the WAN towards the DTE on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number of bytes that have been transmit from the DTE towards the WAN on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number of frames that have been received from the WAN towards to the DTE on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number of frames that have been transmit from the DTE towards the WAN on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number frames received from the WAN towards the DTE that have had the Forward Explict Congestion Notification (FECN) bit set on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number frames received from the WAN towards the DTE that have had the Backward Explict Congestion Notification (BECN) bit set on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number frames received from the WAN towards the DTE that have had the Discard Eligibility (DE) bit set on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number frames transmit towards the WAN from the DTE that have had the Discard Eligibility (DE) bit set on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number of bits/sec received from the WAN on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The number of bits/sec transmit to the WAN on this DLCI. This count will include any frames that are terminated by the unit and do not pass through to the opposite interface (management and networking data).

The Committed Information Rate (CIR) for this DLCI. This can come form one of three sources: From the LMI Full Status Response, configured by the user, or the DTE line rate (default).

The total amount of time that the DLCI has been up as reproted by the LMI Full Status Response (in seconds).

The total amount of time that the DLCI has been declared down (in seconds). A DLCI is Down if it's explicitly declared Inactive through LMI or if it's missing from the LMI Full Status message or if there is no Full Status message at all.

The source of the CIR value for this DLCI. (1) CIR acquired from LMI message. Will override user configured CIR. This feature is not supported by all Frame Relay DCE (switches). (2) CIR configured by user. (3) CIR is DTE Line Rate. Default if CIR is not set by one of the other methods. Enumeration: 'cir-is-dte-datarate': 3, 'cir-configured-by-user': 2, 'cir-acquired-from-lmi': 1.

The current state of the DLCI: (1) DLCI marked active in last full status LMI (2) DLCI in last full status LMI but not marked active (3) DLCI has never been seen in a full status LMI (4) DLCI was seen at least once in a full status LMI but was not in the last full status LMI (5) the full status LMI has timed out; all previously active or inactive DLCIs are changed to this state (6) DLCI was detected in the traffic stream and a full status LMI has not been received so the state cannot be determined yet. Enumeration: 'pvc-lmi-timeout': 5, 'pvc-undetermined': 6, 'pvc-active': 1, 'pvc-not-in-lmi': 4, 'pvc-inactive': 2, 'pvc-unprovisioned': 3.

The number of times the smperPerfThruputPerDlciPvcState transitions from pvc-active or pvc-undetermined to one of the other (inactive) states.

The measure of the percentage time the DLCI is available: UpTime/CreateTime or zero if CreateTime = 0. (in 1/1000 per cent; i.e. availability = 1000 converts to 1%).

Mean Time Between Service Outages: UpTime/OutageCount or zero if OutageCount = 0 (in seconds).

Mean Time to ServiceRestoral: DownTime/OutageCount or zero if OutageCount = 0 (in seconds).

The encapsulation protocol seen in the last frame analyzed on this DLCI: (1) DLCI is the LMI DLCI or no frames have been analyzed (2) The encapsulation is per rfc1490 (3) The encapsulation is per Cisco proprietary (4) The encapsulation is per Annex-G (X.25 over frame relay) (5) The encapsulation is not one of the above. Enumeration: 'encap-other': 5, 'encap-1490': 2, 'encap-annex-g': 4, 'encap-cisco': 3, 'encap-na': 1.

The status of the per-DLCI utilization alarm in the receive direction. (1) there is no alarm condition; utilization is under the configured CIR percentage threshold; if traps are enabled and the alarm had been previously triggered, a utilization alarm clear trap will be sent. (2) the utilization has been over the configured CIR percentage threshold for less than the configured duration. (3) the utilization has been over the configured CIR percentage threshold for more than the configured duration; if traps are enabled a utilization exceeded trap will be sent. (4) the utilization has been under the configured CIR percentage threshold for less than the configured duration. Enumeration: 'alarm-under-threshold': 4, 'clear': 1, 'alarm': 3, 'over-threshold': 2.

The status of the per-DLCI utilization alarm in the transmit direction. (1) there is no alarm condition; utilization is under the configured CIR percentage threshold; if traps are enabled and the alarm had been previously triggered, a utilization alarm clear trap will be sent. (2) the utilization has been over the configured CIR percentage threshold for less than the configured duration. (3) the utilization has been over the configured CIR percentage threshold for more than the configured duration; if traps are enabled a utilization exceeded trap will be sent. (4) the utilization has been under the configured CIR percentage threshold for less than the configured duration. Enumeration: 'alarm-under-threshold': 4, 'clear': 1, 'alarm': 3, 'over-threshold': 2.

The Excess Information Rate. This is defined to be the maximum rate traffic is (supposed to be) allowed to burst to.

Allows the user to zero out all the interface statistics in the DTE portion of the ThruputPerIntf statistics table. (1) Clear DTE interface statistics command. Enumeration: 'clear-statistics': 1.

Allows the user to zero out all the interface statistics in the WAN portion of the ThruputPerIntf statistics table. (1) Clear WAN interface statistics command. Enumeration: 'clear-statistics': 1.

Allows the user to zero out all the statistics in the ThruputPerIntf statistics table. (1) Clear all interface statistics command. Enumeration: 'clear-statistics': 1.

Allows the user to zero out all the per-DLCI statistics in the ThruputPerDlci statistics table and the the short term statistics tables. (1) Clear layer 2 per-DLCI statistics command. Enumeration: 'clear-statistics': 1.

Allows the user to zero out all the statistics in the ThruputPerIntf and ThruputPerDlci statistics tables and in the short term statistics tables. (1) Clear all interface and layer 2 per-DLCI statistics. Enumeration: 'clear-statistics': 1.

Allows the user to remove a Dlci from the short term statistics tables.

Allows the user to replace one DLCI in the short-term statistics table with another one.

Allows the user to replace one DLCI in the short-term statistics table with another one.

A Dlci that is in the short-term stats table. Index by this Dlci value to identify the statistics entry to be replaced.

A Dlci that is to replace another in the short-term stats table. Index by this Dlci value to identify the statistics entry to do the replacing.

Allows the user to reset the availability statistics of an individual Dlci within the short-term stats table.

Allows the user to reset the availability statistics of all Dlci's within the short-term stats table.

Allows the user to reset the count statistics of an individual Dlci within the short-term stats table.

Allows the user to reset the count statistics of all Dlci's within the short-term stats table.

Allows the user to reset both the count and availability statistics of an individual Dlci within the short-term stats table.

Allows the user to reset both the count and the availability statistics of all Dlci's within the short-term stats table.

The Short Term Statistics on the Network Layer protocol for each DLCI. These are protocol-based per-DLCI statistics. The Short Term model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval).

The Network Layer Short Term Statistics for a particular DLCI. This table organizes statistics by high-layer network protocol.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value with which the Statistics are associated.

The total number of received Network Layer bytes that have been counted on this DLCI.

The total number of transmitted Network Layer bytes that have been counted on this DLCI.

The number of received IP bytes that have been counted on this DLCI.

The number of transmitted IP bytes that have been counted on this DLCI.

The number of received IPX bytes that have been counted on this DLCI.

The number of transmitted IPX bytes that have been counted on this DLCI.

The number of received SNA bytes that have been counted on this DLCI.

The number of transmitted SNA bytes that have been counted on this DLCI.

The number of received ARP bytes that have been counted on this DLCI.

The number of transmitted ARP bytes that have been counted on this DLCI.

The number of received Cisco protocol bytes that have been counted on this DLCI.

The number of transmitted Cisco protocol bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols that are not counted elsewhere in this table.

The number of received VNIP protocol bytes that have been counted on this DLCI.

The number of transmitted VNIP protocol bytes that have been counted on this DLCI.

The number of received Annex G protocol bytes that have been counted on this DLCI.

The number of transmitted Annex G protocol bytes that have been counted on this DLCI.

The Short Term Statistics on Network Layer protocols summed across all DLCIs.

The Network Layer Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The total number of received Network Layer bytes that have been counted on this DLCI.

The total number of transmitted Network Layer bytes that have been counted on this DLCI.

The number of received IP bytes that have been counted on this DLCI.

The number of transmitted IP bytes that have been counted on this DLCI.

The number of received IPX bytes that have been counted on this DLCI.

The number of transmitted IPX bytes that have been counted on this DLCI.

The number of received SNA bytes that have been counted on this DLCI.

The number of transmitted SNA bytes that have been counted on this DLCI.

The number of received ARP bytes that have been counted on this DLCI.

The number of transmitted ARP bytes that have been counted on this DLCI.

The number of received Cisco protocol bytes that have been counted on this DLCI.

The number of transmitted Cisco protocol bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols that are not counted elsewhere in this table.

The number of received VNIP protocol bytes that have been counted on this DLCI.

The number of transmitted VNIP protocol bytes that have been counted on this DLCI.

The number of received Annex G protocol bytes that have been counted on this DLCI.

The number of transmitted Annex G protocol bytes that have been counted on this DLCI.

The Short Term Statistics on the IP protocol for each DLCI.

The IP Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value with which the Statistics are associated.

The total number of received IP bytes that have been counted on this DLCI.

The total number of transmitted IP bytes that have been counted on this DLCI.

The number of received TCP over IP bytes that have been counted on this DLCI.

The number of transmitted TCP over IP bytes that have been counted on this DLCI.

The number of received UDP over IP bytes that have been counted on this DLCI.

The number of transmitted UDP over IP bytes that have been counted on this DLCI.

The number of received ICMP over IP bytes that have been counted on this DLCI.

The number of transmitted ICMP over IP bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols over IP that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols over IP that are not counted elsewhere in this table.

The number of received IGRP over IP bytes that have been counted on this DLCI.

The number of transmitted IGRP over IP bytes that have been counted on this DLCI.

The Short Term Statistics on the IP protocol for each DLCI.

The IP Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The total number of received IP bytes that have been counted on this DLCI.

The total number of transmitted IP bytes that have been counted on this DLCI.

The number of received TCP over IP bytes that have been counted on this DLCI.

The number of transmitted TCP over IP bytes that have been counted on this DLCI.

The number of received UDP over IP bytes that have been counted on this DLCI.

The number of transmitted UDP over IP bytes that have been counted on this DLCI.

The number of received ICMP over IP bytes that have been counted on this DLCI.

The number of transmitted ICMP over IP bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols over IP that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols over IP that are not counted elsewhere in this table.

The number of received IGRP over IP bytes that have been counted on this DLCI.

The number of transmitted IGRP over IP bytes that have been counted on this DLCI.

Short Term Statistics on the ICMP protocol for each DLCI.

The ICMP Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value in which the Statistics are associated.

The total number of ICMP bytes that have been counted on this DLCI.

The total number of ICMP bytes that have been counted on this DLCI.

The number of bytes in ICMP ECHO repies that have been counted on this DLCI.

The number of bytes in ICMP ECHO repies that have been counted on this DLCI.

The number of bytes in ICMP destination unreachables that have been counted on this DLCI.

The number of bytes in ICMP destination unreachables that have been counted on this DLCI.

The number of bytes in ICMP source quenches that have been counted on this DLCI.

The number of bytes in ICMP source quenches that have been counted on this DLCI.

The number of bytes in ICMP redirects that have been counted on this DLCI.

The number of bytes in ICMP redirects that have been counted on this DLCI.

The number of bytes in ICMP ECHO requests that have been counted on this DLCI.

The number of bytes in ICMP ECHO requests that have been counted on this DLCI.

The number of bytes in ICMP time exceededs that have been counted on this DLCI.

The number of bytes in ICMP time exceededs that have been counted on this DLCI.

The number of bytes in ICMP parameter problems that have been counted on this DLCI.

The number of bytes in ICMP parameter problems that have been counted on this DLCI.

The number of bytes in ICMP timestamp requests that have been counted on this DLCI.

The number of bytes in ICMP timestamp requests that have been counted on this DLCI.

The number of bytes in ICMP timestamp replies that have been counted on this DLCI.

The number of bytes in ICMP timestamp replies that have been counted on this DLCI.

The number of bytes in ICMP address mask requests that have been counted on this DLCI.

The number of bytes in ICMP address mask requests that have been counted on this DLCI.

The number of bytes in ICMP address mask replies that have been counted on this DLCI.

The number of bytes in ICMP address mask replies that have been counted on this DLCI.

The number of bytes in ICMP packet too bigs that have been counted on this DLCI.

The number of bytes in ICMP packet too bigs that have been counted on this DLCI.

The number of bytes in ICMP group membership queries that have been counted on this DLCI.

The number of bytes in ICMP group membership queries that have been counted on this DLCI.

The number of bytes in ICMP group membership reports that have been counted on this DLCI.

The number of bytes in ICMP group membership reports that have been counted on this DLCI.

The number of bytes in ICMP group membership reductions that have been counted on this DLCI.

The number of bytes in ICMP group membership reductions that have been counted on this DLCI.

Short Term Statistics on the ICMP protocol for each DLCI.

The ICMP Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The total number of ICMP bytes that have been counted on this DLCI.

The total number of ICMP bytes that have been counted on this DLCI.

The number of bytes in ICMP ECHO repies that have been counted on this DLCI.

The number of bytes in ICMP ECHO repies that have been counted on this DLCI.

The number of bytes in ICMP destination unreachables that have been counted on this DLCI.

The number of bytes in ICMP destination unreachables that have been counted on this DLCI.

The number of bytes in ICMP source quenches that have been counted on this DLCI.

The number of bytes in ICMP source quenches that have been counted on this DLCI.

The number of bytes in ICMP redirects that have been counted on this DLCI.

The number of bytes in ICMP redirects that have been counted on this DLCI.

The number of bytes in ICMP ECHO requests that have been counted on this DLCI.

The number of bytes in ICMP ECHO requests that have been counted on this DLCI.

The number of bytes in ICMP time exceededs that have been counted on this DLCI.

The number of bytes in ICMP time exceededs that have been counted on this DLCI.

The number of bytes in ICMP parameter problems that have been counted on this DLCI.

The number of bytes in ICMP parameter problems that have been counted on this DLCI.

The number of bytes in ICMP timestamp requests that have been counted on this DLCI.

The number of bytes in ICMP timestamp requests that have been counted on this DLCI.

The number of bytes in ICMP timestamp replies that have been counted on this DLCI.

The number of bytes in ICMP timestamp replies that have been counted on this DLCI.

The number of bytes in ICMP address mask requests that have been counted on this DLCI.

The number of bytes in ICMP address mask requests that have been counted on this DLCI.

The number of bytes in ICMP address mask replies that have been counted on this DLCI.

The number of bytes in ICMP address mask replies that have been counted on this DLCI.

The number of bytes in ICMP packet too bigs that have been counted on this DLCI.

The number of bytes in ICMP packet too bigs that have been counted on this DLCI.

The number of bytes in ICMP group membership queries that have been counted on this DLCI.

The number of bytes in ICMP group membership queries that have been counted on this DLCI.

The number of bytes in ICMP group membership reports that have been counted on this DLCI.

The number of bytes in ICMP group membership reports that have been counted on this DLCI.

The number of bytes in ICMP group membership reductions that have been counted on this DLCI.

The number of bytes in ICMP group membership reductions that have been counted on this DLCI.

The Short Term Statistics on the Application protocol for each DLCI.

The Application Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value with which the Statistics are associated.

The number of received SNMP bytes that have been counted on this DLCI.

The number of transmitted SNMP bytes that have been counted on this DLCI.

The number of received SNMP TRAP bytes that have been counted on this DLCI.

The number of transmitted SNMP TRAP bytes that have been counted on this DLCI.

The number of received HTTP bytes that have been counted on this DLCI.

The number of transmitted HTTP bytes that have been counted on this DLCI.

The number of received Telnet bytes that have been counted on this DLCI.

The number of transmitted Telnet bytes that have been counted on this DLCI.

The number of received SMTP bytes that have been counted on this DLCI.

The number of transmitted SMTP bytes that have been counted on this DLCI.

The number of received FTP bytes that have been counted on this DLCI.

The number of transmitted FTP bytes that have been counted on this DLCI.

The number of received TFTP bytes that have been counted on this DLCI.

The number of transmitted TFTP bytes that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #1 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #1 that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #2 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #2 that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #3 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #3 that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #4 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #4 that have been counted on this DLCI.

The Short Term Statistics on the Application protocol for each DLCI.

The Application Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The number of received SNMP bytes that have been counted on this DLCI.

The number of transmitted SNMP bytes that have been counted on this DLCI.

The number of received SNMP TRAP bytes that have been counted on this DLCI.

The number of transmitted SNMP TRAP bytes that have been counted on this DLCI.

The number of received HTTP bytes that have been counted on this DLCI.

The number of transmitted HTTP bytes that have been counted on this DLCI.

The number of received Telnet bytes that have been counted on this DLCI.

The number of transmitted Telnet bytes that have been counted on this DLCI.

The number of received SMTP bytes that have been counted on this DLCI.

The number of transmitted SMTP bytes that have been counted on this DLCI.

The number of received FTP bytes that have been counted on this DLCI.

The number of transmitted FTP bytes that have been counted on this DLCI.

The number of received TFTP bytes that have been counted on this DLCI.

The number of transmitted TFTP bytes that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #1 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #1 that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #2 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #2 that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #3 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #3 that have been counted on this DLCI.

The number of received bytes of User Defined Protocol #4 that have been counted on this DLCI.

The number of transmitted bytes of User Defined Protocol #4 that have been counted on this DLCI.

The Short Term Statistics on the Routing protocol for each DLCI.

The Routing Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value with which the Statistics are associated.

The number of received OSPF bytes that have been counted on this DLCI.

The number of transmitted OSPF bytes that have been counted on this DLCI.

The number of received RIP bytes that have been counted on this DLCI.

The number of transmitted RIP bytes that have been counted on this DLCI.

The number of received Netbios bytes that have been counted on this DLCI.

The number of transmitted Netbios bytes that have been counted on this DLCI.

The Short Term Statistics on the Routing protocol for each DLCI.

The Routing Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The number of received OSPF bytes that have been counted on this DLCI.

The number of transmitted OSPF bytes that have been counted on this DLCI.

The number of received RIP bytes that have been counted on this DLCI.

The number of transmitted RIP bytes that have been counted on this DLCI.

The number of received Netbios bytes that have been counted on this DLCI.

The number of transmitted Netbios bytes that have been counted on this DLCI.

Short Term Statistics on the IPX protocol for each DLCI.

The IPX Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value in which the Statistics are associated.

The total number of IPX bytes that have been counted on this DLCI.

The total number of IPX bytes that have been counted on this DLCI.

The number of SPX over IPX bytes that have been counted on this DLCI.

The number of SPX over IPX bytes that have been counted on this DLCI.

The number of NCP over IPX bytes that have been counted on this DLCI.

The number of NCP over IPX bytes that have been counted on this DLCI.

The number of SAP over IPX bytes that have been counted on this DLCI.

The number of SAP over IPX bytes that have been counted on this DLCI.

The number of RIP over IPX bytes that have been counted on this DLCI.

The number of RIP over IPX bytes that have been counted on this DLCI.

The number of NETBIOS over IPX bytes that have been counted on this DLCI.

The number of NETBIOS over IPX bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols over IPX that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols over IPX that are not counted elsewhere in this table.

Short Term Statistics on the IPX protocol for each DLCI.

The IPX Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The total number of IPX bytes that have been counted on this DLCI.

The total number of IPX bytes that have been counted on this DLCI.

The number of SPX over IPX bytes that have been counted on this DLCI.

The number of SPX over IPX bytes that have been counted on this DLCI.

The number of NCP over IPX bytes that have been counted on this DLCI.

The number of NCP over IPX bytes that have been counted on this DLCI.

The number of SAP over IPX bytes that have been counted on this DLCI.

The number of SAP over IPX bytes that have been counted on this DLCI.

The number of RIP over IPX bytes that have been counted on this DLCI.

The number of RIP over IPX bytes that have been counted on this DLCI.

The number of NETBIOS over IPX bytes that have been counted on this DLCI.

The number of NETBIOS over IPX bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols over IPX that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols over IPX that are not counted elsewhere in this table.

Short Term Statistics on the SNA protocol for each DLCI.

The SNA Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value in which the Statistics are associated.

The total number of SNA bytes that have been counted on this DLCI.

The total number of SNA bytes that have been counted on this DLCI.

The number of SNA Subarea bytes that have been counted on this DLCI.

The number of SNA Subarea bytes that have been counted on this DLCI.

The number of SNA Periph bytes that have been counted on this DLCI.

The number of SNA Periph bytes that have been counted on this DLCI.

The number of SNA Appn bytes that have been counted on this DLCI.

The number of SNA Appn bytes that have been counted on this DLCI.

The number of SNA Netbios bytes that have been counted on this DLCI.

The number of SNA Netbios bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols over SNA that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols over SNA that are not counted elsewhere in this table.

Short Term Statistics on the SNA protocol for each DLCI.

The SNA Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The total number of SNA bytes that have been counted on this DLCI.

The total number of SNA bytes that have been counted on this DLCI.

The number of SNA Subarea bytes that have been counted on this DLCI.

The number of SNA Subarea bytes that have been counted on this DLCI.

The number of SNA Periph bytes that have been counted on this DLCI.

The number of SNA Periph bytes that have been counted on this DLCI.

The number of SNA Appn bytes that have been counted on this DLCI.

The number of SNA Appn bytes that have been counted on this DLCI.

The number of SNA Netbios bytes that have been counted on this DLCI.

The number of SNA Netbios bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from protocols over SNA that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from protocols over SNA that are not counted elsewhere in this table.

Short Term Statistics on the ARP protocol for each DLCI.

The ARP Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The DLCI value in which the Statistics are associated.

The total number of ARP bytes that have been counted on this DLCI.

The total number of ARP bytes that have been counted on this DLCI.

The number of ARP request bytes that have been counted on this DLCI.

The number of ARP request bytes that have been counted on this DLCI.

The number of ARP reply bytes that have been counted on this DLCI.

The number of ARP reply bytes that have been counted on this DLCI.

The number of RARP request bytes that have been counted on this DLCI.

The number of RARP request bytes that have been counted on this DLCI.

The number of RARP reply bytes that have been counted on this DLCI.

The number of RARP reply bytes that have been counted on this DLCI.

The number of INARP request bytes that have been counted on this DLCI.

The number of INARP request bytes that have been counted on this DLCI.

The number of INARP reply bytes that have been counted on this DLCI.

The number of INARP reply bytes that have been counted on this DLCI.

The number of received bytes on this DLCI from ARP message types that are not counted elsewhere in this table.

The number of transmitted bytes on this DLCI from ARP message types that are not counted elsewhere in this table.

Short Term Statistics on the ARP protocol across all DLCIs.

The ARP Short Term Statistics for a particular DLCI.

The Short Term statistics model maintains three intervals: current, previous, and cumulative totals. Interval duration is defined by the Short Term Timer (CfgFrPerfTimersSTInterval). (1) Currently active short term interval (2) Previously completed short term interval (3) Cumulative total since last cleared. Enumeration: 'previous-interval': 2, 'current-interval': 1, 'cumulative-counts': 3.

The total number of ARP bytes that have been counted on this DLCI.

The total number of ARP bytes that have been counted on this DLCI.

The number of ARP request bytes that have been counted on this DLCI.

The number of ARP request bytes that have been counted on this DLCI.

The number of ARP reply bytes that have been counted on this DLCI.

The number of ARP reply bytes that have been counted on this DLCI.

The number of RARP request bytes that have been counted on this DLCI.