Arista

Arista EOS deliberately mirrors Cisco IOS command conventions for SNMP - if you already know IOS syntax, EOS will look immediately familiar.

SNMPv2c (community strings)

configure terminal
snmp-server community public ro
snmp-server community secretstring rw
snmp-server location "Rack 4, DC1"
snmp-server contact [email protected]
end

SNMPv3

snmp-server group MYGROUP v3 priv
snmp-server user MYUSER MYGROUP v3 auth sha MYAUTHPASS priv aes 128 MYPRIVPASS

Same group-then-user pattern as IOS: the group carries the security level (priv requiring both authentication and encryption), the user is then attached to that group with its actual credentials.

Sending traps

snmp-server host 192.168.1.100 version 2c public
snmp-server host 192.168.1.100 version 3 priv MYUSER
snmp-server enable traps

As on IOS, snmp-server enable traps alone enables the default trap set; specific categories can be named instead if you want to be more selective (snmp-server enable traps bgp, for instance).

An EOS-specific option: exposing custom OIDs

EOS supports an extension mechanism for serving custom data over SNMP from an external script - conceptually similar to Net-SNMP's pass_persist (covered in the Using net-snmp guide), but built into EOS itself rather than requiring a separate agent:

snmp-server extension .1.3.6.1.4.1.30065.99 /mnt/flash/my_custom_script.py

Since EOS runs on a Linux-based architecture, scripts like this run directly on the switch's own filesystem (commonly under /mnt/flash) rather than needing a separate management host.

Model/platform differences

This syntax is consistent across Arista's switch line. The more relevant difference on Arista isn't between models but between MIB sources: CPU and memory come from the standard HOST-RESOURCES-MIB rather than a proprietary Arista MIB - the SNMP configuration itself doesn't change based on this, but it's worth knowing when you go looking for a CPU OID and don't find an Arista-specific one.

Common OIDs and MIBs

Arista's own MIBs live under enterprises.30065 (1.3.6.1.4.1.30065) - but for genuinely basic health data, EOS leans on standard, cross-vendor MIBs more than most other vendors on this list, adding its own MIBs specifically to fill gaps those standards leave open.

• CPU and memory - standard HOST-RESOURCES-MIB, same objects (hrProcessorLoad, hrStorageTable) covered for other vendors above - EOS doesn't define its own equivalent.
• Temperature, fan, and power sensors - standard ENTITY-MIB and ENTITY-SENSOR-MIB. entPhysicalTable (1.3.6.1.2.1.47.1.1.1) inventories every physical component and gives each one an index; entPhySensorValue (ENTITY-SENSOR-MIB) reports that component's actual reading - Celsius for temperature, RPM for fans, and so on. See the indexing gotcha below before assuming a sensor's index is predictable.
• Sensor thresholds - ARISTA-ENTITY-SENSOR-MIB (1.3.6.1.4.1.30065.3.12). The standard ENTITY-SENSOR-MIB reports a sensor's current value, but not what counts as too high or too low - Arista's own MIB adds that on top, with aristaEntSensorThresholdLowWarning, ...HighWarning, ...LowCritical, and ...HighCritical, keyed to the same physical index as the standard sensor table. Getting real alerting thresholds (rather than just a raw reading with no context for whether it's a problem) means pulling from both MIBs together, not just one.

Gotchas and platform-specific nuances

A sensor's index in entPhySensorTable isn't a simple, predictable number - it's computed from two other values. The index is entPhysicalContainedIn + entPhysicalParentRelPos for that component - for example, a back-panel temperature sensor with entPhysicalContainedIn of 1100006000 and entPhysicalParentRelPos of 3 sits at index 1100006003 in the sensor table, not at some smaller, more obvious row number. There's no way to guess this in advance; the practical approach is walking entPhysicalTable first, reading each component's entPhysicalDescr to identify which physical thing you're looking at (a specific fan, a specific power supply, a specific optic), and only then computing or looking up the matching sensor index - rather than assuming sensor indexes correspond neatly to physical slot numbers.

Reading a sensor's current value and knowing whether that value is a problem require two separate MIBs. entPhySensorValue alone gives you a number with no context - 65 degrees Celsius, on its own, doesn't say whether that's normal or already past a warning threshold for that specific sensor on that specific model. The threshold objects in ARISTA-ENTITY-SENSOR-MIB, indexed the same way, are what actually define "too high" for a given sensor - a monitoring setup built against just the standard MIB alone can read every value correctly and still never fire a meaningful alert, since it has nothing to compare those values against.

EOS's own extension scripts (and the custom OIDs they expose) live on the switch's local flash filesystem - already noted above, worth repeating as a practical gotcha: a script referenced in snmp-server extension that gets removed or fails to survive a software upgrade silently stops answering for that OID, with no separate error distinguishing "script removed" from "script erroring" from "nothing ever configured there" - worth checking the script's continued presence on flash specifically after any EOS upgrade that touched /mnt/flash.