Werk #19972: Fortigate interface check: expose ifName via 'name' attribute, restore ifAlias
| Component | Checks & agents | ||
| Title | Fortigate interface check: expose ifName via 'name' attribute, restore ifAlias | ||
| Date | May 13, 2026 | ||
| Level | Prominent Change | ||
| Class | Bug Fix | ||
| Compatibility | Incompatible - Manual interaction might be required | ||
| Checkmk versions & editions |
|
The Fortigate interface check previously substituted ifName for
ifAlias in its SNMP wire layout: the value of OID .31.1.1.1.1
(ifName, the technical name like port1.5) was placed into the
alias attribute, while the actual ifAlias OID was not fetched at
all. The "Use alias" item-appearance option therefore returned the
technical name on Fortigate hosts but a user-defined string on every
other device — a long-standing inconsistency rooted in the fact that
name did not exist as a first-class interface attribute. (History:
werks 4539 → 6638 → 11267.)
With werk #19971, the shared if64 parser fetches ifName and
populates a dedicated name attribute. The Fortigate-specific hijack
is no longer needed and is removed: ifAlias is now fetched and
exposed at the alias attribute like on every other SNMP device, and
the technical interface name is available via the name attribute.
Incompatible change
If you currently use the option Appearance of network interface = Use alias on Fortigate hosts (the historical default for technical interface names), discovered services will keep the existing item names on the next service rediscovery only if you switch the rule to Use name first.
Migration
- In the discovery ruleset Network interfaces and switch ports, open the rules that apply to your Fortigate hosts.
- Change Appearance of network interface from Use alias to Use name.
- Rediscover services on the affected hosts and accept changed services.
If you rediscover without changing the rule, items will be derived from
the actual ifAlias (often empty on Fortigate), and Checkmk will fall
back to the interface index.