Orion Product Team blog

Why Can’t I Add my Nodes to Orion IP SLA Manager?

2010-03-18T21:30:00Z

We get the occasional support call from customers having trouble adding nodes to Orion IP SLA Manager. They try to add the node, they see the spinner spin for a while, then they get taken back to the main page. What gives? As it turns out, the root cause of this issue is simple: they haven’t installed Orion IP SLA Manager on their additional pollers. In other words, if you want to add an Orion node that is being monitored by an additional poller, Orion IP SLA Manager has to be installed on that poller too.

Now you’re going to ask, “How do I install IP SLA Manager on my additional pollers?” Fortunately, this answer is very simple as well. It’s the same installation package as Orion IP SLA Manager; you just install it on your additional poller. Lastly, there is no additional cost for this. In the past we charged a separate license for Orion modules on additional pollers; that is no longer the case. If you’ve purchased additional pollers, you can install any Orion module on that additional poller for free. Chris LaPoint wrote a detailed blog post on that back in January. You can read it here.

Keeping Nodes in Sync: NPM and NCM

2010-03-16T21:00:00Z

You know that to have nodes appear in the NCM integration module, the nodes need to exist in both NCM and NPM. So, if you add nodes and/or change node properties in Orion, you'd like to have those changes automatically propagated to NCM. However, what you might not know is that you can easily set up a job to help you with this task. In the NCM application, go to Schedule -> Create New Job -> then choose "Import Orion Database." Once you have this set up, everything will stay in sync without your needing to bring up the NCM application (unless you want to manage specific config properties on those nodes).

Eventually, we want to bring node management completely into the Orion website, but in the meantime, try this.

1. Choose the job and set it up according to your preferred schedule.

2. Select the database to be imported.

3. Map the columns. This allows you to sync nodes with custom properties as well.

4. Customize the rows. If for some reason, there are some devices you don't want synced, you'll de-select them here.

5. Choose how you want the job to run. If you choose "Add only new nodes," then that is *all* that will happen. Info for existing nodes won't get updated. If you uncheck that box, you'll get updates and new nodes when the job runs. If a node already exists, it won't be re-added, but keep in mind that that identification is done by IP address, so if you have nodes that tend to change IP address, duplicates could happen.

6. Click finish - and you're done!

A Series of Unfortunate Events: Using Orion’s Syslog Server to Monitor VMware Events

2010-03-12T17:10:00Z

In network management, events are bad news. At least the ones you care about are. You can spend your whole day sifting through various informational events, but most of the ones that need your attention are telling that something is wrong. Most network systems share their events through Syslog, and it’s generally understood that monitoring those Syslog streams is a best practice. Based on the conversations that our PM team has had with users of VMware, it’s much less widely known that you can monitor VMware events using Syslog. VMware host servers support sending their logs via Syslog, and Orion has a built-in Syslog Server, so it’s a plug-meet-socket situation.

VMware has some good docs (see also here) on how to configure Syslog on a VMware box. It’s pretty straightforward as these go, so I’ll assume that you can turn on Syslog and point it at your Orion server.

Once you are collecting Syslog from VMware, what do you do on Orion? Actually, you don’t have to do anything and the Syslog messages will still be collected and displayed in the Syslog View on the web console. Doing nothing is pretty lazy, though, and if you’re bothering to read this, you’re better than that. To get more value from that Syslog stream, you should create some Syslog rules that will trigger an email or some other notification for key events. To create a Syslog rule, go to the Orion server and launch the Syslog Viewer (Start > All Programs > SolarWinds Orion > Syslog and Traps > Syslog Viewer)

Select View > Alerts/Filter Rules… and you’ll see this:

Then click the “Add New Rule” button to see this:

You can get the complete steps for configuring Syslog Rules from the Admin Guide. The rule system is rich, so you can narrow down your alerts based on IP address ranges, hostname pattern, and message severity, which will allow you to get an alert on errors in hosts with one naming convention but not another. Most importantly, for VMware Events, you can create rules based on the content of the Syslog message. The engine scans the content of the message and checks it against the string or regular expression you type. For instance, if you want an email any time a VM is powered off, you can create a rule that triggers when a message with “*is powered off” appears. Similarly, to alert when a VM migrates from one host to another, alert on “*migration*.” Look through you Syslog messages to find the key phrases for your rules.

