Gate SONiC EthernetN breakout on port topology

[ideaship]

Follow-up to the unified breakout mode selection.

Problem

The loose SONiC-name breakout path treats any four consecutive EthernetN
interfaces at <=50G as a 4xNG breakout without consulting the port_config
topology. Unifying breakout mode selection routed this path through
BREAKOUT_MODE_BY_SPEED, which newly enables 4x10G here — so a switch whose
native low-speed ports happen to be named Ethernet0..3 is now misdetected
as a breakout. For example AS5835-54T (native 10G) or DellEMC-S5212f /
AS7326-56X (native 25G) fabricate a 4x10G / 4x25G cage that does not exist.

Change

Add a topology gate on this path: accept the group as a breakout only when
port_config confirms a single multi-lane master (Ethernet{base}) whose
intermediate lanes Ethernet{base+1..base+3} are absent — they only
materialize when the cage is actually broken out. Four separate single-lane
entries are native ports and are now skipped.

• Mirrors the existing 400G sub-path's lane check.
• Lives entirely on the SONiC-name path; BREAKOUT_MODE_BY_SPEED is untouched
  (the NetBox EthX/Y/Z path legitimately needs its 10G entry).
• Adds a regression test covering four native single-lane 25G ports.

Scope / known limitations

• This is a necessary-not-sufficient negative filter: it removes the known
  native-port false positives but cannot by itself prove breakout intent. A
  planned follow-up will add an explicit per-port breakout_mode declaration as
  the authoritative signal (making the bare-EthernetN path safe without
  inference).
• The multi-lane test uses comma detection, consistent with the existing
  detection sites (the offset-multiplier logic and the 400G path). Range-form
  lane specs (1-4) are not used by any bundled hwsku; normalizing lane parsing
  across all detection sites is deliberately left as a separate change.

Related:

• Unify SONiC breakout mode selection across name formats #2488

🤖 Generated with Claude Code

[sourcery-ai]

Hey - I've left some high level feedback:

• The new multi-lane/topology gating logic duplicates lane-handling assumptions used elsewhere (e.g., the 400G sub-path); consider extracting a shared helper for "is multi-lane master with absent intermediates" to keep this consistent and easier to update in one place.
• The new early-continue checks rely on comma-separated lane strings only; if future hwskus introduce range-form lane specs, this will silently misclassify ports, so it may be worth centralizing and normalizing lane parsing now (or at least asserting the expected format).

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new multi-lane/topology gating logic duplicates lane-handling assumptions used elsewhere (e.g., the 400G sub-path); consider extracting a shared helper for "is multi-lane master with absent intermediates" to keep this consistent and easier to update in one place.
- The new early-continue checks rely on comma-separated lane strings only; if future hwskus introduce range-form lane specs, this will silently misclassify ports, so it may be worth centralizing and normalizing lane parsing now (or at least asserting the expected format).

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}