Hi@Kockel 

Is the Sonic wall the DHCP server in the network?

The MAP on the controller looks different as you described. Can you please explain how you connect the sonic wall, the two switches, and the EAPs?

Are the two switches plugged into the SonicWall separately? 

Sonic---SG2428P

  ||

  ||

SG3428

Or do they plug in a chain?

Sonic---SG2428P--SG3428

We also need to know the port profiles on the switches.

  @Kockel 

Hi @Vincent

They are indeed plugged in seperately.

Topology :

Sonicwall (LAN Interface X0) >> TL-SG2428P Port 24 >> Clients

Sonicwall (LAN Interface X2) >> TL-SG3428 Port 24 >> Clients 

X0 and X2 are 2 different ports but behave as an "internal switch" on Sonicwall level.

Sonicwall is indeed the DHCP Server.

But the switches have a static IP address

Port Profile : 
 

Native Network ; LAN(1)

Tagged Network : VLAN28-29-99
Untagged Network : LAN(1)

  @Kockel 

Some More info : 

The Sonicwall has 4 VLANs with corresponding Interface IP's

LAN >> Vlan 1 >> IP 192.168.27.1

Guest >> Vlan 28 >> IP 192.168.28.1

Alarm >> Vlan 29 >> IP 192.168.29.1

Mgmt >> Vlan 99 >> IP 192.168.99.1

I see that omada controller /switches continously see the Sonicwall on the different IP"s to "hop".
Everytime you see a Sonicwall entry in the log it changed to another network, so does the IP... 

Hi  @Kockel 

Possible Causes

• VLAN Configuration: There might be VLANs configured on the SonicWall and the switches that are not properly aligned. If VLAN tagging is inconsistent between the SonicWall and the switches, it could lead to the SonicWall appearing with different IPs depending on which VLAN traffic is traversing through.
• DHCP Relay or IP Assignment: The SonicWall, as the DHCP server, might be misconfigured in terms of how it's relaying IP addresses to the clients behind the switches. There could be a problem with the DHCP scope or the way it's handling requests from different sub - networks.
• Routing and Interface Settings: The internal routing settings on the SonicWall for the X0 and X2 interfaces could be incorrect. If the SonicWall is routing traffic between these interfaces in an unexpected way, it could result in the observed IP - hopping behavior.

Troubleshooting Steps

• Check VLAN Configurations: Review the VLAN settings on both the SonicWall and the switches. Make sure that the VLAN IDs, tagging, and untagging settings are consistent across all devices. If there are any mismatches, correct them and see if the IP - hopping issue persists.
• Inspect DHCP Settings: On the SonicWall, examine the DHCP server settings. Check the scopes, reservations, and relay configurations. Ensure that the DHCP server is correctly assigning IPs to the clients connected to the different switches and that there are no overlapping or incorrect IP ranges.
• Review SonicWall Interface and Routing Settings: Look at the settings for the X0 and X2 interfaces on the SonicWall. Check the IP addresses assigned to these interfaces, the subnet masks, and the routing policies. Make sure that the SonicWall is not misrouting traffic between these interfaces and that the IP addresses are stable and correct.

  @Kockel 

Hi Vincent, honestly, I seem to disagree.

We have this setup running on several sites, with (almost) identical setups.

I think we need to look at this topic : 

https://community.tp-link.com/en/business/forum/topic/584402

Apparantly it has to do with the client detection mechanism in the controller.

Can you confirm this might be the cause?

I will look further into the other connection problems.

Hi  @Kockel 

Sorry for the late reply and thanks for the sharing.

From that thread, seems like it's normal to see these logs.

Let's focus on the issues you are having. Could you please let us know more details about it?

You mentioned the phone calls are not stable; how about other Internet activities?

Side note: Please make sure you are tagging a TP-Link Admin if you want a timely response. Unless we are tagged we do not see that new responses have been added. We do not subscribe to every thread so rely on Tagging to ensure responses.