You are here

integrating AREDN into an existing network..

10 posts / 0 new
Last post
ka9mot
ka9mot's picture
integrating AREDN into an existing network..
Hello, we have an existing network made of wired servers with a dhcp server in area A.
We would like to extend the network by adding new areas B and C.
Area a has a AREDN mesh node acting as a gateway to mesh nodes in area B and C.
We would like all the computers on all area to get their ip addresses from the existing dhcp server but not from AREDN mesh node.
How can we do it ?

I read this tutorial based on hsmm. Would these instructions work on AREDN ?


http://ohiopacket.org/index.php/Integrating_HSMM-MESH_into_an_existing_n...

Regards,


K.


 
File Attachment: 
AE6XE
AE6XE's picture
Yes, the instructions still
Yes, the instructions still apply.     However, the .pdf diagram is not possible (and different than the setup as described in the instructions).   

These instructions munge the LAN network of the mesh node in with a home network with shared address space.   When communicating to other devices on the mesh network, the 192.168.1.x client goes though a NAT through the local mesh node.   Everyone else on the mesh thinks the client is the 10.x.x.x address of the mesh node, and has a mechanism to route back.

The relationship of this 192.168.1.x network to the mesh 10.x.x.x network is the essentially the same as the relationship to the internet.   Mesh and Internet devices can not directly reach in, however port forwards can be setup (from internet and the mesh) to access services on the 192.18.1.x network.   The 192.168.1.x clients can reach out to addresses on both the mesh and the internet, and most things work.  Some applications, e.g. voip phones, may not work with out more complex port forwarding rules to figure out.

Joe AE6XE
 
ka9mot
ka9mot's picture
Thanks a lot.... yes you are
Thanks a lot.... yes you are right about the two scenario... we will use one that works best with aredn firmware..
ka9mot
ka9mot's picture
Hello Joe,
Hello Joe,
can you help me here ?
I tried different scenario but for some reason I can't get the same network solution as the one shown on my pdf diagram ..
Can you please help me and guide me on how I can get something closer to what is displayed on my diagram ?
Thanks,
Kane
 
AE6XE
AE6XE's picture
The .pdf diagram is not
The .pdf diagram is not possible.   It's not possible for devices on the LAN of one mesh node to receive IP addresses from the LAN of another remote mesh node.  These must be different networks with a routing mechanism between them.  It could be 1 hop or 10 hops as a mesh is formed.

These must be 2 isolated networks on the LANs of the 2 different mesh nodes, both could use the192.168.1.x private network space, but these would be distinct and different networks.  Both have a NAT to the mesh no different than 2 home networks at 2 different people's home use this private subnet, both attached to the internet.  But routing between them must use an internet known address, or on the mesh the routing between them would use 10.x.x.x address, to traverse the mesh.

Joe AE6XE
KX5DX
Per your diagram...and your goals...
1. Remove the two AREDN nodes.
2. Replace them with two radios with standard Ubiquiti firmware running as transparent bridge between the zones.
3. Add managed switches at the edges of the wireless shot, with Trunk ports crossing the wireless shot.
4. Configure untagged access ports for your regular network end devices.
5. Configure tagged access ports for VLAN 2, for DtD, and connect your AREDN nodes to these ports.
6. Connect end devices to both networks (standard untagged network on the switches and the AREDN LAN(s) at each node) using two network interfaces, LAN plus Wireless, or two LANs.

This is just my personal preference, I like the idea of trunking the point to point links, as Part 15 operation. This allows me to not only run AREDN across two locations, but also any other VLANs I may need to extend in the future.
AE6XE
AE6XE's picture
Great idea.   If the AirOS
Great idea.   If the AirOS bridge link is 3Ghz ubiquiti devices, then it could also be in part 97 out of the wifi noise.  But assumes you don't also want to watch netflix across the link :) . 

Joe AE6XE
K6AH
K6AH's picture
Need to ID...
If you use the standard Ubiquiti devices and airOS on 3GHz you will also need to create an auto IDer to fulfill the callsign identification requirements of Part 97.119.

Andre
AE6XE
AE6XE's picture
AirOS part97 identification
I think this can be accomplished in the Advanced setup of AirOS.    If one checks the "advanced reporting" option, this includes the "device name" in the 802.11 Management Frame packets.  The "device name" can be assigned the part 97 callsign.   Stations send out "probe request" 802.11 management frames periodically checking the status and communicating with  nearby APs.   I suspect this frequency is within the part 97 requirements--it's probably in the 'seconds' range.   The AP AirOS configuration would have the call sign as part of the SSID and included in every beacon packet.     

Thus, the stations/Clients are transmitting Probe requests and the AP is transmitting Beacons with the control operators callsign to meet Part 97 requirements.  But, need to confirm the default probe request timing for stations in AirOS. 
  
Joe AE6XE
ka9mot
ka9mot's picture
Yes, it is done so easily
Yes, it is done so easily with AirOS wds-ap-repeater mode... it is transparent and allows wireless users to connect to the network when airmax is disable..
Thanks a lot for the input...
K

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer