Extreme Switches and Interface service descriptions

Hey,

we have the task of monitoring several Extreme switches. In particular, I’m having trouble with the Interface Description (or Service Description): Extreme seems to have the habit of including information about the switch type and interface type in the description. Here’s an excerpt from the SNMPwalk:

IF-MIB::ifDescr.198 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbNone Port 1/7
IF-MIB::ifDescr.199 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbNone Port 1/8
IF-MIB::ifDescr.200 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbNone Port 1/9
IF-MIB::ifDescr.201 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbSR Port 1/10
IF-MIB::ifDescr.202 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbSR Port 1/11
IF-MIB::ifDescr.203 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbNone Port 1/12
IF-MIB::ifDescr.204 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbNone Port 1/13
IF-MIB::ifDescr.205 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - GbicSx Port 1/14
IF-MIB::ifDescr.206 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - GbicSx Port 1/15
IF-MIB::ifDescr.207 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - GbicSx Port 1/16

Besides the fact that the service name in CheckMK looks accordingly ugly (we have already fixed this with a Service Description Translation), the difficulties arise as soon as, for example, an SFP module is exchanged, or an SFP is defective. Extreme then does the following:

SFP OK:

IF-MIB::ifDescr.201 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbSR Port 1/10

SFP defective:

IF-MIB::ifDescr.201 = STRING: Extreme Networks Virtual Services Platform 7254XSQ - 10GbNone Port 1/10

With the switch from 10GbSR to 10GbNone in the port and thus the Service Description, this service goes into the state “Unknown” and the discovery detects a new service. The Service Description Translation does not help me here either, as the translation takes place later. Using Interface Index or Alias as Service Description is also not an option.

Is there perhaps a configuration possibility on the side of the switch? Does anyone have experience with this?

this looks horrible… Oo spontaneously I’d guess that without writing a custom plugin to superseed the default if64 snmp plugin, this cannot be handled by checkmk. But maybe someone with more Extreme Network experience has thought of something else…
@thl-cmk you have had your share of weird network cases, has something like this come up :D? (or is it too “extreme” ba dum tiss sorry for the bad pun.)

2 Likes

I think the easiest way is to use the interface index. Only a number but better than your “description”. Second option give all interfaces an alias.

I for my part use most of the time the interface name + a short description as alias and this in turn as service item. Like

Gi0/0/01 - AccessPort
Gi0/0/02 - not used/shutdown
Gi0/0/32 - Server01
Te1/1/1 - Uplink

This way I can also add interface rules based on the item name → AccessPort → dont care about up/down.

If you like you can also have a look at my CheckMK / Vendor independent / if64name · GitLab if64 extension. This could have some disadvantages as the “disable snmp sections” is only honored by the service discovery but not by the normal check run.

With the CheckMK / Vendor independent / Inventory / Interface name · GitLab inventory extension you can add the interface name to the inventory and check if this is better for you.

On one of the Extrem switches (X670G2-48x-4q) here the name is just the stacknumber:portnumber → 1:1, 1:2, and so on

@martin.hirschvogel In the end I would like to see the if64 check extended by adding the interface name to the options available. As far as I know @andreas-doehler has already done that but not published.

2 Likes

@thl-cmk I briefly had the idea of using the Interface aliases but discarded it: we are dealing with about 35,000 switch ports. Some already have an alias configured - the effort to change this is probably too high. Especially since we do “only” monitoring and not network management.

However, the if64name package looks promising - I will use it as a workaround. The loss of the “disable snmp section” is still acceptable to me at the moment.

Additionally, using the ifName in the Interface Check would make sense, in my opinion. @martin.hirschvogel I would like to join @thl-cmk in this request!

I need to look at the small code fragment that gave me the possibility to select the “ifName” as a fourth option inside the interface and switch port discovery.

1 Like

We will discuss with @thl-cmk this proposal and look into potential side effects regarding performance.

I had a little chat with the CMK team about fully integrating ifName into the if64 check plugin. To make a long story short, they will not integrate ifName for performance reasons. Basically, I can understand that, as if64 is a bit heavy on the SNMP side and there are already performance issues with larger devices.

So for now we have to use good descriptions/aliases or patch if64 on the fly (like my if64name plugin). The CMK team will take a look at the problems with the “Disabled or enabled sections (SNMP)”. This worked fine in CMK 2.0, but in CMK 2.1/2.2 the behavior was changed.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.