Cluster Setup Issue – IP Configuration Error on Secondary Node
Cluster Setup Issue – IP Configuration Error on Secondary Node
Hello TP-Link Team,
I'm currently trying to configure an Omada Controller Cluster using the official guide:
🔗 https://www.tp-link.com/br/support/faq/4348/
🖥️ My Setup
Primary OC Software:
-
WAN IP:
143.0.0.127(behind NAT →192.168.0.2)
Secondary OC Software:
-
WAN IP:
177.153.20.155(no NAT, public IP directly assigned)
⚙️ Issue
When I start the cluster, the Primary Node shows as Connected successfully.
However, the Secondary Node fails to join and displays an “IP configuration error”, asking to review the IP settings.
🔍 Troubleshooting Done
I suspected it could be related to the ISP or some firewall rule (Firewalld/CSF), so I tested again in a local environment:
-
Primary: LAN IP
192.168.0.2 -
Secondary: LAN IP
192.168.0.8
In this test, the Primary Node starts normally, but when the Secondary Node tries to start, it still shows the same “IP configuration error”.
❓ Questions
Could this issue be related to:
-
The use of NAT on the primary node (public IP ≠ LAN IP)?
-
The IP detection mechanism of Omada not handling NATed or mixed network setups correctly?
-
Or a missing configuration in
omada_distributed_internal_mongo_cluster.propertiesorsystem.propertiesto support this scenario?
💬 Request
Any guidance, tips, or example configuration (especially when one node is behind NAT) would be greatly appreciated.
Thanks in advance! 🙏
Hi @gui1porpis
Thanks for posting here.
NAT should not be the issue or the root cause. As mentioned in the article, we recommend installing both controllers within the same subnet.
Therefore, if possible, we suggest moving the secondary controller from the public network to the same subnet as the primary controller and then attempting the configuration again.
You mentioned encountering the same error during testing within the same subnet—could you please share a screenshot of the error message with us?
To confirm, do you use Omada software-based controllers? Or hardware controllers, such as OC300?
Hi @gui1porpis
Thanks for posting here.
NAT should not be the issue or the root cause. As mentioned in the article, we recommend installing both controllers within the same subnet.
Therefore, if possible, we suggest moving the secondary controller from the public network to the same subnet as the primary controller and then attempting the configuration again.
You mentioned encountering the same error during testing within the same subnet—could you please share a screenshot of the error message with us?
To confirm, do you use Omada software-based controllers? Or hardware controllers, such as OC300?
Good morning,
I have an OC300 and initially tried setting it up using Software X Hardware, but it returned a compatibility error—this was before I found the FAQ.
As mentioned above, I also tried using two external OC Soft devices, but without success. The photos below show two internal OC Soft devices (on the same subnet), but again, it didn’t work.
Note: The initialization of NODE 2 took almost 20–30 minutes, and even then it returned an error as if it were a fresh installation. However, the Cluster tab remained populated (as shown in the photo).
Here are the machine configurations:
Node1: CPU 4x Intel(R) N97 - 16Gb Ram - 1TB NvME - AlmaLinux 8 - MongoDB 8.0
Node2: CPU 4x Intel(R) Atom(TM) CPU 330 @ 1.60GHz - 3Gb de Ram - 1TB HDD - Centos7 - MongoDB 4.4
Note: I had even given up on the Cluster, and removed everything where Node 2 was going to be, installed it and tried to reconfigure it again just to continue with the Topic.
Note 2: In the first post I had talked about the LAN IPs 192.168.0.2 and 192.168.0.8, but I left one organized on the internal network here, and they were changed above, but the logic is the same.
I'll wait.
Hi @gui1porpis
Thanks for the reply.
Please also share a screenshot of the Cluster Node list for our reference:
@Vincent-TP
Node 1 (main)
Node 2 (secondary)
When trying to start Node 2, it keeps loading (trying to start for a long time, until it gives an error) (print putty), unlike Node 1 which loads as if it were a normal start.