10 Nov
2017
10 Nov
'17
2:08 p.m.
Hi,
When there is a zone with high density (many users),
how many stations does a node accept? Is there a maximum?
Do you have any rough recommendation?
What would you say for the following routers?
WDR3600
WDR4300
NSM5
WR841ND
If, in that same zone, we put several nodes close to each other,
do they somehow load-balance the number of accepted stations per node?
I was told the recommended network size for a LiMe layer-2 cloud was /21.
I would like to know what criteria should be taken into account when
considering to create additional layer-2 clouds.
Is there any maximum number of LiMe nodes (any type) per layer-2 cloud
you would roughly recommend?
Is there any maximum number of LiMe access points per layer-2 cloud you
would roughly recommend?
When you have different layer-2 clouds, I understand they automagically
connect to each other and share their Internet connections.
But, what are the differences for users communicating from different L2
clouds?
I mean compared to users in just one L2 cloud.
They won't share the local name resolution anymore (published services
within the L2 cloud), will they?
Any other difference?
Thank you!!
16 Nov
16 Nov
1:56 p.m.
On Fri, 2017-11-10 at 15:08 +0100, Amuza wrote:
Hi,
Hi Amuza!
Too many questions in one email :)
Will try to address some of them!
When there is a zone with high density (many users),
how many stations does a node accept?
I don't have much information about this, but heard 20, and others more
than 60... so your mileage may vary :)
Is there a maximum?
I would say that if you have a high enough room you can always stack
people :)
There are practical limits, they will start colliding all with each
other to the point there will be no useful traffic.
Keep it as low as possible.
Do you have any rough recommendation?
no... less than 20 I would say.
What would you say for the following routers?
WDR3600
WDR4300
This 2 are ideal, dual radio, big enough, well tested (we use them in
Argentina on a daily basis for many years now).
NSM5
don't know this.
WR841ND
this has not enough storage... you will struggle a lot with it... Also
has one radio, so effective bandwidth will be divided by half per hop!
If, in that same zone, we put several nodes close to
each other,
do they somehow load-balance the number of accepted stations per
node?
There is no code for that, but you could implement it by coordinating
them and only having one at a time announcing the network... in that
situation you also need to spread them over the spectrum (so they don't
collide with each other).
I was told the recommended network size for a LiMe
layer-2 cloud was
/21.
really? don't see why... please share :)
I would like to know what criteria should be taken
into account when
considering to create additional layer-2 clouds.
I like to think about this as administrative boundaries.
People that get along together form a Community, and they should be
part of the same network.
Is there any maximum number of LiMe nodes (any type)
per layer-2
cloud you would roughly recommend?
Don't have any answer for this.
Is there any maximum number of LiMe access points per
layer-2 cloud
you would roughly recommend?
Don't have any answer for this.
When you have different layer-2 clouds, I understand they
automagically connect to each other and share their Internet
connections.
You need to connect them through a wan-to-wan ethernet cable for this
to happen.
But, what are the differences for users communicating
from different
L2 clouds?
Different collision domains, no broadcast across different networks.
I mean compared to users in just one L2 cloud.
They won't share the local name resolution anymore (published
services within the L2 cloud), will they?
Don't have any answer for this.
Any other difference?
Don't have any answer for this.
Bye,
20 Nov
20 Nov
2:49 p.m.
On 16/11/17 14:56, Nicolas Pace wrote:
Sorry, I meant Ubiquiti Networks NanoStation M5
What is that WAN-to-WAN connection? Is that really necessary?
I think I once tested it and it was not needed.
I think the two layer-2 clouds saw each other (wirelessly) and
automatically started to share the Internet connection.
By local name resolution I mean something like a hosts file -to be
edited manually- which is shared only within the layer-2 cloud.
I have never checked it, but I think I read it somewhere.
Maybe it is this A.L.F.R.E.D. that, besides sharing DHCP leases, it is
also sharing the list of published services within the layer-2 cloud
(pairing name and IP address)?
If so, is it only shared within the layer-2 cloud?
On Fri, 2017-11-10 at 15:08 +0100, Amuza wrote:
Thank you Nicolas!
Hi,
Hi Amuza!
Too many questions in one email :)
Will try to address some of them! When there is
a zone with high density (many users),
how many stations does a node accept?
I don't have much information about
this, but heard 20, and others more
than 60... so your mileage may vary :)
Is there a maximum?
I would say that if
you have a high enough room you can always stack
people :)
There are practical limits, they will start colliding all with each
other to the point there will be no useful traffic.
Keep it as low as possible.
Do you have any rough recommendation?
no... less than 20 I would say.
What would you say for the following routers?
WDR3600
WDR4300
This 2 are ideal, dual radio, big enough, well tested (we use them in
Argentina on a daily basis for many years now).
NSM5
don't know this. WR841ND
this has not enough storage...
you will struggle a lot with it... Also
has one radio, so effective bandwidth will be divided by half per hop!
If, in that same zone, we put several nodes close
to each other,
do they somehow load-balance the number of accepted stations per
node?
There is no code for that, but you could implement it by coordinating
them and only having one at a time announcing the network... in that
situation you also need to spread them over the spectrum (so they don't
collide with each other).
I was told the recommended network size for a
LiMe layer-2 cloud was
/21.
really? don't see why... please share :)
I would like to know what criteria should be
taken into account when
considering to create additional layer-2 clouds.
I like to think about this as
administrative boundaries.
People that get along together form a Community, and they should be
part of the same network.
Is there any maximum number of LiMe nodes (any
type) per layer-2
cloud you would roughly recommend?
Don't have any answer for this.
Is there any maximum number of LiMe access points
per layer-2 cloud
you would roughly recommend?
Don't have any answer for this.
When you have different layer-2 clouds, I
understand they
automagically connect to each other and share their Internet
connections.
You need to connect them through a wan-to-wan ethernet cable for
this
to happen. But, what are the differences for users
communicating from different
L2 clouds?
Different collision domains, no broadcast across different networks.
I mean compared to users in just one L2 cloud.
They won't share the local name resolution anymore (published
services within the L2 cloud), will they?
Don't have any answer for this.
Any other difference?
Don't have any
answer for this.
Bye,
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
24 Nov
24 Nov
10:37 p.m.
On Mon, 2017-11-20 at 15:49 +0100, Amuza wrote:
What is that WAN-to-WAN connection?
As I understand, for those devices that have a WAN socket (sometimes
also found as 'internet' socket), you connect them through the WAN
socket instead of the LAN socket.
You still need to config the static IP of the port... (longer
explanation, maybe for later!)
By local name resolution I mean something like a hosts file -to
be
edited manually- which is shared only within the layer-2 cloud.
There is no functionality like that.
Panos proposed an improvement to the current distributed DNS to be able
to define network aliases to the hostnames provided by the hosts (that
get registered by dnsmasq):
https://github.com/libremesh/lime-packages/issues/193
When you have different layer-2 clouds, I understand they
automagically connect to each other and share their Internet
connections.
You need to connect them through a wan-to-wan ethernet cable for
this
to happen.
Is that really necessary?
Not necessary, just a simple way to undestand it.
WAN: other networks
LAN: same network
I think I once tested it and it was not needed.
It is how it is recommended to be done, but maybe it works in other
ways...
I think the two layer-2 clouds saw each other
(wirelessly) and
automatically started to share the Internet connection.
Don't know...
But, what are the differences for users communicating
from
different
L2 clouds?
Different collision domains, no broadcast across different
networks.
I mean compared to users in just one L2 cloud.
They won't share the local name resolution anymore (published
services within the L2 cloud), will they?
Don't have any answer for this.
I have never checked it, but I think I read it
somewhere.
Maybe it is this A.L.F.R.E.D. that, besides sharing DHCP leases,
it
is also sharing the list of published services within the layer-2
cloud (pairing name and IP address)?
Only hostnames, no customizable network hosts file.
You can always flash a custom /etc/hosts file for your network
25 Nov
25 Nov
2:13 a.m.
On 11/24/2017 07:37 PM, Nicolas Pace wrote:
This is already implemented. Look at:
/etc/alfred/dnsmasq-distributed-hosts.lua
when you add a host to your regular /etc/hosts file in one node, all
other nodes get this information through alfred. This data is updated
every five minutes.
Cheers,
Nico
On Mon, 2017-11-20 at 15:49 +0100, Amuza wrote:
By local
name resolution I mean something like a hosts file -to
be
edited manually- which is shared only within the layer-2 cloud.
There is no functionality like that.
Panos proposed an improvement to the current distributed DNS to be able
to define network aliases to the hostnames provided by the hosts (that
get registered by dnsmasq):
https://github.com/libremesh/lime-packages/issues/193
2346
days inactive
2361
days old
lime-users@lists.libremesh.org
4 comments
3 participants
participants (3)
-
Amuza -
Nicolas Pace -
Nicolás Echániz