Hi guys!

What's the correct way to achieve bandwidth limitation and priorization of VoIP traffic on the CPE side (SXT 5HPnD)?

We want to do the bandwidth limitation on the customer CPEs to data rates with 1024k/512k, 2048k/768k, 3072k/1024k (downlink/uplink).

What we also want to achieve is to prioritize some kind of traffic, e.g. SIP and RTP.

AP and CPE are set to WDS with NV2. CPE runs in station-wds mode with NV2 and has a bridge interface bridging ether1 and wlan1.

Can somebody give me a hint on where to start?

Thanks a lot,
Robert

What's the correct way to achieve bandwidth limitation and priorization of VoIP traffic on the CPE side (SXT 5HPnD)?

from my view point ...the best way ,is by user proflie ( hot spot & pppoe )...

from my view point ...the best way ,is by user proflie ( hot spot & pppoe )...

Where will the bandwidth limitation then be applied? At the AP or the client?

We are already using is a FreeRADIUS server using Mikrotik-Rate-Limit reply attribute. But then the queue for bandwidth limitation will show up on the AC. I think this is the same as putting it in a local user profile.

We want the limitation/priorization at the client equipment to free resources at the APs.

You set this at the router. Not at the AP or CPE.

It should be centralized, and managed by a "heavy" device, like RB2011 or higher. Let the AP's and CPE do only one thing: maintain the radio link (layer 1 and 2). Layer 3 and higher should be done by a router.

Other vendors, e.g. Ubiquity and Alvarion are offering the opportunity to limit the upstream/downstream bandwidth directly at the CPE (wireless client).

Why use one heavy device with a strong CPU if you can distribiute the work to many small CPUs?

Another benefit of limitng the bandwidth directly at the customers CPE is that the customers aren't able to congest your wireless network with broadcast-storms and similar... it would be good to limit the amount of broadcasts, too.

I think it must be possible to achieve this at the customers CPE as all the other vendors are doing this already... any ideas how to achieve that correctly for layer-2 traffic (PPPoE)?

rborz, you are correct in stating that it should be controlled as close to the edge as possible.

Although, without the SXT acting as the AC for the clients, it becomes a little more of a manual process im afraid. One place to start is to come up with a common schema for QoS at the edge. Maybe something like a 4 bucket system hierarchy, Voice/Video/Priority/Data. Then assign a common bandwidth across your wireless edge devices.

This would control your traffic generally across your core, then leave the AC to control actual user limitations.

I know its not quite what you wanted, but as I said, its not quite doable the way you expected.

Guess you could write a script and use API calls to the edge, but that would get really complex.

I remember a user mentioning they had configured their CPE's, even downloading at 100% of available bandwidth, when SIP was detected a set bandwidth was then reserved to allow VOIP traffic,

scotthammersley, n21roadie: Thanks a lot for your suggestions! At the moment I don't bother about prioritization of different types of traffic, e.g. best-effort, voip, p2p etc. Now, in the first step, I just want to limit the maximum allowed bandwidth. Prioritization will be the next step after bandwidth limitation is working...

What I recently tried to limit the bandwidth of our customers directly at the SXT and to allow only PPPoE traffic: This works very well for some time... but after some minutes, hours or even days it suddenly stops passing traffic. Well, it doesn't really stop passing all the traffic, it just passes it really slow, e.g. at 80 Kbps for up- and downstream or less. After disconnecting the power supply for a minute everything works again, but only for quite some time.

Any ideas why this happens and how this can be solved?


Robert.

Gotcha.

What RouterOS version are you using?

I tested it with v6.6 and v6.7. I think I had also a test client with 6.10, but I'm not sure about it...

@scotthammersley: Any idea what could be the issue?