06-22-2022 10:57 PM
Hi,
for a client and a non SD-WAN environment.
Situation:
The client has a 4G connection. When sailing, and he moves away from the antenna, the signal loses power and therefore weakens. Furthermore, the available bandwidth drops as wel.
Problem:
I work with a fixed QoS profile on the interface.
What I did:
I measure with IP SLA the RTT and the threshold triggers an EEM APPLET. Seems to work in the lab.
Question:
What if, the QoS Profile changes and changes and changes again... I mean, It could be that the signal is lying. I added the delay and up timers. But, what happens If I change after 5 seconds up time my QoS Profile. What happens to the traffic inside the 'old-queue'?
I wonder if this solution will be negative for the end user?
Any idea or experiences?
06-22-2022 11:43 PM
Hello,
I think what you have come up with is a pretty ingenious solution to be honest.
I (sort of) lab tested this, changing the 'bandwidth percent' value in the QoS class, and it does not seem to affect existing streams. That said, what is the range of your configured QoS profiles, that is, how much do they differ ?
06-23-2022 12:25 AM
06-23-2022 12:36 AM
Hello,
I know that in DMVPN, there is something called adaptive shaping. I am thinking that although your solution is very good, there should be a way to automate this even more (and without EEM). Can you check if the below is available on your device ?
policy-map parent-policy-name
class class-default
shape adaptive { upper-bound bps |percent percentage }[lower-bound bps| percent percentage]
06-23-2022 08:12 AM
From experience, I haven't noticed an adverse impact to a network applications when changing a QoS policy on the fly, even during production hours. But this might have been as much due to there being "few" in-flight packets and/or just a "one-time" blip.
I don't recall seeing any "standard" (found on Cisco's main site) documentation surrounding the actual impact, if any, when making QoS changes. It's possible, something like this might be documented in some prior Cisco Live presentation, which you might search against here.
Interestingly, the approach you're using is one I would have done years ago, myself, but back then, EEM either didn't exist, or was just starting to roll out.
As an aside, though, why are you doing this? The reason I ask, unless you're shaping to manage multiple queues, there's not much reason in doing this. Although, if you're only supporting one queue, shaping might still be of benefit for single queue management, such as using (W)RED, tiered drops or queue size, but otherwise, what benefit do you expect to obtain?
06-26-2022 10:36 PM
06-27-2022 11:13 AM
"If I have a too large bandwidth in the shaper then I'll never have QOS doing it's thing. Correct, not?"
Correct.
Again, though, you've not made clear how your using your QoS. VoIP alone, benefits little from QoS. VoIP with other traffic, though, can benefit very much from QoS.
If you are doing VoIP with other traffic, ideally, you want to keep the non-VoIP traffic from being adverse to VoIP traffic. This would mean slowing non-VoIP traffic at even a hint of lost bandwidth, or only using whatever bandwidth you're sure is actually available. (A simple approach, would be shape, all the time, for what should be the worst case for bandwidth provided. Unfortunately, doesn't take advanage of bandwidth that's actually available.)
BTW, in theory, it shouldn't be all that difficult to obtain some measure of available bandwidth, but the level of access needed, generally isn't available on a Cisco router. However, in the past, for a while, Cisco provided Corvil's bandwidth estimator agent. Somewhat similar products noted in this (old) article, which might be worth reading for additional ideas on what you might be able to do.
Also that's an interesting idea to using a MOS value, but I would be concerned your QoS would only react (late) to a problem, where, again ideally, we don't want a problem (in something like VoIP) to appear at all.
06-27-2022 10:53 PM
06-28-2022 03:02 PM
"I've learned a lot in theory, but saw the effects in reality as well. QoS is importand."
I too consider QoS important. Unfortunately, most don't consider using it except when there's need to support real-time traffic, like VoIP and/or video conferencing.
Now mounting my soapbox. . .
Three stories I like to tell (probably have noted one or more, over the years on these forums), which show benefit of QoS, are centered around a fairly good sized German international firm I worked at a couple of decades ago.
The German firm split its network management into 3 regions, Europe/Africa, Americas, and Asian/Pacific. Although German networking management had over site for the whole international network, they allowed the two other regions much freedom in how corporate networking goals were obtained. (Later, when the firm did start to use real-time apps like VoIP and video-conferencing, then QoS was "needed", but of course [laugh] they [German HQ] weren't much interested in our several years experience using QoS.)
When I came on-board, in the America's HQ, I suggested QoS might mitigate the constant complaints, from the other offices, how poorly the networked performed.
America's network management allowed me to implement QoS between our regional HQ and all the other regional offices (varied between 80 to 100).
Interestingly, the WAN lead engineer, thought QoS was just useless voodoo until the morning he came in and noted his phone was lit like a "christmas tree" with most remote offices complaining what's wrong with the network?
He discovered one of our HQ WAN routers crashed, the prior night, rebooted itself, but without its QoS configuration. He reapplied the missing QoS, and the phone calls stopped. (BTW, this was pre any real-time traffic being on the network.)
About a year later, we were hosting the twice a year principle network engineers' meeting, where all 3 regions engineers met. (NB: the meetings rotated through the regions.) One big complaint, from the other regions was "no matter how much bandwidth, we appear to add [to the WAN], users keep complaining how poorly the network performs". I noted, since we've implemented QoS, we no longer get those complaints and now very seldom upgrade WAN bandwidths (BTW, at that time, possibly saving us about $100,000 a month). Other regions' engineers response, don't see any need for QoS, as we've don't have any real-time traffic.
Lastly, we had a major regional office in South America, whose dual (E3) WAN links ran at 100% all day long during business hours. Those links carried all forms of traffic, from VoIP (by that time we had moved to it), to video-conferencing, to email, to Citrix like apps, to "critical" web apps, to SAP apps, to FTP and Windows file copy traffic, to database replications, to client backups, to other sundry apps. All worked as expected, without complaints. Why? QoS!
So, again, I too consider QoS important.
06-28-2022 10:13 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide