Skip navigation

What's an Operation?

When building Orion IP SLA Manager 3.1, we implemented a couple of highly requested features around operation creation and configuration.  First, let me address what I mean by 'operation.'  This term has caused a little confusion, as it's used interchangeably with a few others.  Some people refer to them as probes, others as tests, but they're all synonymous.  Regardless of the term used, when we say operation, we mean the synthetic traffic generated from one Cisco IP SLA enabled device to another, usually measuring round trip time from source to target and back.  Each operation type does different things depending on the operation, but that's the general idea. 

 

What's are Source IPs and External Targets?

When creating an IP SLA operation on a device, you're looking for information on a specific network path; however, different interfaces on a device may go to different places, so specifying the IP for the operation is important.  Using Orion's default IP for the operation may not give you the data you need.  Many of you spoke up and indicated you needed to be able to specify a different IP or interface than the Orion default, so we added this functionality in 3.1.  Now, what about external targets?  You may be concerned about network quality between one of your remote sites and a website that you don't own, like SalesForce.com.  In this example, SalesForce.com would be the external target.  In IP SLA Manager 3.0 you could only specify an Orion node as a target for an IP SLA operation; however, we added the ability to specify an external target (like SalesForce.com) in3.1.

 

How Can I Specify Source IPs and External Targets?

I'm calling these out specifically because they're a little hard to find if you don't know where to look.  The first is the ability to specify the source IP for an operation.  Check out the screenshots below.

Here you see the final step in the operation creation wizard.  To specify a source IP other than the Orion default, select the operation then click Edit.

This will open the Edit dialogue.  Expanding the Advanced options will show you the field where you can specify the source IP for that operation.

The next feature I'd like to show you is the ability to specify external targets for certain operations (those where it is not implied that the operation will be bidirectional, like TCP Connect).  Let's say you would like to create a TCP Connect operation between a device on your WAN and an external website like SalesForce.com.  First, when creating the operation in the wizard, you need to select the Custom path type, as shown below.

Next, after selecting the node(s) you'd like to use as the source for the operation, select 'Yes, use one more external nodes as a target.'  Selecting this option will open a field that allows you to specify the hostname or IP of the external target, as shown below.

The last step is to specify the source(s) and target(s) for the operation.  In this case there is only one source and target to choose from, but we give you the ability to create more than one at a time through the wizard.

We have recently received requests to be able to specify the target IP or interface, which you can't currently do in IP SLA Manager.  We will be adding this functionality in a future release.

We’ve seen a lot of questions regarding how Orion modules and additional polling engines work so we wanted to quickly clarify what to buy and how to install additional pollers with the latest module versions.  

How it worked in the past:

In the past, to extend the scalability of your main Orion Server, you would purchase an NPM Additional Polling Engine.   Then, for each module installed on your main Orion Server, you had to purchase a module additional polling engine which you would install on each of your NPM Additional Polling Engines.   The module additional polling engine was a separate installer and was separately licensed.

How it works now: 

We decided that charging and licensing each module additional poller was too complicated and potentially expensive for customers, so we decided to make the module piece of the polling engine free.  That's right--free.  We've been changing the licensing since this summer.  It's now been removed from APM (3.0 or later), IPSLA (3.0 or later), and now NTA (with 3.6).

Now, when you buy the NPM Additional Polling Engine, you never have to buy anything more for the additional poller, no matter how many modules you buy.  However, even though you don't have to buy module additional pollers, you still have to install them.  For example, the NPM polling engine won't know about APM until you install the APM bits.  Where are those bits?  They're in your APM 3.1 installer.  Run the same APM 3.1 installer on an NPM additional poller and it will automatically recognize what it is and install the right parts.  Same for NTA 3.6 and IPSLA 3.0 or later. 

What if you already paid for it?  It's still good news because it means we won't charge you for maintenance, and when your network grows and you add pollers, you won't have to buy the module bits separately. 

 

 



If you're like most of us, you have better things to do than go through your nightly config backup report looking for the devices that have changes.

In fact, this has been brought up numerous times on thwack - Config change report with ONLY changed configs.

The good news is  - there's a super easy way to solve the problem. Just select "Send config change details in a separate email" and you'll receive the whole job report as one email, and just the things that changed in a separate email.  This option has been available in NCM since v5.5, but it's easy to miss so we wanted to bring it to your attention. 

 

