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

'Container' prefixes no longer show IP addresses - 'fix' from issue 4744 seems incorrect #4817

New Issue
Closed
opened 2025-12-29 19:20:55 +01:00 by adam · 2 comments
adam commented 2025-12-29 19:20:55 +01:00
Owner
Copy Link

Originally created by @falz on GitHub (Apr 23, 2021).

NetBox version

2.11.1

Python version

3.6

Steps to Reproduce

  1. Create an active prefix of size /24
  2. Create a container prefix of size /27 within the /24
  3. assign an ip address of type loopback inside the container /27

Expected Behavior

We have been using the 'Container' prefix type to document where Loopback addresses are assigned.

Typically this container is a /27 'Container' inside a /24 'Active' prefix. The Container prefix does not have a matching route, it's used for documentation purposes to tell the user where loopback IPs should be assigned from.

The /24 parent route is active, and hence does have an active route on the network.

We would expect to be able to use Container prefixes to document IP addresses, and see the IP addresses from the prefix view.

Observed Behavior

A change in issue https://github.com/netbox-community/netbox/issues/4744 was made to hide the IP addresses tab from Container prefixes:

The issue that was reported was that broadcast and network IPs were visible, the fix appears to be to hide the IP addresses tab from all prefixes that are of type 'Container'.

In this scenario, I cannot see the IP addresses in the /27 from that prefix, but can only see them from its parent /24.

We tested the same workaround as @cpbruton in the referenced issue (Container -> Active) and it does allow us to see the IPs again, it seems like the incorrect fix to us.

Originally created by @falz on GitHub (Apr 23, 2021). ### NetBox version 2.11.1 ### Python version 3.6 ### Steps to Reproduce 1. Create an active prefix of size /24 2. Create a container prefix of size /27 within the /24 3. assign an ip address of type loopback inside the container /27 ### Expected Behavior We have been using the 'Container' prefix type to document where Loopback addresses are assigned. Typically this container is a /27 'Container' inside a /24 'Active' prefix. The Container prefix does not have a matching route, it's used for documentation purposes to tell the user where loopback IPs should be assigned from. The /24 parent route is active, and hence does have an active route on the network. We would expect to be able to use Container prefixes to document IP addresses, and see the IP addresses from the prefix view. ### Observed Behavior A change in issue https://github.com/netbox-community/netbox/issues/4744 was made to hide the IP addresses tab from Container prefixes: The issue that was reported was that broadcast and network IPs were visible, the fix appears to be to hide the IP addresses tab from all prefixes that are of type 'Container'. In this scenario, I cannot see the IP addresses in the /27 from that prefix, but can only see them from its parent /24. We tested the same workaround as @cpbruton in the referenced issue (Container -> Active) and it does allow us to see the IPs again, it seems like the incorrect fix to us.
adam added the type: bug label 2025-12-29 19:20:55 +01:00
adam closed this issue 2025-12-29 19:20:55 +01:00
adam commented 2025-12-29 19:20:55 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Apr 27, 2021):

Duplicate of #5925 ?

You want to see individual IP addresses (loopbacks) which were created directly underneath a "Container" prefix. As a workaround, you can change the prefix to "Reserved" instead of "Container" and it should be fine.

Since this behaviour was changed, Netbox will only show you prefixes under containers. The implication is that a "container" is space carved out for allocating prefixes, not IP addresses. Personally, I find this confusing: Netbox now doesn't stop you creating individual IP addresses within a Container prefix, but it doesn't show you them either - so they appear to have vanished, unless you happen to know they are there and can search for them individually.

(Aside: in the situation you've described I think it's odd that /24 is "Active" and yet you've carved loopbacks out of the same subnet. Any device which is in the outer /24 that tries to contact one of the loopback addresses, will ARP for it, so the router will need to proxy-ARP. Even if that's a weird thing to do, Netbox should be able to document it, and using "Reserved" for the block is not unreasonable IMO)

@candlerb commented on GitHub (Apr 27, 2021): Duplicate of #5925 ? You want to see individual IP addresses (loopbacks) which were created directly underneath a "Container" prefix. As a workaround, you can change the prefix to "Reserved" instead of "Container" and it should be fine. Since this behaviour was changed, Netbox will only show you _prefixes_ under containers. The implication is that a "container" is space carved out for allocating prefixes, not IP addresses. Personally, I find this confusing: Netbox now doesn't *stop* you creating individual IP addresses within a Container prefix, but it doesn't *show* you them either - so they appear to have vanished, unless you happen to know they are there and can search for them individually. (Aside: in the situation you've described I think it's odd that /24 is "Active" and yet you've carved loopbacks out of the same subnet. Any device which is in the outer /24 that tries to contact one of the loopback addresses, will ARP for it, so the router will need to proxy-ARP. Even if that's a weird thing to do, Netbox should be able to document it, and using "Reserved" for the block is not unreasonable IMO)
adam commented 2025-12-29 19:20:56 +01:00
Author
Owner
Copy Link

@falz commented on GitHub (Apr 27, 2021):

Indeed a duplicate of that ticket, I didn't see it.

Thanks for the workaround suggestion, i tested it on a few and it does indeed work. It appears that we will have to change to that for now.

Re your arp issue, that won't affect us the way we're using it - Active in this case means there's an active route on the network, which doesn't correlate with it being on an interface.

The /24 route exists as a covering route to pull traffic towards this destination device, without the need for all of its loopbacks and prefixes to be in the larger internal FIB.

I agree that the documentation for the uses of Reserved and Container on netbox are unclear on intended purpose. Closing this and will chime in / thumbs up on the issue i was a dupe of.

@falz commented on GitHub (Apr 27, 2021): Indeed a duplicate of that ticket, I didn't see it. Thanks for the workaround suggestion, i tested it on a few and it does indeed work. It appears that we will have to change to that for now. Re your arp issue, that won't affect us the way we're using it - Active in this case means there's an active route on the network, which doesn't correlate with it being on an interface. The /24 route exists as a covering route to pull traffic towards this destination device, without the need for all of its loopbacks and prefixes to be in the larger internal FIB. I agree that the documentation for the uses of Reserved and Container on netbox are unclear on intended purpose. Closing this and will chime in / thumbs up on the issue i was a dupe of.
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 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#4817
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?