We've been using PCQ queueing almost from day one on our network, not just to
implement per-subscriber bandwidth caps, but to ensure that grief gets
distributed fairly during periods when bandwidth demand exceeds the gateway
maximum bandwidth. (We've since moved the bandwidth caps to simple queues in
each tower router to distribute the processing load, but the fair distribution
of scarcity is still important to us.)
The problem is that to do this for incoming data (the most critical case), the
queueing has to be attached to the interface closest to the customer. (I'd
like to be able to just say, "the gateway offers X input bandwidth, share it
fairly," but there's no way to do that by configuring queues on the gateway as
far as I know.)
For redundancy, our network is configured as a ring. The edge router has one
gateway interface and two interfaces over which customer data flow. If any
link in the ring breaks, OSPF reroutes customer data all the way around the
ring until it can be repaired. Under normal operation, data to the
geographically furthest station (a major hub) can get routed arbitrarily over
either interface due to ECMP weighting.
I can't figure out a good way to attach PCQ limits to the two customer
interfaces to express a hard bandwidth limit at the gateway. If I give each of
them a limit equal to the gateway's input bandwidth, the gateway can max out
without the shortage being fairly distributed. If I give each of them a limit
equal to half the gateway's input bandwidth, I end up underutilizing the
gateway when there is a lot of demand from one side of the ring and relatively
little from the other. I can't average a queue over two links unless I bridge
them, and that just doesn't make architectural sense.
Anybody have an elegant solution to this problem?
--
Grand Avenue Broadband -- Wireless Internet Service
Circle City to Wickenburg and surrounding areas
http://grandavebb.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.butchevans.com/pipermail/mikrotik/attachments/20150929/783f37e5/attachment.html>
_______________________________________________
Mikrotik mailing list
[email protected]
http://mail.butchevans.com/mailman/listinfo/mikrotik
Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
