40G / MTP over LC-LC trunk modeling (MTP to 4LC duplex break-out)

[Foucault de Bonneval]

Hi,

I need to use a MTP/MPO to four LC duplex breakout cable to connect two 40Gb/s interfaces.

And I'd like to know if anyone has represented it in Netbox.

My scenario is this one :

- I have to devices with SR4 / MTP in two racks

- My pre-cabling has a 12LC duplex cassette on each side

- I created and connected a rear port on each cassette with 12 positions

- I have created an interface with MPO type on each device

But from now when I connect a device interface to a cassette front port on each side, the trace shows that only one position is used in the "rear port"-to-"rear port" cable as in real life I'am using 4 LC duplex positions.

Does anyone have the same issue with the modeling of MTP breakout cables in Netbox patching ?

I'd love to hear your solutions (as long as it does not involve an "intermediary device").

Thanks,

Foucault

[Jason Guy]

Hi Foucault

We have these as well, and while there is no way to represent the connectors, the 40G side has to be broken-out into 4 discrete interfaces. So we create the physical interfaces under the device, and when the 40G becomes 4x10G, we add the additional interfaces, and make the connections. It would be cool if there was a better way to represent the breakout interface and connection, but currently is not important to have that level of precision.

Jason

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/CAKacRJw99NyBpiJ0oH_EnEH6r_fa7GwPTWOp0aOCczBrE_%3DeMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Christian MacNevin]

Did you get any followup on this? This sort of cabling is going to become really prevalent in general, including
for us. 25Gig solutions will primarily be deployed this way, either with cassettes or with 4-way breakout DAC
cables.

Is this just a matter of creating a new form factor which can handle one-to-many connections?

From: <netbox-...@googlegroups.com> on behalf of Foucault de Bonneval <fouc...@thaumiers.com>
Date: Monday, July 8, 2019 at 1:49 PM
To: "netbox-...@googlegroups.com" <netbox-...@googlegroups.com>
Subject: [netbox-discuss] 40G / MTP over LC-LC trunk modeling (MTP to 4LC duplex break-out)

 

External email: Use caution opening links or attachments

 

--

You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/CAKacRJw99NyBpiJ0oH_EnEH6r_fa7GwPTWOp0aOCczBrE_%3DeMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

---

[Elliott Brown]

I've just hit this very issue now with installing our new Core Network.

So far we are modeling the interfaces as they are on the Juniper:

xe-0/1/1:0 -> LC Patch panel back <> Front -> cable out

xe-0/1/1:1 -> LC Patch panel back <> Front -> cable out

xe-0/1/1:2 -> LC Patch panel back <> Front -> cable out

xe-0/1/1:3 -> LC Patch panel back <> Front -> cable out

We are not fully moved onto Netbox, so we are still playing about with some aspect and not running the latest 2.5.13.

[Sander Steffann]

Hi,

> I've just hit this very issue now with installing our new Core Network.
>
> So far we are modeling the interfaces as they are on the Juniper:
>
> xe-0/1/1:0 -> LC Patch panel back <> Front -> cable out
> xe-0/1/1:1 -> LC Patch panel back <> Front -> cable out
> xe-0/1/1:2 -> LC Patch panel back <> Front -> cable out
> xe-0/1/1:3 -> LC Patch panel back <> Front -> cable out

I have been thinking about situations like this as well. We have 40G MPO links that go to the back of a patch panel, where they are split out into 4x 10G LC. Because the MPO QSFP has an internal mux, it feels natural to model the physical MPO side as a "rear-like" port (which nicely matches with the rear port of the patch panel) and the four component interfaces as, I don't know, "virtual/internal front port interfaces"?

That way it would fit in with the current front/rear port architecture, allow to model the MPO connection as a single cable, and allow the component interfaces to nicely link to their connected counterpart.

I recently did a lot of experimenting with more flexible/versatile solutions for cable and connection tracing etc. That was mainly to support DWDM and CWDM and show the most logical remote endpoint to the user from any point on the path. Adding support for this on the interface level is certainly something I kept in mind while working on that, but the DWDM change is already so large that it's not easy for the Netbox maintainers to accept it. It already changes a lot.

Without that extra versatility it would be hard to add component interfaces. With the new versatility it won't be very hard. But adding all of that in one go would be way too much to ask of the maintainers. They have a huge responsibility for the architecture and quality of the code. So I'm encouraging adoption of my more versatile solution first (but hey, I'm biased ;), and then use the new architecture to solve questions like this.

There are more issues in the tracker that can be solved like this. If the Netbox maintainers agree that my proposed change is the right way forward, I promise I will then proceed with all the other questions/issues that can benefit from it!

Cheers,
Sander

PS: and I fully accept that the maintainers might prefer another solution. If so I commit to working on that too