Avoid reserved IPs when using 'get next available IP'

[#1]

Hi,

I’m having a problem with getting the next available IP from a network when provisioning servers.  The problem is that the routine is returning IPs from a range that is ‘reserved’ for future use.  By ‘reserved’ I mean there is a company policy that states these addresses are not to be used for Servers, but they are not currently used in any other way.  I need to find an effective way of marking the reserved addresses as ‘in use’ within InfoBlox.  This seems straightforward until you factor in that most of our networks are under the control of a Microsoft Server.

I have tried two solutions so far:

1. Setting a fixed address – I have this working, but not for networks under Microsoft control (Fixed address x.x.x.x cannot be added to a Microsoft Network because it does not have an associated MAC address)
2. Creating a host record – I cannot get this working (Host records cannot be added to the zone mydomain.local while Microsoft servers are configured for the zone). I don’t think we have any host records in use, so possibly this relates to an implementation decision that I don’t have the full details on.

I have one solution available, that I can think of:

1. Create A records ‘reserved001’, ‘reserved002’, etc.

I don’t like this solution because it means creating hundreds of DNS entries that are not wanted.

Can anyone suggest a better method of marking addresses as ‘in use’ on a Microsoft controlled network?

Thanks in advance for any assistance.

David

[#2 · Accepted solution]

One option is to create fixed-addresses (Microsoft reservations) with fake MAC addresses, for each of the reserved addresses.  Use a unique MAC address for each one, to avoid conflicts on the Infoblox side. 

Another option is to exclude certain IPs in the API call.  Here's an example for creating a fixed address, which excludes an address.  This exclude option takes an array of individual addressed to be excluded.  It also assigns a Commit ID as an extensible attribute value.

curl -k1 -u admin:infoblox -X POST 'https://192.168.1.2/wapi/v2.8/request' -H "Content-Type: application/json" -d \
'[{
  "method":"POST",
  "object":"fixedaddress",
  "data": {
    "name": "host001",
    "comment": "This is a comment for Host 001",
    "mac": "AB:CD:00:11:22:33",
    "ipv4addr": {
      "_object_function": "next_available_ip",
      "_object": "network",
      "_object_parameters": {"network": "10.102.0.0/16"},
      "_result_field": "ips",
      "_parameters": {"exclude": ["10.102.0.1","10.102.0.2","10.102.0.3"]}
	  },
    "extattrs":{"Commit ID":{"value":"10124"}}
    }
  }
]'

