Skip navigation

Many of you have some type of Voice Over IP (VoIP) deployment, which begs the need to monitor your VoIP sites, Call Managers, and other information that helps you manage your VoIP network.  The old Orion VoIP module provided these features, and Orion IP SLA Manager still does today.  As I mentioned in a previous post, we took the VoIP module, added a bunch of features around IP SLA, and renamed it IP SLA Manager.  We did this because VoIP is just a subset of all the cool things you can do with Cisco's IP SLA technology, and it just didn't make sense to call the module 'VoIP' anymore.

This becomes clearer when you take a closer look at IP SLA.  IP SLA is part of the Cisco IOS, so the devices in your network most likely already support it.  This is an important point: you don't need any additional hardware investment to utilize the benefits of IP SLA. When IP SLA is enabled on a device, it acts as a responder that helps measure data across your network.  This is another important point: because your remote devices can act as responders, you can use IP SLA to monitor the health of your network from the perspective of your remote sites, not just from the perspective of where your Orion or network management system sits.

Let's take a simple use case as an example.  Let's say your headquarters are nestled in the beautiful hills of Austin, TX, and you have a remote office in Seattle, both of which connect to SalesForce.com.  Connectivity to SalesForce.com is critical for both your Austin and Seattle offices because your sales reps can't close deals as quickly without it.  From the perspective of headquarters your connectivity to SalesForce.com is just fine, but you're getting complaints from your reps in Seattle that they're having trouble getting to the site.  With IP SLA you can test the connectivity between your Seattle office and SalesForce.com by creating an HTTP test that originates from your Seattle site, even though your Orion sits on a server in Austin.  This is the beauty of IP SLA.

Let's take this example a step further.  Without Orion IP SLA Manager, you would need to telnet into your Seattle device, and manually configure the HTTP test (we also call it an 'operation') through a command line interface (CLI).  If you're not familiar with the CLI syntax necessary to do this configuration, then you're stuck.  This is where Orion IP SLA Manager can help.  The arduous process of logging into the device, and using cryptic commands to create and configure the operation are all greatly simplified through the easy to use web interface in Orion IP SLA Manager.  Not only does IP SLA Manager simplify this process for you, but you also have Orion alerts, reports, and charts available to you to start tracking historical IP SLA data for your network.

I'd like to address one last point on licensing.  We wanted to make licensing simple, so it's based on the number of IP SLA source devices you're managing in Orion IP SLA Manager.  A source device is a device on which you create an IP SLA operation. Even better, we only count devices against your license if you've created operations on them.

You can download and try Orion IP SLA Manager for free here.

Most Orion users are aware that we ship a large MIB database (approaching a million OIDS) as part of Network Performance Monitor, but in conversations with users, we’ve noticed that some users are unclear on exactly what the MIB database is and is not used for.

 

So what is it used for? One of its core uses is to support the Orion SNMP Trap Server that ships as part of NPM. The Trap Server is a “listener” service, which means it waits on the specified port and when a trap is sent on that port, it processes the message. That processing involves looking up the trap in the MIB database to determine how to handle it. Furthermore, if you want to create an SNMP Trap Rule to take some action based on the specific trap, the creation of that rule may involve a lookup in the MIB database, as in the screenshot below.

 

clip_image002

 

What else is the MIB database used for? If you try to create a Universal Device Poller (UnDP), you will typically use the MIB database. As part of the UnDP creation process, you must provide the target OID to be polled. Sometimes, you know the OID already. If so, you can type or paste the OID into the UnDP window. When you do so, it will immediately check the MIB database for that OID. If the OID is in the MIB database, it will automatically fill in the name, description, MIB value type, etc., based on the information in the relevant MIB.

 

One common misconception about the UnDP is that the OID you want to poll must be in the MIB database. Not true. If you have an OID, the UnDP will try to poll it if assigned to a device, regardless of whether it’s in the MIB database or not. What you lose if it isn’t in the MIB database is that you have to fill in the name, description, and other details yourself. That’s it. You can get by without it.

 

clip_image004

 

But what if you don’t know the OID you need? For instance, you might know that you want to measure something like temperature on a Cisco router, but you don’t know exact MIB. In this case, you can click “Browse MIB Tree” in the UnDP and you’ll be able to browse Cisco section of the MIB tree. The data for that browsing session is pulled from the MIB database. And if you are really unsure about what you’re looking for, you can click “Search MIBs”, type in a search term, and you’ll get a list of related OIDs to check out, and those OIDs are pulled from the MIB database. If you’re in more of an exploratory mode regarding what to poll about a particular device, this search functionality is a good way to go.

 