When the rule conditions are met, you can take any number of actions, including the usual send an email, but you can also do some Syslog-specific actions like tagging a Syslog, modifying the Syslog message, or forwarding the message on as a Syslog or converting it to an SNMP Trap.

What events should you alert on? Some of the more common cases we’ve seen are VM cloning, VM migrations (i.e., VMotion), taking snapshots, deleting a VM, and changing resource allocations. The exact set will depend on what matters to you. To create those alerts, just start collecting Syslog and then scan the logs for key messages. As you find ones that seem important, create a rule. You don’t need to do it all at once—you can create them over time until you’ve tuned the monitoring to fit your environment.

Easily adding double and triple gauges for Universal Device Pollers

2010-03-09T20:04:23Z

Technorati Tags: SolarWinds,Orion,Orion NPM,Universal Device Poller,SolarWinds Orion NPM

I ran across another cool post that a member of the thwack community put together that I wanted to share with everyone. lasher put together some new resources for Orion NPM v9.5.1 which allow you to create double and triple gauges within a resource for Universal Device Pollers. If you wanted to accomplish this today, you would need to use a custom html resource, so this makes life much quicker and easier.

So I can hear you saying, ok you had me at double and triple gauges, how do I get this?

First, you can download this resource here

To install:

Copy CustomOIDEditGaugeDoubleTriple.aspx and CustomOIDEditGaugeDoubleTriple.aspx.cs to InetPub\SolarWinds\Orion\NetPerfMon\Resources folder.
Copy CustomPollerRadialGaugeDoubleTriple.ascx and CustomPollerRadialGaugeDoubleTriple.ascx.cs to InetPub\SolarWinds\Orion\NetPerfMon\Resources\NodeGauges folder.
Copy CustomOIDEditLinearGaugeDoubleTriple.aspx and CustomOIDEditLinearGaugeDoubleTriple.aspx.cs to InetPub\SolarWinds\Orion\NetPerfMon\Resources folder.
Copy CustomPollerLinearGaugeDoubleTriple.ascx and CustomPollerLinearGaugeDoubleTriple.ascx.cs to InetPub\SolarWinds\Orion\NetPerfMon\Resources\NodeGauges folder.

As lasher states, there are 4 known issues with it.

Auto-Scale not working and has been disabled.
Auto-Hide Resource not working correctly and has been disabled.
Must set Warning & Error Threshold or Gauges will display red.
Gauge labels do not set correctly when first added to page. (Workaround is to edit the gauge and click submit. Labels will show up correctly after that.)

Community works! - A simpler way to manage Orion email alerts

2010-03-05T05:30:27Z

First of all, mad props to byrona for sharing this tip with the community. I know there’s a lot of you already using this simplified email alert management trick, but I wanted to make sure to spread the word just in case.

Here’s how it works. Instead of configuring static email addresses in the To: field of your Orion Advanced Alert notifications, use a variable (a.k.a macro). The value of this variable can be a custom property.

In byrona’s case, he wanted to have emails sent to the “Primary Contact” or owners of each of the nodes in the event of an issue, so he created a custom property called “Primary Contact” and entered this value for each of his nodes. Then, when setting up alerts, he used the ${Node.PrimaryContact} variable to specify the To: address.

Simple, right? But, you wonder as you lie awake at night, what happens if the Primary Contact hasn’t been filled in on some nodes? Does alerting die slowly? Well, as jainsworth verified, blank fields don’t break email alerts. The emails just don’t get sent out for those nodes. Sleep well.

If this gives you a few minutes back in your day and you want some community karma for yourself, please don’t be shy, share your tips and tricks with the community!

Technorati Tags: SolarWinds,Orion,alerts,email,macros,variables

Windows Credentials and Microsoft DHCP Servers in Orion IPAM

2010-03-02T22:23:40Z

