Skip navigation

Product Blog

3 Posts authored by: rschroeder Expert

If you haven't enabled NBAR2 in your routers, you're not getting all that Netflow offers.  You're missing the Application data that's passing through your L3 interfaces.


And you're probably getting Alerts from NTA, telling you that it's receiving Netflow data that's missing NBAR2 information from an NBAR2-compatible device.


There are at least four places you'll see that Alert.  One is at the top of your Main NPM page, with the white alarm bell and a red instance counter.  Click on it and you can see the alerts:



A second place you'll see these errors is in the Events page:



A third place you'll find it is on the NetFlow Traffic Analyzer Summary page, if you have added in the "Last XX Traffic Analyzer Events" Resource


A fourth place it appears is in the main NPM page for an L3 device's Node Details / Summary:


Obviously, Solarwinds thinks not getting your full NBAR2 information is pretty important.  Nobody needs unnecessary alerts, and it's easy to change a router to use NBAR2.  Just do it.



While I was cleaning up configurations on routers or L3 switches that originally had "plain" NetFlow, and that needed NBAR2 settings added.  I thought "Maybe someone on Thwack could benefit from this information."  I built this "before & after" comparison of their configs so you can see the extra commands needed:

Items in yellow are not part of the original Netflow "non-NBAR2" config on the left.  Don't be thrown off by different Flow Names--they're just names, and can be whatever you want, as long as you follow the right syntax.  Solarwinds puts some GREAT technical support links into their product that bring you right to the information you need to build Netflow properly.  Use them and you'll be happy.


If you have a router or L3 switch that's missing NBAR2 info, you won't be able to edit the existing Netflow settings until you remove the "ip flow monitor" statements (left column, bottom section) from every interface on which they are installed.  But once you take them out, it's easy to just remove all the old flow settings completely using the "no" command, and then you're starting with a clean slate.


After the old Netflow commands are removed, I can  edit the right column's "destination x.x.x.x" to point at the APE I want receiving the Netflow NBAR 2 data, and then paste the entire column into the router--EXCEPT for the bottom two lines:  "ip flow monitor NTAmon input" and "ip flow monitor NTAmon output".  Those lines must be inserted into the L3 interface(s) on the router or L3 switch.


