towerops/docs/librenms-audit/sensors/arista-eos-comparison.md

# Arista EOS Sensor Discovery: LibreNMS vs Towerops

**Analysis Date**: 2026-02-11
**Vendor**: Arista Networks
**OS**: EOS (Extensible Operating System)

## Executive Summary

**Parity Status**: ⚠️ **85% Complete - Gaps Identified**

Both systems discover sensors via ENTITY-SENSOR-MIB, but LibreNMS has Arista-specific enhancements that Towerops currently lacks. These gaps affect threshold accuracy and optical power display.

## Sensor Coverage Comparison

| Sensor Type | LibreNMS | Towerops | Status |
|-------------|----------|----------|--------|
| Temperature | ✅ ENTITY-SENSOR-MIB | ✅ ENTITY-SENSOR-MIB | ✅ COVERED |
| Voltage | ✅ ENTITY-SENSOR-MIB | ✅ ENTITY-SENSOR-MIB | ✅ COVERED |
| Current | ✅ ENTITY-SENSOR-MIB | ✅ ENTITY-SENSOR-MIB | ✅ COVERED |
| Power | ✅ ENTITY-SENSOR-MIB | ✅ ENTITY-SENSOR-MIB | ✅ COVERED |
| Fan Speed | ✅ ENTITY-SENSOR-MIB | ✅ ENTITY-SENSOR-MIB | ✅ COVERED |
| Frequency | ✅ ENTITY-SENSOR-MIB | ✅ ENTITY-SENSOR-MIB | ✅ COVERED |
| Humidity | ✅ ENTITY-SENSOR-MIB | ✅ ENTITY-SENSOR-MIB | ✅ COVERED |
| Optical Power (dBm) | ✅ ENTITY-SENSOR + DOM conversion | ⚠️ ENTITY-SENSOR (watts) | ⚠️ GAP |
| Sensor Thresholds | ✅ ARISTA-ENTITY-SENSOR-MIB | ❌ None | ❌ GAP |
| Sensor Grouping | ✅ SFPs/PSUs/Platform/System | ❌ Flat list | ⚠️ GAP |
| CPU/Memory/Uptime | ❌ Not discovered | ✅ HOST-RESOURCES-MIB | ✅ TOWEROPS ADVANTAGE |
| PSU/Fan State | ❌ Not discovered | ✅ ENTITY-STATE-MIB | ✅ TOWEROPS ADVANTAGE |

## Discovery Architecture

### LibreNMS Approach

**Primary Method**: ENTITY-SENSOR-MIB with Arista-specific enhancements

**File**: `includes/discovery/sensors/entity-sensor.inc.php` (lines 99-242)

**Key Features**:

1. **Sensor Description Cleanup** (lines 99-114)
   - Removes redundant strings ("sensor", "hotspot", etc.)
   - Standardizes power supply names
   - Platform chip cleanup (Trident, Jericho, FM6000)

   ```php
   if (preg_match('/^(DOM|Xcvr) (Rx|Tx)/', $entPhysicalName)) {
       $descr = preg_replace('/^(DOM|Xcvr) /', '', $entPhysicalName);
   }
   ```

2. **DOM Rx/Tx Power Conversion** (lines 182-187)
   - Detects: `"DOM (R|T)x Power"` pattern
   - Converts: watts → dBm (optical power)
   - Formula: `dBm = round(10 * log10(watts / 10000), 3)`

   **Example**:
   - Input: 0.0005 watts (from ENTITY-SENSOR-MIB)
   - Output: -23.010 dBm (user-friendly optical power)

3. **Arista Threshold Table** (lines 189-221)
   - Walks: `ARISTA-ENTITY-SENSOR-MIB::aristaEntSensorThresholdTable`
   - Four threshold levels:
     - `aristaEntSensorThresholdLowCritical` → `low_limit`
     - `aristaEntSensorThresholdLowWarning` → `low_warn_limit`
     - `aristaEntSensorThresholdHighWarning` → `warn_limit`
     - `aristaEntSensorThresholdHighCritical` → `high_limit`
   - Special dBm conversion for optical thresholds

4. **Smart Grouping** (lines 222-242)
   ```
   Pattern                    → Group
   Contains "DOM"             → "SFPs"
   Contains "PwrCon"          → "PwrCon<N>"
   Starts with Trident/etc    → "Platform"
   Starts with Power/PSU      → "PSUs"
   Other                      → "System"
   ```

**Additional Files**:
- `includes/polling/sensors/dbm/arista_eos.inc.php` - Polling logic for dBm sensors

### Towerops Approach

**Primary Method**: ENTITY-SENSOR-MIB (generic) + HOST-RESOURCES-MIB

**Files**:
- `lib/towerops/snmp/profiles/base.ex` - Generic ENTITY-SENSOR-MIB discovery
- `lib/towerops/snmp/profiles/vendors/arista.ex` - Minimal vendor logic
- `priv/profiles/os_discovery/arista_eos.yaml` - OS detection only (no sensor YAML)

