custom speed for interfaces

Any movement on this? The interface percentage graphs are of no help when they are based on the interface speed (1Gbs) and the WAN circuit speed (300Mbs) is considerably less. All of our prior monitoring solutions provided support for this common scenario. Please advise.

looking for something similar.  we sometimes use the Bandwidth Description on a port. which is available via SNMP to know the max the port can utilize
http://www.cisco.com/web/techdoc/dc/reference/cli/nxos/commands/l2/bandwidth__interface.html

So the only requirement for this is to have some way to know what the interfaces 'real' speed is. If you can get the Bandwidth description via SNMP (which I could not find an OID for), then it's easy.

Add a datapoint (say, 'RealSpeed') that gets that speed via the right OID to the Interfaces datasource. 

Then change the Utilization datapoint expression from this:

InOctets*8/if(lt(BasicSpeed,4294967295),BasicSpeed/1000000,Speed)/1000000*100 (which says divide inOctets *8 by BasicSpeed, if BasicSpeed is less than 4294967295, else by Speed)

to

InOctets*8/if(un(RealSpeed),if(lt(BasicSpeed,4294967295),BasicSpeed/1000000,Speed)/1000000*100,RealSpeed) (which says divide InOctets * 8  by RealSpeed, unless RealSpeed is unknown - else use the original expression.) This assumes that the OID reports nothing if that bandwidth description is not set.

If there is no OID to get the 'real' bandwidth, you will be able to manually set a property on the instance level where you can define the real bandwidth, and then you could use the property in the expression.  Instance level properties are being developed right now, so should be released within 3 months.

Is there an update on this feature request? To reiterate the request, it is important to be able to specify a service speed which can be different than a physical interface speed. The physical interface speed being what is learned from the SNMP poll. Then of course, we need to be able to graph, trigger alerts, etc based on this service speed. If you want to be complete, you'll include both an In service speed and an Out service speed as these are sometimes different.

There are instance properties now, but no way I have found to easily define them.  My expectation is I could edit the instance and define properties as needed just like on a device.  Since in the cases where it matters the data MUST be manually defined (e.g., ASA with a gig-E interface hooked to a 50Mbps cable modem), this is a show stopper.

Mark

Yeah - that seems like a silly omission on our part - not being able to manually define ILPs in the UI.  Sorry about that - I'll get that fixed.

This is fairly standard functionality in a monitoring tool. Many WAN circuits will be delivered at a rate limited speed. As an example, a carrier circuit may be clocked at 100Mbps or 1Gbps while the service speed is limited to 10Mbps, 20Mbps or 50Mbps. Utilization reporting, alerting and forecasting should be tied to this service speed, not the interface clock rate.

Ive actually been working on this problem myself but with a bit of a hack. adding a special string to all "circuit" interface descriptions which also contains a parsable "speed". A new datasource then looks for interfaces across all snmp devices for interfaces with that "string" in the description. Once found that parsed speed is used as the reference speed instead of the interface speed on the new datasource.

This is how various FOSS tools (e.g., Observium, LibreNMS) do it and I have considered the same thing.  I have also considered structured device properties (e.g., intf.XXX.upspeed = 20000).  Either requires that I revise multiple similar datasources and diverge from LM standard DSes with any future LM updates requiring a manual merge on multiple portals, but there seems not to be much choice.

Regards,
Mark

With the last release, we finally added the ability to manually set instance level properties through the UI, which lets us solve this issue. 

There is a new version of the snmp64_If- datasource - this is available in the registry, but not yet in core.

Improvements in this datasource:

• Now we support setting instance level properties through the UI (from the Info Tab for any instance via the Manage icon on the custom properties table), we can solve setting custom speed for interfaces.

Setting an instance level property ActualSpeed and/or ActualSpeedUpstream (if different from downstream - if ActualSpeedUpstream is not set, and ActualSpeed is set, ActualSpeed will be used for both upstream and downstream) will override the Speed and BasicSpeed values, used for interface utilization calculation.
Another change - Speed and BasicSpeed are now set as discovered ILPs, rather than unchanging datapoints that were collected every collection cycle (minor efficiency gain).

• Backward compatible interface status filtering. 

LogicMonitor will by default alert when interfaces change status from up to down. This is helpful for alerts about switch ports that connect to servers or routers, or inter-switch links - but less useful if the ports connect to workstations, that you expect to shut off everyday.
In order to limit this behavior to a certain set of ports, you can now set the property interface_description_alert_enable. If a device has this property set, or if it inherits this property, it will only trigger status alerts for interfaces where the interface description matches the regular-expression contained in that property. All other active ports will be discovered and monitored, but not have their status changes (or flapping) alerted on. (If the property is not set, the current behavior of alerting on status changes for all interfaces is maintained.)

For example, setting the property interface_description_alert_enable to the value “core|uplink” on a group will cause all network devices in that group to alert for status changes only on interfaces with the words “core” or “uplink” in the interface descriptions.
All other interfaces will be monitored, but will not have status alerting enabled. (Other alerts, such as for excessive discards, will still be in effect.)

TO exclude all interfaces with the word bridge in the interface description, set the interface_description_alert_enable property to ^((?!bridge).)*$
(That's a regular expression negative lookahead...) All interfaces, except those with bridge in the description, will have status monitored as normal.

• change in the way the discard percentage is calculated, to not trigger until there are at least 50 discards per second, as well as the relevant percentage of drops. (This used to be 50 unicast packets per second, but that would still cause alerts on the standby interface of bonded interfaces.)

These changes are backward compatible, and do not lose any datapoint history.

This new datasource is accessible from the registry using the locator code: 

KYE6HN

Note: This datasource has not been through our final internal QA, but is believed reliable (we're running it internally!). It will be improved in a minor way shortly (a future server release will negate the need to collect interface descriptions as an instance level property), and released to core after that - but that change will be backward compatible, for those of you wishing to adopt this early.