Local Breakout Gateway (LBO) Hardware Architecture Guide
← Back to: 5G Edge Telecom Infrastructure
A Local Breakout Gateway (LBO) steers selected traffic to local LAN/Internet/services at the edge with deterministic low latency and high Mpps, using hardware packet pipelines, inline crypto offload, and link/power telemetry to keep performance explainable in the field.
What is an LBO Gateway & where is the boundary?
A Local Breakout Gateway (LBO) is an edge node that breaks out selected traffic locally (to an enterprise LAN, local services, or a nearby WAN exit) instead of forcing every flow to hairpin upstream. The engineering value is not “more features”, but deterministic forwarding: low p99 latency, high Mpps under microbursts, inline crypto offload, and evidence-grade observability (drop reasons, counters, and event logs).
Boundary rule: this page stays on the Ethernet-side breakout and the hardware fast path (packet pipeline, crypto offload, retimers, PMBus power, watchdog/logging). It intentionally avoids protocol-stack deep dives and sibling-page domains.
| Neighbor | What it “owns” | What the LBO “owns” (this page) | Why it matters in practice |
|---|---|---|---|
| Edge UPF Appliance | User-plane protocol termination & mobile semantics (protocol-stack heavy) | Ethernet breakout policy + fast-path forwarding + observability hooks | Avoids turning the LBO page into a protocol correctness guide; keeps focus on silicon bottlenecks and evidence. |
| Edge Network Slicing Gateway | Slice isolation system & multi-tenant domain boundaries | Local policy decisions, per-class queues, inline crypto, and enforcement counters | Prevents “policy-plane sprawl”; keeps attention on queueing, tables, and deterministic forwarding. |
| SD-WAN / Edge Router | Enterprise routing features and WAN optimization breadth | Low p99, high Mpps, predictable backpressure behavior, measurable drop reasons | Stops feature creep: the design target is stable latency under load, not a full enterprise feature matrix. |
| Edge Security / ZTNA Node | Deep inspection, security policy engines, and threat workflows | Crypto offload as a performance primitive + key custody as a trust primitive | Keeps security discussion bounded to “where crypto sits” and “how keys stay safe”, not DPI feature coverage. |
| Observability / TAP / Probe | Lossless mirroring, capture pipelines, and storage-heavy evidence | On-box counters, drop reasons, and event logs needed for field triage | Focuses on “minimum sufficient evidence” to debug p99 and drops without building a capture appliance. |
| Timing pages | System timing design (grandmaster/boundary clock deep design) | Jitter/latency symptoms caused by link integrity and congestion (no timing system design) | Prevents drifting into PTP system architecture; only keeps network jitter as a forwarding symptom. |
Reader takeaway: An LBO is best explained as a fast-path box with four core levers: (1) packet pipeline (tables/queues), (2) crypto offload (sessions/queues/thermal), (3) link integrity (PHY/retimers), and (4) power & survivability (PMBus + watchdog + logs).
Deployment scenarios & traffic classes (what must be fast)
Real deployments are defined by which traffic must stay local and what “fast” means. For an LBO, “fast” is rarely a single number: p99 latency, Mpps, and burst loss behavior usually matter more than headline throughput. The purpose of this section is to map scenarios into silicon levers and evidence points that can be verified in the lab and in the field.
Typical connectivity shape (kept generic on purpose):
- Multi-port Ethernet (25/50/100G class) on the access/aggregation side.
- Breakout exits toward enterprise LAN, local service networks, and a WAN/backhaul uplink.
- Operational control via an OOB path or management port for telemetry, power control, and logs.
Three traffic classes that define the design:
- Latency-sensitive small packets (Mpps-driven): the box can look “Gbps-fast” yet still fail p99 when the pipeline, tables, or queues are stressed.
- Throughput-heavy large packets (Gbps/Tbps-driven): memory bandwidth, DMA backpressure, and egress shaping dominate.
- Encrypted overlays/tunnels (crypto-driven): session tables, crypto queues, and thermal throttling can turn into hidden p99 cliffs.
| Scenario | Primary KPI (what “fast” means) | Silicon lever (what must be engineered) | Evidence (what must be measurable) |
|---|---|---|---|
| Enterprise local breakout Many short flows + policy |
p99 latency under microbursts; low tail jitter; stable drop behavior | NP pipeline stages; ACL/classification hit rate; queue depth & shaping; drop reason encoding | Per-stage counters; queue occupancy histograms; drop reason breakdown; burst loss curves |
| Local services anchoring Local app networks |
Predictable latency; congestion recovery; fairness between classes | Buffer/queue policy; scheduler; head-of-line blocking avoidance; backpressure control | ECN/RED stats (if used); scheduler counters; recovery time after overload; p99 per class |
| Backhaul offload / constrained uplink Uplink is the choke point |
Throughput efficiency; minimal collateral damage to latency class | Egress shaping; queue isolation; rate-limit enforcement; table scale without thrash | Shaper counters; class-based drops; table miss/evict counters; sustained vs burst throughput |
| Encrypted overlay heavy Crypto is always on |
p99 stability; session scale; rekey without outage | Crypto engine queueing; session table sizing; DMA rings; thermal-aware throttling | Crypto queue depth; session hit/miss; rekey failure counters; thermal throttle events + timestamps |
| Long-reach/connector-rich cabling Signal integrity is hard |
Low error-driven jitter; no link flap | Retimer placement; PHY equalization; FEC behavior; margining | FEC/CRC counters; link flap logs; PRBS/BERT results; error burst correlation to p99 spikes |
| Harsh site conditions Power/thermal stress |
No brownout resets; graceful derating | PMBus telemetry + rails partitioning; sequencing; watchdog policy; event logging | Rail voltage/current/temperature logs; fault-latch history; reset reason codes; derating timeline |
Interpretation guide: When a box “meets throughput” but fails real workloads, the root cause is often not the headline link rate. The common pattern is a mismatch between traffic class (small packets, bursts, crypto sessions) and the internal resource that saturates first (tables, queues, crypto queues, memory/DMA, or link error recovery). The rest of the page uses this mapping to keep every section actionable and measurable.
Reference hardware architecture (block-level)
A practical LBO gateway is best described as a fast-path data plane surrounded by three “support planes”: a control plane for configuration and telemetry aggregation, a management plane that keeps power, watchdog, sensors, and logs alive under partial failures, and a trust anchor that protects keys and boot integrity. This separation prevents feature creep and keeps performance debugging evidence-based.
Role split (who does what):
- Data plane (Switch/NP): parses packets, classifies flows, applies policy, selects queues, and emits drop reasons and counters.
- Flow tables (TCAM/SRAM): hold match/action rules and per-flow state; table behavior is often the first cause of p99 drift under bursts.
- Buffer/Queue/Scheduler: absorbs microbursts and enforces class behavior; queue occupancy is the most direct predictor of tail latency.
- Crypto offload: protects overlay traffic using a dedicated engine and session tables; crypto queues + thermal throttling commonly create “p99 cliffs”.
- High-speed I/O (SerDes/PHY + retimers): maintains link integrity; error recovery (FEC/CRC bursts) can look like software instability.
Control vs management boundary: the host CPU/SoC should focus on configuration and telemetry aggregation, while a separate OOB MCU keeps PMBus power control, watchdog/reset, sensors, and event logs operating even if the host plane is degraded.
Trust anchor (TPM/HSM) is minimal but critical:
- Secure / measured boot: establishes a known-good baseline for the control/management firmware.
- Key custody: stores wrapped keys and protects session material used by the crypto offload block.
- Audit signal: produces measurable boot and tamper evidence for field diagnosis and compliance logs.
Packet pipeline in silicon (tables, queues, and fast path)
In an LBO, the “fast path” is not a single block—it is a pipeline of stages. Real-world failures typically occur when a resource bound is hit earlier than expected: table lookups thrash, queues saturate under microbursts, descriptors/DMA backpressure builds, or crypto queues stall. The most effective design and debugging approach is to map each stage to its primary resource, its typical symptom, and the evidence counters that confirm the root cause.
Fast path segmentation (stage intent):
- Ingress parsing: header decode, flow key formation, and early sanity checks.
- Classification (ACL): match/action decisions; the first place TCAM pressure shows up.
- Policy / route: selects breakout direction and per-class treatment; often SRAM/DDR state heavy.
- QoS / queue: isolates traffic classes and absorbs bursts; queue occupancy drives tail latency.
- Egress shaping: enforces rate/fairness; interacts strongly with backpressure and loss recovery.
Table placement rule-of-thumb: TCAM is best for high-speed matching, SRAM is best for per-flow state and counters, and DDR is used for large structures and logging buffers. When the wrong structure lands in the wrong tier, the symptom is often p99 instability rather than obvious throughput loss.
| Stage | Primary resources | Typical failure symptom | Evidence that should exist (minimum set) |
|---|---|---|---|
| Ingress parsing | parser budget, descriptors, DMA rings | Small-packet collapse; “Gbps looks fine” but Mpps drops; sporadic tail spikes | parser error counters; descriptor/ring occupancy; RX drops with reason codes |
| Classification (ACL) | TCAM match width/depth, action memory | p99 drift under policy load; rule updates cause transient loss or latency jumps | TCAM hit/miss; rule update events; per-rule counters; miss-to-default action counts |
| Policy / route | SRAM state, DDR-backed tables (when large), lookup pipelines | Latency “wobble” correlated with table churn; bursty drops on specific classes | lookup stall counters; cache/entry eviction counts; per-class decision counters |
| QoS / queue | queue depth, buffer pools, scheduler cycles | Microburst loss; head-of-line blocking; one class starving another; tail latency explosion | queue occupancy histograms; drop reason breakdown (tail/WRED/RED); scheduler counters |
| Egress shaping | shaper meters, egress buffers, backpressure control | Throughput plateau; recovery after overload is slow; p99 spikes during congestion unwind | shaper hit/limit counters; egress drops; backpressure events; recovery time measurement |
Why “Gbps is fine” but 64B Mpps fails:
- Packet-rate saturation: the pipeline must process far more headers per second; parse/classify budgets hit first.
- Queue churn under microbursts: frequent enqueue/dequeue and scheduler decisions dominate; tail latency grows before throughput looks broken.
- Descriptor/DMA backpressure: rings fill and backpressure propagates, triggering drops or long tails without obvious link errors.
Crypto offload: where to terminate, and how keys live safely
Crypto acceleration is only effective when the data path, session state, and key custody form a measurable loop. Many “it has an accelerator” designs still fail on tail latency because copy/DMA hops, queue placement, and thermal throttling create hidden bottlenecks that appear as timeouts or renegotiation storms.
Offload placement (inline vs sidecar) changes tail latency:
- Inline: crypto sits on the forwarding chain. The main win is fewer copies and fewer round-trips, but the risk is that crypto queueing becomes a direct p99 driver.
- Sidecar: packets or descriptors detour to a separate crypto unit. It can scale independently, but extra DMA hops and completion jitter frequently show up as p99 spikes.
Hardware role split (no crypto tutorial): bulk engines (AES-GCM / ChaCha) protect throughput, handshake helpers (RSA / ECC) protect connection scale, and session tables protect stability. The dominant failure mode is rarely “algorithm speed”; it is usually queueing + state pressure + backpressure.
Minimum key lifecycle loop (operationally sufficient):
- TRNG → entropy health events (insufficient entropy must be visible).
- Key wrapping → wrap/unwrap success rate and latency should be logged.
- Secure storage (TPM/HSM/SE) → key custody + measured boot evidence.
- Rotate / revoke → rotation trigger, activation time, failure and rollback events must be observable.
| Symptom | Most likely bottleneck points | Evidence to check (minimum set) |
|---|---|---|
| Throughput cliff sudden drop under load |
Crypto queue saturation; thermal throttling; DMA/PCIe backpressure | crypto queue depth; throttle events + reason; DMA ring occupancy; completion latency |
| p99 spikes average looks normal |
Extra copy/DMA hop jitter (sidecar); contention on descriptor paths | copy/descriptor counters; DMA backpressure events; per-batch completion histogram |
| Intermittent timeouts | Session table near-full; eviction/rehash; state sync stalls | session utilization; evict/miss counters; rekey state transitions; retry counters |
| Renegotiation storms | Handshake unit saturation; key rotation glitches; CPU fallback spikes | handshake fail/retry; rotate/revoke events; CPU fallback rate; queue depth correlation |
| Heat-driven slowdown | Crypto hot-spot throttling; fan curve mismatch | per-block temperature; throttle timeline; per-minute throughput vs temperature plot |
High-speed Ethernet: PHY/SerDes/retimers and link integrity
High-speed Ethernet failures often present as “software bugs” because link errors trigger recovery behavior (FEC correction bursts, retransmission, renegotiation, link flaps) that inflate tail latency and cause timeouts without a clean, single-point failure. Retimers and PHY visibility are therefore first-class components in a practical LBO, not optional accessories.
Retimer vs redriver (engineering boundary):
- Redriver: analog equalization; suitable when the channel budget is comfortable and stable.
- Retimer: CDR-based re-timing; required for long traces, backplanes, connector-heavy paths, repeated insertions, and temperature drift margins.
Link integrity to p99 causal chain: bit errors → FEC activity / CRC growth → recovery and buffering → jitter and tail spikes → application timeouts. The engineering goal is to make this chain observable through counters and timestamped logs.
| Symptom | Likely domain | What to log (minimum) | What it correlates with |
|---|---|---|---|
| FEC corrected rising fast | Margin shrinking (temp/connector/aging) | FEC corrected rate + timestamp; temperature; port/lane ID | p99 jitter growth, burst loss sensitivity |
| FEC uncorrected appears | Hard errors / training edge | uncorrected count; training status; error bursts timeline | drops, retransmission spikes, tunnel timeouts |
| CRC/PCS errors | PHY/PCS instability | CRC/PCS counters; lane health; equalization state | sporadic tail spikes and “random” failures |
| Link flap (up/down) | Insertions, power dips, retimer lock issues | flap count; reason code; rail telemetry snapshots | looks like reboots; session resets |
| Speed downshift | Training margin insufficient | downshift events; negotiated speed; training logs | throughput plateau but “more stable” behavior |
| Single-lane anomalies | Connector/pin or lane margin issues | per-lane counters; margining results; location mapping | intermittent p99 spikes tied to load/temperature |
Power & telemetry: PMBus rails, sequencing, and brownout-proof behavior
In an LBO gateway, power delivery is part of performance. A stable p99 requires not only sufficient steady-state power, but also domain isolation, sequencing evidence, and telemetry-driven derating that makes throughput changes explainable rather than “random.”
Typical power-domain tree (why partitioning matters):
- Core domain: fast transients; droop can manifest as tail spikes or sporadic resets.
- SerDes domain: noise-sensitive; rail instability often appears as FEC/CRC growth and link flaps.
- DDR domain: training and refresh margins; sequencing mistakes become intermittent boot failures.
- Crypto domain: hot spots and throttling; “throughput cliffs” are common if thermal limits are invisible.
- PHY domain: link training sensitivity; undervoltage may cause downshift or renegotiation storms.
Brownout-proof behavior is achieved by combining rail partitioning with staged responses: detect droop early, preserve forwarding if possible, and record an evidence bundle that can be replayed in postmortem without guessing.
| Telemetry item | Why it matters | Suggested sampling | Alert grade |
|---|---|---|---|
| Vin / Iin (input bus) | Detect upstream droop and input current peaks that trigger brownout or protection | Fast (1–5s) + on-event snapshot | P0/P1 |
| Vout / Iout (per rail) | Correlate rail droop, load steps, and throttle events to p99 and throughput | Fast (1–5s), burst on anomaly | P0/P1 |
| Temperature (VR/ASIC zones) | Predict thermal throttling before a cliff; explain performance shaping | Fast (1–5s) | P1 |
| Power (V×I) + energy accumulator | Reveal sustained stress vs short bursts; useful for trending and capacity planning | Slow (30–60s) + on-event | P2 |
| PG / rail enable timeline | Make “intermittent boot failure” diagnosable; prove sequencing correctness | On boot + on fault | P0 |
| Fault bits (UV/OV/OC/OT) | Pinpoint protection triggers and rail-level root causes | On-event + periodic audit | P0/P1 |
| Fault log (timestamped) | Postmortem evidence: what happened first, and what cascaded | Persist on every fault | P0 |
| Derating state (throttle level) | Explain throughput/latency changes as deliberate action, not unexplained degradation | Fast + on change | P1 |
Sequencing & PG: why “intermittent boot failures” happen (three root-cause clusters):
- Dependency order mismatch: DDR/SerDes/crypto rails become valid in the wrong order → training failures; prove with PG timeline + training status.
- Load-step mismatch: soft-start and real load steps diverge → Vout dip/OC events; prove with peak Iout + UV/OC bits.
- Input droop edge: Vin sag during enable burst → brownout/BOR; prove with Vin dip + BOR cause + rail UV counters.
Staged derating model (example): temperature/current triggers → throttle crypto clocks → downshift selected ports → finally domain reset. Each transition should generate a timestamped event with scope (which domain/port) and expected impact (throughput/latency).
Watchdog, reset, and survivability (keep forwarding during partial faults)
Survivability is the ability to prevent small faults from escalating into a full outage. In an LBO gateway, that means multi-source health signals, domain-scoped resets, and a minimal evidence pack that makes the root cause provable in the field.
Watchdog boundary (avoid single-source blind spots):
- Control-plane heartbeat: verifies host CPU and configuration logic are progressing.
- Management MCU heartbeat: verifies power/telemetry/logging loop is alive and responsive.
- Data-plane heartbeat: verifies forwarding path remains healthy (e.g., port counters / queue health / pipeline liveness).
Reset strategy should be domain-scoped: reset control plane first when forwarding is healthy; reset data plane only when forwarding evidence indicates failure; use power-domain reset as the last resort. This reduces recovery time while avoiding unnecessary session loss.
Minimal evidence pack (what must be recorded on every fault):
- Reset cause: WDT / BOR / thermal trip / PMBus fault (with reason code if available).
- Rail snapshot: Vin/Vout/Iout/Temp + PG states immediately before/after the action.
- Forwarding snapshot: drop reasons, queue occupancy, link CRC/FEC, crypto queue/session utilization.
- Action record: what action was taken, scope (which domain/port), start/end time, and outcome.
| Fault (detect signal) | Staged action | Business impact | RTO target | Evidence to store |
|---|---|---|---|---|
| Control-plane hang CPU heartbeat stops |
Restart control plane; keep last known forwarding policy | Minimal impact if data plane healthy; management updates paused | < 10s | CPU heartbeat gap; config epoch; forwarding counters snapshot |
| Mgmt MCU stalled telemetry timeout |
Reset MCU; preserve forwarding if possible | Telemetry blindness; deferred alarms until recovery | < 10s | PMBus last-good snapshot; watchdog arbiter decision log |
| Data-plane liveness fail queue/port health |
Reset data plane domain; re-init ports; keep control plane alive | Potential session loss; brief packet loss window | < 60s | drop reasons; queue occupancy; link counters; action timeline |
| PMBus fault UV/OC/OT bits |
Stage: derate → isolate domain → domain reset | Throughput reduction (explained) before disruption | < 60s | fault bits + rail snapshots; derating state changes; temperature |
| Brownout / BOR Vin dip + BOR cause |
Preserve forwarding if possible; otherwise controlled restart | May appear as “random reset” without evidence pack | < 60s | Vin/Iin waveform snapshots; BOR cause; PG timeline; fault log |
| Thermal trip temp threshold |
Throttle first; disable optional acceleration; last resort reset | Throughput decreases; p99 may improve after stabilization | < 60s | per-zone temperature; throttle reason; port/crypto state snapshot |
Performance engineering: throughput vs Mpps vs latency (the real bottlenecks)
“Fast” is not a single number. LBO performance splits into three different bottleneck families: Gbps (bytes moved), Mpps (per-packet overhead), and p99 latency (queueing tail). Microbursts and bufferbloat often dominate tail latency even when average utilization looks safe.
Metric map (what each KPI is really measuring):
- Throughput (Gbps): sustained byte-moving capacity; commonly limited by memory/DMA/backpressure.
- Packet rate (Mpps): per-packet work; commonly limited by descriptors, interrupts, queue depth, and table misses.
- Latency (p50/p99): queueing and retries; commonly dominated by microbursts, bufferbloat, or throttling events.
- Microburst: short congestion spikes that overrun a shallow queue even when average load is moderate.
- Bufferbloat: deep buffering hides drops but inflates p99; the system “works” while user experience degrades.
Evidence-first rule: identify which KPI is failing (Gbps / Mpps / p99), then read the smallest set of counters that can prove the bottleneck. Only after that should a single knob be changed and re-tested.
Typical bottleneck paths (symptom → cause cluster → evidence):
- Small packets (Mpps): descriptor/ring pressure, interrupt storms, queue depth/HoL blocking, TCAM/ACL misses. Check IRQ rate, ring fill level, queue drops, TCAM hit/miss.
- Large packets (Gbps): memory bandwidth limits, DMA stalls, backpressure between blocks, buffer occupancy. Check DMA stall/backpressure, memory BW, queue occupancy.
- Crypto-enabled forwarding: session table near-full, crypto queueing, thermal throttling. Check session utilization/evicts, crypto queue depth, throttle state/temperature.
| Symptom | Most likely cause cluster | Evidence counters to read first | Safe next step |
|---|---|---|---|
| Gbps OK, 64B Mpps low | Descriptor/ring saturation; IRQ/NAPI overhead; queue scheduling overhead | IRQ rate; ring fill level; per-core load; queue drops; backlog depth | Change one knob: interrupt moderation or ring depth; re-test packet-size matrix |
| p99 spikes under bursts | Microburst → queue occupancy; bufferbloat; backpressure chain | Queue occupancy peak; drop reason; latency histogram; backpressure indicators | Isolate burst source; adjust queue/buffer policy only after proving occupancy dominance |
| Throughput cliff after warm-up | Thermal throttling; power derating; crypto clock gating | Temperature; throttle state; power/rail telemetry; crypto queue latency | Verify derating triggers and actions; confirm performance becomes explainable |
| Random drops with low average load | Table misses/slow path; short-lived microbursts; head-of-line blocking | TCAM hit/miss; drop reason; per-queue drop distribution; burst counters | Reduce slow-path triggers; validate with counter deltas (before/after) |
| Crypto enabled → p99 explodes | Session table pressure; crypto queueing; DMA contention | Session util/evicts; crypto queue depth; DMA stall; temperature | Confirm session and queue headroom; tune batching only after evidence |
Recommended tuning order (avoid “QoS by guesswork”):
- Identify the failing KPI: Gbps vs Mpps vs p99 (do not mix conclusions).
- Read drop reason + queue occupancy to confirm queueing dominance.
- Read ring/descriptor + IRQ rate to confirm per-packet overhead dominance.
- Read TCAM hit/miss to confirm table-driven slow path behavior.
- Read crypto/session + throttle to confirm offload/thermal bottlenecks.
- Change one knob at a time and re-test the same matrix for clean attribution.
Validation checklist (lab tests that prove it’s done)
Validation should produce a signable outcome: each test has a clear pass criterion, common failure root causes, and an evidence set that makes failures reproducible. The goal is not only “passing in the lab,” but also field traceability when rare events occur.
Rule: every injected fault (droop, PMBus fault, over-temp) must generate a timestamped evidence pack (rail snapshot + key counters + action record). Without this, “random” becomes the default diagnosis.
| Test item | Pass criteria (examples) | Common failure root causes | Evidence to capture |
|---|---|---|---|
| Link · PRBS/BERT per port / per lane |
Stable link; error counters below threshold; no unexpected downshift | Signal integrity margin; retimer config; thermal drift; connector variability | FEC/CRC counters; link flap log; temperature; negotiated speed/PCS state |
| Link · FEC/CRC thresholds | FEC corrected stays within limit; uncorrected near zero under stress | Noise coupling; inadequate equalization; lane imbalance | FEC corrected/uncorrected; CRC; per-lane margin if available |
| Link · hot-plug cycles | Ports recover within target time; no persistent flap storms | Training instability; firmware timing; power/rail droop on re-train | Port up/down timestamps; rail snapshots; training status codes |
| Forwarding · throughput (RFC-style) | Meets target Gbps across expected packet sizes; stable over time | DMA/backpressure; memory BW; queue policy; table pressure | DMA stall/backpressure; queue occupancy; drop reasons; TCAM hit/miss |
| Forwarding · Mpps (64B/128B) | Meets target Mpps without pathological drops; CPU not saturated | Descriptor/ring depth; interrupt storms; scheduler overhead | IRQ rate; ring fill level; per-core load; queue drops; backlog depth |
| Forwarding · microburst burst + recovery |
p99 bounded; recovery time within target; controlled drops if necessary | Bufferbloat; shallow queues; unfair scheduling; HOL blocking | Latency histogram (p50/p99); queue peak; drop reason distribution |
| Forwarding · congestion recovery | No prolonged tail spikes after congestion clears | Queue drain inefficiency; flow control/backpressure interactions | Queue drain time; backpressure indicators; per-queue stats |
| Crypto · tunnel concurrency | Target concurrent tunnels sustained without cliff | Session table pressure; queueing; DMA contention | Session util/evicts; crypto queue depth; completion latency |
| Crypto · rekey / renegotiation stress | Rekey does not cause outage; p99 controlled during bursts | Handshake burst overload; session churn; control-plane pacing | Handshake rate; session churn; queue depth; p99 timeline |
| Crypto · key rotation without interruption | No tunnel drop; traffic continuity maintained | Key-store access latency; wrap/unwrap bottleneck; policy mismatch | Key events log; action record; crypto errors; tunnel continuity markers |
| Power · cold boot | Boot success rate near 100%; no intermittent sequencing failures | PG dependencies; soft-start mismatch; marginal rails | PG timeline; rail enable order; UV/OC bits; boot logs |
| Power · droop / brownout voltage dip |
Controlled behavior: derate first, then reset only if required | Input sag; insufficient hold-up; wrong thresholds | Vin dip snapshot; BOR cause; throttle state; fault log |
| Power · PMBus fault injection | Fault classified correctly; staged action recorded | Missing telemetry; incorrect grading; no evidence capture | Fault bits; alert grade; rail snapshots; action timeline |
| Thermal · derating curve (hot box) | Predictable performance vs temperature; no unexplained cliffs | Thermal runaway; mis-sized cooling; late throttling triggers | Temperature vs throughput; throttle state; rail power; logs |
| Reliability · 72h soak | No unexplained resets; stable counters; logs consistent | Leakage/thermal drift; rare queue stalls; resource fragmentation | Reset causes; evidence pack archive; counters trend; temperature trend |
| Reliability · reset traceability | Every reset has provable cause and evidence | Missing cause codes; logs overwritten; time not monotonic | Reset cause; timestamps; rail snapshot; counters snapshot; action record |
H2-11 · BOM / IC selection checklist (criteria + example P/N)
This section focuses on selection criteria that protect p99 latency, Mpps, and survivability in an LBO gateway—then lists example orderable parts to speed up sourcing and schematic/BOM kickoff.
1) Switch / NP silicon (fast-path tables, queues, and counters)
- Stage depth
- TCAM/SRAM scale
- Queue/buffer
- Mpps at 64B
- Telemetry richness
- Pipeline + table scale: ACL/classification entries, route/policy objects, per-flow counters and aging behavior.
- Queueing capability: per-port/per-class queues, WRED/ECN, shaping granularity, microburst tolerance.
- Mpps realism: sustained 64B forwarding with features enabled (ACL + QoS + counters), not just “wire-rate”.
- Drop visibility: drop reasons, per-stage counters, queue occupancy snapshots, congestion events.
- Feature budget: tunneling headers that matter for breakout (keep it minimal), but ensure required encapsulations exist.
- Control-plane attach: SDK maturity, warm reboot support, and deterministic configuration restore time.
- Broadcom StrataXGS Tomahawk 4:
BCM56990(family) - Broadcom StrataXGS Trident 4:
BCM56880(family) - Marvell Prestera 7K examples:
98DX7312,98DX7325,98DX7335 - Marvell Prestera access/edge families:
98DX73xx,98DX35xx,98DX25xx - Marvell Prestera “known-in-field” examples:
98DX3236,98DX3257
2) Crypto offload & key boundary (throughput, sessions, and safe key life)
- Inline latency
- Session scale
- DMA backpressure
- Thermal throttling
- Key isolation
- Where termination happens: inline datapath vs “sidecar”; measure copy count, DMA hops, and queue depth.
- Concurrency: max tunnels/sessions with rekey storms; verify “steady” and “burst” behavior.
- Backpressure model: queue saturation signals and deterministic shedding (drop/mark) instead of random latency spikes.
- Key handling: secure storage boundary, key wrapping, and auditable rotate/revoke events.
- Bypass policy: define fail-open / fail-close per traffic class; avoid silent half-encrypted states.
- Intel QAT adapter:
Intel® QuickAssist Adapter 8970(orderable examples:IQA89701G3P5,IQA89701G2P5) - Marvell NITROX III security processor (examples):
CNN3550(NITROX III family) - Secure element (key storage): Microchip
ATECC608Afamily - TPM (measured boot / key store): Infineon OPTIGA TPM
SLI9670(portfolio) - NXP secure element family:
EdgeLock SE050(orderable example:SE050C2HQ1/Z01SDZ)
3) High-speed links: retimers / redrivers / PHYs (BER → retransmits → p99 blowups)
- PAM4/NRZ margin
- FEC counters
- Link flap logs
- PRBS/BERT hooks
- Thermal headroom
- Retimer necessity: long traces, connectors, backplane hops, or high insertion-loss channels → retimer (not just redriver).
- Diagnostics: PRBS/BERT modes, eye/CTLE/DFE controls, lane margining, FEC/CRC counter access.
- Determinism: predictable training time and stable equalization across temperature and aging.
- Power & heat: retimers can dominate hotspots; require heatsink plan and telemetry correlation.
- TI 28G-class retimer:
DS280DF810(8-channel) - TI 25G-class retimer:
DS250DF410(4-channel) - 10GBASE-T PHY example: Marvell Alaska
88X3310 - 10GBASE-T PHY example: Broadcom
BCM84891family
4) Power, PMBus telemetry, and sequencing (brownout-proof performance)
- Rail partition
- Fault logs
- PG timing
- Derating policy
- Telemetry accuracy
- Domain partition: isolate SerDes/PHY/DDR/crypto/switch core rails to contain transients and speed recovery.
- PMBus visibility: VIN/IIN/VOUT/IOUT/TEMP + energy integration + fault history with timestamps.
- Sequencing control: programmable ramps, PG dependencies, and retry policies with bounded worst-case time.
- Derating explainability: define thresholds that map to observable throttle actions (lane downshift, crypto cap, queue policy).
- Power system manager (PMBus): Analog Devices
LTC2977,LTC2974 - Digital multiphase controller (PMBus): TI
TPS53679 - Digital power controller (PMBus): Infineon
XDPE12284C - Digital multiphase controller (PMBus): Renesas
ISL68127
5) Watchdog, reset supervision, management MCU (survivability under partial faults)
- Independent domain
- Window watchdog
- Reset fan-out
- Event persistence
- OOB readiness
- Always-on management: management logic must be alive at power-up, before host CPU and before dataplane is stable.
- Watchdog policy: separate “control-plane dead” from “dataplane dead”; avoid resetting forwarding for recoverable mgmt faults.
- Reset topology: domain resets, staged recovery, and bounded RTO (recovery time objective) per fault type.
- Evidence set: BOR/WDT/thermal/PMBus faults + last-gasp snapshot and monotonic counters.
- Window watchdog supervisor: TI
TPS386000 - Management MCU example: NXP
LPC55S69family - Management MCU example: ST
STM32H743family - Secure element for event integrity: Microchip
ATECC608Afamily
Request a Quote
H2-12 · FAQs (Local Breakout Gateway)
Practical troubleshooting questions mapped to the relevant sections. Each answer emphasizes evidence-first (counters/logs/telemetry) to keep p99 latency and Mpps behavior explainable in the field.
