Hi, everyone,
I have a strange question. We have two nodes. Node 1 is a Rocket with a 120-degree sector antenna mounted at 263' AGL and Node 2 is a Ubiquiti dish mounted at around 40' AGL. Up until this past week, they've had LQ/NLQ in the high 80's to 100. Now, the qualities are all over the board, but the SNR chart shows around an 18 SNR. Everything is mounted securely, so there hasn't been any movement. Both are running on 5.8 GHz with about an 11-mile distance between them.
I'm looking for any suggestions on where to start looking.
Thanks and have a great night. :)
Patrick.
I have a strange question. We have two nodes. Node 1 is a Rocket with a 120-degree sector antenna mounted at 263' AGL and Node 2 is a Ubiquiti dish mounted at around 40' AGL. Up until this past week, they've had LQ/NLQ in the high 80's to 100. Now, the qualities are all over the board, but the SNR chart shows around an 18 SNR. Everything is mounted securely, so there hasn't been any movement. Both are running on 5.8 GHz with about an 11-mile distance between them.
I'm looking for any suggestions on where to start looking.
Thanks and have a great night. :)
Patrick.
Hi, Patrick
IMHO, any LQ/NLQ below 100% indicates a problem.
Are these 2 nodes the only transmitters at each site?
You mentioned a SNR of 18 dB now. What was it before?
Is the sector optimized vertically to be aimed at your dish?
Take a look at the signal SNR in the 48 hour archive. /signal
Does it show fluctuations? Sudden changes in SNR?
Likely the sector has some electrical down-tilt.
Has the sector been adjusted for physical uptilt to optimize a signal at 11 miles?
Else, at physical 0 degrees vertical tilt, the sector antenna might be optimized for a ground mounted antenna at 1.42 miles.
Thus, the higher the 11 mile dish, the weaker the signal.
I hope this helps,
Chuck
On the site where the sector antenna is, we have three transmitters that are about five feet apart. One is on channel 172, one on 174, and one on 176, each with 5 MHz bandwidth. There are other transmitters on the tower, but I don't think any of them are within 90 feet of our three. We're at the very top of the tower and I think the nearest antennas (at least not VHF/UHF) are about 3/4 the way up the tower.
I know that we need to work on re-aiming the dish. But, would the channel spacing need to be changed as well? I think at one point, I had them set to 5 channels apart but we switched them closer. We're also looking at setting up an internet connection within a few blocks, so we'll be able to make adjustments that way as well. And we do need to go out and tidy up some of the cabling at the tower, so that might be part of the problem. If we need to make physical adjustments in the radio room, we can at that time.
Have a great evening. :)
Patrick.
" It's pretty consistent at 18 dBm but occasionally drops down to 0."
"occasionally drops down to 0" Is a huge problem.
"Part of the issue is that the dish was just sort of aimed in the general direction of the sector antenna and hasn't really been adjusted either. "
If mounted on a tower, let us not consider the "sector antenna mounted at 263' AGL " as this antenna is too expensive to adjust.
If roof mounted, let us look at this later.
Let us next consider the dish at 40' a.g.l. and get it aimed.
I will repeat that it is primary to seek 100% LQ/NLQ.
Is the dish the only node that the sector is seeing or are there multiple nodes on that channel.
i.e. Is this a point-to-point or point-to-multi-point situation?
"But, would the channel spacing need to be changed as well? "
Why were those channels chosen?
Why was 5 MHz bandwidth chosen?
I recommend the highest bandwidth that the SNR will allow.
If you can eek another 3 dB from re-aiming the dish, I recommend going to 10 MHz bandwidth.
IMHO, 5 MHz bandwidth should be avoided. Especially if Mikrotiks are to be matched with any other manufacturer.
IMHO, there is no need of a space between channels,
20 MHz bandwidth nodes can be 20 MHz apart,
10 MHz bandwidth nodes can be 10 MHz apart,
5 MHz bandwidth nodes can be 5 MHz apart.
See, https://www.youtube.com/watch?v=CFvsmS5vuc8
from 35:37 to 37:19
I hope this helps,
Chuck
The dish is mounted on a tower and Scott did mention he needs to run a new cable anyhow, so we'll work on aiming it. Ultimately, the tower nodes are going to be point-to-multi-point nodes. We do have another user who's about 3 miles out of town. Between the tower and the dish. If we have to, we'll get his seeing the tower and he can connect to the farther node.
The channel decisions were to stay away from the Part 15 bands as much as we can. While 5.8 isn't used a lot here, most newer home routers have it. So, we want to avoid their channels if we can. As for the bandwidth, I think we might be confused on how that all works. Speaking for myself, I took it to resemble a flashlight. The narrow band will see further out than the wider bands. So, we went with the most narrow that we could. And, I was under the impression (especially from having one channel on 2.4 GHz) that we didn't want any kind of overlap in the three nodes. Unless that was only because they were all on the same 2.4 GHz channel.
Essentially what we're trying to do is divide the town into sectors. NW, NE, and S of the tower. I may have (probably did) misunderstand, and chose channels that were far enough apart to avoid overlap. And since we were able to make a decent connection from the town 11 miles away, we were trying to do that with the 5.8 GHz nodes too.
So listening to the video, if everything else works right, we should be able to use say channels 172, 173, and 174 and set the bandwidth to 20 MHz without any issues? I ask that because the overwhelming majority of the nodes are within 5 miles of the tower and our other high point, which is a direct line of sight to the tower.
Have a great day. :)
Patrick.
P.S. If I haven't thanked you guys enough for all of the help, I do greatly appreciate it. And, I hope others read through these posts and learn from our mistakes, so they don't make them too.
On the same sector?
It is what it is and it may be impractical to make changes on sector antennas up 263' on a tower.
There is a loss of efficiency when there are near and far nodes linking to the same common node.
The 'distance-to-farthest-node' wait time is set to the farthest node in the group.
Chuck
Hi, Patrick:
Was this a 'blind' decision?
Did you do a Wi-Fi Scan at 20 MHz bandwidth at each sector and dish?
YMMV, but I have had very good performance on some part 15 channels on some links.
Our longest link, 13.5 miles, is on channel 140.
Currently 86.7 <> 100+ TxMbps. Often using Short Guard Interval, which I think indicates a very good link.
My link (2.6 miles - through the trees) is on channel 133.
I suggest you set you nodes to 20 MHz BW and do a Wi-Fi Scan, sort the results by channel,
then see what is occupied by part 15 devices and what is not.
If you cannot detect 20 MHz part 15 devices, they are not interference. :-|
3s, Chuck
Orv W6BI
Have a great night. :)
Patrick.
However, OFDM is a very clean modulation; there's very little out of channel splatter. AND, if you drop power 3 dB, it's very minimal (as was reported several years ago in the forums).
Orv W6BI
So, I spent the weekend inside a little room below the tower and here's what I've come up with.
What we had before:
We had three Rocket M5's on the tower at 263' with shielded Cat-6 Ethernet running into the building. The Ethernet cables were connected to lightning arrestors that were NOT grounded properly (it was 9:30 on a Saturday night and everyone said "We'll finish this up this week..." which never happened). From the lightning arrestors, they ran into a Ubiquit N Switch (the PoE injector switch). From that, a single cable ran back to the power source for the switch and then into Port 5 on a MikroTik hAP ac lite.
What we have now:
Same setup, except the lightning arrestors are properly grounded now. Currently, we do not have all of the nodes connected together. They are running into their own PoE injectors and the LAN cables are disconnected (except for one, which is controlling our DMR repeater). Ultimately, we're going to put another MikroTik in along with the Ubiquiti switch.
What I think happened:
We must have gotten some static electricity during the storm that started all of this. It went through the cables, and burned something out in the MikroTik. If I have the three nodes connected on their LAN ports, they knock each other offline. My assumption is that they are all fighting to be the DHCP controller for their little network, and that's why we had issues. The MikroTik was supposed to handle this, but it isn't. Which is why we're replacing it. Currently, with them not connected together, we have two that are rock solid and one that I think needs to be reflashed again. It had a bad cable end on it, so it might not have taken the reflash I did this weekend. I should add that the third node reboots every 20 seconds or so, and doesn't give a stable enough connection while it's up to check anything.
Myquestions:
1. On the three nodes, should I have the LAN host disabled? I think they're currently set to 5 hosts.
2. In the event that we run into another issue, where we have to take the MikroTik out of the equation, would I want to enable one node's LAN Host and leave the others disabled?
3. Do my theories sound plausible, or should I look somewhere else? I had noticed when I had each node plugged into a Netgear unmanaged switch, that they were rock solid (with the exception of the bad cable end on one), but when I plugged all three into the switch, two of them would shut off repeatedly. With them completely disconnected, we have LQ/NLQ of 100% on two nodes (one node is connected to another set of nodes and then to my apartment, and the other is connected to the user who's 11 miles away). The third node is the one I need to reflash.
Have a great day. :)
Patrick.
Current Neighbors LQ NLQ TxMbps Services
NC8Q-M3-192 (dtd) 100% 100% LinkQualityMgr
NC8Q-M3-83 (dtd) 100% 100% LinkQualityMgr
NC8Q-M9-NB (dtd) 100% 100% LinkQualityMgr
The above Ubiquiti devices, Nanostation M3(2) and a Nanobridge M9,
all '5 host Direct', are plugged into ports 2, 3, and 4, of a N-SW.
Port 1 of the N-SW is plugged into the POE port of an Ubiquiti POE-24-30W injector.
The LAN port of the injector is plugged into a 'NODE' port of my VLAN switch.
-----
My Mikrotik uAP is an active part of my local AREDN network.
I will re-test later replacing my VLAN switch with the DtD port 5 of my hAP.
73, Chuck
Hi, Patrick:
I have Ubiquiti ( loco-M2, M5-PBE-400, N-SW(3)) and Mikrotik (LHGs(5) and SXTs(3) and 1 hAP) devices in service.
So, when you identify the device you are referencing as 'the Mikrotik', my mind does not immediately think 'hAP'.
;-)
"My assumption is that they are all fighting to be the DHCP controller for their little network, and that's why we had issues. "
All the LHGs and SXTs that are on N-SWs are set to AREDN default: LAN set to '5 host Direct'.
When you use a N-SW each device's LAN is no longer accessible, so their LAN settings play no part.
Tell me about the POE injector you are using to power the N-SW.
I am successfully using the black Ubiquiti 24 volt 1.25 amp (POE 24-30W) injectors to power up to 3 devices.
1. On the three nodes, should I have the LAN host disabled? I think they're currently set to 5 hosts.
IMHO and experience, it does not matter.
Because I use VLAN switches where needed, I have zero (0) devices set to '1 host Direct'.
2. In the event that we run into another issue, where we have to take the MikroTik out of the equation, would I want to enable one node's LAN Host and leave the others disabled?
Not while using a N-SW plugged into port 5 of a Mikrotik hAP.
Without the hAP, yes you might want that to ensure that you always have access to that single Rockets LAN ports.
If you do not need access to an individual Rocket's LAN and are satisfied with RF/DtD connections, LAN configuration does not matter.
If you are not adding LAN services to any Rocket, LAN configuration does not matter.
The N-SW is an outdoor rated device.
"They are running into their own PoE injectors and the LAN cables are disconnected"
Sounds to me like you have cables from all 3 Rockets coming into a room (shielded from the weather?).
If true, what purpose does the N-SW serve?
If true, perhaps a VLAN capable switch would serve you better than a N-SW (and a Mikrotik hAP).
?
I hope this helps,
Chuck
We originally had everything mounted on a plate, with three PoE injectors. The N-Switch was meant to replace all of that, because we didn't want to have three cables running across the ceiling. I was the one who suggested that we mount the N-switch inside, because if it failed, we wouldn't have a climber readily available to fix it. We're using the same PoE injector that you are. I'll explain more...
When we first got into the building, we thought the N-Switch was the problem. So, we took it out and replaced it with an unmanaged Netgear switch connected to the MikroTik. That didn't solve the problem, and we had one node that was dead completely. So, I reflashed that node connecting it and my computer to the Netgear switch. It saw other nodes at 100%/100% on the same channel. So, I disconnected it and connected the second node (updated the firmware). It saw everything on that channel at 100%/100%. So, I repeated with the third node and had the same results. When I plugged all of them into the Netgear, I noticed that two of them would randomly go dead and come back. When I unplugged them all and just plugged one in, everything worked fine. Which is why I'm assuming they're fighting for DHCP control. Same results if I plugged the MikroTik hAP in with the node.
Tomorrow, I'm taking the N-Switch back out and plugging it back in. I'm also flashing a new MikroTik and taking it with me. Ultimately, the MikroTik is providing DtD for the nodes, and LAN access for a DMR repeater and a PTZ camera. If I have to, I could take an old Cisco switch out there and set that up. But, I would have to figure out the VLAN tags for the three nodes and everything else.
Have a great night. :)
Patrick.
Hi, Patrick:
" When I unplugged them all and just plugged one in, everything worked fine.
Which is why I'm assuming they're fighting for DHCP control."
I am suspect of the 30 watt POE.
Will each one Rocket work? Any 2 Rockets work? Obviously with all 3 there is a failure.
"When we first got into the building, we thought the N-Switch was the problem.
So, we took it out and replaced it with an unmanaged Netgear switch connected to the MikroTik."
"Replaced it with an unmanaged switch" and 3 POEs ? 12W or 24W or mixed?
I imagine the Rockets came with 24W POEs.
Can any one 24W POE power the N-SW and any 2 Rockets? ...N-SW and all 3 Rockets ?
The indoor-rated RB260GSP would replace the N-SW, but requires programming.
The RB260GSP supports up to 4 nodes and retains the one (DtD) cable.
3s, Chuck
What would be an easy way to test the output of the PoE for the N-Switch? I'd imagine making an ethernet cable with one end and putting a multimeter on the other won't work.
Have a great night. :)
Patrick.
Hi, Patrick:
I think not.
I tried to match your setup of
Ubiquiti: 3 Rockets, N-SW, POE-24-30W, Mikrotik hAP
with my
Ubiquiti: 2x Nanostations M3s, 1x Nanobridge M9, N-SW, POE-24-30W, Mikrotik-hAP.
DHCP 5 host Direct enabled on all 3 Ubiquiti devices.
There were no fights.
73, Chuck
POE testers aren't horribly expensive; they're one of those tools you rarely use but are indispensable when you need them.
I bought one of these from Amazon a while back and it proved its worth just this afternoon :-)
https://www.amazon.com/gp/product/B07TS2ZFMR/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Orv
W6BI
+1 with Orv.
https://www.amazon.com/NOYAFA-Ethernet-Continuity-Checking-Loop-Back/dp/B095LS8GWN&tag=arednmesh-20 ~$35.
3s, Chuck
So, I went back out to the tower and tried again. I'm getting frustrated with this, to say the least. Here's what I did.
I plugged one node into the Ubuquiti N-Switch and powered it up. It started rebooting constantly (it was the node that was providing our DMR repeater with Internet up until I walked in today). I switched out the PoE adapter and used the one that I've been powering it with (12 W PoE adapter with just one node plugged in through the switch). No difference.
I decided to reflash the node with the stable 3.22.1 firmware. When I did that, it loaded up the 192.168.1.1:8080 page without any problems. It let me go into setup. It let me reconfigure everything (took a while because my passwords didn't match). It rebooted. Once it rebooted, it started going into the reboot cycle again.
I did a second node with the exact same results. It's almost like DHCP doesn't work. To be clear about this, each node is plugged into its own PoE injector (12 W ones) and the only things plugged into the node were a cable going to the Netgear unmanaged switch and from that to my computer.
I'm starting to wonder if it's not the computer that I'm using. It's a laptop with Windows 10 on it. In the past it has been hit or miss on installing firmware to the nodes, and I do have an older laptop running Ubuntu Linux. Could that be the source of our problems? That maybe Windows corrupted the firmware or the configuration somehow? We're also considering the idea that we need shielded cables in the building. The cables going up to the nodes are triple-shielded direct-burial CAT-6. We're thinking maybe we need to go with at least shielded inside. Everything in there is just regular CAT-6 that you buy in the store.
I'm at a loss, as you can see and am grasping at straws.
Have a great day. :)
Patrick.
P.S. It's like I told our EC. Everything should be working, but it isn't. And everything that could possibly be the cause shouldn't be.
Maybe we should have started a new thread.
Hi, Patrick:
How do you determine that the Rocket is rebooting?
#11 "I should add that the third node reboots every 20 seconds or so, and doesn't give a stable enough connection while it's up to check anything."
#16 "Since it reboots constantly, it could have been causing the issues with the others when they were all plugged in together."
#21
- "I plugged one node into the Ubuquiti N-Switch and powered it up. It started rebooting constantly "
- "I decided to reflash the node with the stable 3.22.1 firmware. When I did that, it loaded up the 192.168.1.1:8080 page without any problems. It let me go into setup. It let me reconfigure everything (took a while because my passwords didn't match). It rebooted. Once it rebooted, it started going into the reboot cycle again.
- "I did a second node with the exact same results . It's almost like DHCP doesn't work. "
Is this with only one Rocket, one POE, and the computer plugged into the LAN port of the POE injector?
Or is the N-SW or 'unmanaged switch' in this test setup?
I am also baffled.
-----
On a different subject...
#21 "it was the node that was providing our DMR repeater with Internet up until I walked in today"
Does every Rocket and the hAP get internet via some other node on the network having "Allow others to use my WAN" enabled"?
IOW, how is that one Rocket "providing our DMR repeater with Internet" ?
Yet another subject...
About that long cable run and the arrestors...how long is the cable run now?
Have you tested without the arrestors?
Maybe they have served their purpose and arrested some lightning and are now in a failed state?
Due to having inline arrestors and a 263' cable run, maybe you need those inline ethernet switch (signal booster) devices.
73, Chuck
#11/#16 The few times that I've been able to get into the node's administration and see it before it reboots, the uptime says 0:00 to 0:01 and then the link goes dead. If it comes back up for me to see again, it's back to 0:00. I'm assuming it's rebooting since the link light goes out on the switch and that uptime acts like it is. I should clarify that I'm usually able to see the status page, and might be able to get an initial look at the mesh status or the setup page, but then when I refresh, the page comes up as "Cannot be displayed" until it's finished bringing the link back up. That's why I said ti's not stable enough to check anything.
With the question about when I reflashed it, I had my computer plugged into one port on the unmanaged Netgear, and one Rocket plugged into another port. Nothing else was plugged in. I was doing it that way, because I'm under the impression that you're supposed to use a "dumb switch" in between them when flashing (per all of the documents and videos I've seen here).
Additionally, I'm leaning towards the computer having messed something up, just because in the past I've had issues with it flashing nodes (especially using TFTP), but those same nodes took perfectly when using my Linux laptop. I was having an issue with the linux laptop, which is why I didn't use it.
#21... Yes. So, we have three nodes in the tower. The South node connects to nodes downtown, which in turn connect to my apartment (and provides Internet). That was rock solid on Saturday afternoon, and I had the DMR repeater plugged into that LAN port via the Netgear dumb switch. I went in yesterday and tried plugging the node into the Ubiquiti switch and it started doing the same thing as the others (link light shutting off about every 30 seconds to a minute).
The NW node eventually will be our main Internet hub. It will be connected directly to a node with a 250 Mbit connection, whereas mine is indirectly connected and a 40 Mbit connection. And the NE Node connects to Scott's house 11 miles away, where he has his Internet turned on. So all nodes have the "Allow others to use my WAN" turned on. If it's a case of we need to only rely on one, then it will be the NW node.
You're baffled too, which is good (because I don't feel alone. :-) ). Like I said, it's odd. When I get them to flash, they sit happily waiting to be configured. Once I configure them, then the problems start. I'm assuming this to be true, as short of plugging a computer in and constantly refreshing the node status "N0CALL-..." page, I don't know for sure. But, I'm able to enter setup, make changes, screw up changes and have it not save the configuration, make the changes again, rinse, repeat a few more times (darn long passwords) and then finally save and get it to reboot. When I switch to DHCP on my computer and try going to 'localnode.local.mesh:8080, that's when the problems show up.
The cables are 300' long, triple shielded on both ends. Sadly, we didn't use a cable tester on them before installing, but we did find one bad end and replaced it. Hindsight... I've tried both with and without the lightning arrestors in the pathway. The arrestors are connected to 3' cables between them and hte N-Switch or the PoE injector. So, are you suggesting something like about halfway up the run, putting the signal booster devices?
Have a great day. :)
Patrick.
What Patrick didn't disclose... is that this exact configuration ran perfectly for over three weeks. My dish at 11 miles away was a solid 100/100 connect prior to these issues. Rather something else was added to the comm building at the base of the tower... we don't know. When the nodes were not connected together for over 24 hours, I had a solid 100/00 connect non-stop. Its only when we try to tie the nodes together that we have issues. They run standing alone perfectly. (At least the NE node I am aimed at did).The reason I have a hard time adjusting my dish is because it is on a crank-up tower. I have to adjust it at 21' AGL where I can not see the tower. Then raise the tower to get it to 50' where I can see the tower.
Maybe we should have started a new thread.
" When the nodes were not connected together for over 24 hours, I had a solid 100/00 connect non-stop.
Its only when we try to tie the nodes together that we have issues."
#20 +1 Jim K6CCC
You may not need a VLAN switch (hAP) if the DMR repeater is the passive/client end of the link.
i.e. If the DMR repeater initiates a connection to a server on the internet, then it does not matter from which Rocket it gets its IP address via DHCP.
IOW, 3 Rockets, 3 POEs, 1 unmanaged switch, 1 DMR repeater's ethernet device.
73, Chuck
The reason we went with the hAP is so the DMR repeater and a PTZ camera could be advertised services on the mesh. If we plug them into the dumb switch and let the nodes randomly assign the DHCP address, is there a way to force the same node to give them IP addresses? I'm going to say "Yes... Turn off DHCP on two nodes, and let one do the work."
I think part of our issue is a misunderstanding of how the whole system works (especially with the hAP in place). So let me see if this is accurate...
On the hAP, Port 1 is the WAN connection (to the Internet), Ports 2, 3, and 4, are LAN connections and Port 5 is essentially a trunking connection with sub interfaces (one for each node connected to it). It doesn't assign IP addresses to the nodes that are connected, it just routes traffic between them (trunking, in Cisco terms). If the traffic is destined for the Internet, it routes it to Port 1. If it's destined for one of the LAN devices, it routes it there. If it's destined for the other nodes, it routes it through the subinterfaces back to the node on Port 5.
If that's accurate, how does it work if they're all connected together through a dumb switch and nothing else? Let's say that node 1 is on Port 1, node 2 is on Port 2, and node 3 is on Port 3. Do the nodes listen for packets with either their mesh IP address or the IP address inside of their LAN? This is the part that confuses me unless I'm confused about the way the whole system works.
Have a great day. :)
Patrick.
"If that's accurate, how does it work if they're all connected together through a dumb switch and nothing else? Let's say that node 1 is on Port 1, node 2 is on Port 2, and node 3 is on Port 3. Do the nodes listen for packets with either their mesh IP address or the IP address inside of their LAN? This is the part that confuses me unless I'm confused about the way the whole system works."
"how does it work if they're all connected together through a dumb switch"
It does not work this way.
On the hAP, not all the ports are connected to a 'dumb' switch.
Port 1 would connect to a port on a the LAN of a home router.
If you wanted to expand the number of LAN ports on a hAP, you could connect port 2 or 3 or 4 into a dumb switch.
If you wanted to DtD connect the hAP to more than one node, you could connect port 5 of the hAP to a dumb switch and the LAN ports of the nodes that you want DtD'ed to this same dumb switch.
You would not plug (Port 1 and Ports 2,3,4) or (Port 1 and Port 5) into the same dumb switch.
You would not plug (port 2 or 3 or 4) and (Port 5) into the same dumb switch.
-----
If you have internet access at the site plug port 1 of the hAP to the internet source, else no connection.
Plug the DMR repeater into port 2 or 3 or 4.
Plug the camera into port 2 or 3 or 4.
Plug port 5 of the hAP and the 3 Rockets into a dumb switch.
If you have internet access off-site and need to provide only the DMR repeater with internet,
you may need more equipment.
73, Chuck
What I meant was, if my idea of how all of the routing works on a hAP is correct, then how would it work if there wasn't a hAP in the system. In place of the hAP, there's just an unmanaged "dumb" switch. After I posted it, it occurred to me that the devices and nodes are all on the switch. So, if packets are sent to the IP address of a device, it will answer for itself. The only time it will really need the node is when it needs to get packets out of the LAN.
My questions were meant to be generic in nature. In our case, nothing is plugged into Port 1 on the hAP. The repeater and camera are in Ports 2 and 3, and the nodes are in Port 5. Whichever node is determined to be the best route to the Internet is where everything will be routed.
I'm used to thinking in terms of Cisco equipment, with trunking and sub-interfaces on the router. DtD and OLSR is different, even though the concepts are similar.
Have a great day. :)
Patrick.
If the LAN ports of the three nodes are connected to the same switch, correct, only one should operate as a DHCP server. You CAN have multiple nodes LAN ports on the same dumb switch as long as only one is operating as the DHCP server. Devices can be forced onto the LAN IP address space for one of the other nodes by giving that device a static IP on the desired node's LAN IP space.
For example my hAP-at-home has a LAN IP space of 10.9.60.80/28 (meaning that the LAN IP of that hAP is 10.9.60.81, and it will assign IP addresses between 10.9.60.82 and 10.9.60.94). My hAP-Portable has a LAN IP space of 10.2.64.72/29 (meaning that the LAN IP of the hAP will be 10.2.640.73 and it will assign IP addresses between 10.2.64.74 and 10.2.64.78). If I were to connect a LAN port of both of those hAP nodes to a dumb LAN switch, a device that were to be connected to that LAN switch and requests a DHCP address would somewhat randomly be assigned an address in one of those two ranges. If I were to turn off DHCP on the hAP-Portable, all DHCP requests would be filled by the hAP-at-Home. However if I were to give a device a static address of for example, 10.2.64.74, it would be operating on the hAP-Portable LAN space. Make sense?
Largely correct. Port 5 is referred to as the Device to Device (or DtD) port. It only connects to other DtD ports. It is always configured on VLAN 2 (unless you play linux games - don't). MOST dumb LAN switches will pass the VLAN tagged traffic, but some will not.
The DtD ports have an IP address that is one number higher in the second octet than the RF port. For example, my previously mention hAP-at-Home has an RF port IP of 10.32.147.197 and the DtD port has an IP of 10.33.147.197. The node's IP addresses are NORMALLY assigned based on a formula based on the MAC address.
No different than any other computers on a LAN, they listen for their own addresses. A node can be reached via any of it's IP addresses. Not gonna take the time for a routing class here. Suffice it to say that each node also operates as a gateway for devices operating on it's IP LAN space.