Netonix Forums

I'm curious how people are handling shaping. I'll start.

I'm doing shaping a couple ways.

1) traditional routeros simple queues with burst limits for service plans.
This is simple, and it works, and I can tie it into RADIUS so queues are dynamically created when a specific device (by MAC) pulls an address (I'm not doing this right now though). I do this on a 3Ghz Core2duo x86 box w/ 2GB RAM.
what I don't like is that it's dependent on routeros, which is either on lower performing hardware or on x86, and on x86 it's got limitations on RAM and isn't well threaded.

2) I additionally use a queue tree for specific routes. I route some traffic out a secondary connection at the headend, and other out a 'backup' connection on another leg of the network. These connections get a queue type SFQ for the interface maximums, then a PCQ under that limiting individuals to a given amount. These connections act as failover links also, but day-to-day they get routes for windows update ip addresses and various other things that are handy to offload off the premium uplink and backhaul links.

3) I queue interfaces for PTP links because the hardware/airmax queues don't do a good job of queuing based on link capacity and latency goes to heck when you saturate a link. I figure out my worst case aggregate capacity as well as the tx and rx and create a queue that has the peak tx, the peak rx, and then use the 'total' queue and limit at the aggregate max. That way I don't exceed the aggregate capacity peak where latency spikes. With this implemented, latency does rise a bit when a link is saturated, but because the packets are being queued and the increase is somewhat predictable and tolerable. If I let them just be, latency could spike by a hundred ms! vs 10ms w/ the queue.


I've considered shaping on the radios, but shaping ingress isn't ideal for one (I don't want to deliver dropped packets all the way across the network), the radio's CPU isn't so great, and the ability to track utilization over time with ubiquiti's tools isn't any good or even possible on newer devices. I've considered doing it anyway and just doing netflow on my mikrotik routers to track this info, but there isn't a good central management interface at this point and airCRM is....well, not coming along as nicely as I'd hope.

Much as you I use Mikrotik Queues for shaping. I also set queues in the radios for a couple of reasons.

1) The cpe limits apply if the customer is communicated directly with another customer on our network that is internal to the shaping device. This is particularly important if the customer has multiple locations and uses your network for all locations. We could shape at our tower routers, but we prefer to keep it at the head-end.

2) We set the cpe download limit to slightly higher than the max MT queue limit, to prevent dropping packets at the cpe level.

3) We set the upload limit to be identical to the max MT queue limit. This prevents the customer from sending so fast we drop at the MT queue. Again preventing wasted network resources.

4) When VoIP is involved, in particularly our VoIP service we add the required bandwidth for the VoIP codec times two to the cpe levels, and leave the MT queue tree to deal with prioritization.

Our network is an OSPF ring, and we assign a /27 per ap for DHCP and then we assign /30, /29, etc for static addressed businesses.

As of right now we shape on CPE. This coming winter though I plan on trying to figure out a radius server that we can use. Shaping on the CPE actually is not that bad. Ingress shapping is bad but I setup with two profiles of shaping on both the wlan and lan egress only. So far works really slick but it makes fat figuring much easier. A couple of times I found mistakes where someone didn't put shaping on one side so it was wide open!

What I find curious is that ubiquiti's airCRM is going to configure CPE shaping as their go-to method of handling this.

rebelwireless wrote:What I find curious is that ubiquiti's airCRM is going to configure CPE shaping as their go-to method of handling this.

I figured this also. That is actually one of the "possible" things I will be looking into. I am hoping that they system will be more stable a little ways down the road to try it but I am not to keen on going with a cloud solution like this yet. Will see how things play out in the coming months.

We use procera + powercode

josh wrote:We use procera + powercode

hows that for cost? was the procera box expensive?

Josh - I'd also like to know more, we're still eyeing Powercode for more than just shaping. Currently, have have linux boxes that do our custom queueing. We have bandwidth allocated to each backhaul, then each AP under the backhaul, and each user under AP under each backhaul (if that makes sense) so everything is equalized. I'm concerned PC doesn't have this feature, just rate and ceiling control per IP address. We have so many sub queues to equalize across multiple backhauls that I don't see just using per IP working out well for us.

WisTech wrote:Josh - I'd also like to know more, we're still eyeing Powercode for more than just shaping. Currently, have have linux boxes that do our custom queueing. We have bandwidth allocated to each backhaul, then each AP under the backhaul, and each user under AP under each backhaul (if that makes sense) so everything is equalized. I'm concerned PC doesn't have this feature, just rate and ceiling control per IP address. We have so many sub queues to equalize across multiple backhauls that I don't see just using per IP working out well for us.

PowerCode absolutely can allocate/restrict bandwidth on a per-AP level.

Also, procera supports BLUE, per-connection BLUE, and CODEL AQM.

Procera is pricey, but very, very good. PowerCode also makes us very happy, it basically saves us 1.5 office employees in labor every month.

josh wrote:

WisTech wrote:Josh - I'd also like to know more, we're still eyeing Powercode for more than just shaping. Currently, have have linux boxes that do our custom queueing. We have bandwidth allocated to each backhaul, then each AP under the backhaul, and each user under AP under each backhaul (if that makes sense) so everything is equalized. I'm concerned PC doesn't have this feature, just rate and ceiling control per IP address. We have so many sub queues to equalize across multiple backhauls that I don't see just using per IP working out well for us.

PowerCode absolutely can allocate/restrict bandwidth on a per-AP level.

Also, procera supports BLUE, per-connection BLUE, and CODEL AQM.

Procera is pricey, but very, very good. PowerCode also makes us very happy, it basically saves us 1.5 office employees in labor every month.

And this is exactly what got us seriously considering PowerCode. Are you running the procera in bridged mode or router? Each of my APs is on it's own VLAN, and I have multiple public ip's under different subnets associated to the same AP. Trying to wrap my head around being able to convert everything over somewhat seamlessly has my head spinning.