SG2210P V5.0 not detected at all by omada controller 5.0.9
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Hi,
I am using SG2210P V5. The interface configuration on switch looks like this 
Omada controller is at 10.0.99.16. This switch's IP address is 10.0.99.11. They are both in the same layer 2 network and I can reach it from the omada controller without any problems.
The problem is, Omada controller fails to find it on the devices list. I tried the omada discover utility and it also can not find the switch. Both of these, The controller and the discover utility see my other switch SG2210MP v1that's also in the same L2 network.
I have tried resetting SG2210P in the past and it has not helped at all, I still can not adopt it.
Please let me know how to debug this ?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
ether1 on router connected to port 4 on SG2210MP
ether2 on router connected to port 1 on SG2210P
EAP245 AP connected to port 2 on SG2210P.
Proxmox VM/Omada controller connected to ether3 on the router.
> from the switch, can you use diagnostics to ping the controller IP? work?
Yes, This works perfectly fine. I can ping the controller from both switches and I can also see the Omada controller's MAC address in the ARP table on the switches.
> have you tried to modify 1/0/1 to be 99 untagged pvid 99?
I have not. The router is configured to only accepted tagged traffic and drop all untagged traffic. Making this change will render the switch unreachable.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
but what you configured is not correct.
i understand that your router only receives ingress with a tag frame. settings 99 to untagged should be fine. as you can set pvid on your router as well.
what's the point in settings 1 and 4? you don't have lag. so, one of the ports is gonna be blocked
is there necessary to use 9214? is the router set to mtu 9214 as well?
tbh, Ive never seen something strange like this. your config is quite unconventional to me and i pointed out what i would usually do. i don't have any other better ideas if you don't try.
(p.s. where did you learn vlan? by practice and training or from some kind of tutorial online? is vlan supposed to work like what you configured? at least contradictory to what i learned)
- Copy Link
- Report Inappropriate Content
@Tedd404
> settings 99 to untagged should be fine. as you can set pvid on your router as well.
I tried this out. I set it to accept untagged traffic and pvid=99.
> what's the point in settings 1 and 4? you don't have lag. so, one of the ports is gonna be blocked
Sorry, What do you mean here ?
> is there necessary to use 9214? is the router set to mtu 9214 as well?
Yes it is. I use 9214 L2 MTU and 9000 L3 MTU in my local network(on all switches/routers and some devices). In this context, I have also tested by setting l3 mtu to 1500 and l2 mtu to 1518 and I still had all these problems.
> (p.s. where did you learn vlan? by practice and training or from some kind of tutorial online? is vlan supposed to work like what you configured? at least contradictory to what i learned)
By practicing a lot and asking for help in online networking groups(reddit / discord / irc / telegram)
- Copy Link
- Report Inappropriate Content
I hope @Clive_A or some other TP Link employee responds in this thread. Please help me understand why this does not work and how exactly does discovery work in the omada universe?
Is it only relying on LLDP packets ? The switch does not add VLAN tags to LLDP packets. They are dropped if I enable router to only accept tagged frames. If I configure router to accept every thing, I can see the LLDP packets in the router.
I can see LLDP packets after I connect the device running omada controller or omada discover utility directly to the switch but omada controller nor omada discover utility can see the switch so what is going on??
- Copy Link
- Report Inappropriate Content
Hi @ishanjain28
I don't have any better answers for you. So, the device is supposed to proactively send the discovery packet to the whole subnet. Broadcast.
But yours does not, I would suggest you reset the switch and start over so that you can verify that the switch is actually working. (So that we rule out the hardware issue or software bug)
Next, based on the fresh start, you start to configure VLAN. After the VLAN creation, check if the Omada Controller can discover the Switch.
If no, post the config and your network diagram. Don't configure other parameters before we figure out what's wrong.
- Copy Link
- Report Inappropriate Content
Hi @Clive_A, I debugged this a bit further and found the root cause.
I'd like to file two bug reports with TP Link and I am really hoping these are resolved.
This is for the people passing by(now and in future). I'll cover the bug with my this switch.
TP Link omada series does not use LLDP, MDNS or any other standardized protocol for device discovery. Instead, The device broadcasts a UDP packet in the management vlan at some intervals. This packet is seen by the omada controller which then offers the option to adopt it.
The bug in SG2210P is that it only broadcasts this packet in vlan1 even when you have not configured any IP address in VLAN 1 and you are using some other VLAN ID for management!
So, I could see the switch on a device connected to directly connected to switch with this config.
!TL-SG2210P
vlan 99
name test
system-time ntp UTC+08:00 139.78.100.163 199.165.76.11 12 140.142.16.34 128.138.140.44 129.7.1.66
no system-time dst
user name admin privilege admin secret 5 $1$E<F:N>K7F1@9O<O=D:A4J7O1M:A2H8N6{[}-%
no service reset-disable
snmp-server
power inline consumption 61.0
no controller cloud-based
no controller cloud-based privacy-policy
interface vlan 1
ip address-alloc dhcp
ipv6 enable
interface gigabitEthernet 1/0/1
interface gigabitEthernet 1/0/2
interface gigabitEthernet 1/0/3
interface gigabitEthernet 1/0/4
interface gigabitEthernet 1/0/5
switchport general allowed vlan 1 untagged
no switchport check ingress
switchport pvid 1
interface gigabitEthernet 1/0/6
interface gigabitEthernet 1/0/7
interface gigabitEthernet 1/0/8
interface gigabitEthernet 1/0/9
interface gigabitEthernet 1/0/10
end
but I could not see the switch when the switch had this config.
!TL-SG2210P
vlan 99
name test
system-time ntp UTC+08:00 139.78.100.163 199.165.76.11 12 140.142.16.34 128.138.140.44 129.7.1.66
no system-time dst
user name admin privilege admin secret 5 $1$E<F:N>K7F1@9O<O=D:A4J7O1M:A2H8N6{[}-%
no service reset-disable
snmp-server
power inline consumption 61.0
no controller cloud-based
no controller cloud-based privacy-policy
interface vlan 99
ip address-alloc dhcp
ipv6 enable
interface gigabitEthernet 1/0/1
interface gigabitEthernet 1/0/2
interface gigabitEthernet 1/0/3
interface gigabitEthernet 1/0/4
interface gigabitEthernet 1/0/5
switchport general allowed vlan 99 untagged
no switchport check ingress
switchport pvid 99
interface gigabitEthernet 1/0/6
interface gigabitEthernet 1/0/7
interface gigabitEthernet 1/0/8
interface gigabitEthernet 1/0/9
interface gigabitEthernet 1/0/10
end
All I have changed here is, Added vlan 99 and made port5 a access port in vlan 99. I also created a dhcp server on the device running omada controller so tp link switch can fetch an IP for itself and I can access it's web interface.
SG2210MP has a command like, `ip management-vlan <vlan-id>`. This command does not exist in SG2210P CLI. Please add this command or fix the firmware to send that discovery packet in all configured interfaces.
Next up, Is the reason behind why my SG2210MP stopped being discovered by the controller after I de-adopted it.
I adopted it, removed it because of a bug(i'll discuss that next) and then it was not discoverable by the controller any more.
This is because management vlan changes in SG2210MP require a reboot. Without a reboot, It'll keep sending broadcasts in vlan 1(the default vlan) instead of sending it in the new management vlan.
The third point is, Omada controller today does not allow purely trunk ports. It forces you to have all ports be either hybrid or access ports. It does this by forcing thet native vlan to be untagged while also allowing other tagged vlans on that port. This limitation is arbitrary and only enforced by the controller. The switch's standalone firmware does not have this limitation.
Please consider asking the dev team to remove this requirement. Thank you
Let me know if I can help with this in any way and please let me know if this is perhaps not the right place to file bugs and where I can actually do that. Thank you for reading all this!
- Copy Link
- Report Inappropriate Content
Also pinging @Tedd404 since they may find this interesting.
- Copy Link
- Report Inappropriate Content
>The third point is, Omada controller today does not allow purely trunk ports. It forces you to have all ports be either hybrid or access ports. It does this by forcing thet native vlan to be untagged while also allowing other tagged vlans on that port. This limitation is arbitrary and only enforced by the controller. The switch's standalone firmware does not have this limitation.
One example of where this causes problems.
I have Omada Access points with management vlan set to 99 and connected to omada switches. All of my Omada APs create SSIDs in different VLANs. In this scenario, I'll have to configure the switch to be a purely trunk port. A hybrid port with native vlan set to the management vlan willl not work. The controller will force native(management) vlan to be untagged and that'll render the access point's interface unreachable.
- Copy Link
- Report Inappropriate Content
Hi @ishanjain28
Thanks for posting in our business forum.
ishanjain28 wrote
TP Link omada series does not use LLDP, MDNS or any other standardized protocol for device discovery. Instead, The device broadcasts a UDP packet in the management vlan at some intervals. This packet is seen by the omada controller which then offers the option to adopt it.
First, at the very beginning of this long back-and-forth conversation, I have said and pointed out how the broadcast works and if you use a different VLAN, you should try the discovery utility to point the Controller's IP address.
Second, I am unsure about the term you use for "management VLAN" as we have a technical term on our Omada Controller called "Management VLAN". How to Configure Management VLAN on TP-Link Smart and Managed Switches Using the New GUI
Or How to configure Management VLAN in Omada SDN Controller (4.4.4 or above)
Third, if you are configuring 802.1Q VLAN, then packets between the VLAN are isolated. No matter what you try, unicast or use discovery utility. The point of the 802.1Q VLAN is to isolate the VLAN.
I think you should tell the difference between "VLAN interface" and "802.1Q VLAN".
In your backup, I don't know how did you delete VLAN 1. But to do what you want, I think you probably do it in a wrong order which makes the switch "unseen" by the Controller.
ishanjain28 wrote
Next up, Is the reason behind why my SG2210MP stopped being discovered by the controller after I de-adopted it.
I adopted it, removed it because of a bug(i'll discuss that next) and then it was not discoverable by the controller any more.
This is because management vlan changes in SG2210MP require a reboot. Without a reboot, It'll keep sending broadcasts in vlan 1(the default vlan) instead of sending it in the new management vlan.
Mechanism of the forget/adopt is that either way, you reset the switch after the command you set.
The switch resets itself and all config are lost after the forget/adopt.
If it falls back to VLAN 1, of course, you cannot find it in VLAN 99 as it broadcasts in VLAN 1.
But I don't find your VLAN 1 in the backup you posted above. Is that because you deleted it by CLI? Again, if you use 802.1Q VLAN, no matter what you do, there is no way you can make it discoverable if the controller is on another VLAN.
ishanjain28 wrote
The third point is, Omada controller today does not allow purely trunk ports. It forces you to have all ports be either hybrid or access ports. It does this by forcing thet native vlan to be untagged while also allowing other tagged vlans on that port. This limitation is arbitrary and only enforced by the controller. The switch's standalone firmware does not have this limitation.
Please consider asking the dev team to remove this requirement. Thank you
Let me know if I can help with this in any way and please let me know if this is perhaps not the right place to file bugs and where I can actually do that. Thank you for reading all this!
All switches we have cannot remove the native vlan(untagged) in standalone mode ever since Omada Controller was introduced. As far as I can see, there is no need to remove that as our goal is to integrate the Omada networking devices with the Omada solution(if you use the Omada Controller and the current VLAN setup can meet all Omada Controller features and functions). I mean if you are simply using our switch, would be better to use it standalone as certain features are not available in Omada Controller mode. There is a very small chance that we will change that to meet your expectation.
Quote your #20 post:
I have Omada Access points with management vlan set to 99 and connected to omada switches. All of my Omada APs create SSIDs in different VLANs. In this scenario, I'll have to configure the switch to be a purely trunk port. A hybrid port with native vlan set to the management vlan willl not work. The controller will force native(management) vlan to be untagged and that'll render the access point's interface unreachable.
No. I don't think so. Native VLAN does not interfere with it at all as we have seen tons of cases with Native VLAN enabled and there is no negative effect on it or any report from the customers. Ever since my work, I have not seen anyone complain about native VLAN causing trouble for them.
I'll do some verification on the VLAN you said above. this week when I have time for it.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 2495
Replies: 24
Voters 0
No one has voted for it yet.