MIBs¶

In short: A MIB is the description a vendor ships with its SNMP values — which name belongs to an OID, what it means, which number stands for which state and in which unit it counts. Vesana reads these files and uses them while setting things up: for names, explanations and suggestions. A check itself still stores only the numeric OID and runs just the same without a MIB.

Find it under Profiles → tab "MIBs".

What a MIB changes — and what it doesn't¶

With MIB	Without MIB
OIDs carry names (`ifHCInOctets` instead of `1.3.6.1.2.1.31.1.1.1.6`)	Vesana shows the bare OID or a name from the built-in catalog
State values have labels (`3 = onBattery`)	The number without a label
Units and display (`rpm`, `0.1 °C`) are known	You enter the unit yourself

Deleting or replacing a MIB changes no check. Checks store numeric OIDs only — they keep running and at most lose the names in the display. A check set up with the help of a MIB can therefore be shared as a profile and runs on any other instance.

Bundled MIBs¶

Vesana ships the common standard MIBs (source "Bundled"), among them:

Interfaces and network: IF-MIB, IP-MIB, IP-FORWARD-MIB, TCP-MIB, UDP-MIB, EtherLike-MIB, BRIDGE-MIB, Q-BRIDGE-MIB, POWER-ETHERNET-MIB
Devices and sensors: HOST-RESOURCES-MIB, ENTITY-MIB, ENTITY-SENSOR-MIB, ENTITY-STATE-MIB
UPS and printers: UPS-MIB, Printer-MIB
Linux/net-snmp: UCD-SNMP-MIB, UCD-DISKIO-MIB, LM-SENSORS-MIB, NET-SNMP-MIB
plus the IANA modules these need (IANAifType-MIB, …)

They are available to all tenants and cannot be deleted. Origin and license of each file are listed in the third-party notices.

LLDP-MIB is deliberately missing: it is an IEEE standard without clear redistribution rights. Upload it yourself if you need it.

Uploading a MIB¶

Profiles → MIBs → "Upload MIB".
Drop or pick files: single MIB files (.mib, .my, .txt or without extension) or a ZIP with the whole vendor package.
Choose Applies to:
Only tenant X — only this tenant sees the MIB.
Instance-wide — all tenants. This choice only exists with the mibs.upload_global permission (see Permissions).
Upload. The dialog reports per module what happened; compilation runs in the background.

Prefer the whole package

Vendor MIBs build on each other (CISCO-SMI is needed by nearly every Cisco MIB). Uploading the complete ZIP from the vendor's website brings all dependencies at once.

What the dialog reports¶

Message	Meaning
new — being compiled	Module stored, compilation running
replaced — being compiled again	A newer version of the same module replaced the old one
unchanged	Exactly this file is already stored
older than the stored version	The file has an older revision (`LAST-UPDATED`). Tick "Replace anyway" and use "Replace selected" to take it on purpose
base module — built into Vesana	`SNMPv2-SMI`, `SNMPv2-TC` & co. are built in; the file is not needed
… files in the package skipped	The ZIP contained files Vesana does not take over: not a MIB (manuals, images), too large, encrypted, damaged or packed with an unknown method. The remaining MIBs of the package are stored; the file names are in the tooltip

A tenant module with the same name as an instance-wide one overrides it for that tenant — a customer can use their own version without changing everyone else's.

From the Vesana library¶

The Vesana library provides vetted vendor MIBs (MikroTik, Synology, Fortinet, HPE, Ubiquiti, APC and more). Profiles → MIBs searches it; Fetch stores the module instance-wide.

Each row says beforehand how the module already exists here: installed, Update (the library has a newer revision) or own version installed — an uploaded or bundled version always takes precedence and is never replaced by the library.
For vendor MIBs the library only distributes the derived directory (names, OIDs, types, value lists, units), not the original text — vendor licences usually don't allow redistribution. These modules therefore show no descriptions. If you need them, upload the vendor's original file yourself; it then replaces the library entry.
No internet, or a configured address without a MIB library: the search says "unreachable"; uploading still works.

