IPAM allows creation of IPAddresses with '0' mask length

[tyler-8]

Environment

• Python version: 3.6.8
• NetBox version: v2.6.7

Steps to Reproduce

1. Create an IP address with a /0 mask

Expected Behavior

Validation error returned in form when trying to create an IP address with a mask of 0.

Observed Behavior

Netbox GUI times out and returns HTTP 504 while trying to load IPAddress detail page. You can see the IP is successfully created in the changelog, but any attempt to view the detail page times out with a reasonable nginx/gunicorn worker timeout (<60 seconds).

[hSaria]

I couldn't replicate this on a fresh install of v2.6.7 or v2.6.11 (httpd/gunicorn). I was able to create an IP address with a /0 mask and I can browse to it and do everything as usual. Anything special about the deployment?

[tyler-8]

I suspect you may not see this behavior on a fresh install. The issue (I'm guessing) is that since all the IP/prefix relationships are done in CPU - and when you have a large number of prefixes and IP addresses, the calculation for a /0 takes an enormous amount of time.

And since the calculation is single-threaded, there's no speeding it up by increasing worker counts. The only solution would then be to increase the gunicorn/nginx worker timeout to some absurdly high number - but anything higher than 60s for a synchronous user-interactive webapp is... not ideal.

This dev environment has the gunicorn worker set for 120s timeout and it's getting hit every time.

[hSaria]

I'll generate some dummy addresses and give it another try. How many addresses do you have?

[tyler-8]

IP Addresses:     169,115
Prefixes:          36,082

[tyler-8]

The API returns a response immediately so this is definitely an issue with the IP/Prefix calculations. Those aren't shown in the IP address detail output.

[hSaria]

Now that I've got 200k+ addresses, I can see what you're referring to. It doesn't even need to be a /0 address, though that one is particularly dangerous as it includes everything.

It's the related IPs table that kills it as it has no limit on the table size, so it tries to render every single address.

Adding a limit or paginating the table minimizes these effects. The former is faster (practically the same as having no related IPs) than the latter (probably because there's far less data to process from the DB).

Personally, I'd go with the limit because it's pretty odd for someone to accurately use that table for anything functional. Like if we paginated the table, who's gonna be like "yeah, let me just go to page 9 of 80, which I'm sure is where that one related IP that I'm looking for is at".