Missing cable trace when multi termination cables.

[joaolucasmacedo]

NetBox version

v3.3.2

Python version

3.10

Steps to Reproduce

0. Create a regular fiber patch panel device with 24 front and rear ports (12 pairs).
1. Create a cable connecting more than 2 rear ports between devices, like 2 fiber patch panels connected by a 2 or 3 pair fiber cable.
2. Connect 2 devices by its interfaces using the correspondent front ports from each patch panel.
3. See that the trace does not "see" the 2 ending interfaces relationship.

Expected Behavior

Being able to see each device on each connection end. My goal is to model 2 devices connected by 2 fiber patch panels. Each patch panel has 12 double SC ports(24 rear and front ports with 1 position). Patch panels are connected by a 3 pair fiber cable on 6 rear ports each. Device interfaces are connected using patch panel's front ports on each side.

Router1-Gig0/0/3 >> |frontPort <> Patch panel <> rearPort| <>----3 pair fiber cable----<>|rearPort <> Patch panel <> frontPort| << Gig0/0/3-Router2

Observed Behavior

It only works as expected if I make each connection using 2 terminations on the middle cable, as if it was a single pair cable between patch panels. See the Cable 25 on the images bellow. If the cable between patch panels is connected to a pair of rear ports on each side everything works fine and I can see the peering device as below:

But if I connect 3 pairs of rear ports on each side of cable 25, as it is on real world, is lost the reace between devices:

[jeremystretch]

I'm not sure this specific topology is something we're able to support. Typically, you would model this as multiple front ports mapped to a single rear port, rather than multiple rear ports all terminated to a common cable. The root challenge is that there's no strict ordering of the individual cable terminations, so it's not feasible to reliably determine the proper far-end terminations when tracing the cable path.

[github-actions[bot]]

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[hhcatv]

It is a real situation that high-fiber-count cables are spliced ​​into multiple ODF trays. Suppose I link 2 network optical distribution frames [ODF] with 24-core optical cable, and each ODF contains 2 ODF trays, which is the real situation. The tray is constructed in a modular way to facilitate the automatic naming of ports. The tray module creates 12 front ports and 1 rear port (required in netbox), the rear port corresponds to the 12 cores in the fiber optic cable. Insert the tray module into the 2 slots of the ODF, and connect the 2 back ports to the 2 back ports of another ODF, that is, to the same optical cable. At this time, the cable routing will appear abnormal. 【Google Translate】 ODF1 front ports:

ODF1 rear ports:

ODF front ports2:

ODF2 rear ports:

Cable Trace:

I don't know, maybe I didn't find the right solution, forgive my translated text.

[DanSheps]

I believe this is fixed with #13337 (#11079) as it is a similar problem

[github-actions[bot]]

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[h3po]

I am facing the same problem when modeling split switch interfaces. I have 4 split switch interfaces connected through a single MPO cable into a module that maps 1 rear to 4 front ports, so the cable is terminated 4x on one side into the single rear port. Attaching an interface to one of the front ports results in that interface being traced to all 4 switch ports.

[arthanson]

@h3po @joaolucasmacedo Can you please try this on NetBox 4? We think this might have possibly been resolved via #13337

[h3po]

@arthanson I just tested with 2faa72c1e921 (v4.0.3), the behavior is still the same. In this example, the "test" interface shows as connected to all 4 switch ports

[joaolucasmacedo]

@h3po @joaolucasmacedo Can you please try this on NetBox 4? We think this might have possibly been resolved via #13337

Hi @h3po I'll try it soon.

[joaolucasmacedo]

@h3po @joaolucasmacedo Can you please try this on NetBox 4? We think this might have possibly been resolved via #13337

Hi @h3po I'll try it soon.

Hi. I've just tested with NetBox 4.0.5(demo) and it is the same. Also there is other bug I found trying to model some fiber patch/splices. I'll try to create a issue for that.

[DanSheps]

Could you supply the full path in the form of a graph of some kind for both of your scenarios? This is likely an unsupported path but we could possible add support for it, via a FR

[joaolucasmacedo]

Could you supply the full path in the form of a graph of some kind for both of your scenarios? This is likely an unsupported path but we could possible add support for it, via a FR

Please, see #16571 Or see this tace

[DanSheps]

I want to see what it should look like, not what it looks like currently

[joaolucasmacedo]

I want to see what it should look like, not what it looks like currently

It should look like this:

As I show on #16571 I'm trying to model a connection between 2 switches that passes through 2 fiber patch panels, and may use different cables connected on its rear ports.

[DanSheps]

So, it looks like it works in your example (because I see it on the demo site), but I think I know what is going on here:

When it enters DIO X1 on the FP1 a cable position is pushed to a position stack. It normally shouldn't matter what order it is pushed in as most enter and exit the same cable on the rear port side, however when it is pushed because there are two different cables, the rear port matters, because when it is popped off the stack, it we need to order the cables in reverse order, otherwise, what we can have is:

[FP1-1A][RP1] --- [RP1][FP1-5A]
[FP2-5A][RP2] --- [RP2][FP2-1A]

As you can see, the position is flipped.

I think there might be some overlap with #11671 as implementing #11671 would allow us to potentially get rid of the position stack.

I have marked #16571 as a duplicate of this, as it really is all related I believe, and closed it out.