Missing cable trace when multi termination cables. #7092

@github-actions[bot] commented on GitHub (Apr 12, 2023):

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.

@github-actions[bot] commented on GitHub (Apr 12, 2023): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@hhcatv commented on GitHub (Apr 27, 2023):

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.

@hhcatv commented on GitHub (Apr 27, 2023): 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: ![image](https://user-images.githubusercontent.com/131244255/234739271-352c8862-b04d-41f9-b6a2-d0337ec35f24.png) ODF1 rear ports: ![image](https://user-images.githubusercontent.com/131244255/234739232-32c9378f-f72c-4b73-a660-94ec1b4903c3.png) ODF front ports2: ![image](https://user-images.githubusercontent.com/131244255/234739320-56ed3faf-aefa-4604-b87f-30cf0a22e696.png) ODF2 rear ports: ![image](https://user-images.githubusercontent.com/131244255/234739369-f35b1cc8-06a8-4d75-8e25-37f5338fca4f.png) Cable Trace: ![image](https://user-images.githubusercontent.com/131244255/234739543-bba80520-0972-4d81-ab9c-8e612a9423e0.png) **I don't know, maybe I didn't find the right solution, forgive my translated text.**

adam commented

@DanSheps commented on GitHub (Aug 7, 2023):

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

@DanSheps commented on GitHub (Aug 7, 2023): I believe this is fixed with #13337 (#11079) as it is a similar problem

adam commented

@github-actions[bot] commented on GitHub (Nov 6, 2023):

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.

@github-actions[bot] commented on GitHub (Nov 6, 2023): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@h3po commented on GitHub (Feb 27, 2024):

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.

@h3po commented on GitHub (Feb 27, 2024): 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.

adam commented

@arthanson commented on GitHub (May 13, 2024):

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

@arthanson commented on GitHub (May 13, 2024): @h3po @joaolucasmacedo Can you please try this on NetBox 4? We think this might have possibly been resolved via #13337

adam commented

@h3po commented on GitHub (May 23, 2024):

@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

@h3po commented on GitHub (May 23, 2024): @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 ![image](https://github.com/netbox-community/netbox/assets/8227075/4742825c-cdfc-4785-8c40-e59b6c1dd0d4)

adam commented

@joaolucasmacedo commented on GitHub (Jun 4, 2024):

@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 commented on GitHub (Jun 4, 2024): > @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.

adam commented

@joaolucasmacedo commented on GitHub (Jun 14, 2024):

@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.

@joaolucasmacedo commented on GitHub (Jun 14, 2024): > > @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.

adam commented

@DanSheps commented on GitHub (Jun 18, 2024):

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

@DanSheps commented on GitHub (Jun 18, 2024): 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

adam commented

@joaolucasmacedo commented on GitHub (Jun 18, 2024):

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

@joaolucasmacedo commented on GitHub (Jun 18, 2024): > 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](https://demo.netbox.dev/dcim/interfaces/928/trace/)

adam commented

@DanSheps commented on GitHub (Jun 18, 2024):

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

@DanSheps commented on GitHub (Jun 18, 2024): I want to see what it should look like, not what it looks like currently

adam commented

@joaolucasmacedo commented on GitHub (Jun 18, 2024):

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.

@joaolucasmacedo commented on GitHub (Jun 18, 2024): > I want to see what it should look like, not what it looks like currently It should look like [this](https://demo.netbox.dev/dcim/interfaces/912/trace/): ![image](https://github.com/netbox-community/netbox/assets/66760118/b9c6ec25-59e5-4731-b3f6-6f1777fb7002) 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.

adam commented

@DanSheps commented on GitHub (Jun 18, 2024):

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.

@DanSheps commented on GitHub (Jun 18, 2024): 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.

adam commented

@github-actions[bot] commented on GitHub (Sep 17, 2024):

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.

@github-actions[bot] commented on GitHub (Sep 17, 2024): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@derjam commented on GitHub (Sep 20, 2024):

It looks like this issue is very identical to my reported bug. #17400
I reported a very simple example to reproduce it.

@derjam commented on GitHub (Sep 20, 2024): It looks like this issue is very identical to my reported bug. [#17400](https://github.com/netbox-community/netbox/issues/17400) I reported a very simple example to reproduce it.

adam commented