NetBox Edition
NetBox Community
NetBox Version
4.5.4
Python Version
3.12
Steps to Reproduce
- Create a /22 prefix
- Create a /23 prefix under the /22
- Create an IP range within the /23
- Manually assign an IP to a device out of the /23, but as a /24.
- Request all available IPs from the range via API.
- Find the IP in the returned range as available with /23.
Expected Behavior
An IP range should only return free IPs that are unassigned, even when the assigned IP does not match the expected prefix.
Observed Behavior
Let's say you have a nested prefix of /22 and /23, and define an IP range out of that /23. Then, manually create an IP attached to a device from that /23, but mark it as /24. If you then request all available IPs from the IP range of the /23, that /24 IP will be in the list of available as a /23.
Actually trying to use that /23 IP as the returned from the list on another device fails as it should, but this causes unnecessary errors and requires expensive checks via automation to ensure an IP is really free.
Attached are some sample API requests exhibiting this behavior:
available-ips.json
ip-address.json
ip-range.json
Workaround
In the automation I have written for provisioning IPs to new hosts, I have to take the returned list of available IPs and perform a search for each one without a prefix to see if it is really allocated. This is a very slow and resource-intensive operation that I would very much like to avoid.
NetBox Edition
NetBox Community
NetBox Version
4.5.4
Python Version
3.12
Steps to Reproduce
Expected Behavior
An IP range should only return free IPs that are unassigned, even when the assigned IP does not match the expected prefix.
Observed Behavior
Let's say you have a nested prefix of /22 and /23, and define an IP range out of that /23. Then, manually create an IP attached to a device from that /23, but mark it as /24. If you then request all available IPs from the IP range of the /23, that /24 IP will be in the list of available as a /23.
Actually trying to use that /23 IP as the returned from the list on another device fails as it should, but this causes unnecessary errors and requires expensive checks via automation to ensure an IP is really free.
Attached are some sample API requests exhibiting this behavior:
available-ips.json
ip-address.json
ip-range.json
Workaround
In the automation I have written for provisioning IPs to new hosts, I have to take the returned list of available IPs and perform a search for each one without a prefix to see if it is really allocated. This is a very slow and resource-intensive operation that I would very much like to avoid.