DX NetOps

Hi,

I have touble to configure event acording to interface description.

I want to filter BAD LINK DETECTED alarms on access ports whitch has particular description.

There is three Attribute ID witch gives interface descriptions

ifAlias, Internal_If_Alias and X_ifAlias.

I want to generate events and alarms acording to interface despription.

For example:

If interface description contais sring "access" generade event 0x0010d11a.

I tried warious contitions and operators but events does not get generated.

I read Event Configuration User Guide but only found basic guidlines.

Perhaps someone has exaples of configuration how to generate alarms and events by Attribute IDs and text strings they contain?

Thanks,

Aurimas

Aurimus,

Can you try the operator as Regular expression and the value of right operand as just access?

Something that work is (you don't need the double quotes):

Hi Aurimas,

Bill Wollforth wrote an excellent tech tip on which attribute to use when dealing with interface descriptions. (see https://communities.ca.com/message/241804492#241804492)

What works best for us is using the actual attribute ID. It is an external one so performance-wise maybe not the best choice but it is only used during the event. (event variable may be better suited).

Hans

Thanks for answers, these were useful articles, but I still have no wanded rezult.

What should I write as string value if I want to filter interfaces by one or two words from longer descriptions.

And I what skould I write if I want to match interfaces without any desctiptions.

Can you be a bit more specific?

You could make a logical OR and match for each word independently or build a regular expression  to match on 2 words (or on something empty (^$ should work but I've got no experience with this particular example))

so for instance the regexp firstword.*secondword should word just fine if the order is fixed. Otherwise the example above with 2 lines will also work and perhaps be more clear when looking at it later...

You should understand that this kind of processing in the system is not recommended: evaluation of logic based on external attributes. It's really slowing down everything.You should be filtering out the interfaces for which you don't want notifications. The way that you are trying to do it, it's not the most effective way in terms of load on the system. I would do it another way: I would create a dynamic GC that is evaluated every 24 hours for all interfaces that have a certain description in the Internal_If_Alias attribute. Based on that GC, I would enable the monitoring of ports by trap. Set the attribute 'DisableTrapEvents (0x11cd0) to no only for those network interfaces. For all the others this would be set to Yes. This way I'm evaluating the attribute, but only once a day. You would have to use the action to re-read the name of the interfaces once a configuration change trap is received from the device. This way you ensure a close to live notification on change of description for the interfaces.

If you filter out the relevant interfaces and you don't do it every time a trap is received it's less load on the system.

Of course, there's always the possibility to have this behavior set at device level, by filtering out which traps are sent based on each interface. As long as the user is setting already the description for the interface (access) it could also set the sending/not sending of the traps for that specific interface that is configuring. This way you skip your configuration of Spectrum altogether: only relevant interfaces are sending traps to SPECTRUM.

I totally agree that one should avoid the use of external attributes where possible, but don't see a big performance hit in this example. I make the assumption that the bad link event rate is not that extreme. (Using event attribute 17 (I was not aware of this option) is of course preferred.)

However the attribute Internal_If_alias should not be used as it does not hold the actual interface description. (See doc http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec614054.aspx for detailed explanation) the X_ifalias is better but also not always accurate. For that reason we went with the external one and accept the penalty. (we change interface descriptions regularly)

As you point out correctly, there is more then one way to do this, using a global collection and tune your events based on that works just fine

In my example, “attribute 17” is in fact not an attribute, but the id of a Trap varbind that gives the value of the interface description that you want to parse.

You are right, I was thinking of X_ifAlias attribute. If you have more than 10.000 network interfaces, the way that you do it impacts the system. I was referring to exactly the same document that you presented here, use of action code 0x10411 to identify the reconfiguration of interfaces and update the X_ifAlias attribute.

If the values are retrieved with an additional varbind variable (I was not aware of that for the link up/down alerts), the way to do it is the one presented by VLefebure.

I tend to avoid doing changes that affect the entire way the system is processing a certain alarm. This way, whenever someone needs traps for ports with other description, you'll need to modify your event.I think the best way to do that is to filter all relevant ports and let the system work as designed.

Excellent argument. For me it was a tradeoff between having numerous collections which are updated periodically against an event configuration.

We have around 200k ports in the network. Updating the collections periodically gave me issues at the time. I was not aware of the action code needed to update the X_Ifalias at that time but I still believe I will run into performance issues.

Following is a bit of topic perhaps but assume there are 200k ports in the network and I want to identify them via the interface description (aka ifalias). Advise is to use the X_ifalias but for that, in order to keep that recent, the action code 0x10411 must be applied to each port periodically. At this moment, this requires a custom script (or restart spectrum periodically but nobody wants that).

Changing the event to use an external attribute only when the event occurs leads to different overhead. The amount of events/hr against the periodic update of all port models. I my environment a quick scan show around 50 events for the last hour over all the landscapes so 50 polls for the external attribute, so around 1200daily for 200.000 port models. If I update the X_ifalias daily or even weekly that would resp be 200.000 queries per day or 30.000 queries per day so tuning the event leads to much less overhead. However if the amount of events bursts the numbers may be against me...

I'm planning to automate some of this stuff. I'll let you know which one is better in my case. I'll test more than one scenario.

So basicaly you all say that I sould avoid using Event Configuration because it impacts system performance? ( and I still was not able to generate desired arerts regarding empty descriptions and and maching srings)

The best way is to create Global Colection of interfaces to periodicaly look for interfaces which has specific descriptions and turn of or enable specific alerts for them?

What I'm saying is that Event Configuration in correlation with External Attributes is not desirable. Event Configuration in conjunction with Event Procedure are the basis of the entire spectrum system. That and the models.

That how I would use it. It depends on the number of interfaces that you need to monitor. I have installations with more than 100.000 network interfaces. I cannot imagine querying the description on the interface every time a bad link trap is received from a device.

It is my opinion that the less you interfere with how the system is created, the less chances of messing things up you have. That and the fact that is faster to read an information from the memory rather than disk or network.

Whenever you'll perform an upgrade on the system, you'll always have to modify the CA provided events with the ones you created.

That makes sence.

One more question, then I was playing with events, I exidently modified some default (CA) events and dont know how to recover them to original state.

Is there some way to make them as they were?

Hi,

Customisation is stored in the ~/custom/ directory (which by the way is not overwriten when you upgrade Spectrum, fortunately !).

If you remove files from there, the system will fall back to the CA definition.

Cheers, v.

I sill have problem.

I have collected interfaces with desired descriptions to Global Collection. But cant turn of alarms for it.

I tried this configuration:

But still I get BAD LINK DETECTED alarms. Per haps there is another way?

If you want to turn off the alarm try setting (by policy):

     "AlarmOnLinkDownTrap" (0x11fc2) to "Never" (0)

     "AssertLinkDownAlarm" (0x12957 to "No"

My collection for this policy contains the condition:

     ...  AND (AlarmOnLinkDownTrap Equal To "Check Status" OR AssertLinkDownAlarm Equal To "Yes")

to find the interfaces, which are not modified.

Regards, Frank

Still no luck I still get BAD LINK DETECKTED alarms of interfaces from access interfaces global colection:

this is my configuration:

AlarmOnLinkDownTrap (0x11fc2) - set it to 0

Why 0x12957 and 0x12054 are TRUE?

I copied my configuration from monitoring passively the connected ports that I have. I saw after I sent the message that this was not what you needed. You need to disable alarms on traps altogether.

So how can I disable alarms on traps for specific Global colection?

You posted a screenshot from Policy Manager. I was under the impression that you know how to use it. that's the one you should use for setting a number of attributes for models that are members of a certain GC.