Ekinops

Ekinops is assigned IANA private enterprise number 20044. Ekinops produces optical transport and DWDM platforms, managed primarily through a network management system rather than a per-device command-line interface.

SNMP configuration

SNMP agent settings - including manager IP addresses and read/write access - are configured through the Ekinops360 network management system or a chassis's local management/craft interface, rather than through commands entered directly on the device. No publicly documented command-line interface for configuring SNMP exists for Ekinops chassis; available documentation points to the Ekinops360 GUI or its bundled craft interface software instead. The relevant objects are defined in EKINOPS-MGNT2-MIB, under enterprises.20044.7 (1.3.6.1.4.1.20044.7). Manager addresses are listed in a table at 1.3.6.1.4.1.20044.7.1.1.1, and the read-only community string is held at 1.3.6.1.4.1.20044.7.1.8.1. SNMPv3 support and a standard ENTITY-MIB implementation for shelf/slot/card inventory are not confirmed in Ekinops's available documentation; Ekinops instead defines its own board-inventory table, mgnt2GigmBoardTable, serving a similar purpose to ENTITY-MIB's physical-entity table.

Sending traps

Each entry in the manager address table also carries its own trap configuration. A destination UDP port (mgnt2GigmManagerTrapPort) is set per manager, along with separate enable flags for control, configuration, and event trap categories (mgnt2GigmManagerEnableCtrl, ...EnableConfig, ...EnableEvent), and five further enable flags covering alarm severity - critical, major, minor, warning, and indeterminate (mgnt2GigmManagerEnableAlarmCrit, ...Major, ...Minor, ...Warning, ...Indeterminate). Severity filtering is handled through these per-manager boolean flags rather than through a single severity-threshold value.

Platform differences

Ekinops chassis have shipped with two generations of management card, commonly referred to as MGMT2 and MGMT4. The two generations expose different MIB sets and OID trees, and a monitoring configuration built against one does not carry over to the other; which generation a given chassis uses needs to be identified before building an SNMP integration against it. Beyond the chassis-level MIB, Ekinops publishes a separate MIB for each type of optical plug-in module a chassis can hold - amplifier, transponder, and filter modules each have their own module, such as EKINOPS-PmOa-MIB, EKINOPS-Pm404-MIB, EKINOPS-Pmfan-MIB, EKINOPS-Pmopm2-MIB, and EKINOPS-PM1001LH-MIB. Which of these MIBs apply to a given chassis depends entirely on which modules are physically installed.

Common OIDs and MIBs

Chassis and slot status are reported under EKINOPS-MGNT2-MIB. Slot occupancy and slot status are read from 1.3.6.1.4.1.20044.7.1.2.1.1.8 and .10 respectively. The same MIB defines chassis-level alarms, including a fan failure alarm (1.3.6.1.4.1.20044.7.2.1.0.10), a CPU over-temperature alarm (1.3.6.1.4.1.20044.7.2.1.35.2), a fan power failure alarm (1.3.6.1.4.1.20044.7.2.1.24.13), and an internal API error alarm (1.3.6.1.4.1.20044.7.2.1.32.1).

Per-module performance monitoring is also alarm-based rather than numeric in the objects that are documented. In the Pmopm2AlmChannel tables (under 1.3.6.1.4.1.20044.64.2.2.3), optical channel status is reported as a set of boolean flags per channel - PowerLowPort, PowerHighPort, AbsentPort, MismatchPort, BalancedPort, and OosPort - rather than a continuous optical-power or bit-error-rate reading. Confirmed object names for raw numeric telemetry, such as an absolute received optical power value, were not found in the available documentation for this MIB family.

Gotchas

Because almost every card type has its own MIB module, a monitoring configuration built for one chassis does not necessarily apply to another chassis with a different mix of cards installed - and the MGMT2/MGMT4 management-card split described above adds a second axis of incompatibility on top of that. The chassis-level MIB documents alarm conditions, such as fan failure or over-temperature, more consistently than it documents numeric readings such as current temperature or optical power level; those readings are more likely to be found in the card-specific MIBs for the installed card type, and even there, most confirmed objects are threshold-crossing alarm flags rather than continuous measurements. A monitoring setup expecting a numeric optical-power or temperature trend line from these MIBs may need to fall back to threshold-crossing events instead.