Hello all-
Doing some initial planning and was just curious if I should:
- Setup a DHCP server/Router on a Raspberry Pi connected to a node
- Allow one of the Mesh nodes to be the DHCP server
- Just setup a static IP assignment
My network will consist of 2 local switches on each side of the mesh, and 3 mesh nodes. If I deploy a static assignment, will one of the nodes act as my router or do I need to have a stand-alone router(Raspberry Pi)? Willing to hear opinions from the group of what works and what doesn't. Trying to keep it simple. Am I making it too complex? Thanks,
Matt
KB9YOJ
If you set a static assignment on a server however and leave the mesh node DHCP enabled I would strongly recommend reserving the IP in side the mesh node (just like you would for any DHCP server when you assign a static IP inside the DHCP range)
The other method you may not be thinking of (or maybe you are) is leave the the devices/servers in DHCP and reserve the IP in the mesh node, this way they always get the same IP but if the mesh node fails its really easy to swap in a new one to replace it. If your use to static IP assignments like I grew up with this may be against ones normal nature for servers, but in a highly dynamic network like mesh (and cloud networks) it makes a lot of sense in that its more flexible than static IP's (at the risk of being a larger pain to get into the server if the DHCP server and DNS goes down but that shouldn't happen in a working mesh network)
On sites using multiple mesh nodes and client devices however you do need to either isolate the mesh nodes networks from each other on the untagged ethernet or disable the DHCP servers (See: https://www.aredn.org/content/device-device-linking-dtdlink ) to make sure that the devices go through the correct node.
Obviously a service/device/etc can only be on the IP network of one mesh node at a time (because of IP routing the mesh node is acting as an IP router) but the mesh node in a stack of multiple mesh nodes will coordinate with the other ones around it to find out which one should handle sending the traffic out on RF.
I do this and it works great.
On the first and second scenarios, the blue links labeled as "LAN" makes it look as if the DtD communication happens on the untagged LAN instead of on VLAN2. It also makes it look like the inter-node communication happens on the LAN to LAN connection, but these are separate subnets as already stated.
Illustrating all 3 networks in the trunk with colors like on the other 802.1q diagrams should help the less experienced meshers when it comes the time to add 2 or more nodes for the first time.