There are fundamental problems with the DHCP / batcher implementation. I have spent plenty of time with support, and have generally found most problems that I’ve identified are inherent to the implementation, not necessarily bugs. For the purposes of this discussion, I will be referencing MikroTik DHCP servers.
Quick example: if the batcher happens to be offline for any reason, addresses will not be assigned to accounts. This is not something support can help with, it is inherent to the implementation.
[I do not have the same specific problem as Chad having to regularly reboot the batcher, but mine is hosted within our network.] Similar to Chad, if the batcher is somehow offline for any reason, while IP assignments stop getting passed, there is no notification of such failure. Also, there are times when a MikroTik router may not run the scripts correctly. I have a handful of customers with addresses auto assigned from subnets we don’t even use any longer because their address de-assignments didn’t make it through to Sonar at the time.
Here are some example problems and solutions:
Problem: The batcher was offline, and some assignments did not get to Sonar.
- Current Solution: Manually log into each MikroTik DHCP server and delete all dynamic leases. Then, when renew requests come through, the batcher will assign all of the addresses to accounts. This does not, however, fix any de-assignments that took place during batcher downtime.
- Fix: Have Sonar use the MikroTik API to pull leases and sync DHCP lists.
Problem: Hardware is not assigned to an account before it gets an address. Sonar receives the DHCP information, but does not store it anywhere. The customer does not get appropriate provisioning, and possibly has their IP blocked.
- Current Solution: Check the associated DHCP server to find the lease. Manually delete the lease. The server will run the script upon renewal, send the info to the batcher, then send it to Sonar.
- Fix: Tie IP addresses to inventory items regardless of location or assignment. Provide notifications of an IP assignment to an unassigned inventory item.
Problem: The batcher sends Option 82 information along with a DHCP request. Sonar checks Option 82 only, not the actual MAC. IP Address is assigned as a piggy back to the Option 82 MAC, and is not assigned to the actual device if it exists. This breaks monitoring of devices behind Option 82 injection.
- Current Solution: Manually assign IP addresses to inventoried items behind Option 82 injection.
- Fix: Prioritize inventory MAC over Option 82 MAC. Provide notifications of IP assignments that match more than one account if the two mentioned MACs are not associated with the same account.
There are others, but these are the examples that come to mind.
Regarding unassigned addresses, I just checked and I have 8 addresses in my Preseem report that are not tied to an account (that should be). This number changes each day. Only 3 of them are customers, but that is why we can’t turn on walled garden / billing redirection as it would send good paying customers to the wrong place. I will fix these, and in a few days there will be more.
As David pointed out above, manually configuring addresses for each customer or device does work, but it seems to defeat the purpose of an automated system.
Thank you, Chris