Orion’s Advanced Alert Engine is a powerful way to set up alerts on possible events in your network.  A big part of what makes it so powerful is the ability to create a wide variety of logical statements via the user interface.  So if you want an alert when a node goes down, but not if that node is named Stan, Kyle, or Cartman, then you can set up a trigger condition that will evaluate each down node and if it matches your conditions, the alert is fired.  If not, then it lets the event pass without a remark. 

What’s happening on the back end of the advanced alert engine is that it’s running a SQL Query.  The trigger condition that you create is actually generating that SQL Query.  The alert engine then executes that query every X minutes, and if it evaluates to true, it fires.

One thing that sometimes trips up users is the way the trigger conditions are constructed.  Each trigger has at least one Condition Group.  The Condition Group is a set of statements that are evaluated together.  Each Condition Group has one of the following logical operators that define how the different statements are treated:  All, Any, None, and Not All.

All and Any are fairly straightforward.  All roughly means “AND”.  If I say,

Trigger if all of the following are true:

Node is Down

Node Name is Kenny

then the whole statement is true only when a node named Kenny is in a Down state. 

Any roughly means “OR”.  If I say

Trigger if any of the following are true:

Node is Down

Node is Warning

then the whole statement is true if a node is in a Down or Warning state.  My recommendation to users is that you stick to All and Any.  They are simple, and I can’t think of a logical statement that you cannot accomplish using all or any.

What about None or Not All?  What do they mean, and why did you include them if you don’t think we should use them?  Well, second part first.  We included them because the control that the advanced alert engine uses to turn your statements into SQL Queries is something we license, and it came with all four logical operators, even though we only wanted two of them. 

What do they mean?  None is roughly the same as saying “not any” or “not a single one”.  If you have a series of statements where None is the operator then the engine will look at each statement under it and if any of those individual statements is true, it will construe the whole Condition Group as false.

Trigger if none of the following are true:

Node is Up

Node Name is Chef

This alert will trigger when node is in any state other than up, unless the node is named Chef.  Note that you could just as easily create an alert with an all that accomplishes the same thing:  Node is not Up and Node Name is not Chef. 

Finally, Not All is roughly the same as saying “at least one is false”.

Trigger if not all of the following are true:

Node is Up

Node Name is Chef

With the logical operator changed, this alert will now trigger any time a node is in any state other than up, but it will also trigger if the node name is anything other than Chef, which would make this alert pretty much useless.

There’s a more formal and detailed explanation in the Orion Admin Guide called Understanding Condition Groups.  My advice is stick to All and Any.  Every time I’ve seen anyone try to use None or Not All, they get unexpected results and end up more frustrated than satisfied.   

Denny

“What happened to VoIP?”  This is one of the first questions people have asked about the new Orion module, IP SLA Manager.  The answer is nothing has happened to the old VoIP module; we just made it better.  Before I elaborate, let me take a few steps back.

Cisco has this really cool technology called IP SLA which enables you, the network engineer, to run a series of tests that can help you assess the health of your network from the perspectives of each of your remote sites.  Why is this important?  You may know everything is fine between you and your office in New York, and you may know everything is also fine between you and your office in San Francisco, but what about connectivity between San Francisco and New York?  This is where IP SLA can help.

These tests are actually called ‘operations’ in IP SLA lingo. For example, if you wanted to check call paths between your VoIP call managers, you would create a VoIP UDP Jitter operation, specifying one device as the source and the other as a target.  Once you’ve created the operation, you can start collecting call path metrics between those devices.  This and other similar use cases are what drove us to release the VoIP module for Orion.

As it turns out, IP SLA supports many operations other than just VoIP, things like measuring the round trip time to access a web page (HTTP), or measuring the time it takes to request and receive a reply from a DNS Server (DNS), or measuring the response times between IP SLA nodes (UDP Echo).  Many of you VoIP customers asked us to support these operations as well, and we have kindly obliged. We took the VoIP module, added support for these IP SLA operations (in addition to several others), and renamed the module ‘IP SLA Manager.’

Some of you are asking, 'I've already been creating IP SLA operations on my routers… what's so great about IP SLA Manager?"  The answer to this is ease of use.  If you've been manually creating operations using CLI, you will appreciate IP SLA Manager's easy to use web interface for creating IP SLA operations.  A wizard will walk you through the process, and, once operations have been created, Orion will start tracking historical data on these operations.

If you’d like to learn more about IP SLA, our Head Geek has a great video here.  We’ve also written a white paper on the ‘Basics of IP SLA,’ which you can find here.  Lastly, you can try out IP SLA Manager for free; you can download it here.

One of the questions I regularly answer on thwack is which NCM component to install where and how to enable integration of NCM with NPM.   Specifically, where to install the 2 different executables included in the NCM download.  

