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 support for spliced pigtails / punched cable to rear ports #2334

New Issue
Closed
opened 2025-12-29 17:24:55 +01:00 by adam · 10 comments
adam commented 2025-12-29 17:24:55 +01:00
Owner
Copy Link

Originally created by @ktims on GitHub (Feb 1, 2019).

Environment

  • Python version: 3.6.3
  • NetBox version: 2.5.5

Proposed Functionality

Add support for patch panels that do not use connectors on the rear side.

Use Case

It is common for both fibre and copper patch panels to be 'hard wired' to another 'rear port' on another panel. Presently the model both enforces a connector on the rear port, and doesn't provide an appropriate connector type to model this.

Database Changes

I'm not sure the best nouns to use, but suggest the addition of two connector types to the cabling model, for 'pigtail fibre' and 'punched copper'. Perhaps just making the field nullable satisfies this, too, if connections to 'null' connectors are allowed. It should also be allowed to connector either of these types on one end to a connectorized panel on the other end.

Originally created by @ktims on GitHub (Feb 1, 2019). ### Environment * Python version: 3.6.3 * NetBox version: 2.5.5 ### Proposed Functionality Add support for patch panels that do not use connectors on the rear side. ### Use Case It is common for both fibre and copper patch panels to be 'hard wired' to another 'rear port' on another panel. Presently the model both enforces a connector on the rear port, and doesn't provide an appropriate connector type to model this. ### Database Changes I'm not sure the best nouns to use, but suggest the addition of two connector types to the cabling model, for 'pigtail fibre' and 'punched copper'. Perhaps just making the field nullable satisfies this, too, if connections to 'null' connectors are allowed. It should also be allowed to connector either of these types on one end to a connectorized panel on the other end.
adam added the status: acceptedtype: feature labels 2025-12-29 17:24:55 +01:00
adam closed this issue 2025-12-29 17:24:55 +01:00
adam commented 2025-12-29 17:24:56 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 1, 2019):

'punched copper' is still 8P8C
'pigtail fibre' is going to break out into individual strands with a individual connector (LC, SC, MPO, etc) (I always do color coded strands anyways, I never use the "position" for fiber)

@DanSheps commented on GitHub (Feb 1, 2019): 'punched copper' is still 8P8C 'pigtail fibre' is going to break out into individual strands with a individual connector (LC, SC, MPO, etc) (I always do color coded strands anyways, I never use the "position" for fiber)
adam commented 2025-12-29 17:24:56 +01:00
Author
Owner
Copy Link

@ktims commented on GitHub (Feb 1, 2019):

'punched copper' is still 8P8C
'pigtail fibre' is going to break out into individual strands with a individual connector (LC, SC, MPO, etc) (I always do color coded strands anyways, I never use the "position" for fiber)

Punched copper isn't 8P8C if it doesn't have an 8P8C connector on it, which it doesn't if it's punched down on the rear of a patch panel.

The fibre does obviously break out to a connector, but that is what the front port is designed to model. On the rear I'd be happy to just have a '12 strand fibre' as a single connector, or break them out to individual strands, but currently you have to choose a connector type, which doesn't make sense when it's pigtails on both ends that are spliced into the patch panels.

You do bring up a good point though. If you model the individual strands (which I think is a good idea), it's also not reasonably possible to then actually connect these to an Interface, since most fibre Interfaces use two strands, but you're only allowed to connect one Front Port to each Interface. Modelling them as duplex pairs breaks down if you need to mix simplex and duplex links.

@ktims commented on GitHub (Feb 1, 2019): > 'punched copper' is still 8P8C > 'pigtail fibre' is going to break out into individual strands with a individual connector (LC, SC, MPO, etc) (I always do color coded strands anyways, I never use the "position" for fiber) Punched copper isn't 8P8C if it doesn't have an 8P8C connector on it, which it doesn't if it's punched down on the rear of a patch panel. The fibre does obviously break out to a connector, but that is what the front port is designed to model. On the rear I'd be happy to just have a '12 strand fibre' as a single connector, or break them out to individual strands, but currently you *have* to choose a connector type, which doesn't make sense when it's pigtails on both ends that are spliced into the patch panels. You do bring up a good point though. If you model the individual strands (which I think is a good idea), it's also not reasonably possible to then actually connect these to an Interface, since most fibre Interfaces use two strands, but you're only allowed to connect one Front Port to each Interface. Modelling them as duplex pairs breaks down if you need to mix simplex and duplex links.
adam commented 2025-12-29 17:24:56 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 1, 2019):

Punched copper isn't 8P8C if it doesn't have an 8P8C connector on it, which it doesn't if it's punched down on the rear of a patch panel.

Don't want to argue with you, but there is a 8P8C connector somewhere right? Just because the connector is on the front and you are punching down to the back doesn't make it any less of a 8P8C connector.