Library MIBs also arrive on their own:

When installing a profile from the library. A profile names the MIBs its checks belong to; Vesana fetches them along and says so in the message. If the library is unreachable at that moment, the profile is installed anyway; the MIBs can be fetched later in the tab.
In the device scan, see below.

MIBs you upload stay on your instance; they are not sent to the library.

States¶

Every MIB shows its state in words:

State	Meaning	What to do
Compiling …	Running in the background, usually seconds	Nothing
Ready	Names and values are known; the number says how many	Nothing
Waiting for dependency	The MIB needs another module that is still missing — its name is shown ("needs CISCO-SMI")	Upload the missing file. It is usually part of the same vendor package. As soon as it is there, the waiting module finishes compiling on its own
Error	The file is broken; the message names the line ("Syntax error in line 233") — or the translation hit a limit ("memory limit reached", time, CPU time)	Get the current version from the vendor's website and upload it again

"Use without …"¶

If a dependency is missing for good (the vendor no longer ships it), you can still put the MIB into service with "Use without X" in the detail view. Everything the MIB itself describes is then known; values whose type would come from the missing module stay without a value list. "Wait for X again" undoes this.

Corrected automatically¶

Some vendor MIBs have known small mistakes (for example a forgotten import of mib-2 or a missing END). Vesana corrects these documented cases before compiling and says so in the detail view. The stored original file stays unchanged.

In the device scan¶

The device scan (Host → Device scan → Search deeper) additionally reads the branches of all MIBs uploaded for the tenant — the device vendor's first — and suggests the values it finds as checks:

The MIB says	Suggestion
Single value with a value list (incl. `TruthValue`)	State check with labels
Table column with a value list	one check over all rows ("worst state"), name column set
Number (Gauge, Integer)	Measurement with the unit from `UNITS` and the factor from `DISPLAY-HINT` (`d-1` ⇒ 0.1)
Number column	Maximum over all rows, name column set
Counter (Counter32/64)	Rate per second
Bit mask (`BITS`)	Text check with bit labels
Text	Text check (not pre-selected)

Interface counters (IF-MIB) need no MIB: the scan suggests utilization, errors and per-interface traffic for every device — see Bandwidth and counters.

A MIB does not say which value is OK, WARNING or CRITICAL. Vesana uses the maintained catalog for that; if it doesn't know the OID, it maps unambiguous labels (ok, normal, up ⇒ OK · warning, degraded ⇒ WARNING · failed, critical, down ⇒ CRITICAL) and marks this visibly as a suggestion — please check. Everything else stays unmapped and reports WARNING until you decide. This includes truth values (true/false): whether "on" is good or bad depends on the value (a disabled feature is often intended), so Vesana never maps them itself.

Above the suggestions, each MIB shows what the device answered ("34 values · 9 suggested" or "Device does not answer in this branch"). If the device identifies as a vendor no MIB is available for, Vesana asks the Vesana library:

If the library has the MIB, Vesana fetches it, says so and runs the scan again by itself — the vendor values are then included right away. From the second scan of the same device on, the MIB is already in place before the scan.
If the library has none or cannot be reached, the scan says so and offers Upload MIB; then Scan again once.

Without an uploaded MIB the scan works exactly as before.

In the check editor¶

Every OID field of an SNMP check (host and profile editor) gets help from the MIB library — only the number is ever saved:

Search MIBs opens a search across all MIBs you may see: name (mtxrHlTemperature), MODULE::name or OID. Results show module, type, value list, unit and description. If you pick a column in the table column field, Vesana also sets the name column when the MIB suggests one.
Typing a name instead of the number works too: VESANA-TEST-MIB::vtTemperature.0 or just vtTemperature — when you leave the field it becomes the OID. A single value without a row gets .0. If the name exists in several MIBs, the field asks which one is meant.
Below the field, Vesana shows which object the number is (MODULE::name.row, kind, type, unit; the description as tooltip). A check's status shows the same as MIB object.
Counters (Counter32/Counter64) keep rising since the device started; a note below the field then recommends a rate check — for interface octets the interface utilisation check.
In the Interpretation block, Take from MIB fills the mapping with the MIB's labels (status as in the scan: catalog before label, otherwise empty) or the conversion with factor and unit from DISPLAY-HINT and UNITS.

