All firewalls disabled, modules R52H.
532A R5, freq 5680, chan 20MHz, WDS withour framing and nstreme = 15mbit HDX and 8/6 FDX
same bridge with NSTREME AND FRAMING = 36mbit HDX and 17/17FDX
Use better antennas, better cards, pigtails or change whatever is pushing your signal back. 10 kms you should easyli do 50mbps with 60 cm. antennas at both ends and signal ~<-60db
A 532 does something in the order of 23Mbits UDP on a long link with Nstreme+polling on, and about half that with regular old 802.11a (no Nstreme+polling). The speed limitation is mostly processor capability on a 532. A 133 does about 11-13Mbits UDP in the same environment.
You get about 35Mbits UDP with a 333 in the same scenario. You will see around 75Mbits UDP running a turbo (40MHz) channel on a 333. We have a couple running that way that work just great, been up and stable for a couple of weeks now with heavy use.
We’re been doing this with MT for better than five years, and have lots of 20+km links running, with the longest over 50km.
Watch out for packet size on EoIP. You may find very slow rates when moving 1500 byte packets. Experiment by changing packet sizes down to maybe 1420.
An example: 1500 bype packets over EoIP, 4Mb/s. 1420 byte packets over EoIP, 14Mb/s.
We are seeing issues with this on our network. Lots and lots of EoIP tunnels. It appears that some customers do not do path MTU discovery and keep trying to shove 1500 byte packets down the pipe which appears to be causing serious fragmentation issues.
We are considering changing our customer-facing Ethernet to 1420 MTU and see if that helps the problem…
Ensuring connection tracking is off at every router in the chain seems to improve the rate at which fragmented 1500 byte packets (i.e. 1500 byte payload inside of EoIP) pass through the routers.
At the moment we’re doing heaps of EoIP with all tunnel sizes set to 1500 bytes. We’ll be moving to MPLS as soon as it’s stable.