You might want to only monitor Netflow NBAR2 data on the North-South interfaces going upstream to a Distribution or Core switch.  Or you might want to catch North-South AND East-West Netflow NBAR2 data by putting flow monitor statements on all sub-interfaces or VLAN interfaces (SVI's).


Once you've completed your work, instead of seeing nothing in the "Top 5 Applications" area on any L3 device's NPM Device Summary page, you'll start seeing data being added every ten minutes.  Data that tells you what applications are using that interface's bandwidth.  And that can be the secret ingredient to finding a bandwidth hog and correcting it!


Is "A Picture Worth A Thousand Words?"  Maybe even more than that!


I frequently receive requests to show departments / teams how their system(s) may be performing on the network.  It's not enough to just tell them "Your server's latency is sub-millisecond, it's connected at 1 Gb/s at Full Duplex, and no network errors have been recorded on its switchports in the last three months."  When you offer that kind of information it's accurate, but it may not fill the actual need of the request.


Maybe they want to know a LOT more that NPM can show about even basic network status of a system:

  • Latency
  • QoE
  • Throughput on multiple interfaces
  • Traffic trending over time--especially with an eye towards predicting whether more resources must be allocated for their system(s) in the future:
    • More memory
    • More bandwidth
    • More storage
  • Growth over the last year in various metrics:
    • Server bandwidth consumed
    • WAN bandwidth utilization
    • Latency changes


I never found a canned NPM Report that would show everything the customer wanted.  But I learned how to build one!


Check out my method of building a Custom View that shows multiple windows in a single screen--my own little "single-pane-of-glass" deployment here:  How to create a simple custom view of multiple interfaces' bandwidth utilization


It's incredibly easy to build a blank custom View that has as many monitors/ windows/ reports as I want:

  1. Create a new View
  2. Add the right number of columns and add the right Custom HTML (or other) resources to them
  3. Edit those resources to display useful and intuitive titles and subtitles
  4. Test that they show the time frames and polling frequency most useful to the customers
  5. Give the customer access to them
  6. Sit back and listen to the praise and excitement!



I just built a new view for all the interfaces on a Core 7609 yesterday using this process, and will build another one today on another 7609.  In the screen shot below I've zoomed far out to give you an idea of what I can see--a graph for each interface's utilization.  Normally I'd have the browser window zoomed in enough that the three columns fill a 24" display and are easily readable, and easy to scroll through vertically.



  • I need just one screen that shows everything physically connected to those core routers.
  • My team sees the labels and information displayed; that helps them understand what needs to be worked on as we move those interfaces onto replacement Nexus 7009's.
  • My boss is able to track progress, see interfaces and throughput change.
  • His boss knows the work's being done, sees what's left to do, and can answer the CIO's questions quickly and easily.


What would you pay an outside vendor to build this kind of custom view for you?  $5K?  More?   Depending on the complexity and number of interfaces, I can start and complete a new multi-interface view, complete with custom labels and customized monitoring periods and granularity in less than ten minutes--AND provide a wealth of useful, specialized information to whichever customer wants it.  Better still, I can show them how to tweak the individual windows' views to reflect differing amounts of polling granularity and time covered by the graphs.


The ability to build this has filled needs by my team, by our IBM Big Iron team (always wanting to see how much of the multiple 10 Gig interfaces they're consuming at once), our Bio Med group (which LANTronix devices have the best or worst uptime--and where they're located!), the Help Desk (what sites or systems are impacted by any given port being down), and more.  I've built all these specialized views / reports and made them available via NPM to multiple teams, and the need for this info only grows.  I've also built custom multi-graph windows that provide information about:

  • Corporate WAN utilization for interfaces that connect campuses in multiple states
  • Contracted EMHR customers' uptime, reliability, and throughput
  • Performance and availability of WAN connected sites based on WAN vendor to track SLA's
  • Cisco UCS Chassis interface utilization
  • Vendor-specific systems and hardware (particularly useful when the vendor blames our network for their hardware or application issues)


Take a look at my "How to" page here:  How to create a simple custom view of multiple interfaces' bandwidth utilization.  Then talk over the idea of providing this kind of information with your favorite (or problem) customers, and you'll see you can build bridges and service unmet needs a lot easier than you expected.  It's another way NPM shines--with information already available to you!

Our Desktop Support Team (which I'll call "EUPS" from here on--for End User Platform Support) rarely unpatches data cables from switches when PC's or printers or other devices move or are retired.  That results in switches and blades with potentially many ports patched, and nothing using those ports.


That's a waste of money.


When someone has a new device to add to a network, possibly requiring a new data drop to be pulled to the network room, and there's no open ports on a stack of switches or in a chassis switch, we've got few options:

  1. Tell the customer "Sorry--there's no room in the inn."  You know that won't float.
  2. Tell the customer "Sorry, we're out of network switch ports, and no one in your department budgeted for adding a new switch or blade (between $5K and $8K, depending on the hardware).  When you can come up with the funds, we'll order the hardware and install it.  Probably in three weeks, if you get the funds to us today."  Nope, that won't float either--although sometimes we have to play hard ball to ensure folks think before they add new devices to a network.
  3. Take a new/spare switch from inventory, install it, and take heat from up above for not planning adequately.  Naw, that's not right, either.
  4. Run Rick's Favorite Report #1 and find which ports haven't been used in a year, have EUPS unpatch them, and then patch in the new devices.  TAH-DAH!  Money saved, customer up and running right away, budget conserved, resources reused--we're the Facilitators that make things happen instead of the No-Sayers that are despised.


So how does this magical report work?  Easily and efficiently!  Check out how to build it here:


Once it's built for a switch, it's easily modified to change switches--just change the switch name in the title, and change the switch name in Datasource1, and run the report.



My team uses this almost every day, and I bet I use it weekly.  How many switches has this saved us from buying, how many ports have we been able to reuse?  Let's say we use it only twice a week.  That's over a hundred ports every year that are repurposed at no cost!  And since they're typically in different network rooms, you might say we avoid having to buy between fifty and a hundred new switches or blades every year. 


A network switch port costs about $169 (including 10/100/1000/POE) if it's in a high-density high-availability chassis switch that's fully populated, and about the same if it's in a stackable switch.


So the actual cost of 50 ports X $169 = $8,450.  That's not too bad since it's money not spent for recovered ports.  100 ports is $16,900.   Not insignificant, and not something you want to waste.


But let's build a worst-case scenario: 

  • Every port on a switch is used
  • You have to buy another switch every time someone needs to patch something new into the network.
  • 50 devices X $5K per switch is a QUARTER MILLION DOLLARS.
  • Perhaps a more realistic approach: Suppose your ports aren't so perfectly mispatched. Maybe only every tenth port to be patched requires adding another switch.  So if you find 100 ports incorrectly patched, you'd spend up to $80K on additional switches.


Some organizations offer a bonus to employees who discover and recommend process changes that result in significant cost decreases to the company, and the company bonus could be equal to 10% to 25% of the annual savings. If someone offered me 25% of $80K for saving the company from having to buy more switches every year, I'd be all over that!


And this easy Solarwinds report does it for free. Did the money saved pay for something significant to the company? Did you get a juicy bonus for your money-saving suggestion?




p.s.:  This report ALSO saves unnecessary downtime--we don't end up guessing about the purpose of a port, and unpatching and repurposing mission critical ports that are only used once every few months or years--because we label those ports in the switches.  The report includes those labels in its output along with how long the ports have been down.  It even displays them by length of down time, from longest to shortest.  Schweet!

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.