starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

POST to /api/ipam/prefixes/{pk}/available-ips/ API returns a /32 address rather than prefix's netmask #1830

New Issue
Closed
opened 2025-12-29 17:19:34 +01:00 by adam · 1 comment
adam commented 2025-12-29 17:19:34 +01:00
Owner
Copy Link

Originally created by @pm17788 on GitHub (Jul 6, 2018).

Issue type

[ ] Feature request
[x] Bug report
[ ] Documentation
[ ] Housekeeping

Environment

  • Python version: 3.5.4
  • NetBox version: 2.3.4

Description

Given the following prefix definition:

{
  "id": 481,
  "family": 4,
  "prefix": "172.16.240.0/27",
  "site": {
    "id": 5,
    "url": "https://netbox/api/dcim/sites/5/",
    "name": "TEST_SITE",
    "slug": "TEST_SITE"
  },
  "vrf": null,
  "tenant": null,
  "vlan": null,
  "status": {
    "label": "Active",
    "value": 1
  },
  "role": {
    "id": 1,
    "url": "https://netbox/api/ipam/roles/1/",
    "name": "Production",
    "slug": "production"
  },
  "is_pool": false,
  "description": "pm17788 Testing POC. Prefix 1",
  "custom_fields": {
    "prefix_gateway": "172.16.0.10",
    "bond0": true
  },
  "created": "2018-03-13",
  "last_updated": "2018-06-22T11:58:02.105686Z"
}

Additionally, a device interface exists:

{
  "id": 6574731,
  "device": {
    "id": 370881,
    "url": "https://netbox/api/dcim/devices/370881/",
    "name": "server-0CC47ABB77FD",
    "display_name": "server-0CC47ABB77FD"
  },
  "name": "eth0",
  "form_factor": {
    "label": "1000BASE-T (1GE)",
    "value": 1000
  },
  "enabled": true,
  "lag": null,
  "mtu": 0,
  "mac_address": "0C:C4:7A:BB:77:FD",
  "mgmt_only": false,
  "description": "Interface 'eth0' on host 'server-0CC47ABB77FD'",
  "is_connected": false,
  "interface_connection": null,
  "circuit_termination": null,
  "mode": null,
  "untagged_vlan": null,
  "tagged_vlans": []
}

During the POST to https://netbox/api/ipam/prefixes/481/available-ips/ of the following JSON, the result returns the ip of /32 rather than the (expected) prefix's /27

{
  "prefix": 481,
  "interface": 6574731,
  "status": 2,
  "description": "Reserving IP on INT 6574731, DEV 370881"
}

{
  "id": 868650,
  "address": "172.16.240.2/32",
  "vrf": null,
  "tenant": null,
  "status": 2,
  "role": null,
  "interface": 6574731,
  "description": "Reserving IP on INT 6574731, DEV 370881",
  "nat_inside": null,
  "created": "2018-07-06",
  "last_updated": "2018-07-06T18:40:03.133753Z"
}
Originally created by @pm17788 on GitHub (Jul 6, 2018). ### Issue type [ ] Feature request [x] Bug report [ ] Documentation [ ] Housekeeping ### Environment * Python version: 3.5.4 * NetBox version: 2.3.4 ### Description Given the following prefix definition: ```JSON { "id": 481, "family": 4, "prefix": "172.16.240.0/27", "site": { "id": 5, "url": "https://netbox/api/dcim/sites/5/", "name": "TEST_SITE", "slug": "TEST_SITE" }, "vrf": null, "tenant": null, "vlan": null, "status": { "label": "Active", "value": 1 }, "role": { "id": 1, "url": "https://netbox/api/ipam/roles/1/", "name": "Production", "slug": "production" }, "is_pool": false, "description": "pm17788 Testing POC. Prefix 1", "custom_fields": { "prefix_gateway": "172.16.0.10", "bond0": true }, "created": "2018-03-13", "last_updated": "2018-06-22T11:58:02.105686Z" } ``` Additionally, a device interface exists: ```JSON { "id": 6574731, "device": { "id": 370881, "url": "https://netbox/api/dcim/devices/370881/", "name": "server-0CC47ABB77FD", "display_name": "server-0CC47ABB77FD" }, "name": "eth0", "form_factor": { "label": "1000BASE-T (1GE)", "value": 1000 }, "enabled": true, "lag": null, "mtu": 0, "mac_address": "0C:C4:7A:BB:77:FD", "mgmt_only": false, "description": "Interface 'eth0' on host 'server-0CC47ABB77FD'", "is_connected": false, "interface_connection": null, "circuit_termination": null, "mode": null, "untagged_vlan": null, "tagged_vlans": [] } ``` During the POST to `https://netbox/api/ipam/prefixes/481/available-ips/` of the following JSON, the result returns the ip of /32 rather than the (expected) prefix's /27 ```JSON { "prefix": 481, "interface": 6574731, "status": 2, "description": "Reserving IP on INT 6574731, DEV 370881" } ``` ```JSON { "id": 868650, "address": "172.16.240.2/32", "vrf": null, "tenant": null, "status": 2, "role": null, "interface": 6574731, "description": "Reserving IP on INT 6574731, DEV 370881", "nat_inside": null, "created": "2018-07-06", "last_updated": "2018-07-06T18:40:03.133753Z" } ```
adam added the type: bugstatus: accepted labels 2025-12-29 17:19:34 +01:00
adam closed this issue 2025-12-29 17:19:34 +01:00
adam commented 2025-12-29 17:19:35 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (Jul 9, 2018):

