ip address allocator allocations not happening sequentially for /31

[jfloresr]

While working on allocating addresses for point to point links I noticed that allocations for /31s are not happening sequestially. It seems to me like the ip address allocator is skipping the next /31 after allocating first /31 net. For example, I am getting a 172.16.1.0/31 allocation and the next allocation I requested gets a 172.16.1.4/31 instead of 172.16.1.2/31. The same thing happens with any subsequent requests.

Attached is a screenshot for reference as well as other test cases that seem to work fine.

[jvikman]

Hi,

What version of the resource-manager are you using?

And I assume you would like it to allocate the next /31 subnet?

Can you check if you have two /32 "nets" available (that would make up one /31)?

[jfloresr]

I am currently using version 3.1.1 from the 4.4.2.1 package.

When I do a show status I see 2 /32s available that makes up the next /31.

We looked at the code and it seems like this was done per design.

[jakerby]

I believe that would be correct in how it is functioning. NSO probably does not understand the need for a network with network and broadcast ip's only, so it issues a /30

[jfloresr]

Actually the behavior we saw coded on the allocator is that it will issue the /31 but it will put the other 2 addresses available as /32s.

This is very strange and not conformant with rfc 3021.

Joksan Flores

NETWORK CONSULTING ENGINEER

Cisco Systems

[mmalysz]

Looking into the code of Resource Manager 4.4.3.2

	if ((!isIpv6 && subs.length == 4 && request == 31 ) ||
	( isIpv6 && subs.length == 4 && request == 127)) {
	/*
	* Split the four into two twos instead
	* Add only single addresses to available.
	* add 3rd and 4th to available.
	*/
	availables.add(subs[2]);
	availables.add(subs[3]);
	/* Allocate as a 2-address "Subnet". */
	Allocation a = new Allocation(new Subnet(subs[0].getAddress(), request),
	owner, username, requestId);
	allocations.add(a);
	reviewAlarms();
	return a;
	}

It looks as by design it decomposes /30 into /31 which is used and 2 /32

[jvikman · Accepted solution]

It is by design and you are not the first to question it.

However, if jfloresr has a pressing need for this maybe we should reconsider. Could you describe your scenario more, do you have a workaround?

[jfloresr]

We are using resource manager for a POC next month to provision the underlay IPs of an entire fabric as well as the loopbacks. In essence, we take a device with just a management interface configured and provision all the configurations requiring minimal input parameters.

Right now we are requesting the /31 from resource manager and allowing it to waste the 2 /32s. Unfortunately the pools for Infrastructure IPs and loopbacks is different so all the /32s are wasted currently.

Joksan Flores

ENGINEER.NETWORK CONSULTING

Cisco Services

jfloresr@cisco.com<mailto:jfloresr@cisco.com>

Tel: +1 919 392 2635

Mobile: +1 919 710 2045

[houlee]

Hi,

We have a customer challenging us exactly the same issue too. They are not happy about the extra two unused IPs. Is this considered as a bug or how we communicate back to the customer about this feature/design?

Thanks.

[vleijon]

This is considered a feature, since it is on purpose - though people seem to largely agree that it is not a good feature.

There are tickets on this, but there is no timeline for when this will be adressed. For customers, work through the ticket system to reach resolution.