Fabric switch: actuation log, 16 modeling gaps, and the convergence build plan

[gunbai-bot]

Design + record for converging the CRS812 fabric lanes to 100GBASE-CR2 through a modeled path. No code — this is the design the credential/read/converge PRs implement, and the honest record of the manual actuation those PRs dissolve. Follows PR #11504 (the EEPROM read grant).

Context (what happened on the hardware)

The operator recoded the QSFP56 host ends with an FS BOX; PR #11504 landed the grant to read the leg EEPROM. This branch investigated the switch end:

• Found and read the CRS812 for the first time (192.168.1.240, RouterOS 7.20.8).
• QSFP56 host recode verified working: byte 192 0x0B→0x40, NIC Supported Cable Speed: 50G_2X→100G_2X, advertises 100GBASE-CR2, former refusal gone.
• No bilateral 100G link trains against the still-Generic QSFP-DD switch end — under autoneg or forced (mstlink --link_mode_force -s 100G_2X), across every switch FEC mode. Host sits in Polling; switch reports auto-init-failed / eeprom-checksum: bad on the DD end.
• All 8 legs restored to known-good 50G.

Verdict is stated at witnessed confidence: switch-side coding is the leading hypothesis, not proven. The isolating test is a hardware substitution control, not more configuration.

What's here

• fabric-switch-actuation-log.md — the out-of-band actuation (operator-approved), the reviewer correction that MikroTik requires forced/autoneg-off (my "non-compliant" framing was wrong), a credential/restore incident (token expired mid-op, left srv5 down until re-auth), and the transcription source for the modeled apply.
• fabric-switch-100g-convergence-gap-analysis.md §6 — 16 modeling gaps (G1–G16) found by driving the real hardware: no autoneg axis, FEC enum can't express RS(544,514), live/two-ended link outcome unmodeled, no REST reader/apply, no switch credential, mstlink unmodeled, fabric_switch_observed stale, dispatch can't fan out, ad-hoc-curl scaffold to kill.
• fabric-switch-convergence-build-plan.md — the normal path, layered per DESIGN §3, credential mirroring spark bootstrap, and the PR sequence.

A deliberate sequencing decision (§4d)

The read path is built first (safe, groundable in captured data). The converge apply is deferred until the hardware links at 100G, because its FEC/autoneg specifics are currently inferred, not witnessed — modeling the apply now would assert as fact what we haven't observed. PR-3's converge will correctly refuse/report Polling until the coding is fixed, which is the honest behavior.

🤖 Generated with Claude Code

[gunbai-bot]

All three findings in review 67282 verified and fixed in the latest commit.

1. FEC meaning fork + §4d over-promotion — confirmed, corrected. The actuation log did call fec91 "correct for 100GBASE-CR2" and map the 100G intent to Fec91, directly contradicting this PR's own G2 (fec91 = RS(528,514); 100GBASE-CR2 needs RS(544,514)/KP4). You're right that it was a 50G observation promoted into a 100G requirement, and right that the autoneg claim got a correction while this one didn't. Fixed the same way: the FEC block now states fec91 is the FEC running at 50G, not the established 100G intent, with a CORRECTION (added with G2) note. Converge must not assume it — G2 obligates refusal if the switch cannot offer the mode's codeword.

2. Standing-observation fork — confirmed, superseded. §0 said the EEPROM was not re-read and establishing the coding was the "first work item"; G12 says byte 192 = 0x40, NIC 100G_2X. Same doc, two current answers. Added a SUPERSEDED 2026-09-17 (see G12) note to §0: the bytes were read, the re-flash took, cause (1) is ruled out, and the one current roster is G12 — the live blocker is the switch-side QSFP-DD end, not the host coding. Kept §0's original text as framing, not as an open question.

3. PR-3 depends on PR-4's deliverable — confirmed, decoupled. PR-3's success criterion named "host mstlink," which is PR-4's tool. The fix is a real distinction I'd conflated: reading the host's negotiated speed is unprivileged (ethtool <dev>, no grant), while forcing it needs PR-4's mstlink grant. Reworded so PR-3's observe-both-ends criterion uses the unprivileged read and does not depend on PR-4; PR-3 alone converges the switch and reports the host still at 50G rather than claiming success off the switch's local link-ok. PR-3 + PR-4 together achieve 100G.

Thanks — all three were real, and the FEC one in particular was the exact §4d trap (a 50G reading standing in for a 100G fact) that the rest of this PR exists to document.

[gunbai-bot]

Both findings in review 67285 addressed in the latest commit.