clip_image006

 

What, then, is the MIB database not used for, even though most people think it is? The most common belief is that the MIB database is used to identify devices. Orion NPM automatically recognizes a very large number of devices automatically, with no configuration. When a new device is added via discovery or via the add-a-node wizard, Orion does an SNMP query, pulls back an OID called the sysobjectID. A reasonable assumption would be that Orion is checking this OID against the MIB database. Reasonable, yet wrong. Orion compares this value with a completely different database to identify the vendor, machine type, etc. Therefore, when you add a device that Orion doesn’t recognize, updating the MIB database won’t help. It’s the sysobjectID database that needs to be updated and that only happens with releases and service packs. It’s not part of the weekly MIB database update.

 

You might ask why we have two databases. Are we trying to be difficult? Nope. This situation is an accident of product evolution. The sysobjectid database came first, long before Orion had a trap server or a universal device poller. SNMP traps were added in 8.0, and the Universal Device Poller was added in 9.0, and both of these features needed a robust MIB database and the older sysobjectid store wasn’t appropriate. Instead, Orion inherited the existing MIB database from our Engineer’s Toolset. We may well consolidate these two databases at some point, but until then, this post explains the way things work today.

 

For those of you that have upgraded to Orion NPM 9.5, I am sure you have noticed one or two changes with what is now called Network Atlas (previously called Map Maker).  For those of you that use Microsoft Office 2007, I am sure the UI looks very familiar.  Overall, we have received terrific feedback, however, some users would like to get some additional UI real-estate back by removing the “ribbon” or top tool bar. I was on thwack the other day and saw this post from one of the Network Atlas Developers michalB here at SolarWinds and learned something new about Network Atlas myself.

 

clip_image001

 

I would like to point to a feature in NA that is a bit hidden and may help to those who do not like the Ribbon. The feature is called Quick Access Toolbar (QAT) and as the name states, it provides quick access to selected tools. You may add buttons and Ribbon groups to this toolbar.

 

The result may look like this:

 

clip_image002

 

or even more like a separate toolbar:

 

clip_image003

 

· To add a button to the QAT, right click on the button, and select "Add to Quick Access Toolbar".

 

· To add a Ribbon group to the QAT (like in the first picture), right-click on the group's caption and select "Add to Quick Access Toolbar". Buttons and groups can be removed the similar way.

 

· To hide the ribbon, right-click on the empty space reserved for the Ribbon tabs (right of the "Help" ribbon tab) and select "Minimize the Ribbon". You can also choose whether to show the QAT below or above the Ribbon.

 

Please note that the customized layout may not persist after you upgrade.

I’ve spoken to quite a few customers who would love to gain visibility into top bandwidth users on their network, but alas, their networking gear does not support flow-based traffic analysis (e.g., NetFlow, sFlow, J-Flow).  I’ve also heard from existing Orion NetFlow Traffic Analyzer (NTA) customers who’ve got great visibility in their core network, but would like to extend NetFlow-based analysis to other non-flow capable sites. 

If you fall into either the aforementioned scenarios, you have several options:

   1. Leverage your Cisco ASAs – Cisco ASAs running the 8.2 software release support exporting NetFlow which Orion NTA can collect and analyze.   For instructions on how to enable NetFlow on your Cisco ASA, see this KB article

   2. Deploy devices that do support NetFlow – This may be overstating the obvious, but if you have the budget, it makes sense to simply deploy devices that support NetFlow into those locations and configure them to export to your Orion NTA collector. For example, a Cisco 800 series router supports NetFlow and is relatively inexpensive

   3. Use a software exporter on a span or mirror port - If you have a managed switch, you can usually configure it to send all the traffic to a single span or mirror port (consult your vendor’s documentation). You can then install a software exporter on a computer and attach it to the span port. The software exporter will then send flow records to your Orion NTA collector.

#1 and #2 are pretty straightforward, so I won’t spend any more time talking about those options.  So, let’s focus on #3.  What is a software exporter and how do you set it up to work with Orion NTA?  

A software exporter transforms received network packets into summarized flow data that collectors like Orion NTA can store and analyze.  There are quite a few software exporters out there, but nProbe is probably the most popular. nProbe also runs on both Windows and Linux, so I’ve focused my integration testing with this software exporter. 

NOTE: For more detailed technical documentation on nProbe configuration, please see the nProbe User Guide.