**Key Features**:

1. **Generic ENTITY-SENSOR-MIB** (base.ex lines 220-251)
   - Standard sensor type mapping (volts, amperes, watts, etc.)
   - Formula-based divisor: `10^(precision - scale)`
   - Entity description fetching via ENTITY-MIB

2. **CPU/Memory/Uptime Discovery** (arista.ex lines 17-26)
   - **Note**: Module is misnamed "wireless_sensors"
   - Actually discovers system metrics via HOST-RESOURCES-MIB:
     - CPU Load: `1.3.6.1.2.1.25.3.3.1.2.1`
     - Memory Size: `1.3.6.1.2.1.25.2.3.1.5.1`
     - Memory Used: `1.3.6.1.2.1.25.2.3.1.6.1`
     - System Uptime: `1.3.6.1.2.1.1.3.0`

3. **PSU/Fan State Sensors** (base.ex lines 294-333)
   - Uses ENTITY-STATE-MIB for operational status
   - Maps physical class: `6 → power_supply`, `7 → fan`

**What's Missing**:
- ❌ No ARISTA-ENTITY-SENSOR-MIB threshold walking
- ❌ No DOM power conversion (watts → dBm)
- ❌ No smart grouping (SFPs, PSUs, Platform)
- ❌ No Arista-specific description cleanup

## Identified Gaps

### Critical Gap 1: DOM Rx/Tx Power Display

**Problem**: Optical power displayed as watts instead of dBm

**LibreNMS**:
```
Sensor: "DOM Rx Power"
Type: dbm
Value: -23.010 dBm
Unit: dBm
```

**Towerops** (current):
```
Sensor: "DOM Rx Power"
Type: power
Value: 0.0005 W
Unit: W
```

**Impact**: HIGH
- Users expect optical power in dBm (industry standard)
- Watts are not intuitive for transceiver troubleshooting
- Makes comparison with vendor datasheets difficult

**Fix Required**:
1. Detect sensors matching pattern: `/DOM (R|T)x Power/`
2. Convert type from `power` → `dbm`
3. Apply conversion: `dbm = round(10 * log10(watts / 10000), 3)`
4. Update sensor unit to "dBm"

### Critical Gap 2: Missing Arista Thresholds

**Problem**: No warning/critical limits for sensors

**LibreNMS**:
```
Sensor: "Temperature Sensor 1"
Value: 45°C
Warn Low: -5°C
Limit Low: -10°C
Warn High: 85°C
Limit High: 95°C
```

**Towerops** (current):
```
Sensor: "Temperature Sensor 1"
Value: 45°C
Warn Low: null
Limit Low: null
Warn High: null
Limit High: null
```

**Impact**: HIGH
- No alerting possible without thresholds
- Users can't set up monitoring alarms
- Critical for production environments

**Fix Required**:
1. Walk `ARISTA-ENTITY-SENSOR-MIB::aristaEntSensorThresholdTable`
2. Map threshold types:
   - Type 1 (lowCritical) → `low_limit`
   - Type 2 (lowWarning) → `low_warn_limit`
   - Type 3 (highWarning) → `warn_limit`
   - Type 4 (highCritical) → `high_limit`
3. Apply dBm conversion for optical sensors
4. Store in sensor schema

### Minor Gap 3: No Smart Grouping

**Problem**: Sensors appear as flat list instead of organized groups

**LibreNMS**:
```
Group "SFPs":
  - DOM Rx Power Sensor 1
  - DOM Tx Power Sensor 1
  - DOM Rx Power Sensor 2

Group "PSUs":
  - PowerSupply1 Sensor TempSensor1
  - PowerSupply1 Sensor VoltageSensor1
  - PowerSupply2 Sensor TempSensor1
```

**Towerops** (current):
```
All Sensors (ungrouped):
  - DOM Rx Power Sensor 1
  - PowerSupply1 Sensor TempSensor1
  - DOM Tx Power Sensor 1
  - ...
```

**Impact**: MEDIUM
- UI/UX issue, not functional
- Makes sensor navigation harder on large switches
- Less critical than missing thresholds

**Fix Required**:
1. Parse sensor descriptions for keywords
2. Apply grouping logic:
   - Contains "DOM" → "SFPs"
   - Starts with "Power" → "PSUs"
   - Starts with "Trident" → "Platform"
   - Default → "System"
3. Store group in sensor metadata

### Minor Gap 4: Verbose Sensor Descriptions

**Problem**: Redundant text in sensor names

**LibreNMS**:
```
"Temp Sensor 1"
"PSU1 Voltage"
"Fan Tray 1"
```

**Towerops** (current):
```
"Temp Sensor 1 sensor"
"PSU1/1 Sensor VoltageSensor1"
"Fan Tray 1 sensor FanSensor1"
```

