Ken, Not entirely an answer to your question, but hopefully useful. The backstory - I was getting pretty annoyed that our VoIP techs kept claiming that Canopy QOS didn’t work even though I have proven with packet captures a number of times that it does work, so we set up a test lab to see how High Priority and standard traffic rate limits interact. End result was that I was only partially correct and it took a little more tweaking to the configuration than I thought. The Canopy manual is correct - but you have to read the fine print and it’s not all in one place if I recall correctly.
Anyway - this i what works for our VoIP customers using QOS with a standard and voice vlan: For All Dual-VLAN (Internet + VoIP) Juniper SRX Deployments: On the SM.... 0. Set "Sustained [Uplink|Downlink] Data Rate" (Kbit/s) based on the customer's service plan (i.e. 6 down / 1.5 up) 1. Set "[Uplink|Downlink] Burst Allocation" (Kbit) to a value equal to "Sustained [Uplink|Downlink] Data Rate" 2. Set "Max Burst [Uplink|Downlink] Data Rate" (Kbit/s) to a value twice that of the "Sustained [Uplink|Downlink] Data Rate" 3. Enable "Hi Priority Channel" 4. Set "Hi Priority [Uplink|Downlink] CIR" to a suitable value. i.e. [(100 * #phones) + 100] (aka 500 Kbit/s for 4 phones) 5. Set "Priority Precedence" "802.p then DiffServ" (either one actually works, but this is belt & suspenders in case the SRX config isn't fully implemented). 6. On the SRX, configure both WAN VLAN interfaces (i.e. internet and phone) with firewall rules to mark traffic as high priority (phone) or low priority (internet) [interfaces -> IFNAME -> UNITNUM -> family inet -> filter] 7. On the SRX, enable rewriting (dscp and 802.1p) on both of the WAN interfaces [class-of-service -> interfaces] This config is valid and tested with 80 Mb/s of simulated upload traffic, 500 Kb/s of simulated VoIP traffic, on an SM with only a 1.5 Mb/s upload cap. No lattency/jitter/packetloss on the simulated VoIP traffic. Only 15-30 ms latency on the internet upload (not bad, considering the SM is forced to discard 95% of the traffic it's getting over the wire). We didn’t analyze the traffic to see how the drops were handled on the SM->AP side. Mark > On Nov 25, 2016, at 12:56 PM, Ken Hohhof <[email protected]> wrote: > > I also posted this question on the Cambium Community forum, but maybe this is > well known and someone here can answer for me, or point me to the info. > > How exactly does Cambium 450 QoS work? Does it buffer traffic and shape it > to the configured rate, or does it do traffic policing? And if it buffers, > what is the buffer size? Is it just a global buffer pool whatever memory is > available, or a fixed buffer per SM/LUID? If it does policing (and even > shapers have to discard traffic if the buffer overflows), does it discard > whole packets (PFIFO instead of BFIFO)?