We get many, many questions on thwack regarding Windows credentials for adding a Windows DHCP server to IPAM. There are few tips and tricks I will share that can make this process relatively painless. First, let me explain why you need to enter Windows credentials in IPAM. A Windows account is required to pull scopes from a Microsoft DHCP server. This account has to be a member of one of the three following groups on the DHCP server: local Administrators, DHCP Users, or DHCP Administrators. IPAM uses this account to log into the DHCP server and to pull scopes you want to manage.

Second tip: the DHCP server you’re adding to IPAM must already be defined as a node in Orion NPM. If you haven’t added the DHCP server as a node in Orion NPM, you won’t be able to add it to IPAM. When you’re adding a DHCP server to IPAM, it displays a list of devices to choose from, and this list is generated from your Orion nodes.

Third tip: use the Windows Credentials manager in IPAM if you’re working with more than one set of Windows credentials. Go to IPAM Settings>>Manage Windows credentials for scope scans, which will take you here:

Note the two sets of Windows credentials I’ve created: Windows 1 and Windows 2. Once created, these are available to you when adding a DHCP server in IPAM, as shown below.

Fourth tip: when in doubt, check out our Knowledge Base articles on this topic. You can find them here. These two articles have some great information on errors you may encounter and how to resolve them.

Different Views for Different Devices

2010-02-25T23:01:00Z

One of the most appealing things about Orion is the ability to drill-down from high-level info into details. You see something green or red on the screen, you click on it, you go to a view that has more details about the thing you clicked on. It’s powerful yet simple. That simplicity of interaction comes from a sophisticated object model. Users almost always start at a Summary view. Summary views typically show everything across the managed network—e.g., all nodes, or all applications, or all network interfaces. If you click on a node from a summary view, you go to Node Details view. That view will show lots of information about the node.

In most cases, for most devices, you will go to exactly the same Node Details view. It’ll show the same data in the same locations on the screen, just for the specific device you clicked. But it doesn’t have to be that way. You can, for many devices, create a distinct view. For instance, by default, wireless controllers have a different node details page because these devices include data that makes sense only for this device type (e.g., a list of “thin” access points).

The Orion construct we used to build the wireless view (and also the VMware ESX view) is Views by Device Type. We have a list of many common network devices that allow custom views; however, when we ship a new Orion, most of those views are set to the default view. You can use this same technique we used to build your own custom views for particular devices.

Here’s a default view:

Here’s a view for wireless controllers.

How do you set up views by device type? First, you need to create a custom view for a type of device. Go to Admin > Manage Views. From here you can add a completely new view or you can copy the existing Node Details view and then modify it.

There are lots of resources to choose from in building something custom.

Next, you go to Admin > Views by Device Type > Node, then click edit. You’ll then click the drop-down box and select the name of the custom view you created. You can repeat for each node type, if you want to get into serious customization.

Note that we have the same construct for different of network interfaces, so you can customize there, too.

Views by Device Type allows you to further customize your Orion web console. You might show different stats for Windows and Linux servers. Or you might use different Custom HTML or User Links resources for HP Switches vs.Cisco switches. Throw in a few universal device pollers, and you have a bunch of device-specific “dashboards”. It’s a powerful feature that isn’t used as often as it might be, so give it a spin.

Technorati Tags: Orion NPM,View,Node,Interface,Device Type,Views by Device Type

Audible Alerts in NPM - aka - Wow - I didn't know it could do that!

2010-02-24T21:23:00Z

Did you know that NPM offers audible alerts? It sure does - and they are super easy to set up. You may find yourself wondering - now why in the world would I need that? Well, you might find yourself work, work, working away and be completely oblivious when an alert appears in another window - or on another monitor. But, if you had sound - a customizable sound - then that would definitely help grab your attention. (When you think customizable sound - think any .wav file you like.) You might also worry that adding sound to alerts would really make a lot of racket in your workplace - no worries - we've solved that too.

Here's how you do it (from the admin guide):

Configuring Audible Web Alerts

