We go out of a housing center where we have Gigabit connection
(2 links to 2 RB1000s with BGP).
We go into 2 directions with licensed gear and carry 366Mbit to the towers.
From there we use 5,8Ghz (non Wlan Equipment) which carries 100MBit per
link to the next towers.
A typical Wlan Segment carries no more than 20-25Mbit HDX (5,5 20MHz Channel RTS/CTS).
If there are weak clients on the segment even less. So we have to optimize segments
to carry as much bandwidth as possible. This is done best with access-lists and MT Clients
as they respect access-list traffic limitation. The outgoing traffic is shaped at the client
so the AP has to do shaping only for traffic to the clients. Shaping 60MBit (3 Segments)
is not the problem for a RB600.
Without limiting the CPE at the CPE one user can kill a segment by sending UDP Traffic storms.
Your central QOS server comes to late. He stops the traffic before sending it to the internet
but the segment with the offending CPE is full of UDP-Traffic.
In your case you maybe need both access-list and QOS as you may get bottlenecks
on the segment and on the internet link.
Very interesting!
This give us a look into a real high bandwidth suppliers setup. Very nice. Your remarks make me re-think my decision to abandon client end shaping....
Some questions though:
- What is "HDX"? I presume I can google for it but you might give me a quicker answer!
Halfduplex. Licensed gear is always Fullduplex.
- Your "outgoing" traffic (=upload?) is shaped at the client. How? Just simple queue in the client? Or you mend the AP still limits the clients "Tx" limit like option of winbox access rule shows me?
The client learns this from the AP access-list. If you look in registration of the client he shows
you the rates the AP gives him.
- Then your "traffic to the clients" (=download) is then shaped by the AP_Tx_Limit in the access rule?
Yes.
Last, but most important: "UDP Traffic storms". What can cause these? Can it happen by wrong configs? Trojans or virusses? Or has to be initiated by abuser?
This depends on the application. If there is a torrent client which sends out 10000 UDP Packets without waiting
for an acknowledge ... Or may be btest
), bad implemented speed test ...
I use mainly MT CPE's and Ubiquity CPE stuff. (The latter will fade out since their failure rates are way to high.)
MT units can be shaped in the AP while the UBNT have an option in the unit itself.
I am only left with notebooks etc. that are allowed to log in. I cannot control their upload, and these are probably also machines prone to risk change of network abuse. How to deal with these? Setup simple queues in AP?
Oh. You've foreign controlled devices (Laptops) connected to your AP.
There you loose control. We do not allow this. We even manage all
CPEs. No customer gets the passwd of his CPE. If he needs e.g. a NAT setting
we do it at no cost. Thats cheaper than let the customers do it.
I have a feeling I can learn a lot from you!
And your capacity makes me feel very little.....
No. Getting traffic from a housing center is much more affordable
than leasing lines. Licensed Gear is no longer unaffordable.
It's more expensive than MT Stuff. But at the center of the
backbone it is worth it's money. Combined with MT-Stuff you
get a great network.
This is a ping from RB450G to RB450G with licensed gear carrying traffic
between.
[admin@GW21] > ping 192.168.50.189
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time=1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
192.168.50.189 64 byte ping: ttl=64 time<1 ms
18 packets transmitted, 18 packets received, 0% packet loss
round-trip min/avg/max = 0/0.0/1 ms