XEDIA-IF-MIB
The XEDIA-IF-MIB extends standard IETF interface management capabilities to monitor and configure specific hardware interface parameters on Xedia network devices. This module provides vendor-specific objects for tracking interface status, statistics, and configuration attributes not covered by the generic ifMIB.
Imported Objects
Objects
8 total| Object Name |
|---|
xediaIfMIBThis module defines additional objects for management of Interfaces in Xedia devices, beyond what is defined in the IETF's ifMib. MODULE-IDENTITY .1.3.6.1.4.1.838.3.40 |
xifObjects OBJECT IDENTIFIER .1.3.6.1.4.1.838.3.40.1 |
xifNextIndexVariable indicating what ifIndex value to use in a row create operation in the ifTable (using the Xedia rowStatus extension).rw INTEGER .1.3.6.1.4.1.838.3.40.1.1 |
xifTableA table that allows add/deletes of ifEntries. SEQUENCE OF XifEntry .1.3.6.1.4.1.838.3.40.1.2 |
xifEntry. XifEntry .1.3.6.1.4.1.838.3.40.1.2.1 |
xifRowStatusThis object is used to add entries to the ifTable. The object ifStackStatus, from the standard ifStack table is covered here as well. It is used to connect and disconnect ifEntries. When creating a new entry, the value of xifRowStatus must be createAndGo(4). In addition, the ifName object must be supplied in the same PDU. Choosing the ifIndex value: While any ifIndex value may be supplied, in order to avoid an error and choose the best value for ifIndex, the xifNextIndex object should be used. It is a test-and-increment variable which means that the client must first get the present value and then do a set (on xifNextIndex) with that same value. If that sequence is succesfull then the client owns that value (until the next reset of the system unless the value is actually used to create an entry). Choosing the ifName value: The choice for ifName must conform to the format: <component-name>.<instance-number>.[<sub-interface-number>] Special cases: To create the next correct ifName <instance-number> or <sub-interface-number> the keyword 'new' may be used. For physical slots (the bottom of a physical the stack) the name format is slot.<slot-number>.<port-number> The bottom of the ipsec stack (virtual in the stack command) is ipsec-transform.1 Example names are: eth.1 frame-relay.new, frame-relay.1.new Example SNMP sequence to create a new CBQ interface: get xifNextIndex.0 value = 32 set xifNextIndex.0 32 <no-error> set ifName.32 'cbq.new' xifRowStatus.32 'CreateAndGo(4)' NOTE: A new layer and sub-interface may not be created in the same request since two ifIndex values are required. If both a new layer and sub-interface are offered, only the layer is created and no warning is given. Connecting and disconnecting ifEntries: In order to connect or disconnect created ifEntries, the ifStack table must be used. Each entry in the stack table indicates a connection between two ifEntries. For example, to connect an interface with ifName of eth.1 and the other with the name ip.1, the following would be done. If the ifIndex values are not known, the xsysIfNameIndexTable should be used. It has an index of ifName and returns the associated ifIndex. Once the ifIndex values of the two ifEntries to be connected are known, then create or remove an entry in the stack table. Example SNMP sequence to connect eth.1 to ip.1 get xsysIfIndex.'eth.1' (note instance value is a string) value = 20 get xsysIfIndex.'ip.1' value = 24 set ifStackStatus.24.20 'CreateAndGo(4)' To disconnect: set ifStackStatus.24.20 'Destroy(6)' Restrictions: To be consistent with the cli 'stack' command in most cases the stack can be built from the bottom. However, when connecting CBQ layers, there are some cases where it must be conneceted to its upper layer before connected to its lower layer. For instance, when connecting eth.1 cbq.1 ip.1 cbq.1 must be connected to ip.1 before eth.1 is connected to cbq.1.rw RowStatus (SNMPv2-TC) .1.3.6.1.4.1.838.3.40.1.2.1.1 |
xifNotifications OBJECT IDENTIFIER .1.3.6.1.4.1.838.3.40.2 |
xifConformance OBJECT IDENTIFIER .1.3.6.1.4.1.838.3.40.3 |
More MIBs from Xedia
Browse all XediaMIBs →The XEDIA-SYSTEM-MIB provides SNMP objects to monitor and manage system-level parameters, including hardware status, resource utilization, and operational state, specifically for Xedia embedded networking devices.
The XEDIA-NETWORK-ADDRESS-TRANSLATOR-MIB provides management objects for monitoring and configuring Xedia's proprietary Network Address Translator (NAT) devices, enabling the tracking of translation sessions, address pool utilization, and packet flow statistics between RFC1918 private networks and the public Internet.
The XEDIA-POLICY-MIB enables SNMP-based configuration and monitoring of routing policy definitions, including match conditions, action sets, and policy application states, specifically within Xedia networking hardware. This module provides granular visibility into the operational status and parameter values of traffic steering rules to facilitate automated policy enforcement and troubleshooting.
The XEDIA-IPSEC-MIB enables monitoring and configuration of Xedia IPsec VPN tunnel states, security associations, and cryptographic parameters on Xedia networking hardware. It provides specific objects for tracking tunnel establishment status, packet counters, and IPsec policy enforcement metrics to ensure secure data transmission integrity.
The XEDIA-IP-MIB extends standard IETF IP-MIB functionality to monitor and manage IP-layer parameters, interfaces, and routing statistics specifically within Xedia hardware platforms. This module provides vendor-specific object identifiers for tracking IP traffic counters, interface states, and protocol configurations on Xedia network devices.
The XEDIA-NETWORK-TIME-PROTOCOL-MIB enables monitoring of Xedia's RFC 1305-compliant Network Time Protocol (NTP) implementation to manage UTC synchronization states, server association parameters, and time offset metrics across network hosts.