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

Assigning prefixes from a container unique across all VRFs #10407

New Issue
Closed
opened 2025-12-29 21:31:02 +01:00 by adam · 8 comments
adam commented 2025-12-29 21:31:02 +01:00
Owner
Copy Link

Originally created by @avolmensky on GitHub (Oct 25, 2024).

Deployment Type

Self-hosted

Triage priority

I volunteer to perform this work (if approved)

NetBox Version

v4.1.1

Python Version

3.10

Steps to Reproduce

import pynetbox
from pprint import pprint

nb_apiUrl = "http://netbox-staging"
nb_apiToken = "xxxxxxxxxxxxxxxxxxxxxxx"

nb_api = pynetbox.api(nb_apiUrl, nb_apiToken)

test_vrf = nb_api.ipam.vrfs.create({
    "name": "test-vrf",
    "rd": "65000:100",
    "enforce_unique": True,
    "description": "Test VRF",
})

test_container = nb_api.ipam.prefixes.create({
    "prefix": "203.0.113.0/24",
    "status": "container",
})

test_prefix = nb_api.ipam.prefixes.create({
    "prefix": "203.0.113.0/30",
    "status": "active",
    "vrf": test_vrf.id,
})

test_prefix2 = test_container.available_prefixes.create({
    "prefix_length": 30,
})

pprint(dict(test_prefix))
pprint(dict(test_prefix2))

Expected Behavior

test_prefix and test_prefix2 shoud be assigned unique prefixes

Observed Behavior

Duplicate prefix of 203.0.113.0/30 is assigned to both test_prefix and test_prefix2

>>> pprint(dict(test_prefix))
{'_depth': 0,
 'children': 0,
 'comments': '',
 'created': '2024-10-29T02:34:04.364981Z',
 'custom_fields': {'config_items': {}, 'parent_interface': None, 'route': None},
 'description': '',
 'display': '203.0.113.0/30',
 'display_url': 'http://netbox-staging/api/ipam/prefixes/5709/',
 'family': {'label': 'IPv4', 'value': 4},
 'id': 5709,
 'is_pool': False,
 'last_updated': '2024-10-29T02:34:04.365010Z',
 'mark_utilized': False,
 'prefix': '203.0.113.0/30',
 'role': None,
 'site': None,
 'status': {'label': 'Active', 'value': 'active'},
 'tags': [],
 'tenant': None,
 'url': 'http://netbox-staging/api/ipam/prefixes/5709/',
 'vlan': None,
 'vrf': {'description': 'Test VRF',
         'display': 'test-vrf (65000:100)',
         'id': 330,
         'name': 'test-vrf',
         'rd': '65000:100',
         'url': 'http://netbox-staging/api/ipam/vrfs/330/'}}

>>> pprint(dict(test_prefix2))
{'_depth': 0,
 'children': 0,
 'comments': '',
 'created': '2024-10-29T02:34:04.707703Z',
 'custom_fields': {'config_items': {}, 'parent_interface': None, 'route': None},
 'description': '',
 'display': '203.0.113.0/30',
 'display_url': 'http://netbox-staging/ipam/prefixes/5710/',
 'family': {'label': 'IPv4', 'value': 4},
 'id': 5710,
 'is_pool': False,
 'last_updated': '2024-10-29T02:34:04.707731Z',
 'mark_utilized': False,
 'prefix': '203.0.113.0/30',
 'role': None,
 'site': None,
 'status': {'label': 'Active', 'value': 'active'},
 'tags': [],
 'tenant': None,
 'url': 'http://netbox-staging/api/ipam/prefixes/5710/',
 'vlan': None,
 'vrf': None}
