Design and defend an SRv6 PoC for a Dell OEM account
S3·E4Two questions before anyone touches the whiteboard · NVIDIA briefing room, two weeks before the bake-off
Builds on: L3VPN and EVPN services over SRv6, Ping the SID: OAM and the five failures that actually happen, Who actually ships SRv6: the Dell and NVIDIA support matrix
Before you read: what do you already know?
3 quick questions. Wrong answers are fine and expected; trying first makes the lesson stick.
After this lesson you can
- Produce a PoC plan with topology node roles a SID plan an encapsulation choice and an MTU budget.
- Ask the two disqualifying questions - REPLACE-C-SID and EVPN over SRv6 - before the plan is written.
- Compose exit criteria and a risk register that names every open question of this course by its subject.
- Defend each claim in the plan with a primary source or an explicit three-state support answer.
Episode 4 — Two questions before anyone touches the whiteboard
The network lead arrives with his topology already drawn and his date already promised. Around the table: the Dell SE and the promise spreadsheet, the procurement person who wants to know how many boxes get replaced, an NVIDIA PM who has said “not announced” twice before the coffee arrived, and you. The lead wants to start with addressing. You ask two questions first, because both are cheap this morning and ruinous in a bake-off.
Does their incumbent deployment use REPLACE-C-SID? RFC 9800 defines both compression flavors and warns that operators should generally avoid instantiating SIDs of different flavors within the same routing domain or locator block, while NVIDIA switching documents uN and uA, the NEXT-CSID behaviors, and nothing else.[1][5] Does he need EVPN over SRv6? The Cumulus Linux Segment Routing page documents no BGP service SIDs at all, and FRR’s BGP guide documents L3VPN and global-table SRv6 with no EVPN section, so the PoC you can actually run would not demonstrate it.[5][7]
Compression exists because the original encoding was expensive on every single packet: forty bytes of outer IPv6, eight bytes of SRH base, sixteen bytes per segment.[3] Packing several 16-bit identifiers into one 128-bit container is how segment routing stopped being an argument about header size and became an argument about what the network should do.[1]
Ask the two questions that can cancel the plan before you write the plan.
He answers no to both, so the plan is worth writing. It starts with why those two questions are gates and not risks.
1Two questions that can cancel the plan
Before topology, before addressing, before anything you would put on a slide, ask two questions. Both are cheap to ask and expensive to discover late.
Do they need REPLACE-C-SID? RFC 9800 defines two compression flavors. NEXT-C-SID builds each container as “a fully formed 128-bit SID” whose argument is “the contiguous series of subsequent CSIDs”; REPLACE-C-SID instead carries an index in the argument and packs subsequent containers into positions.[1] NVIDIA switching documents uN and uA — End and End.X with NEXT-CSID — and nothing else.[5] The RFC permits both flavors in one domain but warns that “operators should generally avoid instantiating SIDs of different CSID flavors within the same routing domain or Locator-Block.”[1] A customer whose incumbent deployment is REPLACE-C-SID flavoured is not a customer for an NVIDIA switching PoC as designed, and you want to know that in the first call rather than in a bake-off.
Do they need EVPN over SRv6? RFC 9252 defines it and RFC 9819 tightened the argument signalling in July 2025, but the Cumulus Linux Segment Routing page documents no BGP service SIDs at all, and FRR’s BGP guide documents L3VPN and global-table SRv6 with no EVPN section.[5][7] If EVPN multi-homing over SRv6 is the requirement, the PoC you can actually run does not demonstrate it, and saying so early is the whole job.
Everything else is a design decision. These two are gates.
Brief — Email, Tuesday: "We want to offer the BlueField-3 B3140H SuperNIC in the XE9780 for Spectrum-X customers. Can NVIDIA qualify it? I need a plan by Friday."
Dell platform PM (17G AI servers): So — can you get it qualified? What do you need from us to start?
2Topology and node roles
An SRv6 design is a statement about who does what, and RFC 8754 gives you exactly three roles: SR source node, transit node and SR segment endpoint node — where a transit node does nothing SR-specific at all.[3] Assigning those three roles is the first page of the plan, because it determines who needs a feature and who needs only IPv6.
The reference shape for a Dell OEM account with NVIDIA hardware, and the one NVIDIA itself documents, is: “The NICs connected to the switch fabric perform SRv6 origination and termination, and the switches act as SRv6-aware nodes.”[5] Where there is no SRv6-capable switch, the switches are simply transit and the design still works.[3]
Diagram source (Mermaid)
flowchart LR; H1["Host A workload"] --> BF["BlueField-3<br/>SR source node<br/>DOCA Flow SRH push"]; BF --> D1["Dell PowerSwitch<br/>TRANSIT<br/>plain IPv6 forwarding"]; D1 --> SP["Spectrum-4 + Cumulus 5.14+<br/>segment endpoint<br/>uN / uA"]; SP --> D2["Dell PowerSwitch<br/>TRANSIT"]; D2 --> EP["Linux endpoint<br/>segment endpoint<br/>seg6local End.DT46"]; EP --> H2["Host B workload"]
Two constraints belong on this page rather than later. On the switch side, Cumulus Linux supports segment routing “on the Spectrum-4 switch only. In the default VRF only”, with a maximum of 256 locators.[5] On the NIC side, DOCA Flow’s SRv6 is an external action that “must be registered before calling doca_flow_init()”, supports PUSH only in hardware with removal done in software, and “strictly requires an internal scratch register on the port. If this register is unavailable (which is dependent on the specific hardware model and firmware configuration), the pipe creation will fail.”[6]
And one lab-reality constraint that shapes the dry run: the containerlab documentation’s own dell_sonic session shows the VM reporting FRR 8.2.2, which predates the SRv6 SID Manager (FRR 10.2), static SIDs (10.3) and uA (10.4) entirely.[9][12] That is why the Dell node in the reference topology is a transit node. Confirm the version yourself with vtysh -c "show version" and record it in the plan rather than assuming either way.[9]
3The SID plan and the MTU budget
A SID plan is four numbers and a policy. The four numbers are the Locator-Block, Locator-Node, Function and Argument lengths, which RFC 8986 constrains only by L+F+A no greater than 128 with the remaining bits zero.[2] The policy is which profile you standardise on across the domain.
Standardise on F3216 unless something forces you off it. RFC 9800 makes it mandatory to implement: “an implementation MUST support a 32-bit LBL and a 16-bit CSID length (LNFL)”, and the capacity formula floor((128-LBL)/LNFL) gives six uSIDs in one 128-bit container at those lengths.[1] The same section warns that “a deployment should use consistent LBLs and CSID lengths for all SIDs within a routing domain” because heterogeneous lengths hurt compression efficiency.[1]
Then check the profile against every implementation in the path, because they do not all agree. FRR’s defaults are block-len 24 and node-len prefix-len minus 24 with 16 function bits, and the constraint is “block-len+node-len = locator-len” and block-len+node-len+func-bits <= 128.[8] Cumulus Linux publishes a fixed table of supported combinations: uN at 32/16/0, uA plus uN at 16/16/16, uN only at 16/16/0, and uA only at 16/0/16.[5] A plan that specifies 32/16/16 and expects uA on Spectrum-4 has already failed, and reading that table is a five-minute check.
The MTU budget follows directly from the encoding choice: 40 bytes of outer IPv6, 8 bytes of SRH base, 16 bytes per segment.[3] Three uncompressed segments is 96 bytes of overhead; the same path expressed as a single uSID carrier is 40 bytes with no SRH at all.[1][3] H.Encaps.Red sits between the two: it “reduces the length of the SRH by excluding the first SID”, and the SRH push “MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV.”[2] In FRR that is encap-behavior H_Encaps_Red.[7]
State the budget as a subtraction the customer can check: their smallest path MTU, minus the overhead you chose, equals the largest inner packet the PoC will carry. If that number is smaller than their application’s MTU, the plan changes now rather than during the demo.
4Verification ladder, exit criteria and the risk register
The verification ladder from module 2 is the backbone of the plan’s test section, in this order: show segment-routing srv6 locator detail, show segment-routing srv6 sid, ip -6 route show filtered for seg6local, show isis segment-routing srv6 node, show bgp segment-routing srv6, show bgp nexthop detail, then traffic.[8][7][16][17] Each rung becomes an exit criterion by attaching an observable output to it. An exit criterion nobody can run is an opinion.
Write the criteria as pairs — command and expected output — and include at least one negative test. The best negative test in an SRv6 PoC is the ping ladder: prove that a programmed SID answers or returns Parameter Problem Code 4, and that an unprogrammed address is silent, so that the customer’s own team can tell the three apart afterwards.
The risk register is where this course’s honesty shows up. Every one of these belongs in it, phrased as an open question with the document that would close it:
| Risk | State today | What closes it |
|---|---|---|
| Dell Enterprise SONiC 4.5.x SRv6 support | Unverified; only the 4.4.0 matrix is public and it contains no SRv6 row[10] | The 4.5 matrix and release notes from the Dell Digital Locker |
| Dell SmartFabric OS10 SRv6 support | Unverified; the 10.6.0 TOC extraction was partial with no segment-routing chapter, the 10.6.0.6 release notes rendered as no data, and a probed chapter URL returned 403[13][14][15] | The current OS10 feature matrix for the customer’s platform |
| Which BlueField and ConnectX generations expose the DOCA Flow SRv6 external action | Unverified; the guide states only a hardware-model and firmware dependency for the scratch register[6] | A pipe-creation test on the customer’s exact card and firmware |
| FRR support for EVPN over SRv6 | Undocumented in FRR’s BGP guide[7] | A vendor statement or a test; do not assume either way |
| Per-ASIC SRv6 capability beyond Spectrum-4 | Unverified; the only NVIDIA statement is a Cumulus software statement[5] | A per-ASIC capability document if one exists |
| MSD advertised as zero anywhere in the path | Checkable before the PoC | An IS-IS LSP dump confirming all four MSD types present and non-zero[4] |
| FRR version inside the lab’s Dell SONiC image | Checkable in five minutes | vtysh -c "show version" on the node[9] |
5Write it, dry-run it, defend it
Brief. A Dell OEM customer runs an AI training pod: BlueField-3 SuperNICs in Dell PowerEdge hosts, Dell PowerSwitch leaf and spine, no NVIDIA switches. They want host-driven path selection across the fabric to steer specific flows away from a congested spine.
Gates. REPLACE-C-SID? Not required — no incumbent SRv6 deployment. EVPN over SRv6? Not required — the requirement is path selection, not tenancy. Both gates pass, so the PoC proceeds.[1][7]
Roles. BlueField-3 = SR source node (SRH push through DOCA Flow).[6] Far-end Linux host = segment endpoint (seg6local). Every Dell switch = transit node, no SRv6 feature required, because RFC 8754 section 3.2 asks nothing of a transit node beyond IPv6 forwarding.[3] This is the sentence that lets the PoC happen at all on their current hardware.[10]
SID plan. F3216: Locator-Block 32 bits, CSID length 16 bits — the mandatory-to-implement NEXT-C-SID profile, so floor((128-32)/16) gives six uSIDs per 128-bit container.[1] The node uSID is that 16-bit CSID (Cumulus writes the same profile as its uN 32/16/0 row).[5] Local service functions (uDT4/uDT6/uDT46) are allocated as a further 16-bit micro-SID inside the node’s own block — that is what FRR’s func-bits 16 sizes, and it is not part of the node SID’s CSID length.[8] ULA block, one /48 per node under it, function values allocated from a documented range. Recorded as a table with one row per node so the customer’s team can extend it.
Encapsulation and MTU. Single uSID carrier where the policy is one container: 40 bytes of overhead, no SRH.[1][3] Fallback for multi-container policies: H.Encaps.Red, 40 + 8 + 16(n-1).[2] Budget: smallest path MTU 9216 minus 40 equals 9176 bytes of inner packet for the compressed case. Stated as a subtraction, with the smallest-MTU link named.
Verification ladder and exit criteria.
| # | Command | Expected | Exit criterion |
|---|---|---|---|
| 1 | ip -6 route show on the endpoint, filtered for seg6local |
The End.DT46 route with its VRF table | Present with the planned SID |
| 2 | ping each SID in the list | Reply or Parameter Problem Code 4 | No silent SID in the list |
| 3 | ip -s -6 route show with count on the endpoint |
Non-zero packets on the target SID | Counter increments with test traffic |
| 4 | payload sweep at the planned MTU | Passes at the budgeted size | Largest inner packet at least the application MTU |
| 5 | steer a flow via a second segment list | Flow changes path | Path change observed on the intended link |
Risk register. The seven rows from segment 4, each with the document that closes it.
Dry run. The whole ladder executed in containerlab with FRR endpoints and dell_sonic as transit, with the real transcripts pasted in as the expected-output appendix, and the FRR version inside the Dell image recorded.[9]
Write the plan for the second brief: a brownfield WAN team migrating from MPLS L3VPN to SRv6, on FRR-based PEs, with Dell switches in the core.
- Gates. REPLACE-C-SID: ask ____________________ because ____________________. EVPN over SRv6: ask ____________________ because FRR’s BGP guide documents ______ and ______ only.
- Roles. PEs are ____________ nodes and ____________ nodes; the core switches are ____________ nodes and require ____________.
- SID plan. Profile ______ , block ___ node ___ function ___ argument ___ . Check it against FRR’s constraint that block-len + node-len = ____________ and the sum plus func-bits is at most ______.
- Encapsulation. For a single-segment policy choose ____________________, configured in FRR as
encap-behavior ________________. MTU budget written as: ____________ minus ____________ equals ____________. - Coexistence. Because the customer still runs MPLS during migration, the FRR default ____________ must be turned off with ____________, or scoped per peer with
neighbor X:X::X:X ____________________. - Exit criteria. Five rows of command and expected output. At least one must be a ____________ test.
- Risk register. Name at least four open questions and, for each, the ____________ that closes it.
Produce and defend a complete plan. Take whichever brief you were not given in the faded section and write the full PoC plan: topology with node roles, SID plan with block, node, function and argument lengths and the profile named, encapsulation choice with an MTU budget written as a subtraction, the verification ladder, exit criteria as command-and-expected-output pairs, and a risk register naming every open question with the document that closes it.
Then dry-run it end to end in containerlab and paste the real transcripts in as the expected-output appendix. Finally, score the plan against the scenario simulator’s rubric — the drill it runs is the DOCA qualification case, so borrow its scoring, not its content — and fix every claim that lacks a primary-source citation or a three-state support answer.
Acceptance criteria. The two gates are answered before any design decision appears. Every node in the topology carries exactly one of the three RFC 8754 roles. The SID plan’s numbers are checked against every implementation in the path, including the Cumulus supported-combination table if a Spectrum-4 appears.[5] The MTU budget is a subtraction with the smallest-MTU link named. Every exit criterion names a command. The risk register contains at least five rows, each with a named document or test. No sentence in the plan asserts Dell SRv6 support or non-support.[10] And one closing line states plainly that no NVIDIA certification currently lists an SRv6 objective, so this work is account-driven competence rather than exam preparation.[11]
The dry run, and what nobody has to buy
The plan is short: three node roles from RFC 8754, a SID plan standardised on F3216, an MTU budget written as a subtraction the network lead can check against his own smallest link, exit criteria as command-and-expected-output pairs, and a risk register whose every row names the document that closes it.[1][3] The Dell switches are transit nodes and need nothing but IPv6 forwarding, which is procurement’s answer too: nothing gets replaced.[3] The night-shift operator has already labelled them. The notebook is full. What you say to the network lead, and the case closes here: “Every claim in this plan carries a source or a state, and the two things that could have cancelled it we asked about on day one.”
Lab
Pre-flight inventory. On the Dell-lab hardware record: BlueField-3 model and firmware (flint -d <mst dev> q), DOCA version (cat /etc/mlnx-release), host kernel (uname -r), mlxconfig -d <mst dev> q output, every interface MTU on the intended path, and the current ip -6 route show on both hosts. Save all of it to a file — it is both your rollback reference and the equipment appendix of the plan.
- Execute the reduced plan. BlueField-3 pushing the SRH, the containerlab fabric as the domain, a second host terminating in Linux
seg6local.[6] Time every step and log the wall-clock cost. Rollback: remove the DOCA Flow pipes and theseg6localroutes you added, restore any MTU you changed from the pre-flight file, and re-runip -6 route showto confirm it matches. - Watch for the two documented failure modes. If pipe creation fails, check whether the port has the internal scratch register the SRv6 PUSH requires — its availability depends on the hardware model and firmware configuration.[6] If behaviour is undefined rather than failing, confirm
doca_flow_external_action_srv6_register()was called beforedoca_flow_init().[6] - Record the MTU pair. Largest inner payload over an uncompressed multi-segment path versus the same path as one uSID carrier.[1][3] Put both numbers in the plan; they are the compression argument in the customer’s own units.
- Log what you could not do. Every step that needed hardware you do not have — an SRv6-capable switch, a second BlueField generation, a specific firmware. That log is the equipment list you send the customer before the real PoC, and it is the most useful artefact this lab produces.
- Answer one open question if you can. Your card and firmware either expose the DOCA Flow SRv6 external action or they do not. Record the result with the model, the firmware version and the date — it converts one unverified row in the risk register into a fact.[6]
- Optional, customer lab only. Run the full plan with a Spectrum-4 doing uN and uA in the middle, which turns the path into the architecture NVIDIA documents: NICs originate and terminate, switches act as SRv6-aware nodes.[5] Rollback:
nv unset router segment-routing static srv6-sid <prefix>,nv unset router segment-routing srv6 locator,nv set router segment-routing srv6 state disabled, thennv config applyand confirm against the pre-changenv config show.[5] - Finish the plan. Fold the timings, the MTU pair, the equipment list and any newly-closed risk row back into the document, and re-read it aloud one more time.
Goal. Write a PoC plan, prove it in containerlab, and have it reviewed.
- Answer the gates in writing. REPLACE-C-SID and EVPN over SRv6, each with the sentence you would say to the customer and the source behind it.[1][7] Expected: two short paragraphs, no hedging. If not: you are still designing before qualifying.
- Write the plan. Topology with node roles, SID plan, encapsulation and MTU budget, verification ladder, exit criteria, risk register naming every open question of this course with the document that closes it.
- Build the topology. FRR endpoints plus
dell_sonicas transit. First recordvtysh -c "show version"inside the Dell node and write the FRR version into the plan.[9] Expected: a version that predates the SRv6 SID Manager, which is exactly why it is a transit node.[12] If not: note the newer version — it changes what that node could do, and the plan should say so. - Dry-run the ladder. Execute every rung and paste the real output into the plan’s appendix.[8][7] Expected: each exit criterion either passes with a transcript or is rewritten. Rollback:
containerlab destroyon the topology file returns the host to its pre-lab state; remove any host sysctl you set for the run. - Prove one negative. Include the ping ladder producing a reply, a Parameter Problem Code 4 and a silence, so the customer’s team can classify outcomes without you.
- Peer review. Run the plan through the scenario simulator’s rubric — the simulator’s own drill is the DOCA qualification case, so take the scoring and not the subject matter — and fix every claim lacking a citation or a three-state answer. Expected: at least one claim gets weakened; if none does, you did not look hard enough.
- Read it aloud. Any sentence you cannot say without qualifying it is a sentence that needs a source or a deletion.
Retrieval check
10 questions from memory. Answer before looking anything up; misses become flashcards.
Explain it to a Dell SE
Explain to a Dell SE, in five sentences, how you would run an SRv6 proof of concept for a customer who has BlueField NICs and Dell switches but no SRv6-capable switch.
Sources
Facts in this lesson were checked against RFC 9800, RFC 8986, RFC 8754 and RFC 9352 (rfc-editor 2026-09-07); Cumulus Linux 5.18 Segment Routing; DOCA Flow 3.5.0; FRR latest docs and release list; containerlab dell_sonic kind; NCP-AIN certification page, all 2026-09-07. Dates are when each page was fetched.
- RFC 9800 — Compressed SRv6 Segment List Encoding · fetched 2026-09-07
- RFC 8986 — SRv6 Network Programming · fetched 2026-09-07
- RFC 8754 — IPv6 Segment Routing Header (SRH) · fetched 2026-09-07
- RFC 9352 — IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane · fetched 2026-09-07
- Segment Routing | Cumulus Linux 5.18 · fetched 2026-09-07
- DOCA Flow Programming Guide (v3.5.0) · fetched 2026-09-07
- FRR documentation — BGP (latest) · fetched 2026-09-07
- FRR documentation — Zebra (latest) · fetched 2026-09-07
- Containerlab — Dell Enterprise SONiC (dell_sonic kind) · fetched 2026-09-07
- Dell Enterprise SONiC Distribution Compatibility Matrix Release 4.4.0 · fetched 2026-09-07
- NVIDIA-Certified Professional: AI Networking (NCP-AIN) certification page · fetched 2026-09-07
- GitHub API: FRRouting/frr releases · fetched 2026-09-07
- Dell SmartFabric OS10 User Guide Release 10.6.0 — About this guide · fetched 2026-09-07
- Dell SmartFabric OS10 10.6.0.6 Release Notes · fetched 2026-09-07
- Dell SmartFabric OS10 10.6.0 — probed segment-routing chapter URL (HTTP 403) · fetched 2026-09-07
- FRR documentation — IS-IS (latest) · fetched 2026-09-07
- iproute2 man source: ip-route.8.in (main) · fetched 2026-09-07
The same idea elsewhere
Other lessons that cover this ground, sometimes from another course's angle.
- NVIDIA switching: uN and uA on Spectrum-4Elsewhere in this course · Same ground: interop, frr and limits
- NCP-AIN: blueprint map, gaps and a study planSpectrum-X course · Same ground: cert, method and limits
- NUMA alignment with Topology Manager and CPU ManagerK8sNet course · Same ground: scope, limits and fae