On a fiber panel, unless you are using the pigtail (I am assuming you actually mean MPO/MPT fan-out or MPO/MPT to LC/SC cassettes) changes are you are going into a housing to connect the two connectors together. You actually do have a connector on the both side (front and back), and if you really want to get down to it, you should be modelling these completely.

The other "other good point", I simply put a "Simplex/Duplex" converter object on my switches/interface modules and label them "Upstream/Downstream" (For example, TenGigabitEthernet1/1/1.Upstream and TenGigabitEthernet1/1/1.Downstream" and link the single interface to the LC connector with a "zero length" cable.

@DanSheps commented on GitHub (Feb 1, 2019): > Punched copper isn't 8P8C if it doesn't have an 8P8C connector on it, which it doesn't if it's punched down on the rear of a patch panel. Don't want to argue with you, but there is a 8P8C connector somewhere right? Just because the connector is on the front and you are punching down to the back doesn't make it any less of a 8P8C connector. On a fiber panel, unless you are using the pigtail (I am assuming you actually mean MPO/MPT fan-out or MPO/MPT to LC/SC cassettes) changes are you are going into a housing to connect the two connectors together. You actually do have a connector on the both side (front and back), and if you really want to get down to it, you should be modelling these completely. The other "other good point", I simply put a "Simplex/Duplex" converter object on my switches/interface modules and label them "Upstream/Downstream" (For example, TenGigabitEthernet1/1/1.Upstream and TenGigabitEthernet1/1/1.Downstream" and link the single interface to the LC connector with a "zero length" cable.
adam commented 2025-12-29 17:24:56 +01:00
Author
Owner
Copy Link

@ktims commented on GitHub (Feb 1, 2019):

Don't want to argue with you, but there is a 8P8C connector somewhere right? Just because the connector is on the front and you are punching down to the back doesn't make it any less of a 8P8C connector.

The way Netbox models patch panels, there are two connectors for each circuit. One on the front, one on the rear. There is no physical connector on the rear (unless you count the IDC punch block as a connector... in which case it should appear in the list of options), therefore it doesn't make sense for the model to require one, which is the present state. Obviously the front port is 8P8C.

(I am assuming you actually mean MPO/MPT fan-out or MPO/MPT to LC/SC cassettes)

I don't know why you would assume such when I have clearly stated that's not what I'm talking about... this case is clearly supported. Let me reiterate the request is to add support for spliced pigtails.

The other "other good point", I simply put a "Simplex/Duplex" converter object on my switches/interface modules and label them "Upstream/Downstream" (For example, TenGigabitEthernet1/1/1.Upstream and TenGigabitEthernet1/1/1.Downstream" and link the single interface to the LC connector with a "zero length" cable.

This is a clumsy workaround. Better support would be appreciated.

@ktims commented on GitHub (Feb 1, 2019): > Don't want to argue with you, but there is a 8P8C connector somewhere right? Just because the connector is on the front and you are punching down to the back doesn't make it any less of a 8P8C connector. The way Netbox models patch panels, there are two connectors for each circuit. One on the front, one on the rear. There is no physical connector on the rear (unless you count the IDC punch block as a connector... in which case it should appear in the list of options), therefore it doesn't make sense for the model to require one, which is the present state. Obviously the front port is 8P8C. > (I am assuming you actually mean MPO/MPT fan-out or MPO/MPT to LC/SC cassettes) I don't know why you would assume such when I have clearly stated that's *not* what I'm talking about... this case is clearly supported. Let me reiterate the request is to add support for *spliced pigtails*. > The other "other good point", I simply put a "Simplex/Duplex" converter object on my switches/interface modules and label them "Upstream/Downstream" (For example, TenGigabitEthernet1/1/1.Upstream and TenGigabitEthernet1/1/1.Downstream" and link the single interface to the LC connector with a "zero length" cable. This is a clumsy workaround. Better support would be appreciated.
adam commented 2025-12-29 17:24:57 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 4, 2019):

I don't know why you would assume such when I have clearly stated that's not what I'm talking about... this case is clearly supported. Let me reiterate the request is to add support for spliced pigtails.

You don't need a new connector for spliced pigtails, as they will still either have a ST/SC/LC/etc connector.

@DanSheps commented on GitHub (Feb 4, 2019): > I don't know why you would assume such when I have clearly stated that's not what I'm talking about... this case is clearly supported. Let me reiterate the request is to add support for spliced pigtails. You don't need a new connector for spliced pigtails, as they will still either have a ST/SC/LC/etc connector.
adam commented 2025-12-29 17:24:57 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 4, 2019):

8P8C is technically a modular form factor. We could add a "Fixed" type to represent punched-down terminations.

I'm not sure what you mean by "spliced pigtails." Can you share a photo?

Modelling them as duplex pairs breaks down if you need to mix simplex and duplex links.

You can model duplex and simplex links on the same device. For example, we have fiber ports named 1/2 and 3/4 for duplex links (two strands per port), and 5 and 6 for simplex links.

@jeremystretch commented on GitHub (Feb 4, 2019): 8P8C is technically a modular form factor. We could add a "Fixed" type to represent punched-down terminations. I'm not sure what you mean by "spliced pigtails." Can you share a photo? > Modelling them as duplex pairs breaks down if you need to mix simplex and duplex links. You can model duplex and simplex links on the same device. For example, we have fiber ports named 1/2 and 3/4 for duplex links (two strands per port), and 5 and 6 for simplex links.
adam commented 2025-12-29 17:24:57 +01:00
Author
Owner
Copy Link

@ktims commented on GitHub (Feb 4, 2019):

Mea culpa. @DanSheps is right, I'd never actually closely examining the splice trays, but of course the pigtails terminate in connectors, for some reason I thought they were spliced directly to the bulkhead connectors. Sorry guys.

You can model duplex and simplex links on the same device. For example, we have fiber ports named 1/2 and 3/4 for duplex links (two strands per port), and 5 and 6 for simplex links.

Hmm, I guess this works. It does tie the logical 'connection' a little closely to the physical plant for my liking (the modelling of the connectors / cables depends on what type of connection they are used for, not how the cable is built), but it's a decent compromise.

@ktims commented on GitHub (Feb 4, 2019): Mea culpa. @DanSheps is right, I'd never actually closely examining the splice trays, but of course the pigtails terminate in connectors, for some reason I thought they were spliced directly to the bulkhead connectors. Sorry guys. > You can model duplex and simplex links on the same device. For example, we have fiber ports named 1/2 and 3/4 for duplex links (two strands per port), and 5 and 6 for simplex links. Hmm, I guess this works. It does tie the logical 'connection' a little closely to the physical plant for my liking (the modelling of the connectors / cables depends on what type of connection they are used for, not how the cable is built), but it's a decent compromise.
adam commented 2025-12-29 17:24:57 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 4, 2019):

8P8C is technically a modular form factor. We could add a "Fixed" type to represent punched-down terminations.

Fixed or 110 would work. I mean, technically it is a 110 connection. I think everyone gets what is going on with 8P8C though, not everyone would get 110. Might get fixed, but might also mis-use it.

@DanSheps commented on GitHub (Feb 4, 2019): > 8P8C is technically a modular form factor. We could add a "Fixed" type to represent punched-down terminations. Fixed or 110 would work. I mean, technically it is a 110 connection. I think everyone gets what is going on with 8P8C though, not everyone would get 110. Might get fixed, but might also mis-use it.
adam commented 2025-12-29 17:24:57 +01:00
Author
Owner
Copy Link

@jbakklund commented on GitHub (Feb 14, 2019):

Hi @jeremystretch. Here is a photo showing a patch panel delivered with factory mounted pigtails prepared for splicing incoming cable(s). This panel has 48 LC/APC connectors in front and no connectors at the rear other than the 48 naked fiber tails (or pigtails).
panel75-lc-apc-pigtail-03
I have one such panel where 24 of the front ports (numbered 25-48) are related to one single rear 'port' named '25-48' of the fictitious type 'LC' with 24 positions (or fixed splices). They are all 'connected' to a 24-strand multicable connected to a rear port named '1-24' in the far end - and tracing a connection e.g. from port 29 at one end, via the fifth position at the rear to port 5 at the distant end - works just fine.

But allowing 'splice' or 'fixed splice' as connection type - would make sense in this case.

@jbakklund commented on GitHub (Feb 14, 2019): Hi @jeremystretch. Here is a photo showing a patch panel delivered with factory mounted pigtails prepared for splicing incoming cable(s). This panel has 48 LC/APC connectors in front and no connectors at the rear other than the 48 naked fiber tails (or pigtails). ![panel75-lc-apc-pigtail-03](https://user-images.githubusercontent.com/33431806/52814863-77d5a680-309d-11e9-8118-66f043f9200e.jpg) I have one such panel where 24 of the front ports (numbered 25-48) are related to one single rear 'port' named '25-48' of the fictitious type 'LC' with 24 positions (or fixed splices). They are all 'connected' to a 24-strand multicable connected to a rear port named '1-24' in the far end - and tracing a connection e.g. from port 29 at one end, via the fifth position at the rear to port 5 at the distant end - works just fine. But allowing 'splice' or 'fixed splice' as connection type - would make sense in this case.
adam commented 2025-12-29 17:24:57 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 15, 2019):

@jbakklund what is the model of that cassette?

@DanSheps commented on GitHub (Feb 15, 2019): @jbakklund what is the model of that cassette?
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: 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#2334
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?