Here’s how to set up nProbe to work with Orion NTA:  

1. Download and install nProbe on a Windows (or Linux) server

  • Download an evaluation version of nProbe and install it on a server.  As noted in the diagram above, you'll need a server with two NICs - one to connect to the span port of the switch and the other to export flows to the Orion NTA server. The eval version of nProbe supports 2,000 flows export, so you’ll eventually need to purchase a copy.  It’s around $100.

2. Enable port spanning or port mirroring on your Managed Switch

  • Configure port mirroring or port spanning on your managed switch to the port that the server running nProbe is connected.  This will allow nProbe to see all traffic flowing through the switch.  You’ll need to consult your switch documentation for how to configure port mirroring or port spanning. If possible, consider only spanning the ports of interest to reduce the amount of flow data collected.

3. Add the nProbe server to Orion

  • Add the server running nProbe to Orion, including all interfaces
  • Add the server interfaces as monitored NetFlow Sources
  • Go to NTA settings and enable “Allow monitoring of flows from unmanaged interfaces”

4. Configure nProbe to export flows to Orion NTA

  • Open command prompt on nProbe server and navigate to C:\Program Files\nProbe-Win32>
  • Run nProbe from CLI using the options listed below: 

             nprobe

                 /c - output to console.  This is the easiest method, especially for a demo situation, because you can review the debug messages.

                 -n <Orion NTA server address>:<port>  - IP address and port that should receive the flow records.  Use 2055 for port.

                 -b 1 - modest level of reporting

                  -i  <interface> - generally 1 on Windows; en0/eth0 on Linux; en0 for Ethernet on OSX, en1 for wireless

                 -u <in-index> - sets the ingress interface for all flows (use 1).

                 -Q <out-index> - sets the egress interface for all flows (use 2). 

          E.g. nprobe /c -i 1 -n 10.199.15.50:2055 -b 1 -u 1 -Q 65539

  • NOTE:  It’s important the ingress (-u) and egress (-Q) interface indexes be set to the server interfaces being managed in Orion. NTA will drop flows from interfaces that are not managed in Orion.  You can see the interface index for the server interfaces in Orion by drilling down to their respective interface details view. So, if your nProbe server had two interfaces being monitored in Orion NTA, you would just set the option –u to the index of one of them and the –Q switch to the index of the other.   See nProbe documentation for other command line options.

Did you know that the Engineer's Toolset comes with a bunch of useful tools that can help you diagnose and troubleshoot issues on your network?  Did you know that these tools are integrated with Orion?  Not only are they integrated with Orion, but we just improved that integration with the recent release of Toolset v10.4.  Before we dive into the details of that integration, I want to talk about a few of the tools in Toolset that you might find useful.

The Engineer's Toolset has been around for a while, and we're adding new tools with each new release, so there are many useful tools available in the product.  Many of these are standalone tools; however, we added what's called the Workspace Studio in v10, which provides an easy to use interface for using multiple tools and gadgets together in the same work space.  Here are just a few of the tools included in the Engineer's Toolset:

  • Find out what is plugged in where with the Switch Port Mapper
  • Find a MAC address in a list of switches with the MAC Finder gadget
  • Draw a Layer 2 map using the Neighbor Map gadget
  • Configure and view Netflow data with the Netflow Configurator and Netflow Realtime tools
  • Create subnets with the Subnet Calculator
  • Examine the DNS query tree across multiple DNS servers (even those outside your control) with the DNS Analysis tool
  • Scan your network (or someone else's) using the IP Network Browser
  • Check your security footprint with the Port Scanner
  • Use the TFTP and the SCP/SFTP Servers to upload IOS and config files
  • Use the MIB Browser tools to find out all sorts of information about your devices

These are just a few of the tools at your disposal with the Engineer's Toolset.  Many of these tools are very useful in the context of Orion, which brings us to the integration.  If you have Toolset installed, right clicking on a device in Orion will give you a menu of tools you can use from within the Orion web console.  If you've got Toolset v10.4 installed, you now have the Workspace Studio gadgets available to you via this right click menu as well.  This menu is displayed in the screenshot below.

 

I'd like to leave you with one more tip on using Toolset with Orion.  Toolset requires ActiveX, so your best bet is to use Internet Explorer when running the Orion web console.  You can try using the IE Tab add-on for Firefox, but we have seen issues with this in the past.  We'd love to hear from you if you've got this working.

       

Filter Blog

By date: By tag: