r532 running AP with nstream - problem for far away customer

We are experiencyng some jitter issue on an AP based on a rb532 running 2.9.18 where there are 15 customers.
10 of this customers are around 1 mile from the ap and the other five are between 8 and 10 miles.

On these dfar away customers we are experiencing a lot of jitter and some packet loss that is around 10-15% at client’s full load.

I tried all the frame policy on the ap without any significan change in behaior.

Can some hel pme to fix this issue?

regards
Rosario

Uhm, could you gives us more to go on, perhaps?

Wireless minipci is a cm9 running at 5.4-5.7ghz
Nstream enabled and polling enabled.

I played with ack-timeout on ap and cpe withou any improvment;
The cpes are configured on staion-wds because I need to let the voip ata (bihind the cpe) to be the pppoe client.

The wireless networ is routed and each ap is tunneled to the pppoe concentrator by eoip.

thanks

the answer is; don’t use wds for that many stations.
there is nothing wrong in using wds but for some reason it slows down alot when there are many stations connected..

good observation.

but i didn’t fine a way to transparently bridge the cpe without wds.

If set the wireless interface on station I can:

  1. create a pppoe client on wlan1 and it is workin;
  2. bridge wlan1 and ether1 and run a pppoe client on bridge and it is working;
  3. bridge wlan1 and ether1 and use pppoe client on ether1 AND IT IS NOT WORKING. To let it works i have to switch to station-wds

Do you know howto have the option 3 working without WDS?

Regards

No, but i can rub it in, in many different ways.
:smiling_imp:
Which i won’t.
How about running pppoe server on your cpe as well?

no…to much complication about routing public ip, fragmentation of the ip pool…

I think it should be a better way…

please a little more detailed help…:))

You could set it up like:

AP WLAN1 IP address 10.0.0.254/24, PPPoE server set up to assign public IPs

CPE in normal station mode.

Then assign an IP address to each CPE WLAN1 interface using DHCP (name each radio (Wireless RadioName) so you know who is who from a pool of IPs in the 10.0.0.0/24 subnet. Using this subnet for management only (if the PPPoE connection is down)

On each CPE set up a PPPoE client to connect to your AP (or main Access Concentrator) this connection becomes the default route for the CPE and you can assign a public address to it, you can also set up DHCP and NAT on the CPE’s ethernet interface for the customers computers / devices (like SIP phones) to use in the 192.168.0.0/24 range.

You could also set up some QoS for ICMP on the AP and the CPE so that pings get through no matter how busy the link is, if your customer is using that to see how fast the network is then they will always be pleased

sorry but i don’t like it very much.
May be you don’t know how complex is the NAT for voip connection when you have to support t.38 on udptl

I’m not familiar with t.38 on udptl, we use a setup like the one I described including EoIP from the AP to a central AC with no problems at all, the clients are using SIP phones and IAX on Asterisk and the NAT is not a problem at all. You could route you customers a small subnet - but then I see you do not want to route either…

I would say however that we are moving away from EoIP as it is not as efficient over our wireless links in comparison to pure routed traffic.

I noted the same thing about EoIP. And also in the future we would like to avoid it.

But the first step could be avoid WDS to bridge the pppoe client (on voip ata) to the wireless interface of the ap.

Anyone was able to do that?

Regards
Rosario

rpingar,

Try to disable the nstreme in the point to multipoint environment, too much overhead and the RB532 can’t handle the load, especially the 5.8 ghz band

Regards
Albie