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

Many-to-many mappings for pass-through ports #11717

New Issue
Closed
opened 2025-12-29 21:48:56 +01:00 by adam · 1 comment
adam commented 2025-12-29 21:48:56 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Oct 13, 2025).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v4.4.2

Feature type

New functionality

Proposed functionality

NetBox currently permits assigning multiple front ports to a single rear port. This FR proposes extending the data model to support the reverse as well (multiple rear ports to a single front port), enabling many-to-many assignment among front and rear ports. The current implementation, which employs a ForeignKey from FrontPort to RearPort and an Integerfield would be replaced by a bi-directional many-to-many assignment.

Once implemented, it will become possible to condense of expand the "stack" of positions in both directions across a pair of pass-through ports.

Use case

Extending the data model to support multi-port mappings in either direction would enable modeling complex pass-through paths. These are commonly seen e.g. in datacenter Clos fabrics which utilize crossover fiber modules to simplify spine-to-leaf connections. An example is show below:

Image

The resulting M2M table for the above topology would look like this:

FrontPort Position RearPort Position
1 1 1 1
1 2 1 2
1 3 2 1
1 4 2 2
2 1 1 3
2 2 1 4
2 3 2 3
2 4 2 4

Database changes

There are two relevant fields currently defined on the FrontPort model:

class FrontPort:
    rear_port = models.ForeignKey(
        to='dcim.RearPort',
        on_delete=models.CASCADE,
        related_name='frontports'
    )
    rear_port_position = models.PositiveSmallIntegerField(
        verbose_name=_('rear port position'),
        default=1,
        validators=[
            MinValueValidator(REARPORT_POSITIONS_MIN),
            MaxValueValidator(REARPORT_POSITIONS_MAX)
        ],
        help_text=_('Mapped position on corresponding rear port')
    )

These would be replaced by a ManyToManyField on the FrontPort model. This M2M assignment would utilize a custom "through" table which annotates the numeric position of each port:

class PortMapping:
    front_port = models.ForeignKey(
        to='dcim.FrontPort',
        on_delete=models.CASCADE,
    )
    front_port_position = models.PositiveSmallIntegerField(
        default=1,
    )
    rear_port = models.ForeignKey(
        to='dcim.RearPort',
        on_delete=models.CASCADE,
    )
    rear_port_position = models.PositiveSmallIntegerField(
        default=1,
    )

External dependencies

N/A

Originally created by @jeremystretch on GitHub (Oct 13, 2025). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v4.4.2 ### Feature type New functionality ### Proposed functionality NetBox currently permits assigning multiple front ports to a single rear port. This FR proposes extending the data model to support the reverse as well (multiple rear ports to a single front port), enabling many-to-many assignment among front and rear ports. The current implementation, which employs a ForeignKey from FrontPort to RearPort and an Integerfield would be replaced by a bi-directional many-to-many assignment. Once implemented, it will become possible to condense of expand the "stack" of positions in both directions across a pair of pass-through ports. ### Use case Extending the data model to support multi-port mappings in either direction would enable modeling complex pass-through paths. These are commonly seen e.g. in datacenter Clos fabrics which utilize crossover fiber modules to simplify spine-to-leaf connections. An example is show below: <img width="550" height="266" alt="Image" src="https://github.com/user-attachments/assets/5a585a32-a627-4c9c-8261-124c5552a50c" /> The resulting M2M table for the above topology would look like this: | FrontPort | Position | RearPort | Position | |---|---|---|---| | 1 | 1 | 1 | 1 | | 1 | 2 | 1 | 2 | | 1 | 3 | 2 | 1 | | 1 | 4 | 2 | 2 | | 2 | 1 | 1 | 3 | | 2 | 2 | 1 | 4 | | 2 | 3 | 2 | 3 | | 2 | 4 | 2 | 4 | ### Database changes There are two relevant fields currently defined on the FrontPort model: ```python class FrontPort: rear_port = models.ForeignKey( to='dcim.RearPort', on_delete=models.CASCADE, related_name='frontports' ) rear_port_position = models.PositiveSmallIntegerField( verbose_name=_('rear port position'), default=1, validators=[ MinValueValidator(REARPORT_POSITIONS_MIN), MaxValueValidator(REARPORT_POSITIONS_MAX) ], help_text=_('Mapped position on corresponding rear port') ) ``` These would be replaced by a ManyToManyField on the FrontPort model. This M2M assignment would utilize a custom "through" table which annotates the numeric position of each port: ```python class PortMapping: front_port = models.ForeignKey( to='dcim.FrontPort', on_delete=models.CASCADE, ) front_port_position = models.PositiveSmallIntegerField( default=1, ) rear_port = models.ForeignKey( to='dcim.RearPort', on_delete=models.CASCADE, ) rear_port_position = models.PositiveSmallIntegerField( default=1, ) ``` ### External dependencies N/A
adam added the status: acceptedtype: featurenetboxcomplexity: high labels 2025-12-29 21:48:56 +01:00
adam closed this issue 2025-12-29 21:48:56 +01:00
adam commented 2025-12-29 21:48:57 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Oct 13, 2025):

Would this also add the ability to map multiple front ports to the same rear port position and vice versa, so that splitters/combiners can be modeled as well? That is certainly one of the other challenges we face today with the current model.

@sleepinggenius2 commented on GitHub (Oct 13, 2025): Would this also add the ability to map multiple front ports to the same rear port position and vice versa, so that splitters/combiners can be modeled as well? That is certainly one of the other challenges we face today with the current model.
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 complexity: high netbox status: accepted 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#11717
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?