XCO as SNMP Proxy

EFA acts as the SNMP Manager for all the SLX devices and agents and receives the traps from all the devices in its inventory.

Simple Network Management Protocol (SNMP) traps are alert messages sent from a remote SNMP-enabled device to a central collector, the SNMP Manager. Trap messages are the main form of communication between SNMP monitoring tools – an SNMP Agent and an SNMP Manager.

XCO acts as the SNMP Manager for all the SLX devices and agents and receives the traps from all the devices in its inventory. Once you register an SLX device with XCO, XCO automatically configures the SLX device to send v3 traps to XCO.

XCO acts as an SNMP proxy for all the SNMP v2 and v3 traps received from the SLX devices, forwarding them onto an external trap receiver, if there is one.

During an update operation, XCO verifies that it is still registered to receive traps from the SLX devices. If a device is unregistered from XCO, the SNMP configuration on the device is updated to no longer send traps to the XCO IP address.

Commands for configuring SNMP
The following commands are available for configuring SNMP on the SLX device. The configuration you set is persisted in the XCO database. DRC is supported.
  • efa inventory device snmp community create
  • efa inventory device snmp community delete
  • efa inventory device snmp community list
  • efa inventory device snmp user create
  • efa inventory device snmp user delete
  • efa inventory device snmp user list
  • efa inventory device snmp host create
  • efa inventory device snmp host delete
  • efa inventory device snmp host list
  • efa inventory device snmp view create
  • efa inventory device snmp view delete
  • efa inventory device snmp view list

For more information about these commands, see ExtremeCloud Orchestrator Command Reference, 3.2.0 .

Notes
  • The device IP address is the one included in SNMP-COMMUNITY-MIB::snmpTrapAddress.0. It is not the XCO IP address.
  • XCO forwards all received traps. In other words, no trap is filtered out.
  • Port 162 on the host where XCO is installed must be available. During a fresh installation, the port availability is checked and the installer returns an error if the port is not available. However, during an upgrade from a previous version of XCO, you must ensure that the port is free.

For more information about SLX-OS MIBs, see the Extreme SLX-OS MIB Reference for your version of SLX-OS.

Limitations
  • A maximum of four trap subscribers is supported.
  • V2c and v3 SNMP subscribers are not validated.
  • Only traps generated by SLX devices are forwarded. Alerts and alarms from XCO itself are not forwarded.
  • Only traps are forwarded. Current XCO tasks or alerts and syslog messages are not forwarded as traps.
  • SNMP Informs are not supported.
  • There is no in-band support for trap forwarding.
  • The Drift and Reconcile process does not show a drift in device configuration for SNMP v3 trap configuration that XCO has pushed. However, every time the device update operation runs, XCO checks if the device is configured to send traps to XCO and if not, pushes the configuration again.
  • For a multi-node deployment during failover of the active node, some traps might be missed while the SNMP service is bootstrapping on the new active node. There is no loss of traps if the standby node goes down.
Migration of existing switch configuration

When you boot the service for the first time after upgrade, any SNMP and NTP configuration on the switch are queried and persisted in the database and managed by XCO.

Similarly, any breakout interfaces or interfaces that have status admin-state DOWN and have a non-auto speed or non-default MTU value are persisted in the database and managed by XCO.

If you have additional updates to make to these configurations, you must make them manually using the XCO commands only.

If these configurations are updated using the SLX commands directly on the switch (meaning, not by using the XCO CLI), they are considered as drifted and are reconciled.

gosnmp-service

The gosnmp-service is responsible for persisting the trap subscribers, receiving the SNMP traps, and forwarding them to the subscribers.

The service is stateless, so no historical data (that is, previously received traps) is persisted.

For high availability deployment, the service runs in active-active mode, however, since the VIP is bound to one host at a time, the pod running on the active node receives the traps. On failover, the standby node takes over and the SNMP service running on that node forwards the traps.

You may have multiple IP subnets configured to access XCO. In such a case, XCO creates multiple subinterfaces under the management interface to which XCO is bound. XCO does not determine which interface sends out the trap, syslog or webhook. The administrator is responsible for configuring a route to the recipient. If one is found, the server sends out the trap. For more information, see Multiple Management IP Networks.