Curiously, doing a GET to the same API endpoint returns IPs with the correct net mask:

[
  {
    "family": 4,
    "address": "172.16.240.2/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.3/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.4/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.5/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.6/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.7/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.8/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.9/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.10/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.11/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.12/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.13/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.14/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.15/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.16/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.17/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.18/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.19/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.20/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.21/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.22/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.23/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.24/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.25/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.26/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.27/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.28/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.29/27",
    "vrf": null
  },
  {
    "family": 4,
    "address": "172.16.240.30/27",
    "vrf": null
  }
]
@pm17788 commented on GitHub (Jul 9, 2018): Curiously, doing a GET to the same API endpoint returns IPs with the correct net mask: ```JSON [ { "family": 4, "address": "172.16.240.2/27", "vrf": null }, { "family": 4, "address": "172.16.240.3/27", "vrf": null }, { "family": 4, "address": "172.16.240.4/27", "vrf": null }, { "family": 4, "address": "172.16.240.5/27", "vrf": null }, { "family": 4, "address": "172.16.240.6/27", "vrf": null }, { "family": 4, "address": "172.16.240.7/27", "vrf": null }, { "family": 4, "address": "172.16.240.8/27", "vrf": null }, { "family": 4, "address": "172.16.240.9/27", "vrf": null }, { "family": 4, "address": "172.16.240.10/27", "vrf": null }, { "family": 4, "address": "172.16.240.11/27", "vrf": null }, { "family": 4, "address": "172.16.240.12/27", "vrf": null }, { "family": 4, "address": "172.16.240.13/27", "vrf": null }, { "family": 4, "address": "172.16.240.14/27", "vrf": null }, { "family": 4, "address": "172.16.240.15/27", "vrf": null }, { "family": 4, "address": "172.16.240.16/27", "vrf": null }, { "family": 4, "address": "172.16.240.17/27", "vrf": null }, { "family": 4, "address": "172.16.240.18/27", "vrf": null }, { "family": 4, "address": "172.16.240.19/27", "vrf": null }, { "family": 4, "address": "172.16.240.20/27", "vrf": null }, { "family": 4, "address": "172.16.240.21/27", "vrf": null }, { "family": 4, "address": "172.16.240.22/27", "vrf": null }, { "family": 4, "address": "172.16.240.23/27", "vrf": null }, { "family": 4, "address": "172.16.240.24/27", "vrf": null }, { "family": 4, "address": "172.16.240.25/27", "vrf": null }, { "family": 4, "address": "172.16.240.26/27", "vrf": null }, { "family": 4, "address": "172.16.240.27/27", "vrf": null }, { "family": 4, "address": "172.16.240.28/27", "vrf": null }, { "family": 4, "address": "172.16.240.29/27", "vrf": null }, { "family": 4, "address": "172.16.240.30/27", "vrf": null } ] ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#1830
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?