@ravi bejjarapu wrote:
@Joseph W. Doherty
Have sent the required configs separately.
Got it.
Still lacking much information that I would like to see, but some suggestions . . .
Again, if we're going to shape to avoid bumping into WAN provider's bandwidth limits, so that we can manage congestion, it's rather important we don't exceed those limits. So, firstly, you might contact your provider and find out exactly what they are "counting" toward those limits. If they are only counting packet bits, your current shaper settings should be fine. But, if they are truly trying to provide the equivalent of wire bit rates, you want to allow for L1 and L2 overhead, which your IOS appears to be able to easily do. Non VLAN tagged Ethernet frames have an additional 18 bytes L2 overhead, and L1 adds an additional 20 bytes. If you cannot get clarity from your WAN provider, try: shape average # account user-define 38
I see your hub policy uses multiple child policies (which can be fine), and the child policy you sent me sort of is "QoS book" or AutoQoS kind of policy. Such policies, IMO, are often overly complex and if device supports FQ, are unnecessary. (If you think about it, CBWFQ, does its FQing between classes, but if classes support FQ, do you need as many class queues?)
I also see WRED being used in class-default. I generally often strongly recommend WRED NOT be used by other than QoS experts. Class FQ, when available, IMO, is often a much superior choice. If FQ not available, possibly even WTD is a better choice. (BTW, WRED isn't "bad", per se, it's more of a useful specialized technique for specific use cases, at least in modern networks.)
Here's my generic base QoS model:
policy-map BaseModel
class real-time
priority percent 35
class hi-priority
bandwidth remaining percent 81
fair-queue
class lo-priority
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
In the above model, almost all traffic should be in class-default, where FQ, alone, often does a very nice job of keeping bandwidth hogs from stomping all over light weight traffic flows.
For some traffic, that really needs priority guarantees, something like VoIP data and/or VidConf can be directed to the real-time class. "Known" bandwidth hogs, something like email between servers, data backups, etc., might be deprioritized by directing to the lo-priority (or background) class. Traffic that really, really needs a priority boost, above and beyond what class-default's FQ provides, but doesn't need quite the service guarantee of something like VoIP, might be directed to hi-priority (or foregound) class. Ideally, only light weight kinds of traffic should be placed into this class (e.g. screen scraping apps).
The above model really is built around 4 priority levels, absolute priority over all else, normal priority, better than normal priority and less than normal priority. FQ within all but the absolute priority class, generally precludes heavy bandwidth using flows from being adverse to light bandwidth using flows, within the same class. The 3 non-LLQ classes do have a major prioritization split, between them, so a busy higher class can be adverse to a lower class. (Often, ideally, you want actual class loads to be the converse of their bandwidth allocations, which have been set for dequeuing priority, not expected bandwidth utilization. I.e. you want the hi-priority class to use the least amount of bandwidth, and bulk bandwidth flows to be in the lo-priority class. NB: I had cases, where using a similar policy, total link utilization was running at 100% all day long, during business hours, but that because (laptop) client to server data backups, running in the the low-priority 1% class were consuming 80% of the link. The other 20%, though, was usually dequeued before such backup traffic. Effectively, that 20% average usage had on-call 99% of the link's bandwidth, so it pretty much acted like there was no other traffic on the link.
An example I used to like to use, to show the power of FQ, i would set up a link between lab routers. On the "local" router, I would telnet to the second router. All works just fine.
Next, also on the "local" side, I would send, using a traffic generator, 110% UDP traffic to the far side. While that was happening, telnet to the far side, generally, was not at all usable.
Next, on the "local", with the same 110% data stream, I would enable FQ. Then, telnet started to respond, very similar to when there was no UDP traffic being concurrently sent.
Also, beside telnet, I might also ping the "far" router too. Without FQ, when the 110% data stream was running, most pings failed or showed very high latency (compared to when the UDP wasn't running). Again, with FQ, and the data stream active, not a huge increase in ping times, but no lost pings.
Understand, the above policy is a base, and can be "tweaked" in various ways. For instance, if I had streaming video, the default FQ queue depths might be inadequate, so I might need to increase per flow and/or class queue depths, for class-default (if supported), or create another class for streaming video, probably about the same priority as class-default (with streaming video, latency and jitter, because of inherent client buffering, are usually rather lax, but you don't want to drop packets).
Also, BTW, believe your routers may offer a two level LLQ. If so, you might place VoIP in L1 and VidConf in L2.
If your topology is using strictly hub and spoke, you should be able to manage your QoS needs on your devices. If you start to do any spoke to spoke, you may check whether your MPLS vendor can provide any QoS support (often they can, and will, sometimes at extra cost, sometimes no extra cost, but also often, their QoS support tends to be very basic).
Lastly, the one interface stats you provided (branch, correct?) showed a drop percentage of 0.088. Under the old rule of thumb that anything less than 1% is acceptable, looks fine, but firstly, the old rule really applied to bulk data transfers, like FTP, and second, that an average of weeks, you may be having much, much higher drop spikes to bouts of transient congestion, which is the kind of thing that users complain about the network being occasionally slow.
Unfortunately, network engineers only see stats on multiple seconds to multiple minutes, but transient congestion, which can cause users to perceive the network being slow, often happens down in the millisecond range. This is one of the reasons I so much like FQ, it deals well congestion, down at individual packets. As TCP's slow start, is particularly bursty, it protects other concurrent flows from that, and will often just drops packets from such a flow.
To summarize, shape such that you can manage any congestion, not allowing a provider to willy-nilly drop your packets, insure traffic has the bandwidth it needs, and when there's not sufficient bandwidth for all flows' "want", concurrently, chose which flows' packets will be dropped.
If you take to heart, the above, what you might do, is create a new child policy and try it on just one site, both on HQ and/or branch. See how it works for you.
Again, which a policy using FQ, even if you use a traffic generator to saturate a link (using one or multiple flows), it shouldn't be too adverse to same class FQ'ed traffic and not to any higher level classes.
Such a test often makes believers out of the power of FQ and good traffic prioritization management.