When browsing the Orion Web Console, audible alerts can be sounded whenever new alerts are generated. When enabled, you will receive an audible alert the first time, after login, that an alert is displayed on the page. This alert may come from either an alert resource or the Alerts view. You will not receive audible alerts if the Alerts view or the alert resource you are viewing is empty.

Following the initial alert sound, you will receive an audible alert every time an alert is encountered that was triggered later than the latest alert that has already been viewed. For example, a user logs in and sees a group of alerts with trigger times ranging from 9:01AM to 9:25AM, and the user receives an audible alert. If the user browses to a new page or allows the current page to auto-refresh, a new alert sounds if and only if an alert triggered later than 9:25AM is then displayed.

To enable audible web alerts:

1. Log in to the Orion Web Console as an administrator.

2. Click Admin in the Views toolbar, and then click Account Manager in the Accounts grouping of the Orion Website Administration page.

3. Select the account you want to configure.

4. Click Edit.

5. Select the sound file you want to play when new alerts arrive from the Alert Sound list.

Note: By default, sounds are stored in the Sounds directory, located at C:\Inetpub\SolarWinds\NetPerfMon\Sounds. Sounds in .wav format that are added to this directory become available as soon as the Edit User Account page refreshes.

6. Click Submit.

And there you go. Sound!

CBQoS and NetFlow aren’t peanut butter and jelly for you?

2010-02-18T17:00:00Z

We believe that CBQoS and NetFlow go together like peanut butter and jelly, but several of you commented that it was frustrating that you had to enable NetFlow on the interface to drill down to see CBQoS data. Who are we to dictate how you like your CBQoS? Well, the good news is with Orion NTA 3.6 you can have it any way you like it.

If you’ve upgraded to NTA 3.6, you’ll notice there are now two LAST RECEIVED columns in the NetFlow Sources resource:

As long as one of the LAST RECEIVED columns has a date/time stamp, then drill down is enabled and you can navigate to the respective interface details views. You’ll notice that in the screen shot, Cur-3725 is not receiving NetFlow, but it is being polled for CBQoS data.

What if you don’t want to store all that CBQoS data in your database? Also new in 3.6, you can disable CBQoS data storage on specific interfaces. Navigate to NTA Settings and click Manually Manage NetFlow Sources. You’ll see a dialog like this where you can check the boxes for both NetFlow and CBQoS.

We’re busy working on further improvements to CBQoS polling, so stay tuned and keep the great feedback coming!

Technorati Tags: SolarWinds,Orion,NetFlow,CBQoS,NTA

I just got a tweet my network is down

2010-02-16T14:15:07Z

Technorati Tags: SolarWinds,SolarWinds Orion NPM,SolarWinds Orion,twitter,network alerts

As much as I wish I could take credit for this, I can’t. ljenkins figured this out and posted it to thwack a few months back, which the inner geek in me thought was pretty dang cool, so I wanted to blog about it.

Orion can send you an email or page when a network event occurs, but what about using twitter as a medium to distribute your network alerts and events? Obviously you would not want to expose this to the entire twitterverse (which according to urban dictionary is a real word), so you can set your privacy setting to only share tweets with those who you expressly give access to. In twitter go to Settings and in here there is a checkbox to protect my tweets, see below.

Here are the step by step instructions to get this to work with Orion.

1. Log on to your Orion NPM server using an account with software installation privileges.
2. Download and extract the version of the cURL utility that is appropriate for your Orion NPM server from the cURL website.
Note: For the purposes of this procedure, the cURL package curl-7.19.5 is extracted to C:\cURL\.
3. Click Start > All Programs > SolarWinds Orion > Alerting, Reporting, and Mapping > Advanced Alert Manager.
4. Click Configure Alerts.
5. If you want to use Twitter notification with a new alert, click New, and then create your new alert. For more information, see Creating and Managing Alerts in the SolarWinds Orion Network Performance Monitor Administrator Guide.
6. If you want to add Twitter notification to an existing alert, click the alert with which you want to use Twitter, and then click Edit.
7. Click the Trigger Actions tab.
8. Click Add New Action.
9. Click Execute an external program, and then click OK.
10. On the Execute Program tab, click Browse (...) next to the Program to execute field.
11. Locate and then select C:\cURL\curl.exe.
12. Add the following parameters to the selected program path:
-u username:password -d status="message"http://twitter.com/statuses/update.xml.
Note: The following is an example of a complete path with parameters and alert text specified:
C:\cURL\curl.exe -u UserName:Password -d status="ALERT! ${Caption} is ${Status}." http://twitter.com/statuses/update.xml.
13. Click OK on the Edit Execute Program Action... window, and then click OK on the Edit Alert window.
14. Click Done on the Manage Alerts window.

