custom speed for interfaces

This is very encouraging -- thank you for the update!  There is one remaining architectural issue to resolve -- there is no way to reference ILPs within alerts or other places where tokens can be used.  Is this something that will be included in the final version?  It would be helpful to show at least some of those values in related alerts.

One more observation on the interface description filtering behavior -- I have developed an API-based method to do the same thing and the one problem we run into is that AD will not update the description of an interface that is has operStatus != up at the time AD runs.  This means that if you want to exclude ports from alerting based on description and you change the description to stop LM from alerting, it will not matter if the interface is already down -- this defeats the purpose of avoiding alarms for unimportant interfaces, at least not without manual instance tuning.  I have played with removing the operStatus filter from AD, but the results were not good.  It really seems like there should be some datapoints that are can be updated regardless of the filter and others that update only when the filter applies.  Or more generally, datapoint groups within a datasource, each able to have a distinct filter.

The new DS should also have a default nonunicast threshold, though my challenge there is I care less about one DP with that happening (in most cases) that seeing it across multiple ports and/or multiple devices.

Thanks,
Mark

I opened a  ticket to allow ILPs to be used as tokens in alert messages - thanks for that.

What was wrong with removing the operStatus filter? We're actually thinking of removing that in another update, once we can group interfaces automatically based on status (so you wouldn't have to look in the down ones...

What non-unicast threshold would you want? As a percent of unicast, or ...?

Excellent on the token thing -- looking forward to that!

What I found when I removed the operStatus AD filter was that a bunch more interfaces reported alarm almost immediately.  I think my script to deactivate alerts would have eventually caught up, but it was super noisy so I quickly reverted.  I need to look at the new way as my method was a necessary evil given the tools available.  I did notice later, though, that failure to update the description for down interfaces made my script less useful than intended.

Nonunicast is a funny thing.  Acceptable levels tend to vary in different environments (I have seen Nexus 7K cores handle 50000pps without breaking a sweat -- not good, but not deadly to the switch), but there are levels that are absolutely bad in typical environments.  I normally do not set thresholds on percentage as this could trigger for ports with in otherwise inactive hosts seeing not much other than nonunicast traffic.  A rule of thumb is that for access ports, under 200pps can be safely ignored (though it is still high).  Trunk ports will tend to be higher as you will see combined levels for all VLANs on the trunk.  When we see "freak out" levels, they are in the 1000pps or higher range.  Translating to LM-speak, I would start with "> 200 1000 2000" (but again, hard to set just one good threshold).

I remember the days when 100 broadcast packets per second could hang a 486...

Nowadays my inclination would be to just set a warning on "> 1000".  Excess  non-unicast is still bad, but unlikely to be traffic impacting bad - and if it is, discards and other thresholds should trigger.

So that would allow investigation in the case of a legitimately problematic non-unicast level, but not generate alerts for situations that are not impacting things, and would otherwise be considered noise alerts. And we should add a "top 25" graph for inbound non-unicast traffic on all interfaces to our default network dashboard, for people that are inclined to investigate this more closely....

(On our infrastructure, we have 200 non-unicast pps on our busiest 10 G ethernet trunks....)

Seem reasonable?

I can live with a default of 1000 as it would definitely catch storms, which is the main goal.  We have settled (in our other tools) on 100-200pps as a default with higher levels for trunks.  We also try to watch for such things over extended periods, but average-over-time is a different FR I am awaiting action on :).

When I listed "> 200 1000 2000", was trying to keep to the "LM way" :).

Note: as of v100, Instance level properties now work as tokens in alert messages. Development tells me they did prior to v.100 - which I thought I tested, and found the didn't - but in any case they definitely work in v.100.

Excellent on the token thing -- looking forward to that!

What I found when I removed the operStatus AD filter was that a bunch more interfaces reported alarm almost immediately.  I think my script to deactivate alerts would have eventually caught up, but it was super noisy so I quickly reverted.  I need to look at the new way as my method was a necessary evil given the tools available.  I did notice later, though, that failure to update the description for down interfaces made my script less useful than intended.

Nonunicast is a funny thing.  Acceptable levels tend to vary in different environments (I have seen Nexus 7K cores handle 50000pps without breaking a sweat -- not good, but not deadly to the switch), but there are levels that are absolutely bad in typical environments.  I normally do not set thresholds on percentage as this could trigger for ports with in otherwise inactive hosts seeing not much other than nonunicast traffic.  A rule of thumb is that for access ports, under 200pps can be safely ignored (though it is still high).  Trunk ports will tend to be higher as you will see combined levels for all VLANs on the trunk.  When we see "freak out" levels, they are in the 1000pps or higher range.  Translating to LM-speak, I would start with "> 200 1000 2000" (but again, hard to set just one good threshold).

On 2/3/2018 at 6:19 PM, Steve Francis said:

Note: as of v100, Instance level properties now work as tokens in alert messages. Development tells me they did prior to v.100 - which I thought I tested, and found the didn't - but in any case they definitely work in v.100.

Thanks!  Is the format documented, or is it literally the name within the instance and it is just in scope for the datapoint instance at alert time?  How are clashes with device property names avoided, I guess is my real question...

On 04/01/2018 at 11:00 PM, Steve Francis said:

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

•  

Can you give some examples of what ActualSpeed should be set to? Is it bits? bytes?

Sorry - ActualSpeed and ActualSpeedUpstream should be set in Mbps.

Should've documented that.

I'm doing a POC with LM and this was one of the things that I was concerned about.  I'm still learning the system and I appreciate any help I can get with this.

I have a 25Mbps fiber connection in a Gig port so interface utiliaztion % was nearly useless.  On that port, I added a custom property called "ActualSpeed" with a value of 25.  Then I went in and added the datasource for snmp64_If from the LM repository. 

I let it ride over night but my utilization for that port still seems to be based on 1000Mbps, so am I missing another step?

Thanks!