Dynamic IP type customer

[drwho17]

I need the Ubiquity EMS to be able to track IP changes within clients. It appears the client/server scenario we see now isn't reflecting changes to the IP in the EMS interface. We are using PPPoE and the ip's for customer change from time to time, I believe the EMS should be able to track these changes. I believe most larger deployments handle IP management in a similar manner.

"Sticky IP"'s only work if the IP is available upon the client reconnect, however if you have a large amount of clients in the thousands or 10's of thousands these IP's get snapped up before the Ubiquity radio can reboot or try to reauth to claim it's ip again.

[UBNT-Thomas]

I'm also wondering what the correct behavior should be for dynamic IP type customers (pppoe assigned in my case). It seems that once I've enabled management on them, if they reauth with a new IP the display isn't updating to the new IP and they go into alarm, maybe the hooks are missing in airos to send a new message to the EMS when a new IP is aquired? I see the same issue when changing hostname on the radio as well, the changes don't appear to get propagated to the EMS.

IP changes are currently not reflected in AirControl at all after a device is connected. So if you are not working with either static IPs or sticky dynamic IPs you may see the problem you report. In this case you need to disconnect the device in AirControl, discover it again so that the IP is updated (either automatically through local subnet multicast or manual IP range scan in the "Add device" dialog).

As long as the device is in the local subnet or the IP is not reassigned on reboot AirControl has the info required to update the IP, it is just not fully implemented at this time.

The scenario where IP numbers change on reboot and the device cannot be discovered through multicast requires additional support at the firmware side where devices communicate the change to AirControl that we are considering for the future. It would be interesting to hear how many customers require this feature vs. are OK with the sticky IP restriction.

[jdmarti1]

This is a feature I am very interested in. We also use PPPoE and see that quite often. It's a pain to have to go and resurvey the network just to update the server.

[Sirhc]

IP changes are currently not reflected in AirControl at all after a device is connected. So if you are not working with either static IPs or sticky dynamic IPs you may see the problem you report. In this case you need to disconnect the device in AirControl, discover it again so that the IP is updated (either automatically through local subnet multicast or manual IP range scan in the "Add device" dialog).

As long as the device is in the local subnet or the IP is not reassigned on reboot AirControl has the info required to update the IP, it is just not fully implemented at this time.

The scenario where IP numbers change on reboot and the device cannot be discovered through multicast requires additional support at the firmware side where devices communicate the change to AirControl that we are considering for the future. It would be interesting to hear how many customers require this feature vs. are OK with the sticky IP restriction.

I wrote a Manager very similar to this one (AirControl). I too ran into this problem you are discussing. There are 2 options.

Option 1: The radios would have to have a firmware modification so that the radio gleams the ip address of the monitoring server when it logs into the radio so as to report back to mom (the server) after reboots or ip address changes. This is the best option.

Option 2: AirControl has to be able to login to all your routers and look for the radio when it disapears. In the case of cisco it would issue the command sh arp | include <the mac>. This works, I had to use it as I could not get China to implement option 1. :(

Please note that in my network which covers 1200+ sq miles I created tower interconnects placing a Cisco 1800 at each tower then used OSPF thus creating more capacity and fault tolerance back hauls. Thus the monitoring software has to be aware of all the WISP's routers and check them all. In our case we have ALLOT of routers to check. Or when a device is discovered you could optionally select the controlling router from a user's predefined router list which would speed up the discovery of the new IP because it no longer needs to check all routers.

[UBNT-Thomas]

Great feedback. Please see email for follow-up on a few details.