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

1:1 patch panels fail when between 1:n panels #3646

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

Originally created by @steffann on GitHub (May 7, 2020).

Originally assigned to: @steffann on GitHub.

Environment

  • Python version: 3.6.9
  • NetBox version: 2.8.2

Steps to Reproduce

  1. Disable any installed plugins by commenting out the PLUGINS setting in
    configuration.py.
  2. Create the following setup:
                1                                           2
[Device 1] -----------+                               +----------- [Device 2]
      Iface1          |                               |          Iface1
                  FP1 |       3               4       | FP1
                  [Panel 1] ----- [Panel 5] ----- [Panel 2]
                  FP2 |  RP1     RP1     FP1     RP1  | FP2
      Iface1          |                               |          Iface1
[Device 3] -----------+                               +----------- [Device 4]
                5                                           6
  1. get Exception: Invalid position for Rear Port 1 (1 positions): 2)

When writing this issue I created the cables in numerical order, but the order of creation of the cables doesn't really matter. As soon as cables 3 and 5 are in place, NetBox will try to trace the connection from device 3 to determine what its connected endpoint is, and it will raise the exception upon reaching panel 5.

Expected Behavior

I expected the front ports of panel 1 to correspond to the front ports of panel 2.

Observed Behavior

NetBox tries to map the front ports of panel 1 to the front ports of panel 5, which doesn't work because it is a 1:1 pass-though panel.

Originally created by @steffann on GitHub (May 7, 2020). Originally assigned to: @steffann on GitHub. ### Environment * Python version: 3.6.9 * NetBox version: 2.8.2 ### Steps to Reproduce 1. Disable any installed plugins by commenting out the `PLUGINS` setting in `configuration.py`. 2. Create the following setup: ``` 1 2 [Device 1] -----------+ +----------- [Device 2] Iface1 | | Iface1 FP1 | 3 4 | FP1 [Panel 1] ----- [Panel 5] ----- [Panel 2] FP2 | RP1 RP1 FP1 RP1 | FP2 Iface1 | | Iface1 [Device 3] -----------+ +----------- [Device 4] 5 6 ``` 3. get `Exception: Invalid position for Rear Port 1 (1 positions): 2)` When writing this issue I created the cables in numerical order, but the order of creation of the cables doesn't really matter. As soon as cables 3 and 5 are in place, NetBox will try to trace the connection from device 3 to determine what its connected endpoint is, and it will raise the exception upon reaching panel 5. ### Expected Behavior I expected the front ports of panel 1 to correspond to the front ports of panel 2. ### Observed Behavior NetBox tries to map the front ports of panel 1 to the front ports of panel 5, which doesn't work because it is a 1:1 pass-though panel.
adam added the type: bugstatus: accepted labels 2025-12-29 18:30:20 +01:00
adam closed this issue 2025-12-29 18:30:21 +01:00
adam commented 2025-12-29 18:30:21 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (May 7, 2020):

For those looking at #3193 and #4548, this is a related issue. I think (hope) this closes the last case where 1:1 patch panels confuse the trace. 🤞🏻

@steffann commented on GitHub (May 7, 2020): For those looking at #3193 and #4548, this is a related issue. I think (hope) this closes the last case where 1:1 patch panels confuse the trace. 🤞🏻
adam commented 2025-12-29 18:30:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 7, 2020):

@steffann Please extend the recreation steps above to specify exactly how the exception is triggered. Does it occur when replicating the topology, or when initiating a trace? If the later, from what termination are you tracing?

@jeremystretch commented on GitHub (May 7, 2020): @steffann Please extend the recreation steps above to specify exactly how the exception is triggered. Does it occur when replicating the topology, or when initiating a trace? If the later, from what termination are you tracing?
adam commented 2025-12-29 18:30:21 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (May 7, 2020):

Question updated.

For a code example that builds this topology please take a look at the attached PR. It has a test case that creates the described topology: 8ff65591d5/netbox/dcim/tests/test_models.py (L626)

@steffann commented on GitHub (May 7, 2020): Question updated. For a code example that builds this topology please take a look at the attached PR. It has a test case that creates the described topology: https://github.com/steffann/netbox/blob/8ff65591d51090b2283bbe912d8f8cd7c1840e69/netbox/dcim/tests/test_models.py#L626
adam commented 2025-12-29 18:30:21 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (May 7, 2020):

Further symptoms that can be cause by this issue:

The signal handler runs outside the transaction by default, so even though an exception is raised the cable has already been created. Therefore we can still trace from the endpoints:

Behaviour when doing a trace from device 3:

  • arrive at Panel 1 through FP2: push 2 into the stack
  • arrive at Panel 5 through RP1: pop 2 from the stack
  • raise exception because Panel 5 only has 1 position

When tracing from device 4:

  • arrive at Panel 2 through FP2: push 2 into the stack
  • arrive at Panel 5 through FP1: push 1 onto the stack
  • arrive at Panel 1 through RP1: pop 1 from the stack
  • arrive at device 1 instead of device 2
@steffann commented on GitHub (May 7, 2020): Further symptoms that can be cause by this issue: The signal handler runs outside the transaction by default, so even though an exception is raised the cable has already been created. Therefore we can still trace from the endpoints: Behaviour when doing a trace from device 3: - arrive at Panel 1 through FP2: push 2 into the stack - arrive at Panel 5 through RP1: pop 2 from the stack - raise exception because Panel 5 only has 1 position When tracing from device 4: - arrive at Panel 2 through FP2: push 2 into the stack - arrive at Panel 5 through FP1: push 1 onto the stack - arrive at Panel 1 through RP1: pop 1 from the stack - arrive at device 1 instead of device 2
adam commented 2025-12-29 18:30:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 7, 2020):

It occurs when creating the topology

It's important to spell out the exact steps taken to reproduce the error in the initial report. This allows users troubleshooting an issue in the future to determine whether they've run into the same bug. Saying "Create the following setup" isn't sufficiently detailed as there's a possibility that a different series of steps can arrive at a completed topology without triggering the bug. Please call out the order in which each link is established so that it will be clear to a user how exactly the bug is triggered.

@jeremystretch commented on GitHub (May 7, 2020): > It occurs when creating the topology It's important to spell out the exact steps taken to reproduce the error in the initial report. This allows users troubleshooting an issue in the future to determine whether they've run into the same bug. Saying "Create the following setup" isn't sufficiently detailed as there's a possibility that a different series of steps can arrive at a completed topology without triggering the bug. Please call out the order in which each link is established so that it will be clear to a user how exactly the bug is triggered.
adam commented 2025-12-29 18:30:22 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (May 7, 2020):

Question updated

@steffann commented on GitHub (May 7, 2020): Question updated
adam commented 2025-12-29 18:30:22 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Jul 6, 2020):

This bug does not occur anymore in v2.8.7

@steffann commented on GitHub (Jul 6, 2020): This bug does not occur anymore in v2.8.7
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#3646
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?