If you use the API directly: a symbolic name in an OID field is rejected (HTTP 422) — a collector knows no MIBs.

Detail view¶

Clicking a row opens the side panel:

State with a sentence and a way out (compile again, use without dependency, delete)
Facts: revision, source, scope, enterprise branch (1.3.6.1.4.1.<number>), file
Needs / Needed by: the dependencies in both directions, colored by state
Values and tables: all objects of the MIB with search (name or OID) and a filter by kind. A click expands type, unit, display, value list and description

Deleting¶

Delete in the detail view first shows which checks use values from this MIB:

3 checks use values from this MIB: … — These checks keep running; they only lose the names in the display.

Modules that need the deleted MIB wait for it again afterwards. Bundled MIBs cannot be deleted.

Permissions¶

Permission	Allows	Default
`mibs.view`	List, detail, looking up names	Admin, Operator, Viewer
`mibs.upload`	Upload for your own tenants, compile again, "use without …" — and fetch MIBs from the Vesana library	Admin
`mibs.delete`	Delete your own tenant MIBs	Admin
`mibs.upload_global`	Upload, change and delete instance-wide — affects all tenants	Super admin only

Instance-wide counts only for accounts holding the permission in all tenants — as with the icon library. Uploads, deletions and "use without …" are written to the audit log.

MIBs from the Vesana library are always stored instance-wide, even when a tenant admin fetches them: they are vetted library data, not anyone's own content — and they never cover anything uploaded locally. When installing a profile and in the device scan, the permission the action already requires applies (installing a profile or scanning a device). Every fetch is written to the audit log (mib_hub_import).

Security¶

A MIB is plain text; it contains no executable code. Vesana still compiles it carefully:

in a separate process with time and memory limits (3 minutes, 1.5 GB) and without network access,
only files that a person on this instance uploaded or that Vesana ships — what comes from the Vesana library is not compiled at all: it is a finished directory that Vesana checks against its schema (fields, limits, module name) and rejects otherwise,
the result is a validated data directory, never generated program code.

The limits apply per translation run: if a run with several modules hits a limit, Vesana re-translates the modules in smaller groups or one by one — afterwards only the module that also fails on its own is set to Error. Large ZIP packages are unpacked in the background; the interface stays usable meanwhile.

Upload limits: a single file up to 8 MB, a ZIP up to 48 MB with at most 3000 entries and 200 MB unpacked, up to 50 files at once. When looking up names, Vesana accepts OIDs with up to 128 arcs; longer input is rejected immediately.

FAQ¶

Do I need MIBs to build SNMP checks? No. Every SNMP check works with the numeric OID. The MIB only makes setting up easier to understand.

I uploaded the MIB, but it is still "waiting". The name of the missing module is shown. Upload exactly that file — usually it is in the same vendor ZIP, often under a different file name. The waiting module then finishes on its own.

Why does it say "base module — built into Vesana"? Base modules such as SNMPv2-SMI are built in. The file from the package is skipped; that does no harm.

Why did MIBs come along when installing a profile? The profile in the library names the MIBs its checks belong to. With them, Vesana shows names and labels instead of bare OIDs. The checks also run without them.

Why is the description of a library MIB empty? For vendor MIBs the library only distributes the directory, not the text (licence). Upload the vendor's original file — it takes precedence over the library entry and brings the descriptions along.

Can one tenant see another tenant's MIB? No. Tenant MIBs are visible only within their tenant; instance-wide MIBs are visible to everyone.