Originally created by @avolmensky on GitHub (Oct 25, 2024). ### Deployment Type Self-hosted ### Triage priority I volunteer to perform this work (if approved) ### NetBox Version v4.1.1 ### Python Version 3.10 ### Steps to Reproduce ```python import pynetbox from pprint import pprint nb_apiUrl = "http://netbox-staging" nb_apiToken = "xxxxxxxxxxxxxxxxxxxxxxx" nb_api = pynetbox.api(nb_apiUrl, nb_apiToken) test_vrf = nb_api.ipam.vrfs.create({ "name": "test-vrf", "rd": "65000:100", "enforce_unique": True, "description": "Test VRF", }) test_container = nb_api.ipam.prefixes.create({ "prefix": "203.0.113.0/24", "status": "container", }) test_prefix = nb_api.ipam.prefixes.create({ "prefix": "203.0.113.0/30", "status": "active", "vrf": test_vrf.id, }) test_prefix2 = test_container.available_prefixes.create({ "prefix_length": 30, }) pprint(dict(test_prefix)) pprint(dict(test_prefix2)) ``` ### Expected Behavior `test_prefix` and `test_prefix2` shoud be assigned unique prefixes ### Observed Behavior Duplicate prefix of `203.0.113.0/30` is assigned to both `test_prefix` and `test_prefix2` ``` >>> pprint(dict(test_prefix)) {'_depth': 0, 'children': 0, 'comments': '', 'created': '2024-10-29T02:34:04.364981Z', 'custom_fields': {'config_items': {}, 'parent_interface': None, 'route': None}, 'description': '', 'display': '203.0.113.0/30', 'display_url': 'http://netbox-staging/api/ipam/prefixes/5709/', 'family': {'label': 'IPv4', 'value': 4}, 'id': 5709, 'is_pool': False, 'last_updated': '2024-10-29T02:34:04.365010Z', 'mark_utilized': False, 'prefix': '203.0.113.0/30', 'role': None, 'site': None, 'status': {'label': 'Active', 'value': 'active'}, 'tags': [], 'tenant': None, 'url': 'http://netbox-staging/api/ipam/prefixes/5709/', 'vlan': None, 'vrf': {'description': 'Test VRF', 'display': 'test-vrf (65000:100)', 'id': 330, 'name': 'test-vrf', 'rd': '65000:100', 'url': 'http://netbox-staging/api/ipam/vrfs/330/'}} >>> pprint(dict(test_prefix2)) {'_depth': 0, 'children': 0, 'comments': '', 'created': '2024-10-29T02:34:04.707703Z', 'custom_fields': {'config_items': {}, 'parent_interface': None, 'route': None}, 'description': '', 'display': '203.0.113.0/30', 'display_url': 'http://netbox-staging/ipam/prefixes/5710/', 'family': {'label': 'IPv4', 'value': 4}, 'id': 5710, 'is_pool': False, 'last_updated': '2024-10-29T02:34:04.707731Z', 'mark_utilized': False, 'prefix': '203.0.113.0/30', 'role': None, 'site': None, 'status': {'label': 'Active', 'value': 'active'}, 'tags': [], 'tenant': None, 'url': 'http://netbox-staging/api/ipam/prefixes/5710/', 'vlan': None, 'vrf': None} ```
adam added the netbox label 2025-12-29 21:31:02 +01:00
adam closed this issue 2025-12-29 21:31:03 +01:00
adam commented 2025-12-29 21:31:03 +01:00
Author
Owner
Copy Link

@avolmensky commented on GitHub (Oct 25, 2024):

Summary

We use a lot of route leaking between VRFs and use public addressing to maintain unique addressing between VRFs. I have recently updated from Netbox version 3.2.2 and this behavior has changed.

Details

Previously, I understood that containers functioned as described in issue #1073, but it looks like #10109 (Commit 7ba0b42) has changed this behavior.

For now I am running the fix contained in https://github.com/netbox-community/netbox/issues/14776#issuecomment-1887853361 and it is working fine

Request

I can see use cases for the behavior of both. Does anything in the current version of Netbox allow us to specify how we want a container to assign prefixes? If not is it possible to add an option to configuration.py (or something similar) to change the behavior of this?

I'm happy to submit a PR if needed

@avolmensky commented on GitHub (Oct 25, 2024): #### Summary We use a lot of route leaking between VRFs and use public addressing to maintain unique addressing between VRFs. I have recently updated from Netbox version 3.2.2 and this behavior has changed. #### Details Previously, I understood that containers functioned as described in issue #1073, but it looks like #10109 (Commit 7ba0b42) has changed this behavior. For now I am running the fix contained in https://github.com/netbox-community/netbox/issues/14776#issuecomment-1887853361 and it is working fine #### Request I can see use cases for the behavior of both. Does anything in the current version of Netbox allow us to specify how we want a container to assign prefixes? If not is it possible to add an option to configuration.py (or something similar) to change the behavior of this? I'm happy to submit a PR if needed
adam commented 2025-12-29 21:31:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 25, 2024):

Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