**Impact**: LOW
- Cosmetic issue only
- Doesn't affect functionality
- Minor UX annoyance

**Fix Required**:
1. Apply regex cleanup to descriptions:
   - Remove " sensor" suffix
   - Remove duplicate "Sensor" strings
   - Simplify PSU naming

## Towerops Advantages

### Advantage 1: CPU/Memory/Uptime Sensors

Towerops discovers system metrics that LibreNMS does not:

**Sensors Discovered**:
- CPU Load (%)
- Memory Size (units)
- Memory Used (units)
- System Uptime (ticks)

**OIDs**:
- `1.3.6.1.2.1.25.3.3.1.2.1` - hrProcessorLoad
- `1.3.6.1.2.1.25.2.3.1.5.1` - hrStorageSize
- `1.3.6.1.2.1.25.2.3.1.6.1` - hrStorageUsed
- `1.3.6.1.2.1.1.3.0` - sysUpTime

**Impact**: Useful for capacity planning and troubleshooting

### Advantage 2: PSU/Fan State Sensors

Towerops discovers operational state via ENTITY-STATE-MIB:

**Sensors Discovered**:
- Power supply operational status (ok, warning, failed, etc.)
- Fan operational status (ok, warning, failed, etc.)

**OID**: `1.3.6.1.2.1.131.1.1.1.3` - entStateOper

**Impact**: Enables proactive maintenance alerting

## Device Coverage

Both systems discover sensors on all Arista EOS platforms:

**Spine/Leaf Switches**:
- 7050 Series (7050S, 7050T, 7050X, 7050X2, 7050X3)
- 7060 Series (7060CX, 7060DX, 7060PX, 7060SX)
- 7280 Series (7280E, 7280R, 7280SR, 7280CR, 7280QR)
- 7320 Series (7320X, 7320X2, 7320X3)
- 7358 Series (7358X4)
- 7368 Series (7368X4)
- 7388 Series (7388X5)

**Edge/Access Switches**:
- 7010 Series (7010T, 7010TX)
- 7020 Series (7020R, 7020SR, 7020TR, 7020TRA)
- 720D Series (720DT, 720DP)
- 722XPM Series

**Routers**:
- 7500E Series
- 7500R Series
- 7800R3 Series

**Universal Leaf Switches**:
- 7800 Series

## Implementation Priority

### High Priority (Production Critical)

1. **DOM Power Conversion** - 2-3 hours
   - Add to `lib/towerops/snmp/profiles/vendors/arista.ex`
   - Detect pattern: `/DOM (R|T)x Power/`
   - Apply conversion formula
   - Update sensor type to `dbm`

2. **Arista Threshold Discovery** - 4-6 hours
   - Walk `ARISTA-ENTITY-SENSOR-MIB::aristaEntSensorThresholdTable`
   - Map 4 threshold types to sensor limits
   - Handle dBm conversion for optical sensors
   - Update sensor schema with limits

### Medium Priority (Nice to Have)

3. **Smart Grouping** - 2-3 hours
   - Add grouping logic to vendor module
   - Parse descriptions for keywords
   - Store group in sensor metadata
   - Update UI to display groups

4. **Description Cleanup** - 1-2 hours
   - Add regex cleanup rules
   - Remove redundant "sensor" strings
   - Simplify PSU/Fan naming

### Low Priority (Cosmetic)

5. **Rename Vendor Module Function** - 5 minutes
   - Rename `wireless_sensors/0` → `system_sensors/0`
   - Update module documentation

## Recommended Implementation Plan

### Phase 1: Critical Fixes (1 day)
1. Implement DOM power conversion
2. Implement Arista threshold discovery
3. Test on live Arista switch
4. Verify thresholds and alerting work

### Phase 2: UX Improvements (0.5 days)
1. Implement smart grouping
2. Implement description cleanup
3. Test UI display

### Phase 3: Documentation (0.5 days)
1. Document Arista-specific behavior
2. Update vendor module comments
3. Add test cases

**Total Effort**: ~2 days of development

## Conclusion

**Status**: ⚠️ **85% Complete - Improvements Needed**

Towerops has good base ENTITY-SENSOR-MIB coverage but lacks Arista-specific enhancements that improve usability and enable alerting. The gaps are well-defined and fixable.

**Critical Fixes**:
- ❌ DOM power conversion (watts → dBm)
- ❌ Arista threshold discovery

**Nice to Have**:
- Smart grouping (SFPs, PSUs, Platform)
- Description cleanup
- Better module naming

**Towerops Advantages**:
- ✅ CPU/Memory/Uptime sensors (HOST-RESOURCES-MIB)
- ✅ PSU/Fan state sensors (ENTITY-STATE-MIB)

**Recommendation**: Prioritize DOM conversion and threshold discovery for production readiness. These fixes enable proper monitoring and alerting for Arista EOS devices.