To help clarify deployment, here’s a quick overview:

• NCM “Server” executable – installs the NCM server, client application, and standalone website.   These components can be installed on the same server you installed NPM or on a completely separate server.  PLEASE NOTE: Installing this executable on the same server as NPM does NOT automatically enable integration with NCM.  You still need to install the NCM integration module described below.
• “NPM integration” executable – installs the NCM integration module on your Orion NPM website.  This component must be installed locally on your Orion NPM server.  After installation and configuration wizard has finished, you will see a Network Configuration Manager link show up in your Orion NPM website.   

One last tip: When upgrading from previous versions of NCM, don’t forget to also upgrade your NCM integration module at the same time.  Otherwise, you won’t see any of the cool new features!    For example, the NCM 5.5.1 integration module now allows you upload and download configs, execute scripts, and run inventory and compliance reports directly from your Orion NPM 9.5 website! 

This is the first
post of a new effort here at SolarWinds.  We are kicking off an Orion product team blog.  Why would we do
this?  The product team already monitors thwack, our community forum, and
responds to user comments and questions many times every day.  So, you
might ask, what else could we possibly have to say?  Lots, actually.

With thwack,
we're reacting to users, and we're committed to continuing that ongoing
conversation.  With this blog, our desire is provide a proactive channel
where we can talk to users about Orion.   In this blog, we're going
to assume that the reader owns and uses Orion and its modules.  That
assumption gives us the freedom to talk about nitty gritty details of the
product and its features.  Prospective customers are welcome to read and may
benefit from doing so, but our goal is to provide a service to existing
customers.  In fact, in a future release of Orion, we intend to make the
blog available right in the product in order to make the content as readily
accessible as possible for all customers.

What are we
trying to accomplish? 

1. First and foremost, we want to provide
   some content that might fall in the "tips and tricks" category.  We talk
   to and hear from so many customers who have done really interesting things with
   Orion, and we want share some of their creativity more widely.  We also
   talk to new customers who like Orion and suspect (correctly, more often than
   not) that they are only getting a fraction of the value of the product. The
   Orion family strives to be easy, yet powerful, which means that the "meat and
   potatoes" of the product can be accessed without much effort, but over time,
   ever more power reveals itself.    We want to accelerate that
   revelation process.  
2. The other thing we expect to do is talk
   about features-new and old-and the rationale behind them.  Product
   Management and Engineering work closely on the design of each feature,
   including end user feedback as much as possible.  In the end, we spend a
   lot of time on the features, and we care about the
   details.   And since you're the consumer of these features, we figure
   you all care about them, too, and will be interested as well.  We know our
   spouses aren't.  We've tried talking to them, and frankly, we're tired of
   the eye-rolling when we try to tell them excitedly about the new, cool thing we
   just released.   So, we'll tell you about the features instead. 
   We'll explain what we were trying to accomplish, why we made the design
   decisions we made, and all the inside dirt.

We encourage
comments and we'll respond.  It's just another channel for our ongoing
dialog about Orion.  Please add this blog to your RSS Reader or set up
email notifications if you're interested in this content. 

Often, when we make a simple configuration change on our Cisco ASAs, we get the following change notification email:

BEFORE		AFTER
Today    4/30/2009 9:32:32 AM		ADDS 4, DELETES 4, CHANGES 0
		<— More —>
	<— More —>
		<— More —>
	<— More —>

( I assume this pasted ok )

This one only has a couple of "more" items, but some notifications have a dozens or more.  Very unuseful information.  Are others with ASA experiencing this?

ASA 8.0(4)28 and NCM 5.1.1

Orion 9.5 SP4

NetFlow Traffic Analyzer 3.5 SP2

(and Network Configuration Manager 5.5.1)

running on a virtual Windows Server 2003 R2 SP2 server.

I'm getting the error "NetFlow Service service hung on starting" on bootup. However the service does start a minute of two later (its set to automatically restart on error).

It looks like its trying to start to soon (for example before the Network Connections service starts, which seems foolish for something that looks at network traffic!).

I've noticed a couple of other posts on this subject but they didn't have answers that worked for me

Any thoughts?

Thanks

Andrew

After taking a bit of time with the traps that my Orion system is receiving I finally figured out what seemed to be missing, the traps don't have any explanations associated with them.

In the previous NMS systmes that I have worked with including the free ones, the traps had explanations as that information is stored in the MIB and therefore should be made available.

I am curious why Orion doesn't make this information available on their traps, it makes some of them almost impossible to understand unless I am just missing something.

Here is an example pretty much the same trap on two different systems…

ORION

