Per,
I am not aware of any GUI interface to NBAR except QPM. But it is surprisingly easy to configure via the CLI, you end up with class-maps that look like this:
class-map match-any BULK
match protocol ftp
match protocol tftp
class-map match-any SCAVENGER
match protocol napster
match protocol gnutella
match protocol fasttrack
match protocol kazaa2
Keep in mind the interface must be running CEF for NBAR to work. Chances are, you already know all these things - just throwing them out there.
But I can speak a tad to the CPU load due to NBAR. This of course is quite difficult to quantify, and I certainly have never seen any charts, numbers, etc. Some docs say that they will take less CPU than an access-list, some case-studies show that it takes slightly more than an access-list.
In my experience it has been about on par with an access-list. We have NBAR running on over a hundred distribution/WAN routers, classifying and marking inbound from the LAN, LLQ to the WAN, 5-class model following the Cisco baseline. These routers all average about 6 megs of throughput each way during the day, and we see maybe 5% CPU due to all QoS activities. Not bad at all.
But then we have a 7600 that averages 430 megs of throughput each direction during the day, NBAR running on about 30 interfaces, 10 of those interfaces generating 90% of the traffic. QoS added about 55% to the CPU, so we had to scale back the QoS policies on that box.
I know that is not a clear answer but hopefully it is helpful. If you roll out QoS in incremental waves you can head off any CPU problems that NBAR may cause by modifying where needed, as opposed to throwing a 10-class model onto the network and risking an overload somewhere. Good luck!
Best regards
Robert
