Interface & cable types¶

Interfaces and cables carry an optional type — the physical medium. The values are a standards-based taxonomy (IEEE / TIA / ITU-T media types), not tenant data: Danbyte ships the vocabulary the same way it ships length units, and nothing is pre-selected. Both dropdowns are searchable and grouped into sub-categories, so 200+ media types stay navigable.

The single source of truth is api/dcim_choices.py; the frontend fetches it from GET /api/dcim/choices/ (each choice carries value, label, group). Slugs deliberately track NetBox's vocabulary (v4.5 era), so device-type imports, operator muscle memory, and external tooling carry over 1:1.

Interface type groups¶

Fixed vs pluggable: media-specific slugs (10gbase-lr) say what the link is; transceiver slugs (10gbase-x-sfpp) say what the port accepts. Use the form-factor slug for switch ports that take optics, and the media-specific slug when the medium is fixed (RJ45, BiDi OLT/ONT ports, fixed-optic gear).

Cable type groups¶

The coax family matters for broadcast/OSP plants (RG-6/RG-11 drops, RG-59 CCTV, LMR antenna runs); DAC/AOC matter in-rack; OM/OS grades drive optic reach budgets.

Custom values still round-trip¶

The API serializers accept any string for type (lenient CharField), so imports and SNMP syncs never fail on an unknown medium; the UI shows an unknown value verbatim at the top of the dropdown and keeps it selectable. The curated lists only control what the dropdown offers. Deployments can trim/extend the lists in api/dcim_choices.py.

Research notes — what was added and why¶

Added in the 2026-07 expansion (all slugs NetBox-compatible):

• Media-specific Ethernet (10gbase-lr, 100gbase-dr, 400gbase-zr, …) — lets an interface say which IEEE PMD is in the port, not just the cage form factor. Needed for optical budget/reach planning and for modelling fixed-optic hardware.
• BiDi variants (1000base-bx10-d/u, 10gbase-br-d/u, 40gbase-sr4-bd, 100gbase-sr1.2, 400gbase-sr4_2) — single-strand links are direction- asymmetric; FTTx and strand-constrained plants model each end differently.
• Backplane Ethernet (*base-kr*, *-kx*, *-kp4) — blade chassis and stacked fabric midplanes.
• 1.6T Ethernet + OSFP1600/QSFP-DD1600 — IEEE P802.3dj generation; ships in AI-fabric gear.
• SONET/SDH OC-3 → OC-3840 — legacy carrier/WAN links still in every telco inventory.
• Stacking media (StackWise, VCP, SummitStack) — stack ports are cabled ports; without a type they pollute "other".
• PON generations bpon, 25g-pon, 50g-pon on top of the existing GPON/XGS-PON set — 50G-PON (ITU-T G.9804) is the current build-out edge.
• Wi-Fi 7 / LR-WPAN / MoCA / DOCSIS / 4G / 5G — access-edge completeness.
• Cable coax + USB families — RG/LMR grades and USB (console/serial leads) so real patch schedules don't need free-text.

Deliberately not added: vendor marketing names (e.g. "SFP56-DD"), pre-standard optics without an IEEE/ITU slug, and anything better modelled as a custom field on the interface (channel width, DWDM wavelength, PoE class).

Plan — parametric cable profiles (OSP fiber)¶

The type taxonomy says what a cable is made of; it does not describe its internal structure (strand/tube/ribbon layout). That's the next gap for outside-plant fiber:

• OSP loose-tube cable groups fibers into buffer tubes (typically 12 per tube): a 144-fiber cable is 12 tubes × 12 fibers; 288-fiber = 24×12 or 12×24.
• OSP ribbon cable stacks 12/24-fiber ribbons; Sumitomo SWR reaches 3456–6912 fibers in one sheath.
• Splice closures and FDHs join these mid-span; accurate tracing needs the cable to know its tube/ribbon layout.

Today Danbyte models this with RearPort.positions + FrontPort mappings on patch-panel devices, which covers structured cabling but forces splice closures to be modelled as devices. The plan — adapted from the NetBox "cable profiles: dynamic slug parsing" proposal — is:

1. Cable.profile slug field (blank = simple cable, current behaviour). Two parseable shapes, mirroring how symmetric cables really present:
2. single-{C}c{P}p — one logical connector of P positions per end (single-1c144p = 144-fiber cable, one bundle).
3. trunk-{C}c{P}p — C connectors of P positions per end (trunk-12c12p = 12 buffer tubes × 12 fibers).
4. Slug parser + class factory, cached — profiles are generated from the slug (regex ^(single|trunk)-(\d+)c(\d+)p$), not hand-listed, so any real-world tube/ribbon count works without code changes. Generated classes are cached in a module dict keyed by slug (bulk tracing rebuilds nothing).
5. Complex profiles stay hardcoded — breakout/shuffle layouts (non-linear position maps, e.g. MPO shuffle cassettes) get dedicated classes looked up by exact slug before the parser runs.
6. Validation in Cable.clean(), not choices= — bounds connectors ≤ 256, positions ≤ 8192 (8192, not 1024: Sumitomo ships 6912-fiber cable; headroom on top). The UI dropdown stays a curated list; API/import accept any slug that parses.
7. Termination positions — CableTermination grows a positions array so an end can land on specific strands of a port; trace logic maps per-position through the profile instead of treating the cable as opaque.

This keeps one physical cable = one Cable row (instead of splitting a 288-fiber cable into 24 logical cables), and makes splice-point tracing position-accurate. Tracked on the roadmap.