How Does Orion Mark a Node as Down?

2010-02-11T21:17:00Z

This is a very common question we get. What’s going on behind the scenes when a node goes into warning status, or when it’s actually down? Well, it all starts with a simple ping. Orion pings its nodes at regular intervals to determine the status of those nodes. When Orion gets a response, everything is cool and the node is green.

What happens when Orion doesn’t get a response? When that happens, we can’t immediately assume the node is down, as there are a number of other reasons why the node may not be responding other than it being down. In other words, we want to be really sure the node is down before we mark it as such. How do we do this?

First, on the initial missed ping we are going to put the node into warning status by marking it yellow. When the node goes into a warning status, Orion initiates what we call a fast polling cycle where it pings the node every 10 seconds to try and determine if it’s really down. If Orion doesn’t receive any responses during this cycle, it determines the node is officially down and marks it red.

There is one other piece to this, which is how Orion calculates a node’s availability over time. What’s the difference between status and availability? To keep it very simple, a node’s status is an indicator of what the node is doing now; a node’s availability is a measurement of that node’s status over time. Orion calculates availability in two possible ways: either by historical node status, or by packet loss percentage over time. We give you the option of specifying which calculation to use. This setting is under Admin>>Settings>>Polling Settings (screenshot below).

I won’t go into a great deal of detail about these two settings, as you can read about them in the Administration Guide here; however, there are a couple of worthwhile points to mention about them. First, Node Status is the simpler calculation. It’s very straightforward; it basically looks at up/down status over time and calculates availability based on that. This leads me to my second point: use the Node Status setting unless you specifically need to know node availability based on packet loss. The Percent Packet Loss calculation is more complicated; don’t bother with it unless you specifically know you need it.

Fear and Loathing of Roadmaps: Why your PM won’t give you a date

2010-02-10T12:20:00Z

If you’re an Orion customer, you’re probably also a geek, which means you spend a non-trivial amount of time thinking of ways to improve the world around you---even things (or people) you love. Since Orion is part of your world, you see ways to improve it. Never content to just innovate privately, you post to thwack to share your vision of what might be. That’s where Product Managers (PMs) come in. We read all of those posts and we try to respond. Sometimes we can’t say more than that the feature is on the roadmap. For us, it means that we’ve heard the request often enough that we fully intend to do the feature, but we may not have a particular release slotted in. Other times, we are actively working on the feature, which means it should be in the next release. In that case, we post it on thwack as “…what we’re working on…” . It’s not a promise because things get worked on and dropped, but it’s a pretty good bet.

To be fully up front, the other option is that you’ve just suggested a feature we’ve never heard before so it’s not on any roadmap. With those unique features, we may probe other customers to see if they’re also interested. Sometimes, the feature is just what they didn’t know they wanted. Other times, it’s like we just asked them if they might want a three-armed jacket: “Uh, that might be useful if I had that extra arm, but having just the regulation two arms, I probably wouldn’t use it myself.”

Now, once you’ve been told that a feature is on the roadmap or that we’re actively working on it, your inevitable next question is “Great! When do we get it?” That’s where the problems start. We mostly can’t tell you, and even in a few cases where we might be able to tell you, we won’t. Let me explain. Sometimes, we really can’t. In some cases, sharing information about a future date for a specific feature can impact how SolarWinds’ reports its revenue (because of a set of boring complicated accounting rules), which is a big deal for a publicly-traded company. Consequently, we have to be extremely conservative about what we say date-wise. Some customers point out that other companies do it, and maybe they do, but they’re probably not handling their earnings exactly the same way, and they’re bigger or have been public longer. In any case, we are following the advice of our financial auditors. I can tell you that we have spent quite a bit of time trying to achieve the maximum amount of transparency without crossing the line with our auditors.

