I'm running an 877W at home and I'm trying to configure QoS on my downstream link. The theory is if I set my downstream bandwidth to 80% of the link speed, the choke point is under my control and I can choose what gets discarded. It works just fine on the Linksys that I just replaced (google wondershaper if you're curious).
I have my upstream service policy working fine on the dialer interface, but cannot figure out how to apply one downstream. Obviously I can't apply queueing inbound on the dialer interface and my ethernet and wireless interfaces are bridged together with IRB. I don't want to apply the QoS on the hardware because I have 2 downstream interfaces (so how do I split the bandwidth?) and I don't want to limit ethernet to wireless traffic. I've tried applying both LLQ and GTS policies to the BVI and the interface will accept neither. I've also thought about marking the packets inbound and then applying something like WRED downstream but again this won't work on the BVI. I really don't want to rate limit my classes as this won't allow efficient use of the bandwidth when there is no congestion.
in short, you can't do absolutely anything for the downstream QoS. it is not a limitation of the router but a consequence of the "physics" of the itnernet where unless you controller a point of congestion, you can't set QoS on that.
So you can just hope the ISP gives priority to DSCP EF, that is becoming more and more frequent.
If it was working with the linksys, we should understand what and why was working, because there is no easy explanation.
>but a consequence of the "physics" of the itnernet where unless you controller a point of congestion, you can't set QoS on that
That's exactly the point, if we rate limit at below our downlink speed then the queue (usually) moves under our control, and we can choose to allow interactive traffic, and drop bulk traffic. It's not perfect (we can't guarantee what happens elsewhere), but it stops our ISP queueing/dropping and moves it to our control.
Not exactly. If you rate limit input, that will not prevent the upstream node to still send data at his desire. Remember, when a packet has arrived already at the interface, it doesn't help that you throw it aways, as it will not prevent other packets to arrive.
If you want to control all what the router received, you can set a GRE tunnel, and do all the shaping/LLQ on there. As long the 877 only received from the tunnel, you effectively have control.
but if we start throwing away TCP packets then the flow throttles back - as in WRED. So we can throttle back the bulk traffic and let the interactive continue rather than let them all lose packets and throttle back.
This is the method that packeteers and other "bandwidth manageres" uses - throw away stuff on input and/or output in the hope to slow down the senders.
Sometime it works, sometime it doesn't, for sure it messes with the nature of a TCP connection badly enough.
The difference is that when doing the "packeteer way" properly, it keeps track of each flow and drops or shapes with intelligence. Doing the same on the router with wred or policing will not attain the same effect, as the router will act practically random.
And, in any case, it will not have effect on UDP senders.
Conclusion, sorry, unless you want to add a device or software that uses the techniques above mentioned, and be prepared to be potentially disappointed, sorry, the router won't be able to fix the issue for you.
For your reference, the list of feature that you can do on the VLAN1 interface, is listed here:
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...