snmpTrapEnterprise = CISCO-HSRP-MIB:cHsrpMIBNotificationPrefix
experimental.1057.1 = 10.10.10.10
cHsrpGrpStandbyState.11.106 = 5
snmpTrapOID = CISCO-HSRP-MIB:cHsrpStateChange
sysUpTime = 2158108441

OpenNMS

Cisco Event: HSRP State Change.

cHsrpGrpStandbyState    1      initial(1) learn(2) listen(3) speak(4) standby(5) active(6)

As you can see I get much better information with OpenNMS.  Without the additional information the "cHsrpGrpStandbyState" number would mean nothing.  Is there some way to make this information from the MIB available in Orion as well?

Hi all…

I have performance problems on my Orion pollers, so I am trying to share the load.  I now have an SLX engine, with 4 additional SLX pollers and I have an additional web server installed to a separate server.  I have NCM installed on the main poller, so I think I should move it off of this poller, and stick it somewhere else.  I think the obvious choice is the additional web server, as it is not too busy.

Do you see any problems with this?  I have installed the NCM/NPM integration module, so will this cause a problem when moving NCM? 

Any assistance would be much appreciated

Cheers

dan

Webcast: Network Troubleshooting Part 2- TODAY!

Click here to register for Part 2.  If you missed Part 1, click here.  Join us after the webcast when Josh will continue to answer your questions including any he does not have time for on the Webinar!

What's Hot?

SolarWinds has added a new page that keeps you on the cutting edge of what is hot in the way of products, community activity and free tools.  Check it out!

Does anyone have SNMPv3 running with Cirrus?  I'm trying to add my first Cirrus node in that is using v3 and I'm having some trouble.  I have the same exact settings in Cirrus as I do in Orion, but for some reason, Cirrus cannot poll the device.  In Orion (which is on the same server), I have no context configured, but in Cirrus, it seems that I need a context, or I get an authorization failure when attempting to validate the SNMP credentials.  However, with the context in, the SNMP validation passes, but no information is populated, such as the System OID and name.  My SNMPv3 view on the router is configured to allow this particular user (the same user that is configured in Orion) to view the entire 1.3 tree.  Here's my settings in Cirrus:

SNMP Version:  3
Context:  context1
Username:  noc
Auth Type:  SHA1
Auth Password:  <auth_pass>
Encryption Type:  AES128
Encryption Password:  <encryption_pass>

Is there something I'm missing?

One thing I have noticed in the Netflow Database Maintenance is the option to Delete expired flow data.  It is set to process 1000 IPs at a time and run for a Max of 15 minutes.  I have a large number of expired IP's (2301751).  So, the 1000 it processs per day, doesn't even touch it.  What should it be set to?  I would think I would want to have a low number of expired IP's, but unless I manually run the DB maintenance all the time, the number of IP's grows rather large.

I am having problem getting my Cisco 7960G to connect to my GXE5028. My X-lite softphone works fine. I have all the name, password and extension setup in GXE to be the same (ex: all set to: 6001).  I am using SIP firmware P0S3-07-5-00 on the 7960. Please help.

I would like to include recent syslog and events in my email events that are sent.  For instance, when cpu utilization is high, I would like to see the last 10 syslog messages from that server in the email that is sent. Here is my logic:

Node Information:  

Node: ${Node.Caption}
IP Address:  ${Node.IP_Address}
Node Type:  ${Node.MachineType}

Memory Utilization:  ${Node.PercentMemoryUsed}
Response Time:  ${Node.ResponseTime}

Alert Infromation
Alert Trigger time: ${AlertTriggerTime}
Count:  ${AlertTriggerCount}
Acknowledged:  ${Acknowledged}
Acknowledged By:  ${AcknowledgedBy}
acknowledged On:  ${AcknowledgedTime}

Recent logs: 

${SQL:Select Top 25 * From SysLog where IP = '${Node.IP_Address}' and (DATETIME > (GETDATE()   - 7)) }

This does not seem to work, is anyone doing this? 

Hello

     I'm running Orion 9.1 SP3.  I'm monitoring ~200 Cisco routers.  I'm trying to figure out if there's a way I can get a report which will show me where daily traffic flows are growing among those routers.  Overall traffic flow incoming from our ISP recently grew suddenly a bit and I want to see if that appears to be from a particular site(s) with increasing traffic or if it's just an effect of traffic growing among all our sites overall.

    At first thought this seems like an obvious kind of question to ask from Orion and all it's gathered data.  However, as I start looking at the canned reports and also at the custom report writer, it seems to me there is no straightforward way to try and put something like that together, if at all.

     Either that or I am completely blowing it for due dilligence.  Which I won't swear to never suffering from :)  Thank you for any advice or pointers anyone has time to give!

-John