Clients in MESH are displayed incompletely
Since apparently the German community is not so strongly represented, I try it again in the English-speaking forum:
The following setup: SG2428P > EAP610-Outdoor > EAP225-Outdoor > SG1005P > LAN Clients
All clients connected to the SG1005P are arranged wrong.
According to the OC200 controller, they are connected to the port on the SG2428P where the EAP610-Outdoor is actually connected.
Practically, however, they should be displayed "behind" the EAP225-Outdoor.
But behind the EAP225-Outdoor only clients connected via WLAN are displayed.
Is there a way to manually place the clients in the correct position?
Would e.g. a SG2008P (Omada "capable") solve the problem, or is it then also shown as directly connected to the port already occupied by EAP610-Outdoor?
Is there perhaps a 5 port counterpart to SG2008P?
Thanks a lot
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
AngelK wrote
Since apparently the German community is not so strongly vertretten, I try it again in the English-speaking forum:
The following setup: SG2428P > EAP610-Outdoor > EAP225-Outdoor > SG1005P > LAN Clients
All clients connected to the SG1005P are arranged wrong.
According to the OC200 controller, they are connected to the port on the SG2428P where the EAP610-Outdoor is actually connected.Practically, however, they should be displayed "behind" the EAP225-Outdoor.
But behind the EAP225-Outdoor only clients connected via WLAN are displayed.
Is there a way to manually place the clients in the correct position?
Would e.g. a SG2008P (Omada "capable") solve the problem, or is it then also shown as directly connected to the port already occupied by EAP610-Outdoor?
Is there perhaps a 5 port counterpart to SG2008P?
Thanks a lot
@AngelK If I remember correctly, the SG1005P is an unmanaged switch & therefore not controllable or compatible with the Omada system. You could try changing to the SG200P which is controllable with OC200
- Copy Link
- Report Inappropriate Content
@GaelForce: Yes, the SG1005P is unmanaged, however the OC200 should still be able to detect that the packets are coming from behind the last Omada managed device. This would not be the switch port on the SG2428P, but the EAP225-Outdoor. Following this logic, the actual traffic between EAP610-Outdoor and EAP225-Outdoor is also never shown, although the packets from LAN device behind the SG1005P pass over the mesh bridge (EAP610-Outdoor <> EAP225-Outdoor) and actually have to be considered as traffic. How else should the correct utilization of the EAPs be calculated?
- Copy Link
- Report Inappropriate Content
AngelK wrote
@GaelForce: Yes, the SG1005P is unmanaged, however the OC200 should still be able to detect that the packets are coming from behind the last Omada managed device. This would not be the switch port on the SG2428P, but the EAP225-Outdoor. Following this logic, the actual traffic between EAP610-Outdoor and EAP225-Outdoor is also never shown, although the packets from LAN device behind the SG1005P pass over the mesh bridge (EAP610-Outdoor <> EAP225-Outdoor) and actually have to be considered as traffic. How else should the correct utilization of the EAPs be calculated?
@AngelK The OC200 can indeed see that a stream is coming in from the 1005P but that device is NOT a client on the EAP225-Outdoor, just a data point. As such it is not on an SSID but on the mesh backbone. The first point that will be capable of dissecting & reporting will be SG2428P, NOT the EAP's. If a managed switch was used in place of the SG 1005P under the control of the OC200, then reporting would be from that device & not from the SG2428P.
- Copy Link
- Report Inappropriate Content
This is the correct behaviour. Using a mesh link via the hardware ports is functionally equivalent to that mesh link being an ethernet cable. As such anything plugged on the far end of the mesh appears as if plugged into the same switchport as the near-end mesh AP. As @GaelForce stated above, if you want to 'see' far end clients mapped to ports, you need to install a managed switch there (ie SG2008(P) )
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
AngelK wrote
Could it be because the ER605 router is not yet connected (another non Omada router is doing routing and DHCP) and therefore the traffic of the clients cannot be displayed? The clients connected to the SG1005P produce about 40GB of traffic in 24 hours, but I can't see this anywhere at the moment. In fact, only the traffic produced by WiFi clients logged on to the EAPs is counted. Maybe everything will be different when the ER605 does routing and DHCP.
@AngelK Your problem has nothing to do with the router, a fact that you have already confirmed by stating that you can see client data from the EAP's. As I have already stated, the data flow coming from the SG1005P is just a stream (everything combined) which the OC200 is unable to decode or log as the SG1005P is an unmanaged switch. To get what you require needs a TP-Link managed switch integrated into the Omada system. Then & only then will your data be logged.
- Copy Link
- Report Inappropriate Content
But I don't understand that now: if 40 GB of data is moved between EAP610 and EAP225, you have to see it somewhere, regardless of whether the data comes behind a non-omada managed device or not. The EAPs are both Omada managed and have promoted 40 GB 0 and 1.
If 40GB is transmitted via the wifi bridge, the wifi channel is utilized. If this is not recorded because the polluters are not wifi clients, then the OC200/Omada simply shows incorrect utilization values and that cannot be correct.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 778
Replies: 8
Voters 0
No one has voted for it yet.