Improved Breakout Modeling

[davidgwatkins]

Hi all,

Have seen the topic of interfaces on breakout modules discussed in several places, but never to a complete and (to me) satisfactory resolution. The addition of many-to-many relationship on Cable terminations solves some of the challenges of modeling the physical infrastructure, but not all, and does not capture the logical. I am proposing NetBox at work, and anticipate this being a source of significant pushback given our widespread use of breakouts. (Aside: our current inventory also very poorly models this connectivity, but you know, change is hard and should be feared above all.)

I opened #11070 to address this issue. Essentially, a cable termination would consume the native interface of the equipment (QSFP, OSFP, CFP, etc). The proposed child cables would consume the child interfaces of the parent native interface, and the termination choices for A and B terminations would be limited to the subset of the A and B terminations of the parent cable, enabling cable traces to be completed between child interfaces and the remote devices, perhaps through fiber plant.

After further thought, I believe the interface model would need to be updated as well. The child interfaces are not logical or virtual interfaces -- they are physical; they map to electrical lanes of the parent interface. As such, the child interface should inherit the type of the parent with sub-rate speeds. I think enabling loose restrictions in choices here would be the way to go -- for instance, given a QSFP28 native interface, child interfaces could have type QSFP28 (10GE) or QSFP28 (25GE), with perhaps a test to sanity check breakout children interface speeds not exceeding parent. Would avoid granularity of typing to specific breakout (4x10GE or 2x100GE) -- there are an enormous variety of these and will continue to grow and evolve (see: introduction of QSFP-DD 800).

So, to recap:

• Add boolean "breakout" to interface operation section (see rough mock-up below)
• Child interfaces of parent interface with breakout = true must inherit type of parent (or new breakout type)
• Introduce parent-child relationship (depth limit 1) to cable model
• Limit child cable termination selection to parent for both sides

Trying to get up to speed with Django enough to be able to contribute the changes myself -- potentially over the holiday break and on a fancy new v3.4 build -- but wanted to solicit feedback from maintainers and the community at large before I invest a large amount of time and effort and have a PR rot on the shelf.

[jsenecal]

There is already a parent:child functionality to interfaces. Connecting Childrens to cables negates the requirement for a modification to the cable model. However the graphical representation could benefit from an added boolean to a parent interface. Something along the lines of "Channelized interface"

But maybe I'm missing the point ?

[davidgwatkins]

@jsenecal The point of child cables is to model components of the larger cable. Say I have an MPO-8 connector on one side, and 4x duplex LC on the other side. I can treat that as one cable now, with the MPO connector consuming the interface of the QSFP in the native interface in termination A, and the LC connectors consuming either SFP interfaces or simplex/duplex of the intermediate fiber plant for termination B. If I then operate the QSFP interface in breakout mode (4x10G, say), and create four 10G interfaces, how do I now model the connectivity between these child interfaces of the QSFP parent to the remote end interfaces? Separate cables would fail -- the desired B termination is already consumed.

A single cable with termination A consuming both the QSFP and the child interfaces would create a many-to-many relationship of all termination B interfaces, solving perhaps the cabling modeling, but not the interface connectivity issue where QSFP child interfaces trace to only a single remote device interface.

[mtinberg]

The issue is that only Virtual interfaces are allowed to be Child interfaces (aka subinterfaces) so there would need to be changes to validation rules to allow a QSFP28 to have children SFP+ interfaces representing an octopus cable. I suppose you could make a single-object custom_field on Interface pointing to Interface so children can point to their parent outside of the existing validation rules. As far as having the db model validate specific mappings of parent to child (eg a QSFP28 can have x number of SFP+ children or whatever) there is an ongoing maintenance burden to keep this data accurate (similar to the burden of enumerating all interface types) that would need to be taken into account for pushing validation into the core vs just providing a data storage mechanism that is broadly accurate and having custom Reports or other validation mechanisms to audit/enforce more fine-grained accuracy. I've not used custom validators, can get get this deep? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Jonathan Senecal ***@***.***> Sent: Tuesday, December 13, 2022 11:05 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Improved Breakout Modeling (Discussion #11158) There is already a parent:child functionality to interfaces. Connecting Childrens to cables negates the requirement for a modification to the cable model. However the graphical representation could benefit from an added boolean to a parent interface. Something along the lines of "Channelized interface" — Reply to this email directly, view it on GitHub<#11158 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMYBDQ3DJHNEEYRKCKDWNCUHNANCNFSM6AAAAAAS3EFBFY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[davidgwatkins]

Custom Fields is my fallback plan, assuming this proposal gets shot down. ;-)

The proposed boolean "breakout" in operation could enable (or force) child interfaces to use types other than Virtual.

Totally hear you on the maintenance burden of enumeration of types, especially as they evolve. What about a single interface type "breakout lane" to provide maximum coverage of all options?

[ITJamie]

I think this is where ether child interfaces should be extended or a whole other model made to account for the "lanes" effectively as interfaces which can be traced.

I hope we get this modeled without any custom fields longterm.

[ITJamie]

I agree on it needing to be child interfaces or a new similar model to specifically call out the lanes used.

When going from 1 100gb port on one device to 4 25gb ports on different devices it would be easier to model it if each set of "lanes" was its own child interface circuit

[davidgwatkins]

Exactly. Perhaps the only additional interface type enumeration required would be "Breakout Lane", and abstract the number of lanes. 4x10G and 4x25G are super common in our deployment, but we also have a bunch of the 10x10G also, and are planning 400G and 4x100G, and exploring 8x100G SERDES (2x400G, 8x100G). There are more emerging products like integrated line systems on the horizon.

[sleepinggenius2]

I had previously opened #7552 for this and it seemed to gain some traction as first, but ultimately got closed for inactivity. I would still love to see that and hopefully something like #7553 implemented at some point, as they are both still constant pain points when I'm trying to model things.

[cpmills1975]

Conscious that this is now quite an old discussion, but I've just started trying to model break out cables.

It seems sensible that there is some way of modelling which lane a connection uses. Showing a cable trace through a break out cable from the QSFP end seems to make sense in that all of the downstream devices are shown in the trace so it's reasonably straight forward to work out the path but tracing from the SFP end back to the QSFP shows just a single cable with no indication that it is part of a breakout.

[cookiesowns]

Would be really great to have this implemented in some form. Especially for breakout -> panels -> servers