I’ve set up a mesh network of 10 RB’s connected to our network via a ‘master’ running Hotspot authentication on the bridge of the master. This is to provide coverage to a University residence where we expect around 300 users to be accessing it, maybe more… Most of the user accounts will be 64k.
I’ve installed rstp on the mesh which seems to work quite well, and at this stage there are 10 test users using it with no real problems as yet.
My question is that on inspecting each RB’s bridge port status, I find one (so far) that does not seem to allocate a ‘root port’ or ‘alternate port’ roles on any of the WDS connections - they are all ‘designated port’.
This particular board has 4 WDS’s, and comparing it to one other that also has 4 WDS interfaces, I see port roles - 1 ‘root port’, 2 ‘designated ports’, and 1 ‘alternate port’.
Path cost on each is set as on others, and the RB in question does not seem to affect the operation of the mesh. I do get momentary packet gain (2-3 packets) when a WDS interface is switched on or off somewhere in the mesh, presumably as the new path is allocated.
So, to summarise:
What can be wrong (if anything) on the rogue routerboard port roles?
Does it matter what path cost value is set relative to the whole mesh?
Should each RB be set with path cost value relative to the ports on the local RB only?
In RSTP, the bridge device with the lowest priority becomes the “root bridge”, and all calculations are done relative to it. I’m not sure what is used to break a tie, but there will only be a single “root bridge”.
The port “role” is determined by it’s relation to the “root bridge”:
A “root port” has the currently used (lowest cost) path to the root bridge.
An “alternate port” is currently unused, but does have a (higher cost) path to the root bridge.
A “designated port” is a downstream port, facing away from the root bridge. There may or may not be another path to the root bridge over such a port, but if there is, it is unused.
The root bridge will never have root or alternate ports, only designated ports.
The other participating bridge devices will always have exactly one root port, and any number of alternate and/or designated ports.
If a non-root bridge does not have any alternate ports, it does not have redundancy.
If a non-root bridge does not have any designated ports, then it is not in the lowest cost path to anything else.
As you are using RSTP with WDS, you should not manually set the port costs, but rather simply let the external FDB adjust it on the fly (seems to have an inverse relationship with the CCQ of the WDS peer). If you want to exert more control (while still taking advantage of the nifty dynamic link between WDS and RSTP), you can adjust the “WDS Default Cost” and “WDS Cost Range” parameters of the wireless interface.
Since you only have one link into your mesh (the “master”), you should force that router to be the root bridge. Since the priority defaults to 8000, you can just set it to 7000 or so on your “master” router.
Have now set the ‘root bridge’ - thanks for that bit of info - I saw it, but overlooked it… let’s see how it affects the system…
Another thing - I’m usnig static WDS between the AP’s, and here the path cost must be set manually. My method was to set the AP first to Dynamic WDS, wait for the router to assign path costs, and then use those values in my static WDS - is this acceptable?
Changing the WDS interfaces to static gives you more manual control, and perhaps makes it a bit more stable. But, it makes the system less dynamic.
Personally, I leave things dynamic. If a particular WDS link goes bad (but remains up), RSTP will avoid it when WDS is dynamic; but with static configuration, it will keep using it at the same cost.
People (myself included!) want OLSR for mesh, largely because it takes ever changing link quality into account. Many don’t seem to realise that MT’s WDS+RSTP pseudo-mesh already does that thanks to the external FDB, and for small systems it works great (albeit at L2, with an artificially imposed “virtual tree” topology).
Half the fun of mesh, is being able to ignore the mesh.
I hear you about the static vs dynamic WDS - what I’m trying to avoid is an apparent reaction by the MT to ‘think too hard’ about which way to go with marginal signals from far nodes. I see dynamic WDS appearing and dropping all the time, and I figure this can only introduce more latency as paths keep changing quite frequently.
So - what I did (while the mesh was completely dynamic) was to choose the best 3 signal strengths on each node and set those as static WDS paths, thereby still keeping the reduncy of the mesh. I then set the path cost as i mentioned earlier.
I do see in wireless logging that although all the nodes are now static WDS mode, there are still dynamic requests coming in.
Why is this happening? My feeling is once again that the MT is going to waste time denying dynamic requests.
Some more strange stuff… maybe to do with RSTP ‘test package’ status…
Forcing the root bridge definitely makes a difference in the stability & ping times through the mesh, but setting dynamic WDS really slows it down a LOT. Static WDS seems to be much more stable - BUT for some reason my root bridge loses its root status occasionally!
How can this happen? All other routers have their priority set to the default 8000, and I’ve steadily changed my root bridge priority setting down by 1000 each time it changes - I’ve got it set on 5000 now…
What I do see is that if the router reboots, the bridge status window reflects a change in the priority back to 8000, even though it has been set as a lower number…
After a root bridge reboot, it did not resume acting as the root bridge. It’s priority was still 7000, but the root bridge role remained with another unit at 8000. Upon changing the intended bridge’s priority to 6000, things began working as they should. Even after changing back to 7000, it remained the root.
I don’t know why that happened, but I’m going to be keeping an eye on it. (that little pseudo-mesh had previously been running 2 months without issue)
As to the stability of dynamic WDS, I have not had a problem; but, I’m only using WDS+RSTP on a very small scale, and I’m not too surprised there are problems. If static WDS is more stable for you, than by all means go for it.
As to the stability of dynamic WDS, I have not had a problem; but, I’m only using WDS+RSTP on a very small scale, and I’m not too surprised there are problems.
All seemed to be fine when there were only 5 MT’s in fairly close proximity - mounted around 4 thick concrete 6-story buildings. All MT’s have little 8dBi omni’s on CM9’s.
When I added the next 5 to extend the range to a cluster of double-story student accomodation, things started to fall over. Now I’m really struggling to get a balance between static WDS and signal strengths…
Maybe I should split the two sections and link them with 5Ghz…
Dynamic WDS is good when you are making a new mesh system. If the WDS node count will increase in wide area then lot of wds liks will be establishing and disconnecting the wds links (the nodes wich has very low signal strenght between them).
First place all the nodes in their places enable dynamic WDS, then monitor few hours, days or maybe more to see which WDS links ar stable and wich not. Then start changing these dynamic WDS links wich are stable to static ones. After you have done that, you can disable the Dynamic WDS mode.
Better to leave so many WDS per AP that all of them are connected with other end all the times - not disconnecting. Maybe you were getting lower ping times because the traffic was going through the one of the WDS that you have removed later (slower WDS link with lower signal strenght and quality).
About the root bridge changing - we will research that.
looks like a bug, we will try to fix it.
Also an aditional comment on the dynamic wds and the links with bad signal that are disconnecting - you can use connect-list to specify wich links for WDS to establish and what should be the minimum signal strenght - min-signal-strength argument.
Please send the support output file from the RB112 router which doesn’t work.
Maybe you haven’t added that static wds interface to the bridge port?
Will send supout.rif…
And nope - definitely have bridge ports set - here is an example of my programming script - I have one for each of the routers for quick setting of static WDS:
should “connect=no” not set to “connect=yes” , but “only when signal is better then -85” ?
could you also explain your #4 setting ?
and couldyou add wich version ROS you are using ?
Well my thinking was to force routers that I don’t want connected to stay disconnected.
My #4 setting is straight out of the Mesh wiki, and controls the router WDS authentication.
I did try using the min-signal-strength setting on #4, but that also didn’t appear to help. The setting of -90 was my threshold, but still got connections at -92.
Well my thinking was to force routers that I don’t want connected to stay disconnected.
if you mean you NEVER want the mac to associate then you should add the mac to the wireless acces list and refuse acces.
for as far as i know the connect list is for clients you “want” to connect BUT only when …
from the manual ;
The Connect List is a list of rules (order is important), that determine to which AP the station should connect to.
At first, the station is searching for APs all frequencies (from scan-list) in the respective band and makes a list of Access Points. If the ssid is set under /interface wireless, the router removes all Access Points from its AP list which do not have such ssid
If a rule is matched and the parameter connect is set to yes, the station will connect to this AP. If the parameter says connect=no or the rule is not matched, we jump to the next rule.
If we have gone through all rules and haven’t connected to any AP, yet. The router chooses an AP with the best signal and ssid that is set under /interface wireless.
In case when the station has not connected to any AP, this process repeats from beginning.
acces list is for clients you want/don’t want to connect
i think you should use acces list if you would like WDS AP’s to STAY disconnected.
not sure all rules also work for WDS, most of the manual only speaks of stations.