[#3]

I agree with MRichard. You can use the exclude option to specify all the IPs that are not allowed to be allocated.

Also, regarding fixed addresses, instead of providing a random mac address, you can create a fixed address reservation, by specifying the mac as 00:00:00:00:00:00, like below

curl -k -u admin:Infoblox -H 'content-type: application/json' -X POST "https://127.0.0.1/wapi/v2.10/fixedaddress?_return_fields%2B=ipv4addr,mac&_return_as_object=1" -d '{"ipv4addr":"172.26.1.200","mac":"00:00:00:00:00:00"}'

Hope this helps,

Krishna

[#4]

Hi,

Thanks to both of you for the very fast and informative responses, and apologies for not getting back to you sooner.

I still don’t understand why the fixed address technique doesn’t work in my environment.  The code I have does work and I am using the mac addr 00:00:00:00:00:00, but it only works on some networks and not on others.  The differentiator seems to be that it is not working on Microsoft controlled networks, and the error message backs that up.

However, for the time being I would like to concentrate on the other technique you have suggested, which is to exclude some IPs from next_available_ip.  That seems to be a very good suggestion and is something I was not aware was available.  In modifying the code I use to implement this I think it is a good idea to change as little as possible, since there are a lot of established systems dependent upon it, but I cannot seem to get it working.  The original code looked like this:

# Original code (working)
rest_url = 'https://' + self.iba_host + '/wapi/v' + self.iba_wapi_version + '/' + net_ref + '?_function=next_available_ip&num=1'

r = requests.post(url=rest_url, auth=(self.iba_user, self.iba_password), verify=self.iba_verify_ssl)

print("DEBUG %s\n" % r.json())

To this I tried to add exclude, so that it looked like this:

 #  First attempt (not working)
 rest_url = 'https://' + self.iba_host + '/wapi/v' + self.iba_wapi_version + '/' + net_ref + '?_function=next_available_ip&num=1,exclude=[“10.38.0.2”]'

r = requests.post(url=rest_url, auth=(self.iba_user, self.iba_password), verify=self.iba_verify_ssl)

print("DEBUG %s\n" % r.json())

This comes back with the error “(List value expected for field: exclude)” and I couldn’t find any way of presenting the list of exclusions that solved this problem.  Eventually I reached the conclusion that I have to pass the data in a different way and so I changed the code to look like this:

# Replacement code
rest_url = 'https://' + self.iba_host + '/wapi/v' + self.iba_wapi_version + '/' + net_ref
payload = {
  '_object_function': 'next_available_ip',
  '_parameters': {
      'exclude': ['10.38.0.2'],
      'num': 1,
  },
  '_result_field': 'ips',
  '_object': 'network',
  '_object_parameters': {
      'network': '10.38.0.0/24',
      'network_view': 'default',
  }
}
r = requests.post(url=rest_url, auth=(self.iba_user, self.iba_password), verify=self.iba_verify_ssl, data=payload)
print("DEBUG %s\n" % r.json()) 

This one fails with “(Unknown argument: _parameters=exclude)”, but it also doesn’t like any of the other paramters I have given it – I discovered this by commenting out each of the fields the API complains about in turn.  I got the object I set payload to from https://ipam.illinois.edu/wapidoc/objects/network.html#network – was that wrong?

Any ideas what is the mistake I am making here?

I think I would prefer to remain with the 'first attempt' solution, if possible, but I cannot see how the data is supposed to be formatted.

Thanks again for any assistance!

[#5]

Hi,

It seems the answer to my previous post is this:

rest_url = 'https://' + self.iba_host + '/wapi/v' + self.iba_wapi_version + '/' + net_ref + '?_function=next_available_ip'
payload = '{"exclude": ["10.38.0.2"], "num": 1}'
r = requests.post(url=rest_url, auth=(self.iba_user, self.iba_password), verify=self.iba_verify_ssl, data=payload)

No idea why I found that so hard to work out before!  But anyway thanks again to all that helped. 

[#6]

I know this is an old thread, but has anyone been able to add an exlcude list to a GET method?  We want to do a ping check and maybe some other stuff before we use a POST to create the reservation.

The POST method seems to be brute force -- for example it overwrote an existing reservation, so we really, really want to do a GET first.   But one problem is we want to avoid using .255, .0, and .1  in /23 and larger networks where they are valid IP addresses but can still confuse end users that are used to working on /24s, but normally these are not reserved. An exlcude list would let us skip those.

Also, as a side note, where is exclude even documented? All we can find in the WAPI docs are some examples that don't list all the options. Thanks!!

[#7]

I've posted an answer over here : https://community.infoblox.com/t5/api-integration-devops-netops/exclude-list-for-get-next-available-...

[#8]

How do I exclude a specific range like 192.168.0.1-192.168.0.10? Thanks! 

[#9]

I ran into this same issue. In my case I am using the infoblox plugin for vRA and do no want to hack into the API code for that to add the exclude parameters. What I found was I can create a host record for multiple IPs and uncheck the "Enable in DNS" box on the host record. The creation went through without any errors regarding the microsoft zone. Now those IPs are "used" in infoblox and will not be allocated by next available IP.

[#10]

---

@darrenoid wrote:

I ran into this same issue. In my case I am using the infoblox plugin for vRA and do no want to hack into the API code for that to add the exclude parameters. What I found was I can create a host record for multiple IPs and uncheck the "Enable in DNS" box on the host record. The creation went through without any errors regarding the microsoft zone. Now those IPs are "used" in infoblox and will not be allocated by next available IP.

---

I can't believe it's been 6 years and Infoblox still finds it necessary to assign IPs that are not in an Infoblox DHCP range. This is so backwards it is ridiculous. The API should think "Hey, I need an IP address from this VLAN/subnet. Looks like DHCP is handing out addresses, score! Better grab one of those dynamic addresses for now! If sysadmin wants to change the IP addresses later on then he can change it from dynamic to static on the client or by using an IP resveration in Infoblox. You know, the way DHCP is SUPPOSED to work. 

Infoblox has this all backwards. This bug/shortcoming with the API handing out static IPs is dumb. Please, please fix this issue. I shouldn't need to create a DHCP pool of static IPs to prevent Infoblox and vRA from handing them out. 

[#11]

From an IPAM perspective, a DHCP range is considered "utilized" and those addresses are not available for allocation within the network space.  This allows the DHCP service to allocate addresses to DHCP clients without any concerns of stomping on a newly alllocated system.   The behavior is stable and predictable, and does not require services restarts to implement.  Our customers have been depending on this behavior for many years.

If you feel the behaviour should be changed, please work with your Infoblox account team to file an RFE (request for enhancement) and include a solid business case for the chanbge, and level of impact for not implementing the change.  The account team can help prioritize the request.