@jeremystretch commented on GitHub (Oct 25, 2024): Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.
adam commented 2025-12-29 21:31:04 +01:00
Author
Owner
Copy Link

@avolmensky commented on GitHub (Oct 29, 2024):

I have edited the original comment with Python code used to replicate this issue.

@avolmensky commented on GitHub (Oct 29, 2024): I have edited the original comment with Python code used to replicate this issue.
adam commented 2025-12-29 21:31:04 +01:00
Author
Owner
Copy Link

@pl0xym0r commented on GitHub (Oct 29, 2024):

"enforce_unique": True works into the VRF.
AFAIK, test_prefix2 is not created into Test VRF, so normal behavior to have 2 prefixes with same values.

@pl0xym0r commented on GitHub (Oct 29, 2024): "enforce_unique": True works into the VRF. AFAIK, test_prefix2 is not created into Test VRF, so normal behavior to have 2 prefixes with same values.
adam commented 2025-12-29 21:31:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 29, 2024):

As @pl0xym0r points out, uniqueness is (optionally) enforced only within each VRF. It is valid to have duplicate prefixes among VRFs and the main table.

@jeremystretch commented on GitHub (Oct 29, 2024): As @pl0xym0r points out, uniqueness is (optionally) enforced only within each VRF. It is valid to have duplicate prefixes among VRFs and the main table.
adam commented 2025-12-29 21:31:05 +01:00
Author
Owner
Copy Link

@avolmensky commented on GitHub (Oct 29, 2024):

Is there any reasoning behind the decision to change this behaviour? There was a work around previously where someone could use status active to force it to be unique within the VRF only.

How do users that route leak between VRFs assign globally unique prefixes? Is that not possible going forward?

Wouldn't it make sense to add a config parameter (or similar) to give the ability to assign globally unique prefixes?

@avolmensky commented on GitHub (Oct 29, 2024): Is there any reasoning behind the decision to change this behaviour? There was a work around previously where someone could use status active to force it to be unique within the VRF only. How do users that route leak between VRFs assign globally unique prefixes? Is that not possible going forward? Wouldn't it make sense to add a config parameter (or similar) to give the ability to assign globally unique prefixes?
adam commented 2025-12-29 21:31:05 +01:00
Author
Owner
Copy Link

@pl0xym0r commented on GitHub (Oct 30, 2024):

You can check issues (closed) + discussion about this topic with "l3 domain" keywords.
You can use present_in_vrf filter to have a representation of your l3 domain with all prefixes of all VRF imported.

@pl0xym0r commented on GitHub (Oct 30, 2024): You can check issues (closed) + discussion about this topic with "l3 domain" keywords. You can use `present_in_vrf` filter to have a representation of your l3 domain with all prefixes of all VRF imported.
adam commented 2025-12-29 21:31:05 +01:00
Author
Owner
Copy Link

@avolmensky commented on GitHub (Oct 30, 2024):

You can check issues (closed) + discussion about this topic with "l3 domain" keywords.

I had a read of the L3 Domain issues, it looks like that didn't go anywhere? That would be a very complex way to solve my problem.

You can use present_in_vrf filter to have a representation of your l3 domain with all prefixes of all VRF imported.

The route target import/export doesn't work for my use case, we have VRFs and route leak (with a prefix-list) only specific prefixes (not everything) between VRFs. Also, it doesn't look like you can route leak to/from the global table using the route targets in netbox.

Sounding like there is no way to assign a globally unique prefix in netbox?

@avolmensky commented on GitHub (Oct 30, 2024): > You can check issues (closed) + discussion about this topic with "l3 domain" keywords. I had a read of the L3 Domain issues, it looks like that didn't go anywhere? That would be a very complex way to solve my problem. > You can use `present_in_vrf` filter to have a representation of your l3 domain with all prefixes of all VRF imported. The route target import/export doesn't work for my use case, we have VRFs and route leak (with a prefix-list) only specific prefixes (not everything) between VRFs. Also, it doesn't look like you can route leak to/from the global table using the route targets in netbox. Sounding like there is no way to assign a globally unique prefix in netbox?
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 netbox
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#10407
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?