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

Connecting Interface to Rear Port half fails #2978

New Issue
Closed
opened 2025-12-29 18:24:19 +01:00 by adam · 4 comments
adam commented 2025-12-29 18:24:19 +01:00
Owner
Copy Link

Originally created by @millijuna on GitHub (Oct 26, 2019).

Environment

  • Python version: 3.7.3
  • NetBox version: 2.6.6

Connecting a device Interface to a patch panel rear port does not work correctly if that rear port is not associated with a front port. Netbox throws the following error:

<class 'ValueError'>

Connected endpoint must be an Interface or CircuitTermination, not <class 'dcim.models.RearPort'>.

The model becomes inconsistent in this state. The patch panel shows the rear port connected to the device interface, but the interface on the device does not show it as connected to the rear port. Likely the best behaviour here would be to prevent the user from making this connection (to an unconnected rear port) until it's associated with a front port.

Steps to Reproduce

  1. Create a patch panel with just a 110 punchdown rear port, and not associated with a front port
  2. Create a simple device with a basic 8P8C interface
  3. Connect the interface to the rear port on the patch panel
  4. Observe the error
  5. Look at the status of the patch panel and note that it shows the rear port as connected
  6. Look at the status of the device, and note that it shows the interface as not connected.

Expected Behavior

Either prevent the connection to the unassociated rear port, or allow it without the errors.

Observed Behavior

Originally created by @millijuna on GitHub (Oct 26, 2019). <!-- NOTE: This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.7.3<!-- Example: 3.5.4 --> * NetBox version: 2.6.6<!-- Example: 2.5.2 --> Connecting a device Interface to a patch panel rear port does not work correctly if that rear port is not associated with a front port. Netbox throws the following error: <class 'ValueError'> Connected endpoint must be an Interface or CircuitTermination, not <class 'dcim.models.RearPort'>. The model becomes inconsistent in this state. The patch panel shows the rear port connected to the device interface, but the interface on the device does not show it as connected to the rear port. Likely the best behaviour here would be to prevent the user from making this connection (to an unconnected rear port) until it's associated with a front port. ### Steps to Reproduce 1. Create a patch panel with just a 110 punchdown rear port, and not associated with a front port 2. Create a simple device with a basic 8P8C interface 3. Connect the interface to the rear port on the patch panel 4. Observe the error 5. Look at the status of the patch panel and note that it shows the rear port as connected 6. Look at the status of the device, and note that it shows the interface as not connected. <!-- What did you expect to happen? --> ### Expected Behavior Either prevent the connection to the unassociated rear port, or allow it without the errors. <!-- What happened instead? --> ### Observed Behavior
adam added the type: bugstatus: accepted labels 2025-12-29 18:24:19 +01:00
adam closed this issue 2025-12-29 18:24:19 +01:00
adam commented 2025-12-29 18:24:19 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 28, 2019):

I am unable to reproduce this following the steps outlined.

Please review your steps to reproduce.

@DanSheps commented on GitHub (Oct 28, 2019): I am unable to reproduce this following the steps outlined. Please review your steps to reproduce.
adam commented 2025-12-29 18:24:19 +01:00
Author
Owner
Copy Link

@millijuna commented on GitHub (Oct 28, 2019):

Huh...

Just walking through this right now:

  1. Create a new 2U rack (named "Test Rack")
  2. Create a new Generic Patch Panel in bottom U (named "Test Patch") at the start, it has no front/rear ports.
  3. Create a rear port on the Generic Patch Panel (named it "Rear Port 20") of type 110, and 1 position.
  4. Create a new generic device that is not in a rack (In my case, it's an access point, but that's largely irrelevant).
  5. On that device page create an interface (if it doesn't already exist, as it does in my template). In my case, "Gig 0"
  6. Click on the "Connect" icon for that interface, and select "Rear Port" and navigate to the rear port created in step 3) above. Select Cat 5e for type, distance to say 50' and colour to blue.

And it blows up with the error as mentioned in the initial report.

it's relatively minor, as the problem goes away when that rear port is associated with a front port. It's mostly a problem with the initial workflow I was doing as I was documenting how my APs connect. I don't have my Patch Panel templates fully populated, as they often have 25 pair trunks hanging off the back, and the occasional AP direclty punched down on them.

@millijuna commented on GitHub (Oct 28, 2019): Huh... Just walking through this right now: 1) Create a new 2U rack (named "Test Rack") 2) Create a new Generic Patch Panel in bottom U (named "Test Patch") at the start, it has no front/rear ports. 3) Create a rear port on the Generic Patch Panel (named it "Rear Port 20") of type 110, and 1 position. 4) Create a new generic device that is not in a rack (In my case, it's an access point, but that's largely irrelevant). 5) On that device page create an interface (if it doesn't already exist, as it does in my template). In my case, "Gig 0" 6) Click on the "Connect" icon for that interface, and select "Rear Port" and navigate to the rear port created in step 3) above. Select Cat 5e for type, distance to say 50' and colour to blue. And it blows up with the error as mentioned in the initial report. it's relatively minor, as the problem goes away when that rear port is associated with a front port. It's mostly a problem with the initial workflow I was doing as I was documenting how my APs connect. I don't have my Patch Panel templates fully populated, as they often have 25 pair trunks hanging off the back, and the occasional AP direclty punched down on them.
adam commented 2025-12-29 18:24:20 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 29, 2019):

This is my bad, I missed the one step of "not associated with a front port"

@DanSheps commented on GitHub (Oct 29, 2019): This is my bad, I missed the one step of "not associated with a front port"
adam commented 2025-12-29 18:24:20 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 6, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Dec 6, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
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#2978
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?