Best QOS for monitoring throughput

[CiscoPurpleBelt]

So what does anyone suggest the best QOS policy to implement on a a switch interface (switchport, SVI, even Tunnel, etc.) to capture and/or monitor throughput?

[balaji.bandi]

If you have any NMS can do that for you, Like example PRTG. 

If you looking Manually export data using external scripts for the below information - make own Graphs :

Table 11. Monitoring QoS

Command	Description
show class-map [class_map_name]	Displays a list of all class maps configured.
show class-map type control subscriber {all | name }	Displays control class map and statistics. all—Displays information for all class maps. name—Displays configured class maps.
show policy-map [policy_map_name]	Displays a list of all policy maps configured. Command parameters include: policy map name interface session
show policy-map session [ input | output | uid UUID ]	Displays the session QoS policy. Command parameters include: input—Input policy output—Output policy uid—Policy based on SSS unique identification.
show table-map	Displays all the table maps and their configurations.

[CiscoPurpleBelt]

Right, I am trying to see what can be done just on actual device.

[balaji.bandi]

You can do on the device as mentioned, as it has some over head on the device.

Looking some Visibility of application aware based, Like any NMS which can support is best rather on device.

[Joseph W. Doherty]

That depends on the "need" of your monitoring application.  I.e. basically the same question for any application traffic using QoS.

I.e. consider jitter (unlikely for monitoring device interface throughput), packet loss (applications using UDP often more sensitive, vs. those using TCP), delay (also probably not an issue unless you're looking to "see" performance "real-time").

BTW, be careful how you monitor, too much monitored data or too often queries can show the monitoring, itself, is a problem.

[CiscoPurpleBelt]

So you are saying just configure some class-maps within itself could present a problem if too much correct?

[Joseph W. Doherty]

Not exactly.

What I'm saying is, QoS should be defined/configured to support the needs of application traffic.  This also applied to traffic, directed to or from a device being monitored.  As I don't know exactly what you monitoring application is, I cannot suggest more concerning how QoS might be best configured to support it.

Concerning too much, that was in reference to the impact of monitoring itself, both on bandwidth utilization and/or CPU impact to the network device.  However, yes it's also possible to make matters worst by a "poor" QoS configuration.

[Leo Laohoo]

AKiPS -- Very affordable and "cheap" (does not require hefty VM requirement).  

Reach out to them because they are very happy to provide "evaluation" license.  

[Joseph W. Doherty]

To OP, and others, going off topic here . . .

@Leo Laohoo, I assume AKiPs is something you have first hand experience with, and like, correct?

If so, that alone like makes this a "good" product.

That said, I would be a bit concerned about their 1 minute poll, and, I assume, the amount of data they "pull", but perhaps they are clever and both "pull" (perhaps for longer term trends?) and "trap" (perhaps immediate issues?).  If you have first hand experience, no issues with product?

[Leo Laohoo · Accepted solution]

---

@Joseph W. Doherty wrote:

I assume AKiPs is something you have first hand experience with, and like, correct?

If so, that alone like makes this a "good" product.

That said, I would be a bit concerned about their 1 minute poll, and, I assume, the amount of data they "pull", but perhaps they are clever and both "pull" (perhaps for longer term trends?) and "trap" (perhaps immediate issues?).  If you have first hand experience, no issues with product?

---

• Cost  
• Vendor agnostic
• Regular polling of end devices.  
• Customisable e-mail alerts. 
• Easy to update
• Very "cheap" deployment options -- Does not require TB of memory and several trillions of CPU core.  

 

The graph above is a "snapshot" of our busiest APs (based on the number of clients), taken from a particular duration (last 8 hours), from a site (based on the AP hostname regex).  All the options can be done on one page -- And not click this page for this option, go to this page for that option, into that rabbit-hole for that other option.  Change one option and the output changes immediately.  It does not need to wait for several minutes.  

Updating AKiPS is a breeze.  "click here".  Wait 10 to 20 minutes.  Done.  

We welcome the 1 minute polling and we have had no issues.  Not only does the graph above look more "accurate" but, with monitoring of CPU, memory, discards, errors, etc., we get a more clearer picture.  

Aside from vendor agnostic, AKiPS does not "discriminate" on the hardware.  As long as the target platform talks SNMP, AKiPs will pull data out.  If, for example, someone has a Catalyst 3550, AKiPS will pull data out of it.  If AKiPS do not have the MiBs configured, contact support and they will respond immediately.  Getting "unknown" platforms into the DB takes weeks and not years.  

AKiPS is able to detect subtle memory &/or CPU leaks.  And this is one of the things we liked.

[CiscoPurpleBelt]

@Leo Laohoo @Joseph W. Doherty Thanks everyone. Experience and info about some good free tools is awesome! Any others you guys recommend?

Also, for just referencing metrics on Cisco devices itself, the bits/sec is one way I am easily referencing to get an idea of how much throughput or traffic is tx/rx on any particular port. You guys have any other suggestions to get good baslines or ideas of traffic on the network if you do not have any applications or tools such as the above, Solarwinds, etc.?

[Leo Laohoo]

PRTG, Cacti are free tools.