Representing breakout interfaces/cable

[ronniefalcon]

HI,
I want to be sure I am following the "best practice" when representing the following:

I have 40 GbE port that can be broken out into 4x10 with a breakout cable. But at rest it is simply a 40GbE port. So I must define the port as 40GbE when creating the device type.

However it's not "known" how this port will be treated in future so, to me, it seems defining the physical port as its "as-built" speed and then using virtual interfaces to define the 4x10 [or similar] when needed is the best approach?

It seems "ok" but it also doesn't seem right. Is the alternative to approach the cable as the source of the "breakout" and define it this way? I see chatter that this is the incorrect thing to do :)

Do I have this right, or is this more meant for VLAN interfaces and the like?

[mtinberg]

Check the list for similar questions, Brian Candler wrote about this recently, but once you plug in the breakout cable, you now have added 4 new 10G physical interfaces to the device and the 40G interface can be marked as occupied by the breakout (either the mark connected flag or a custom_field that your templates respect). The physical relationships between the cables/fiber strands, the breakout interfaces and the QSFP might not be perfectly modeled but I think for Interfaces the main focus is not the physical modeling but the logical model needed to template interface configs. Interfaces are strongly associated with VLANs, IPs, FHRP, custom_fields, etc. that allow you to template their config, and the physical details of how specific breakout interfaces are related to the QSFP or which fiber strands are in use don't affect config templating all that much. Eg. if you need a config statement to breakout the port, templating a boolean custom field to enable that statement doesn't require the template to know which specific ports are created by the breakout, unless that's part of the config, right? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: ronniefalcon ***@***.***> Sent: Monday, March 6, 2023 6:34 PM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] Representing breakout interfaces/cable (Discussion #11917) HI, I want to be sure I am following the "best practice" when representing the following: I have 40 GbE port that can be broken out into 4x10 with a breakout cable. But at rest it is simply a 40GbE port. So I must define the port as 40GbE when creating the device type. However it's not "known" how this port will be treated in future so, to me, it seems defining the physical port as its "as-built" speed and then using virtual interfaces to define the 4x10 [or similar] when needed is the best approach? It seems "ok" but it also doesn't seem right. Is the alternative to approach the cable as the source of the "breakout" and define it this way? I see chatter that this is the incorrect thing to do :) Do I have this right, or is this more meant for VLAN interfaces and the like? — Reply to this email directly, view it on GitHub<#11917>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM36VLA44YJDBAMEOLTW2Z7CBANCNFSM6AAAAAAVRZW4WM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[candlerb]

Certainly you're right to start with the single 40G port in the Device Type as you have done. When you want to break it out to 4x10G, then there are a couple of options:

1. Create four new virtual interfaces, with the 40G port as their "parent". Connect a cable to the 40G port at one end, and to four 10G ports at the other end. (Netbox allows a different number of terminations at each end of a cable).
2. Create four new 10G physical interfaces, and either delete or "mark connected" the 40G port (as @mtinberg suggests). Then drop four separate cables into these new 10G interfaces.

Option (1) is better for modelling the physical (cabling) reality: the breakout cable really does have a single connector, going into a single port. But option (2) works better for cable tracing and for finding interface neighbors.

[dionrowney]

This seems like an "all you have to do is" answer. It doesnt really seem the best solution as it should represent the physical world and show correctly in a trace.

I have 100G switches that break out to panels via an LCx4-MPO breakout cable. I now have to misrepresent them as 4 connections plus and 4 separate wires when they are not. If I do it the other way I see the breakout cable but when trying to trace it shows 4 interfaces even though the device is only connected to 1.

I recommend this as a feature enhancement. It seems to me (correct me if I am wrong) that right way is to set the switch port interface 1/1/1 as a QSFP28, then create 4 virtual ports named 1/1/1:[1-4] as children (as this is what the switch does anyways). These children need to have a "position" variable like rear ports do, which when tracing map to through the parents interface wire connection.

Unless I am missing something?

[rapik0088]

using virtual interface is not a case. as the virtual port (1/1/1:[1-4]) is actually a physical port which can be a part of LAG and can have vlan sub-interfaces

[candlerb]

A virtual port can have vlan sub-interfaces just fine in Netbox, so that's not an issue.

I agree that what is there today is not a perfect representation, but it's not the only limitation of the data model.

[rapik0088]

i've just got a dozen of PTX10001-36MR.
and most of the ports should be 4x100G, 4x10G and 4x25G :)
so i have to go with just a phy layout to make a task for my patching team.
and then i will be waiting for this feature to be added into the magic Netbox :)

[fairlight0815]

Option 1 would only work if the cable of the parent port will be connected to multiple interfaces on the same device. It is not possible to connect the breakout cables to multiple devices. But that's exact the use case we're looking for. Do you have any furhter idea how to document it well, without switching to option 2?

[dlayerbynight]

I have the same problem as @ronniefalcon, a QSFP+ interface on one side and four servers with an interface on the other side. The connection between them is a QSFP+ breakout cable. To me it looks like the suggested solutions to model this in netbox are not working.

When creating four new additional virtual interfaces with the 40G port as a parent, it is not possible to connect a cable between the virtual interface and the server interfaces. Only physical interfaces may be connected via cable.

What is the best way to represent the relation between the 40G parent port (for example xe-0/0/1) and the virtual ports (xe-0/0/1:0 to xe-0/0/1:4) in netbox?

[candlerb]

When creating four new additional virtual interfaces with the 40G port as a parent, it is not possible to connect a cable between the virtual interface and the server interfaces. Only physical interfaces may be connected via cable.

That is correct. However, one cable can have multiple connections at either end (or both).

What is the best way to represent the relation between the 40G parent port (for example xe-0/0/1) and the virtual ports (xe-0/0/1:0 to xe-0/0/1:4) in netbox?

The virtual interfaces have a "parent" attribute, which can point to the physical port.

So IMO, the best solution for now is:

1. Create a single physical interface xe-0/0/1 for the QSFP+
2. Create four virtual interfaces xe-0/0/1:[0-3] for the 10G ports, with the QSFP+ physical interface as the parent. These can be configured with the relevant IP address or VLAN or whatever.
3. Create a cable which connects to the QSFP+ interface at one end, and four different device interfaces at the other end.

Physically, that's an accurate model of the breakout cable. What you lose is the ability to trace from the virtual 10G interface to the corresponding peer interface; these will not show as connected peers, since Netbox has no way of associating the N'th termination on a cable at one end, with the N'th child interface on the other.

The alternative, which IMO is less good, is:

1. Create four physical interfaces for the 10G components of the QSFP+ port. Configure them with IP address, VLAN etc.
2. Create four separate "cables" from these to the four different devices interfaces at the other end.

This gives you better tracing, and you can see link peers, but does not reflect physical reality of the breakout cable.

[nickper]

As hardware port capacity grows larger and density stays the same, it becomes more common to use breakout cables.
We for example use 400G breakout cables to 100G. with different endpoints
From the CLI perspective they operate as 4 different interfaces x/x/x/1-4. On the physical side it is partly breakout, with an patch box to 4x 100G.