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

Circuit Termination issue when connected to a rear port with N front ports #2863

New Issue
Closed
opened 2025-12-29 18:22:54 +01:00 by adam · 5 comments
adam commented 2025-12-29 18:22:54 +01:00
Owner
Copy Link

Originally created by @laguyle on GitHub (Sep 11, 2019).

Environment

  • Python version: 3.6.7
  • NetBox version: 2.6.3

Steps to Reproduce

  1. Connect A side and Z side of a circuit to a rear port of a device on both side with N front ports associated (in our case a multiplexer)
  2. Connect front port 1 of the multiplexer on side A to an interface 1 of a device X
  3. Connect front port 1 of the multiplexer on side Z to an interface 1 of a device Y
  4. Connect front port 2 of the multiplexer on side A to an interface 2 of a device X
  5. Connect front port 2 of the multiplexer on side Z to an interface 2 of a device Y

Here is a network diagram to understand our case:

image

Expected Behavior

We should see interfaces 1 and 2 of device X connected to interfaces 1 and 2 of device Y through the circuit.

Observed Behavior

Only interfaces 1 of devices X and Y are well linked through the circuit.
Interfaces 2 are not totally linked.
I supposed it's due to the fact that when we link the first front port of each mux to interfaces 1 of devices X and Y, terminations of the circuit is moved to Device X - port 1 on A side and Device Y - port 1 on Z side.
I think terminations of the circuit should always stay as the first port or interface it is linked, in our case the rear port of each MUX.

Originally created by @laguyle on GitHub (Sep 11, 2019). ### Environment * Python version: 3.6.7 * NetBox version: 2.6.3 ### Steps to Reproduce 1. Connect A side and Z side of a circuit to a rear port of a device on both side with N front ports associated (in our case a multiplexer) 2. Connect front port 1 of the multiplexer on side A to an interface 1 of a device X 3. Connect front port 1 of the multiplexer on side Z to an interface 1 of a device Y 4. Connect front port 2 of the multiplexer on side A to an interface 2 of a device X 5. Connect front port 2 of the multiplexer on side Z to an interface 2 of a device Y Here is a network diagram to understand our case: ![image](https://user-images.githubusercontent.com/39376910/64680154-880c0380-d47d-11e9-9763-d7a048750b7c.png) ### Expected Behavior We should see interfaces 1 and 2 of device X connected to interfaces 1 and 2 of device Y through the circuit. ### Observed Behavior Only interfaces 1 of devices X and Y are well linked through the circuit. Interfaces 2 are not totally linked. I supposed it's due to the fact that when we link the first front port of each mux to interfaces 1 of devices X and Y, terminations of the circuit is moved to Device X - port 1 on A side and Device Y - port 1 on Z side. I think terminations of the circuit should always stay as the first port or interface it is linked, in our case the rear port of each MUX.
adam added the status: duplicate label 2025-12-29 18:22:54 +01:00
adam closed this issue 2025-12-29 18:22:55 +01:00
adam commented 2025-12-29 18:22:55 +01:00
Author
Owner
Copy Link

@wols commented on GitHub (Oct 8, 2019):

NetBox version: 2.6.5
I wanted to adjust the config, but get the error message when connecting the MUX rear ports:
Side A has 1 positions and rear has 2. Both terminations must have the same number of positions.

My MUX (X side):
mux-x

This constellation is NOT a "Y junction". You should create the MUX as device with Interfaces.

@wols commented on GitHub (Oct 8, 2019): NetBox version: 2.6.5 I wanted to adjust the config, but get the error message when connecting the MUX rear ports: `Side A has 1 positions and rear has 2. Both terminations must have the same number of positions.` My MUX (X side): ![mux-x](https://user-images.githubusercontent.com/764167/66390137-4f9f0d00-e9ca-11e9-8c75-ff3f16e9a821.png) This constellation is NOT a "Y junction". You should create the MUX as device with _Interfaces_.
adam commented 2025-12-29 18:22:55 +01:00
Author
Owner
Copy Link

@zelfix commented on GitHub (Oct 9, 2019):

I have the same error, as a result, I have to use interfaces on the passive DWDM device instead of rear and front physical ports.

@zelfix commented on GitHub (Oct 9, 2019): I have the same error, as a result, I have to use interfaces on the passive DWDM device instead of rear and front physical ports.
adam commented 2025-12-29 18:22:56 +01:00
Author
Owner
Copy Link

@wols commented on GitHub (Oct 9, 2019):

Suggestion: if you bring all interfaces to one vlan(group) you can see them as vlan members (vlan role: doc) ;-)

@wols commented on GitHub (Oct 9, 2019): Suggestion: if you bring all interfaces to one vlan(group) you can see them as vlan members (vlan role: doc) ;-)
adam commented 2025-12-29 18:22:56 +01:00
Author
Owner
Copy Link

@laguyle commented on GitHub (Oct 10, 2019):

I don't want to define interfaces on my DWDM devices, this doesn't make sense.
The functionnality to associate several front ports to one rear port is exactly what we need.

But I think there is a limitation somewhere in the code that requires that a rear port has to be DIRECTLY connected to a rear port of another device with exactly the same number of front ports on each devices.
But in our case, rear ports are not directly connected because we want to insert a circuit between them.

@laguyle commented on GitHub (Oct 10, 2019): I don't want to define interfaces on my DWDM devices, this doesn't make sense. The functionnality to associate several front ports to one rear port is exactly what we need. But I think there is a limitation somewhere in the code that requires that a rear port has to be DIRECTLY connected to a rear port of another device with exactly the same number of front ports on each devices. But in our case, rear ports are not directly connected because we want to insert a circuit between them.
adam commented 2025-12-29 18:22:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 23, 2019):

Just realized this is the same issue as described in #3288

@jeremystretch commented on GitHub (Oct 23, 2019): Just realized this is the same issue as described in #3288
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: duplicate
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#2863
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?