Last week, the Head Geek and I did a webinar on Orion NPM product training.  Once of the common things that kept coming up was questions regarding database maintenance.  What is it?  How do I know if it is working right?  How do I customize it?  So I figured what better place to expand on this topic than the Orion product blog.

 

First off, what is it?

 

The formal definition:    
Database maintenance performs a series of data summarizations that help you optimize the size of your Orion database. Data summarization consists of gathering all the collected network data for a defined period of time, calculating statistics from the data, and then discarding the data itself while retaining the statistics. In addition to data summarizations, it also cleans up data related to deleted items in the database, saving additional space.  Orion automatically runs database maintenance every night keep your database compact and performing well.

 

What does this mean?    
Within Orion there are tons of dials and knobs you can turn to tweak your installation of Orion including how long we keep data for before purging and how we summarize data.

 

For example, in the Admin section of the web console if you are on NPM 9.5 you can go to Polling Settings and under Database Setting you can find some of these items including when the scheduled nightly database maintenance job will run (default is 2:15am).

 

DB Maint

 

This brings up a question around what exactly does data summarization mean and how does it affect Orion? There are three retention options to discuss.

 
      
  • Detailed Statistics Retention    
    All statistics in the Orion database collected at any frequency shorter than 1/hour are summarized into hourly statistics after the period of time designated as the Detailed Statistics Retention period. By default, this period is 7 days.
  •    
  • Hourly Statistics Retention    
    All statistics in the Orion database that are recorded at any frequency shorter than 1/day but longer than 1/hour are summarized into daily statistics after the period of time designated as the Hourly Statistics Retention period. By default, this period is 30 days.
  •    
  • Daily Statistics Retention    
    All statistics in the Orion database older than the Daily Statistics Retention period are deleted. By default, this period is 365 days.
 

With the default settings, reports covering the last week will have detailed data. Reports covering the last month will have hourly data. You can run reports with daily data covering up to the last year. Beyond a year there is no data.

 

How do if I know if the job is running correctly each night?

 

On the Orion server if you navigate to the installed directory, mine is C:\Program Files\SolarWinds\Orion, you will find a set of files in there named swdebugMaintenance.log and 5 more with a .number extension on the end.  Open this up and you will see what the job did, how long it took to run and if there were any errors.  If you don’t see at the end that the  maintenance has completed, if there are any errors or if it is taking a very long time to complete, you may want to further investigate to see if something is wrong.

Gaining Direct Access to the Orion Console from EOC without a Login Screen

 

Orion Enterprise Operations Console provides a console for aggregating data from multiple Orion servers. For instance, an EOC Top 10 lists includes nodes from different Orion servers into a single list.

 

clip_image002

 

When the user clicks on one of those nodes, EOC launches the Node Details page for the target Orion…except for the first time you access that Orion web console is a given session. The first time you access a target Orion, the user is asked for login credentials for that Orion, which some users find really annoying.

 

clip_image004

 

Why do we do ask for it? We do it for security reasons. We assume that most users would not want credentials being passed in the open. And while that may be true, after we shipped EOC 1.0, many users told us that within their firewall, this kind of security “violation” was really no violation at all. Please, they asked, could you just provide an auto-login feature so that users would never be asked for Orion credentials.

 

In EOC 1.1, we did just this. If you go to EOC > Settings > Admin > Web Console Settings, you will see a screen that asks if you want to “Allow Orion auto-login”. It’s still off by default, but flip that switch, and auto-login is activated.

 

clip_image006

 

Unfortunately, I have had quite a few users of EOC 1.1 who complained to me or to Support that they wanted this feature. When I told them that it was already implemented, they were surprised. As a product team, we were a little disappointed because a feature the users can’t find is like no feature at all. Still, rather than cry in our beer, we made a small change in EOC 1.2 to make it easier to find. We moved the setting from Web Console settings to Manage Orion Servers, a section that every EOC user visits at some point.

 

clip_image008

 

You may be asking, what is this EOC 1.2? Is it GA yet? No, but we have just released the EOC 1.2 Release Candidate (RC), which will be in your Customer Portal if you are current on maintenance. Once we get some feedback on the RC, General Availability won’t be far behind.

NCM currently supports 2 config types per device: running and startup.  However, you can backup many more things by using these config types as containers for storing other information (e.g., show commands, different firewall context configs, etc.). In this simple example, I’ll walk you through how you can quickly backup the results of the ‘show vlan’ command in either the startup or running config container of a duplicate device.  

