custom speed for interfaces

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

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 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.

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.

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.

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

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.

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.

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