I have 3 RB532 with SR5 radios on 120º panels as base, and 30 RB112 with SR5 or CM9 radios as clients.
I want to configure them the best way to get as much bandwidth as I can, with no drops (dynamic WDS tends to produce drops in bandwidth when a client connects/disconnects)
As I’m just starting, I can change to anything that is needed, but I want to insurance quality and quantity in my clients bandwidth (say 1Mbps at least).
I’ve tried WDS bridging, NStreme polling, plain routing in my test bed (two RB112 with 60dBm each connected to a single PC) Running MT Bandwidth test in each PC, I get 7Mbps at the most. If I run same test though a hub, I get almost 50Mbps (both directions)
What bandwidth should I expect on RB112 links?
Which is the best configuration to reach that bandwith?
We would use a box we call the ombudsman running MT RouterOS and subtend the multiple APs to the ombudsman and use the distributed system(s) to maximize throughput.
[IMHO]
Any significant per packet operations beyond the minimum required of an AP will tax the RB532 and result in dropped packets.
Routing and distributing the work load are your friends.
[/IMHO]
Thanks for your post. I assume your ‘ombudsman’ is a PC running ROS, connected via ether to each RB532, right?
So this PC does the main work, and RB532s receive just the minimal traffic they need to, so they don’t have to waste time dropping packets.
How do you config ROS to get rid of ‘bad’ pàckets?
You don’t bridge, you route everything, and try to keep more or less the same load on each RB532.
Do you use hotspot, PPoE, or just plain routing (static or dynamic via OSPF,BGP, RIP, etc)?
We favor the RB532 as an ombudsman where it is enough. Two of the ombudsman’s primary taks are keeping bogons, etc. from reaching the backbone and enforcing SLAs (our most popular package is Bronze, marketed as a “best effort” and “share and share alike”).
Visit http://www.dfwairport.com/terminals/ and imagine you are a packet who wants to go from the top (north end) or one of the terminals of the airport to the bottom (south end) of the airport. To avoid delay, introduce an ombdusman to maximize revenue by keeping backbone traffic deminimus (no unnecessary or mal traffic). IMHO not dropping paying/righteous packets reduces latency and improves service levels and thus revenues.
Each of the orange semi-circles represents code in the AP which could delay your trip (introduce latency and packet loss) if the AP is assigned the duties of the ombudsman.
Put some heavy duty mangles and queues in an AP, put it under load and measure packet loss. Disable the mangles and queues in the AP and remeasure packet loss. Enuf said.
Genau/exactly. When traffic has been minimized, dropping paying packets is counter-productive.
I’ll leave that to others; in fact, I posted a request earlier today asking for a community effort to address that. Meanwhile, the examples at demo.mt.lv and demo2.mt.lv have some good rules for dropping bad packets.
I’m not saying we never bridge, but we do favor routing vs. bridging. In real life, bridges cross waterways and other obstacles in the path, but with a good route, you can go around the world.
We use everything in the kitchen sink. BGP for upstream and certain downstream peers. We make extensive use of OSPF; we like the /32 model from dialup days where a customer could log in to any pop and get a dedicated public IP address if he has that service level; of course, route aggregation is your friend. One of my favorite routing options is ‘redistribute connected subnets’ or ‘redistribute-connected<>no’ in MT-speak.
As a coworker in France wrote today, “Bonne Annee.”