First, manually select the existing template for the original device

You’ll need to manually assign the device template for the original device so NCM won’t try to use the modified version we’ll create later.

1. Right-click on the device and select Edit Selected Node.

2. Scroll down to the Communication Section and change the Device Command Template from "Auto Determine" to the appropriate template for your device type (e.g., Cisco IOS for a Cisco 3750)

image 

Second, create a copy of your original device

By creating a copy of your original device, you can use the duplicate device’s startup and running config containers to store other information while leaving the original device for storing proper startup and running configs.

1. Select Nodes > Add New Node

2. Choose a name that will allow you to distinguish the device from the original (e.g., Cisco-Aus-3725-VLAN-Bkup)

3. When prompted to add the network device again, click Yes

image 

Next, create a device template for storing ‘show vlan’ data

We’ll take the original template used for the device, create a copy, and modify it to execute ‘show vlan’ instead of ‘show running’ and store the results in the Running config container. 

1. Open Windows Explorer and navigate to your device template directory:  <install dir>\SolarWinds\Configuration Management\DeviceTypes

2. Copy the original template used for that device and rename it as appropriate (e.g. Cisco IOS Show VLAN-1.3.6.1.4.1.9.ConfigMgmt-Commands
        e.g. ‘Cisco IOS-1.3.6.1.4.1.9.ConfigMgmt-Commands’ to ‘Cisco IOS Show VLAN-1.3.6.1.4.1.9.ConfigMgmt-Commands’

3. Open the file in a text editor and change the name inside it as well:
        e.g. Device="Cisco IOS Show VLAN" to Device="Cisco IOS Show VLAN"

4. Change the Running Config command variable to back up results of ‘show vlan’ instead of ‘show running’:
        e.g. <Command Name="Running" Value="running"/> to <Command Name="Running" Value="vlan"/>

 

Finally, assign the new device template to your secondary (duplicate) device

1. Restart the NCM desktop application

2. Right-click on the duplicate device and select Edit Selected Node

3. Change the Device Command Template from "Auto Determine" to the modified template

image 
4. Right-click on the duplicate device and select Download Configs to test

image

Now when scheduled config backups occur, you will have a backup of the results of ‘show vlan' as well as the startup and running configs.  Remember, we only used the Running config container for the duplicate device.   This means you can still use the Startup config container for some other show command.

We’re working on providing out of the box support for multiple config types per device, but in the interim, we’re hoping you find this workaround useful!

macnugetz

Using Alert Variables

Posted by macnugetz Jan 7, 2010

Strangely enough, alert variables are one of the more straightforward features to configure in Orion's alerting engines.  Although they may seem a little confusing at first, they're really just a way to include relevant information in the messages that are sent when an alert is triggered or reset.  That's it.  These messages could be one of a number of things, like messages sent to the event log, or an email that's triggered when the alert fires.  That said, let's walk through the steps of configuring variables in an alert message.

When creating alerts in the Alert Manager, you can specify variables on the 'Trigger Actions' tab.

Here you can see we have two messages that will trigger when the alert fires: one to the event log, and an email.  Let's take a look at the event log message.

Here, we have specified the contents of the message to be written to the event log using two variables: ${NodeName} and ${Status}.  When the proper trigger conditions are met, an alert will fire that will write a message to the event log, and the message will tell us which node is affected as well as the status of the node. You can also specify variables in the same way when configuring an email to be sent when the alert triggers.

I'd also like to share a hint.  Not all of the variables available to you are displayed in the variable list in the Alert Manager.  For a complete list of variables, check out the appended Administration Guide which is posted here.

 

Since we released NPM 9.5 I have seen a couple posts on thwack and had multiple users ask me, “Those new hover over pop ups over nodes and interfaces are awesome, but….can I customize them?” The answer is yes you can, however, this is at a global level and there are only certain variables which can be added to the tooltips and they currently only apply to the hover over on maps. Here is what variables are available and how to apply them.

 

1. Log into the Orion Web Console

 

2. On the Home page select “Edit” on the Network Map Resource

 

3. At the bottom of the page click on “Customize Map Tooltips”

 

4. Enter the appropriate variables from the link above

 

clip_image001

 

5. Click submit and hover over your favorite node, interface or volume on a map and you should see that variable now available

Filter Blog

By date: By tag: