More sophisticated startup/adoption need for Omada Routers
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Problem: replacing or upgrading a router in a multi-site environment (exactly the kind of solution Omada seems to be targeting).
Issues:
- defaulted or forgotten devices all power up as 192.168.0.1/24 and VLAN=1 regardless of site settings
- above can be an issue if one site IS actually using the default IP space (which one often does to at least make managing at least 1 site easier) and/or default routes are created
- DHCP is activated with above settings which causes some devices to re-IP in a completely different subnet than their peers (which breaks a lot of stuff)
- Often the primary site switch needs to be reset which forces ALL devices to re-IP on default subnet
- The ensuing reboot/adopt/configure/reboot/adopt sequence goes on for a long time
- Seems to require that the new router be pre-configured with the non-standard subnet before any of this begins to avoid death spiral during adoption (Adopt Failed errors)
Suggestions:
1. Power up Router with default IP settings, but leave DHCP temporarily disabled
2. Sniff traffic for management frames from a controller for a set period of time and quietly re-adjust subnet to match those if found
3. Once successfully adopted and configured, then (re) enable DHCP, VPN etc.
Extra Ideas:
Currently when transitioning between router models, there is a pop up screen that allows the user to map existing WAN and LAN networks to specific physical ports. This overwrites some settings in those network definitions, which means they have to be re-done later (ie gateway speed settings). I would suggest instead that multiple router models be permitted for a site, with the network<->port mappings retained for each.
Hi @d0ugmac1
1. The router is never intended to work in that way as when it powers up, the default VLAN 1 is set to be DHCP server = enabled. For this idea, that would require an additional window to ask the user if the DHCP should be enabled or not.
And, if the DHCP server is not enabled, for most customers, the first when they log in to the router, they have to set an IP address like what we have in the CPE product. That would be very demanding for newbies.
2. The packet is sent from the devices by default. If you wireshark, you can see the devices actively broadcast the packet to find the controller. The controller remains silent all the time and detects packets that fit the identity of an Omada product.
Which ports do Omada Controller and EAP Discovery Utility use?
What you suggest make the controller actively send broadcast to the network. This could complicate things. You have to send broadcast packets back and forth several times to finish this handshake.
What you suggest in point 2, I understand it. But this saves a few clicks and reboots. The idea is to give enough freedom to customers so they can take control of their network. This is helpful for some newbies and is like automation.
Anyway, will bring your feedback to the team for further evaluation. 