Samuel's correct. NBAR is a completely separate technology with some obvious overlap with NetFlow. We at SolarWinds have seen a few requests for NBAR, but the interest has been mild.
It's definitely something we could do. It's not difficult, but as with anything, it takes time, and we would do that instead of something else. When we've interviewed users about NBAR, most folks don't know much about it. The few who do are under the impression that it's a big hit on router resources (esp. CPU, if I recall) and hence don't have any great desire to deploy it. If any of that changes and we have a groundswell of interest in NBAR, we will be responsive.
I would like to request native NBAR support be added to either Orion NPM and/or the Netflow Traffic Analyzer. It is very valuable to be able to see Layer 7 data via NBAR in addition to the Netflow data. It will provide more visibility into what is going on in the network, and more visibilty is always a good thing!
Netflow monitors the data in Layer 2 through 4 only and is only able to determine applications by port. This of course is not useful for applications that use dynamic ports. NBAR completes the view by examining the data from Layer 3 through 7. It uses layer 3 & 4 PLUS deep packet inspection (layer 7) for traffic classification. This is useful for statefull inspection of dynamic port traffic. NBAR is a nice feature already built into most Cisco routers that just needs to be collected and presented in a useful way by a good tool such as NTA.
Thanks for the post. I am doing some more fact finding now on NBAR deployment so it is very timely. We don't have NBAR built in today but is you set it up manually you can use Orion's Universal Device Poller to poll the NBAR MIB for results.
Please please ADD NBAR !!! Technology to Orion NPM ... I have been requesting it since long time ago...
Currently I monitor it with Universal Custom Pollers...
(As a fact: NBAR it is NOT cpu intensive at all.. nothing, nada.. im a cisco engineer and there is enough documentation on cisco site about it already... It does not add even 2% of cpu.. I have it running on production at&t routers: 800's, 2600's, 2800's, 3800's, 4500, 6500, 7200, and so on.. without a problem)
My current issue is that the Counters of every protocol are in a Different Table! that the Names of each protocol... So, I can not "join" them with a Universal Custom Poller.. So I have to Guess which one I want to monitor.. also sql table "custompollerstatistics_detail" increases size since it keeps all the records of the nbar mib table. (I know I could monitor the exact oid), but since they change from IOS to IOS.. it is kind of difficult.. It would be Wayyyy Easier! to have that "Names" table joined with Nbar counters table.. So.. I could select to monitor ONLY a few: http, ftp, exchange...
My guess is that there is some Lack of Marketing about NBAR: (Im very sure that a lot of ppl here would like it to troubleshoot and have more useful Reports... and in case of a problem THEN you could use Netflow to identify the root cause)
FYI... NBAR will tell you the traffic of Each Protocol in your network: Web (http), FTP, Netbios, SAP, Exchange, smtp, etc etc.. WITHOUT the detail of Netflow (which consumes A LOT of DB Space).
Let's say there are 4 levels of granularity in a Network Traffic:
1) Orion NPM Interface Traffic <--- Without detail.
