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

Add network model #8913

New Issue
Closed
opened 2025-12-29 20:42:47 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:42:47 +01:00
Owner
Copy Link

Originally created by @dmulyalin on GitHub (Dec 4, 2023).

NetBox version

v3.6.6

Feature type

New functionality

Proposed functionality

Similar to how we have sites and tenants we often find network systems subdivided into different networks segments a.k.a. "networks" pertaining to network generations evolution, company acquisitions and mergers or simply denoting administrative boundaries.

Use case

We often need to document devices relationships with network they belong to, common solution is to use tags or custom fields. Having dedicated "network" model allows to provide built-in functionality to group devices based on the network they are part of.

Database changes

New "network" model that is very similar to "tenant" model, network model fields

  • name
  • description
  • tags
  • comments

Changes to existing model to add reference to the "network" model:

  • device
  • site
  • rack
  • circuit
  • asn
  • prefix
  • config context

External dependencies

No response

Originally created by @dmulyalin on GitHub (Dec 4, 2023). ### NetBox version v3.6.6 ### Feature type New functionality ### Proposed functionality Similar to how we have sites and tenants we often find network systems subdivided into different networks segments a.k.a. "networks" pertaining to network generations evolution, company acquisitions and mergers or simply denoting administrative boundaries. ### Use case We often need to document devices relationships with network they belong to, common solution is to use tags or custom fields. Having dedicated "network" model allows to provide built-in functionality to group devices based on the network they are part of. ### Database changes New "network" model that is very similar to "tenant" model, network model fields - name - description - tags - comments Changes to existing model to add reference to the "network" model: - device - site - rack - circuit - asn - prefix - config context ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:42:47 +01:00
adam closed this issue 2025-12-29 20:42:47 +01:00
adam commented 2025-12-29 20:42:47 +01:00
Author
Owner
Copy Link

@apellini commented on GitHub (Dec 4, 2023):

So you want to create a relational model that represents network hierarchy. Example: Core ==> Distribution ==> Access, or Spine ==> Leaf. In network we could have two hierarchies, physical (Core, Access) and logical (Core, CPE, FW, ADC, Access) that depends on design, in some case on R&S there is host networks in other cases L3 is configured on Network Services (FW, ADC).

@apellini commented on GitHub (Dec 4, 2023): So you want to create a relational model that represents network hierarchy. Example: Core ==> Distribution ==> Access, or Spine ==> Leaf. In network we could have two hierarchies, physical (Core, Access) and logical (Core, CPE, FW, ADC, Access) that depends on design, in some case on R&S there is host networks in other cases L3 is configured on Network Services (FW, ADC).
adam commented 2025-12-29 20:42:48 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 5, 2023):

This sounds very much like the L3 domain proposed in https://github.com/netbox-community/netbox/discussions/7608 which was referenced in #8895

@DanSheps commented on GitHub (Dec 5, 2023): This sounds very much like the L3 domain proposed in https://github.com/netbox-community/netbox/discussions/7608 which was referenced in #8895
adam commented 2025-12-29 20:42:48 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Dec 6, 2023):

@apellini did not think about this usecase, but yeah, "network" model could be used to represent network layers hierarchy. My primary usecase that I was observing in sizable networks - company evolves, aquisitions and mergers happen, people give names to networks as they build them e.g. "corp net abc" or "data centre xyz" or "foobar backbone". New model will allow to denote what network this or that entity belongs to.

@DanSheps hmm, 'Layer3 domains' seems to be more routing related, while "network" model is more falls into "Organisation" section in the menu, but if we generalise the usecase, probably we can say that "network" encompasses L3 and L2 domains.

@dmulyalin commented on GitHub (Dec 6, 2023): @apellini did not think about this usecase, but yeah, "network" model could be used to represent network layers hierarchy. My primary usecase that I was observing in sizable networks - company evolves, aquisitions and mergers happen, people give names to networks as they build them e.g. "corp net abc" or "data centre xyz" or "foobar backbone". New model will allow to denote what network this or that entity belongs to. @DanSheps hmm, 'Layer3 domains' seems to be more routing related, while "network" model is more falls into "Organisation" section in the menu, but if we generalise the usecase, probably we can say that "network" encompasses L3 and L2 domains.
adam commented 2025-12-29 20:42:48 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 6, 2023):

company evolves, aquisitions and mergers happen, people give names to networks as they build them e.g. "corp net abc" or "data centre xyz" or "foobar backbone". New model will allow to denote what network this or that entity belongs to.

This is what Tenancy and/or the Prefix hierarchy can be used for, we are not going to create a nenw model that essentially duplicates existing models.

'Layer3 domains' seems to be more routing related, while "network" model is more falls into "Organisation" section in the menu, but if we generalise the usecase, probably we can say that "network" encompasses L3 and L2 domains.

If you just are trying to organize so that you know who uses what assests, that is what Tenancy is for.

@DanSheps commented on GitHub (Dec 6, 2023): > company evolves, aquisitions and mergers happen, people give names to networks as they build them e.g. "corp net abc" or "data centre xyz" or "foobar backbone". New model will allow to denote what network this or that entity belongs to. This is what Tenancy and/or the Prefix hierarchy can be used for, we are not going to create a nenw model that essentially duplicates existing models. > 'Layer3 domains' seems to be more routing related, while "network" model is more falls into "Organisation" section in the menu, but if we generalise the usecase, probably we can say that "network" encompasses L3 and L2 domains. If you just are trying to organize so that you know who uses what assests, that is what Tenancy is for.
adam commented 2025-12-29 20:42:48 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Dec 6, 2023):

I usually use VRFs and Tenants for this. Perhaps the FR here is to make VRFs "Network (Name)spaces" (and allow hierarchy?) to make those more organizational while allowing them linked to actual network "vrfs" more related to the actual l3vpn/l3vrf domain. Something alog those lines, havent got a coffee yet.

@jsenecal commented on GitHub (Dec 6, 2023): I usually use `VRF`s and `Tenants` for this. Perhaps the FR here is to make VRFs "Network (Name)spaces" (and allow hierarchy?) to make those more organizational while allowing them linked to actual network "vrfs" more related to the actual l3vpn/l3vrf domain. Something alog those lines, havent got a coffee yet.
adam commented 2025-12-29 20:42:48 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Dec 6, 2023):

Ic, yeah, was using tenancy to represent this so far as well. Think you right.

@dmulyalin commented on GitHub (Dec 6, 2023): Ic, yeah, was using tenancy to represent this so far as well. Think you right.
adam commented 2025-12-29 20:42:49 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Dec 6, 2023):

Thank you for the advice, re reading documentation about tenancy helped me to realise this is what i was looking for

@dmulyalin commented on GitHub (Dec 6, 2023): Thank you for the advice, re reading documentation about tenancy helped me to realise this is what i was looking for
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: feature
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#8913
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?