Download the PHP package meklis/switcher-core without Composer

Switcher-Core

PHP library providing a single, vendor-agnostic interface for network equipment: switches, OLTs, and routers.

Русская версия

Overview

Switcher-Core abstracts away vendor-specific protocols and command sets behind one API. Instead of writing a wrapper for every vendor, you call a named module (e.g. system, fdb, vlans) against a Device, and the library:

1. Detects the device model from SNMP sysDescr / sysObjectID (or an explicit model key).
2. Loads the matching YAML configuration (OIDs, module bindings) for that model.
3. Dispatches the call to the vendor-specific module implementation, or a shared/general one when no vendor-specific implementation exists.

The set of modules supported by a given device, and the exact shape of the response, depend on the device's capabilities and vendor. This is a deliberate trade-off: a single strict schema across all vendors is not achievable for heterogeneous network hardware. See the field naming convention below for how the library keeps responses as consistent as practical.

If your equipment is not in the supported list, implement the module classes and configuration described in Module Development and contribute it, or maintain it in a fork.

Supported transports

• Telnet
• SSH
• SNMP (v2c only)
• RouterOS API (without SSL)

Supported vendors

• [x] D-Link switches
• [x] Huawei switches
• [x] EdgeCore switches
• [x] Huawei OLTs
• [x] BDCOM OLTs
• [x] ZTE OLTs
• [x] C-Data OLTs
• [x] V-Solution OLTs
• [x] Mikrotik routers
• [x] Cisco switches (basic)
• [x] GCOM OLTs
• [x] Alcatel switches (basic)
• [x] Eltex switches (basic)
• [x] HP switches (basic)
• [x] Dell switches (basic)
• [x] Allied Telesis switches (basic)
• [x] TP-Link switches (basic)
• [x] Juniper switches (basic)
• [x] Raisecom switches (basic)
• [ ] Extreme routers

• [ ] Cisco routers

• Full device and module compatibility matrix
• Module reference
• Per-device module and response reference (HTML)

Requirements

• PHP >= 7.2
• PHP extensions: yaml, zip, curl, json, mbstring, snmp, sockets, ssl

Installation

Quick start

Example output of the system module (exact fields vary by vendor):

Response field convention

Some modules (e.g. fdb, pon_onts_status) are implemented differently across vendors and platforms, so their output cannot be perfectly uniform. The library follows one rule consistently:

• A field with no leading underscore is part of the module's common contract: same name, same meaning, across every implementation of that module.
• A field prefixed with _ is platform- or vendor-specific and not part of the common contract.
• When two platforms report semantically the same value under different names, the common field uses a neutral name, and each vendor's original field name is kept alongside it with a leading underscore (e.g. a common ident field, plus _serial on one platform and _mac on another).

Interface objects (interface / interfaces) follow their own, already-established convention: id, name, type, parent are common; _port, _slot, _onu, _snmp_id, _technology, _type, etc. are platform-specific.

See Module Development for details and examples.

Repository layout

Developing and extending modules

Adding support for a new device model, or a new module, is a configuration-plus-code task: OID files, a model definition, and (when no existing module fits) a PHP class. This is documented in full in Module Development.

Testing

This runs the PHPUnit suite (tests/), which currently checks configuration consistency (OIDs, models, modules). It does not verify behavior against real hardware — automated tests here are not a substitute for testing against an actual device. See Module Development for how to do that with bin/console.

Used in

wildcore.tools

License

MIT