Other times, we won’t reveal dates because it’s just a bad idea. We could tell you that your feature is planned, say, for two releases from now. We could even create a slide deck that showed your feature on a timeline. But we won’t do it. Every PM on our team has worked in traditional enterprise software companies. We have all created a set of roadmap slides and flown out to see a large customers and showed them a 2- or 3-year roadmap. We’ve made (or at least implied) promises about the future and how bright it will be when we deliver the features that the customer wants. We’ve also eaten those promises. Choked on them, really. We didn’t plan to be liars, but things happened. Things that are outside of PM’s control. And sometimes changing the roadmap is just the right thing to do. The reality is that software is a fast-moving and fluid business and that long-term promises always have a whiff of fiction about them.

In light of the slippery nature of software creation, we’ve had to decide how to communicate with our customers. One of the important values inside SolarWinds is our relationship with our customers. Consequently, we don’t want to lie to you. I wouldn’t like to promise a friend that I can definitely go to lunch on a particular Thursday a year from now because there’s just too many ways that I might be prevented from showing up. Next week, sure, but not next year. We won’t make promises we don’t know we can keep.

That’s why when you ask for a date, we evade or just refuse to provide one. Occasionally, a customer gets annoyed or frustrated. We know it’s unsatisfying, and we regret it, but we’d rather you be annoyed at us not giving you a date now than having you furious because we had to change plans. In the end, we want to be completely honest and as transparent as we possibly can be. Don’t let this post stop you from asking for dates. By all means, ask. If we can say “weeks, not months”, we’ll say something like that. Ask for what you want to know, and we promise we’ll tell you as much as we can.

NCM - Inventory Report Web Views... See More in Fewer Pages

2010-02-03T16:19:00Z

One of life's small frustrations now has an easy fix.

I exchanged emails with a customer who mentioned that it can be frustrating to page through pages and pages in the inventory report. If the view showed just a few more rows....it would be so much nicer as you could see much more on one screen.... but alas.... there's no setting for that.

Well, actually there is, but it's a bit roundabout. You can change this:

to this:

And... it's easy.

NCM Standalone:

Just go to your c:/inetpub/solarwindsncm directory and find the web.config file. Find the line <add key="InventoryPageSize" value="20" /> and change it to something bigger – say 200 (or whatever you desire). Save it and voila – you’ll have a lot longer page view.

NCM Integration Module:

Go to the Orion web.config file and add the line:

In the AppSettings section in Orions web.config file

Example:

</appSettings>

Save it and you are done. Feel free to experiment with the line length until you get the report view just right.

Using a weather map as your background for your maps

2010-02-02T11:54:51Z

Technorati Tags: SolarWinds,SolarWinds Orion NPM,SolarWinds Orion,Network Atlas,Cisco Live,Cisco,Weather Map

So I am sitting here in our European office trying to decide what to write on. I was catching up on my thwack posts since I was in Barcelona last week for Cisco Live (aka Networkers) and have seen some discussions on thwack recently from some of you and I keep hearing about the Weather Map like we have on the online demo. Hmmm seems like a great idea for a post!!

I am going to describe this setup using 9.5 and above.

1. Using Network Atlas, create a new map and click on Linked Background in the top ribbon bar and you will receive a dialog to specify the URL to the weather map image you wish to use.

2. Enter the url and click validate to ensure we can retrieve the image ok from the Orion server and once the validation is successful, click ok. In this case below I specified Europe since this is where I am currently at, as you can see, it is freaking cold here.

3. Drag onto the map your nodes or other maps you want to have on this image and save the map.

4. You can edit your map resource on the Summary Home page to show this map.

Now your map on you Network Summary home page will always show the current weather based on when the page refreshed.

Orion IP SLA Manager - Get More Granularity With Your Operations

2010-01-29T18:39:00Z

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.