1. Superseded fact left in prose — now marked on the carrier. You're right: the PR proved fabric_leg_cable_observed false and left the correction only in docs/plans/. Added the annotation on the carrier itself (gunbc.spark.fabric_switch_observed): it states that nic_supported_speeds: "50G_2X..." is now wrong post-recode (byte 192 = 0x40, NIC reports 100G_2X), that linked_speed_gbps: 50 stays true only by coincidence (the blocker is switch-side, not a NIC cap), names it the a_live_authority_name_carries_a_superseded_claim class, and states the trigger — the G12 event model supersedes the row rather than overwriting it. A doc note wasn't the mark; the carrier now carries it.

2. Restore incident owes a recurring_failure_mode row — filed. Per DESIGN §4b, added gunbc.recurring_failure_mode.a_rollback_depends_on_a_credential_that_can_expire_mid_actuation: the invalid state (rollback gated on a credential that can expire mid-run, mutation already applied, no held recovery path), why it survives testing (happy path works the whole valid window; only a long session trips it), the srv5 specimen, the discriminator (bites out-of-band per-step-credential actuation; not the modeled once-per-run-and-removed path), rung (mitigatable), ceiling (eliminated by not actuating out of band), the next-rung trigger (the modeled converge path becomes the only actuation path), and the review tell. It compiles green (the_new_failure_mode_row_compiles); the roster is gitignored and regenerates from the directory at compile.

Both were the right call — the superseded-authority one is literally the class that's already rostered, and the incident genuinely earned its own row rather than a markdown bullet. Thank you.

[gunbai-bot]

Fixed in the latest commit — you're right, and my annotation-only fix was itself the violation.

The // annotation asserted a machine claim in prose ("so a reader does not consume nic_supported_speeds as current") that no Accepted program can read (§4c), while a value the same commit calls WRONG kept answering (§5: a wrong answer is a loud error, not a warning). A dissolution trigger doesn't authorize leaving known-false data standing.

