Jeremy Stretch has generously contributed a few of his great articles into the CT3 wiki: the Policing versus Shaping article describes the performance impact both QoS mechanisms have on TCP sessions and the IPv6 EUI-64 article describes the algorithm that's used to transform a MAC address into an IPv6 address, resulting in automatic generation of unique IPv6 interface addresses.
Policing implementations in Cisco IOS are a bit confusing: IOS supports three different algorithms that are configured with very similar parameters of the police command in modular QoS CLI. There's also the older rate-limit command that uses a limited implementation of one of the three algorithms. You'll find all policing details, including the graphic representations of all three algorithms in the QoS Policing in Cisco IOS article in CT3 wiki.
Setting the size of the hardware output queue in Cisco IOS with the (then undocumented) tx-ring-limit (formerly known as tx-limit) has been a big deal when I was developing the first version of the QoS course that eventually became the initial release of the Implementing Cisco Quality of Service training. However, while it's intuitively clear that the longer hardware queue affects the QoS, years passed before I finally took the time to measure the actual impact. The results are available in my wiki.
I had to do some precise QoS tests and needed a flooding tools that I could tightly control, so I rewrote the PERL UDP flooding program to include a few additional parameters: you can specify the desired bandwidth or inter-packet delay. You can download the new source code from the CT3 wiki.
As my readers have mentioned in a comments to my previous post on this topic, you should use kernel-based floods for high-performance or you could use Iperf to do the UDP floods or TCP bandwidth measurements. However, as I do the QoS tests in a remote lab with virtual PCs that have no Internet connectivity for obvious security reasons, it's easiest to make changes to a PERL script over the console window.
I ran a few tests to document the differences between the fair queuing and FIFO queuing in Cisco IOS as well as the impact of queuing mechanism on the software/hardware queue used. The results are stored on CT3 wiki.
A while ago I've been a co-mentor to a graduate student who investigated the difference between shaping and policing for his thesis. While doing the lab tests, he stumbled across an interesting problem: he could not configure fancy queuing (for example, CB-WFQ) on a point-to-point Frame Relay subinterface. The solution was to configure a QoS hierarchy, doing shaping first and queuing within the shaping queues.
A few days ago, Arden Packeer covered the same topic in one of his blog posts, so it looks like the underlying problem (and the solution) is not as widely known as I had assumed. Time to write a tutorial on Queuing Principles in Cisco IOS.