Took your first resolution: corrected the literal to the post-recode truth. nic_supported_speeds now carries the mstlink Supported Cable Speed after the recode — 100G_2X, 50G_1X, 50G_2X, 25G, 10G, 1G — so the field is true. linked_speed_gbps stays 50 because the link still trains at 50G for a switch-side reason, so the two are independently true rather than one implying the other. The annotation is rewritten as honest rationale (why the value is what it is, and that G12's event model will make it derived) with no prose standing in for a machine check — and as you noted, G12 supersedes a true reading just as well as it would a false one.

Verified nic_supported_speeds is read by nothing (only linked_speed_gbps, by fabric_rail_desired and the witness, both unchanged); the observed witness stays green.

Thanks — this was the right call. I'd tried to discharge a §5 debt with a §4c annotation, which is exactly the trap.

[gunbai-bot]

Both fixed in the latest commit.

1. build-plan §4d over-assertion. You're right — "forced-both is what actually trains 100G on this hardware" is asserted as fact and this PR's own log falsifies it (the one mstlink forced-both run stayed in Polling, no bilateral link). Restated at the confidence the log supports: forced-both is the MikroTik-required production candidate, the one run of it did not train, so PR-3 + PR-4 together let us re-test forced-both properly once the QSFP-DD coding is fixed — they don't, on current evidence, achieve convergence by themselves. That removes the false signal to a PR-4 worker that building the mstlink grant achieves convergence.

2. actuation-log unmarked superseded claims. The "forced path is non-compliant for CR" claim and the "VERDICT: 100G will not come up in any configuration" both stood unmarked at their sites while the retraction sat 25 lines below. Marked both at their sites — struck through with a pointer to the mstlink re-test section — so a reader hits the correction where the wrong claim is, not 25 lines later.

This is the third time a review has caught me leaving a superseded claim standing with the correction elsewhere — it's a real habit in how I was writing this log, and co-locating is the fix. Thanks for holding the line on it.

[gunbai-bot]

Fixed — deleted the field rather than growing it.

You're right on both counts: correcting the stale value in the prior commit grew a String leaf hiding named parts this module already models — the link-mode set (extdeps.ethernet.link_mode LinkMode rows imported right here), the instrument, and the date. "100G_2X, 50G_1X, ..." is the §3 nickname, and the mstlink, fw 28.45.4028 suffix is the §6 instrument-output transcription.

Since nic_supported_speeds is read by nothing (only linked_speed_gbps is consumed, by fabric_rail_desired and the witness), the coherent fix is to delete it, not enrich it into a List<LinkMode> that nothing would read — a richly-modeled dead field is still a §3c dead field. Removed from the type and the data row; the "what the link reports" note now states the NIC advertised mode set wants a typed List<LinkMode> cited to its instrument and isn't carried until a consumer needs it. The observation itself (post-recode 100G_2X, mstlink) lives in the actuation log and lands typed when G12's event model gives it a consumer.

Verified nothing else constructs FabricLegCableObserved or reads the field; the observed witness stays green.

This closes the loop the earlier review (review 67294) opened — it offered delete-or-correct, I chose correct, and correcting turned out to grow the anemic leaf, so delete was the right call after all.

[gunbai-bot]

Fixed — and you're right that I'd marked one stale claim in this file while leaving two others unmarked.

I swept the whole file this time rather than one claim per round:

• SUPERSEDED banner over the pre-recode narrative (:39–63) — the "COMPLIANCE CODING IS A DEMONSTRATED BLOCKER" / "nothing attests 100GBASE-CR2" / "refuses it today" claims now carry a banner: the coding attests 100GBASE-CR2 post-recode (byte 192 = 0x40), the refusal is gone, the live blocker moved switch-side. Kept as the pre-recode reading rather than rewritten, with G12's event model (PR-1) named as the trigger.
• The eeprom observation rows are marked as the 2026-09-08 pre-recode acquisition. I deliberately did not re-value primary_compliance_code: 11 — a receipt is a dated snapshot, and overwriting it would falsify the historical record; the post-recode reading is a new acquisition that lands as an additional row under G12. Stated as a temporal fact (these are the pre-recode coding; the current reading is byte 192 = 0x40 per the actuation log), not as a machine directive to the reader — which is the distinction from the nic_supported_speeds case, where the value was wrong-and-unread so deletion was right.

Observed witness stays green.

This is the recurring pattern from the last few rounds and I own it: I'd been marking the claim I happened to be editing rather than sweeping the file. Done that now.

[gunbai-bot]

Fixed — you're right, and this closes the gap in my earlier reasoning.

My SUPERSEDED // banner on the eeprom rows was the §4c trap I'd argued my way out of: I claimed these were dated receipts, but FabricLegEepromObservation has no acquisition timestamp and .first() → fabric_leg_reading → LegReadingTaken → fabric_cable_plant consumes the row as the live reading. So primary_compliance_code: 11 on spark-a3ee was a known-false LegReadingTaken — silent wrongness on the plant path (§5), with the true value parked in markdown (§6), which a comment can't discharge.

Took your option 1: re-valued spark-a3ee to the complete post-recode dump I actually read — byte 192 = 0x40 = 64 (attests 100GBASE-CR2), date_code 260914 — so the plant answers the current coding. spark-ac79 keeps its last actual reading (11): it was re-flashed too but not re-read, and re-valuing it would fabricate an observation nobody took (per your note that ac79 is fine to leave). The two legs now disagree by coding, which the distinct-serial witness exists to keep representable — and the module's own note says the model must represent one leg recoded and the other not.

The banner is replaced with a factual note (which leg is post-recode, which is last-actual), not a reader directive. All 7 fabric-switch witnesses green, including the coding-ceiling and two-legs-distinct claims.

This was the crux the whole fabric_switch_observed thread kept circling: I treated a consumed live value as if a comment could mark it stale. It can't — the carrier had to carry the truth.

[gunbai-bot]

Both fixed — both are consequences of the a3ee re-value that I failed to sweep, and you're right that I applied the correct standard everywhere else and missed these.

1. The "two legs agree today" type annotation at fabric_switch_observed.dag:242 contradicted my own new block 18 lines below saying they now disagree. §4c — an annotation may not restate what the declarations structurally say, and this said it wrong. Corrected: whether they agree is derived, and they now disagree (a3ee re-read to 0x40, ac79 still at its last pre-recode 0x0B), which is the divergence the per-row shape exists to keep representable.

2. The crs812_desired_fec() rationale — "Clause 91, the FEC the 100GBASE-CR2 attestation is conditional on" — was true of the 0x0B coding (attests ieee_50gbase_cr2 RequiresClause91Fec), but my re-value to code 64 makes a3ee attest ieee_100gbase_cr2 FecUnconditional, so the rationale is falsified. Fixed the comment: the conditional-on justification was for the pre-recode coding; the real 100G FEC (RS(544,514)/KP4 per gap G2, which the CRS812 may not even expose) is an open question; the returned Fec91 is retained as the provisional forced-DAC value and not asserted as the correct 100G FEC — that's decided by the converge test (PR-3), deferred until the hardware links (§4d). Value unchanged, comment only.

Assessment witness green.

This is the tail of the re-value: correcting a consumed data row propagates to every annotation and rationale that referenced the old value, and I should have swept both files in the same commit. Done now.