DEV Community: sonic components

Juinper Networks

sonic components — Wed, 02 Sep 2026 15:49:35 +0000

Upgrading Juniper MX Networks from 100GbE to 400GbE: What Engineers Need to Know

Moving a production network from 100 Gigabit Ethernet to 400 Gigabit Ethernet sounds simple on paper:

Replace a 100G interface with a 400G interface and get four times the bandwidth.

In a real carrier or data-center network, however, the interface is only one part of the equation.

The router's forwarding silicon, switch fabric, midplane, power system, cooling, optics, software release, slot selection, redundancy configuration, and licensing can all determine whether the expected capacity is actually available.

Juniper's MX240, MX480, and MX960 platforms provide an interesting example because these systems can be upgraded with newer generations of Modular Port Concentrators rather than requiring an immediate chassis replacement.

One particularly useful case study is the Juniper MPC10E-15C, a Trio 5-based line card capable of supporting both 100GbE and 400GbE interfaces.

This article isn't about whether you should buy a particular line card.

Instead, we'll use the MPC10E-15C to examine the engineering questions that should be answered before attempting a 100G-to-400G upgrade on an existing Juniper MX network.

Video Overview

The video provides a short overview of the hardware. Below, we'll go deeper into the architecture and the deployment considerations that matter when integrating this class of line card into an existing MX environment.

Why Moving from 100G to 400G Isn't Just a Port Upgrade

Suppose an edge router has four heavily utilized 100GbE connections.

At first glance, replacing those links with 400GbE interfaces appears straightforward.

But consider what happens behind the physical port.

Traffic entering that 400G interface must travel through several parts of the system:

Interface → Packet Forwarding Engine → Fabric → Other line cards/interfaces

Every component in that path needs sufficient capacity.

A 400GbE optic connected to a router that cannot move 400 Gbps through its internal architecture does not magically create a 400 Gbps forwarding system.

This distinction becomes especially important when installing modern line cards into chassis that may have been deployed years earlier.

Understanding the MPC10E-15C Architecture

The MPC10E-15C is a fixed-configuration Modular Port Concentrator designed for the MX240, MX480, and MX960.

It contains 15 multirate interfaces divided into three groups.

Each group contains:

Four QSFP28 interfaces
One QSFP56-DD interface

Across the entire card, that becomes:

12 × QSFP28

plus

3 × QSFP56-DD

The QSFP28 interfaces support 10GbE, 40GbE, and 100GbE operation.

The QSFP56-DD interfaces add support for 400GbE.

This mixed architecture is useful because most networks don't transition from 100G to 400G everywhere simultaneously.

Why Mixed 100G and 400G Connectivity Is Useful

Network upgrades normally happen incrementally.

Imagine an ISP with several 100GbE upstream connections, peering links, aggregation paths, and data-center interconnects.

Perhaps only two links are approaching capacity.

Replacing every 100G interface would make little sense.

Instead, the operator might move the highest-utilization links to 400G while leaving other connections at 100G.

A mixed-port line card makes that possible.

The twelve QSFP28 interfaces can continue serving the existing 100G environment while the three QSFP56-DD interfaces provide a migration path toward 400G.

That is a much more realistic network transition than assuming everything becomes 400G overnight.

Three Packet Forwarding Engines

The MPC10E-15C contains three Packet Forwarding Engines.

Each PFE provides a maximum bandwidth of:

500 Gbps

Therefore, the theoretical aggregate forwarding capacity is:

3 × 500 Gbps = 1.5 Tbps

The architecture uses Juniper Trio 5 silicon.

This matters because forwarding capacity isn't simply determined by how many ports exist on the front panel.

The Packet Forwarding Engines perform the actual high-speed packet processing required by the router.

Modern service-provider networks may simultaneously need to handle:

IPv4 and IPv6 forwarding
MPLS
VPN services
Internet peering
Subscriber traffic
Traffic engineering
Data-center connectivity
Large forwarding tables
High packet rates

As interface speeds increase, forwarding architecture becomes increasingly important.

The Midplane Question: 800 Gbps or 1.5 Tbps?

This is one of the most important details when considering an MPC10E upgrade.

The same line card can operate at substantially different aggregate throughput depending on the MX chassis configuration.

With a compatible standard midplane, Juniper documents throughput of up to:

800 Gbps

With an enhanced midplane, maximum line-rate throughput can reach:

1.5 Tbps

That is a substantial difference.

So the question shouldn't simply be:

Does my MX960 support this MPC?

A better question is:

What throughput can my specific MX960 configuration actually provide to this MPC?

Those are not the same question.

Check the Midplane from Junos

Before planning an upgrade, one of the useful commands to run is:

show chassis hardware

Juniper documents different descriptions for the standard and enhanced backplanes.

An enhanced configuration reports an enhanced platform backplane, while a standard configuration reports the regular platform backplane.

This is an excellent example of why network upgrades should begin with an inventory of the existing chassis rather than with an assumption based solely on the router model number.

Two MX960 routers can carry the same model designation while containing different generations of internal infrastructure.

The Switch Fabric Matters Too

The midplane isn't the only consideration.

To achieve maximum line-rate performance, the switch fabric must also provide sufficient capacity.

For the MPC10E-15C, Juniper documents requirements involving SCBE3-MX Switch Control Boards and increased-bandwidth fabric operation.

For maximum performance, Juniper specifies:

MX960

3 × SCBE3-MX

MX240 / MX480

2 × SCBE3-MX

The MPC's fabric redundancy mode also needs to be configured appropriately for increased bandwidth.

This is an important engineering lesson:

A 1.5 Tbps line card does not automatically create a 1.5 Tbps system.

The entire forwarding path has to support that capacity.

Redundancy Can Affect Available Bandwidth

There is another tradeoff worth considering.

Network engineers naturally want redundancy.

But fabric redundancy and maximum bandwidth can interact.

Juniper's technical material for the MPC10E architecture shows that achieving full line-rate performance can require all available fabric planes to participate.

That means engineers need to understand the relationship between:

Maximum throughput
Fabric configuration
Redundancy mode
Failure scenarios

This isn't unique to Juniper.

It is a general principle of modular routing systems: maximum theoretical capacity and maximum capacity under every redundancy condition aren't necessarily identical.

When planning a 400G migration, both normal operation and failure-state behavior should be modeled.

Don't Forget Power and Cooling

High-capacity forwarding silicon consumes significant power.

Juniper documents a maximum power requirement of approximately:

785 watts

for the MPC10E-15C under its specified 40°C test configuration.

At 25°C, Juniper documents approximately:

720 watts

under the specified test conditions.

That is just one line card.

In a chassis containing several high-capacity MPCs, total power and thermal requirements can become significant.

Juniper therefore specifies high-capacity power supplies and fan trays for these configurations.

Before adding several modern MPCs to an older chassis, check:

Available power capacity
Installed power-supply generation
Power redundancy
Fan-tray generation
Airflow
Ambient temperature
Rack power budget
Facility cooling

The fact that a line card physically fits into a slot doesn't mean the chassis is ready to operate it.

MX960 Slot Placement Requires Attention

The MX960 introduces another planning consideration: slot selection.

High-power, high-capacity line cards can have placement restrictions because of cooling and chassis architecture.

Juniper documentation for the MPC10E family includes MX960 slot restrictions that engineers should review before installation.

This means an upgrade plan should include a map of the existing chassis.

Document:

Which slots are occupied
Which MPCs are installed
Which slots are available
Current power consumption
Current fabric configuration
Routing Engine configuration
Switch Control Board configuration

Doing this before purchasing hardware can prevent a surprisingly expensive installation problem.

400G Optics Are Part of the Design

The line card is only half of a 400GbE link.

The optical layer matters just as much.

A network architect needs to determine:

Required distance
Fiber type
Connector type
Optical standard
Link budget
Patch-panel losses
Existing DWDM infrastructure
Breakout requirements
Supported Juniper optics

For short data-center connections, the optical design may be relatively straightforward.

For metro or long-distance carrier networks, the optical transport architecture can become considerably more complex.

Don't select the router interface independently from the optical path.

Design them together.

Jumbo Frames and MTU Planning

The MPC10E-15C supports large MTUs.

Juniper documents transit traffic MTUs up to:

16,000 bytes

and host-bound packet MTUs up to:

9,500 bytes

This can be valuable in environments using jumbo frames, MPLS encapsulation, data-center interconnects, and other applications where additional packet overhead needs to be considered.

But changing one interface doesn't solve an end-to-end MTU problem.

The entire path should be validated.

That includes:

Router interfaces
Transport equipment
Switches
Firewalls
MPLS paths
Data-center fabrics
End systems

MTU mismatches can create difficult-to-diagnose problems even when every individual device appears healthy.

What About MACsec?

The interfaces on the MPC10E-15C provide hardware support for MACsec.

That can be useful for organizations requiring encrypted Ethernet connectivity between network locations.

But hardware support and feature entitlement aren't always the same thing.

Engineers should verify the appropriate Juniper software and bandwidth licensing for the intended MACsec deployment.

This is another reason to include licensing in the technical design rather than treating it as a purchasing detail that can be handled afterward.

Software Release Matters

Hardware compatibility alone isn't enough.

The MPC10E-15C was introduced with Junos OS 19.1R1 support, while support for operation with a standard midplane begins with Junos OS 19.2R1.

In a production environment, however, the goal shouldn't simply be to run the earliest software release that recognizes the hardware.

Before deployment, evaluate:

Current Junos release
Recommended Junos release
Other installed MPCs
Routing Engine compatibility
Feature requirements
Known issues
Maintenance windows
Upgrade path

Adding a new generation of forwarding hardware may therefore trigger a broader software lifecycle discussion.

A Practical Pre-Upgrade Checklist

Before moving an existing MX240, MX480, or MX960 toward 400GbE, I would collect at least the following information.

1. Chassis

Identify the exact MX platform and hardware revision.

2. Midplane

Determine whether the chassis has the standard or enhanced backplane.

3. Switch Fabric

Identify the installed Switch Control Boards and determine available fabric capacity.

4. Fabric Mode

Understand whether the desired redundancy configuration provides the bandwidth required by the new MPC.

5. Slots

Confirm that the intended line-card position is supported.

6. Power

Calculate existing and projected chassis power consumption.

7. Cooling

Verify fan trays, airflow, ambient temperature, and facility cooling.

8. Junos

Confirm software compatibility and determine whether an upgrade is required.

9. Optics

Select supported transceivers based on distance and optical architecture.

10. Licensing

Identify any feature or capacity licenses required by the intended configuration.

11. MTU

Validate the complete path if jumbo frames or additional encapsulation are used.

12. Failure Scenarios

Determine what happens to forwarding capacity if a fabric component or other redundant element fails.

Upgrade the Chassis or Replace It?

This leads to the bigger architectural question.

When traffic outgrows an existing router, should the operator replace the entire platform?

Not necessarily.

One of the advantages of modular platforms such as the MX240, MX480, and MX960 is that several generations of interface and forwarding technology can potentially coexist with the chassis over its operational life.

A network originally designed around 10G interfaces may have subsequently moved through 40G and 100G generations and can, in the right configuration, reach 400G connectivity.

That can protect a substantial infrastructure investment.

But there is a limit.

If upgrading requires replacing the midplane, switch fabric, power supplies, fan trays, software, optics, and most line cards, engineers should compare that investment against migrating to a newer routing platform.

The technically possible upgrade isn't always the economically sensible upgrade.

Final Thoughts

The transition from 100GbE to 400GbE demonstrates why router capacity planning must be performed at the system level.

Using the Juniper MPC10E-15C as an example, the front panel tells only part of the story.

Yes, the card provides:

12 QSFP28 interfaces
3 QSFP56-DD interfaces
400GbE capability
Three 500 Gbps Packet Forwarding Engines
Trio 5 forwarding silicon
Up to 1.5 Tbps aggregate throughput

But achieving that performance depends on the infrastructure behind those interfaces.

The midplane matters.

The switch fabric matters.

Fabric configuration matters.

Power matters.

Cooling matters.

Slot placement matters.

Software matters.

Optics matter.

Licensing matters.

And redundancy matters.

That is the real lesson for engineers planning a 400GbE upgrade:

Don't design around the speed printed next to the port. Design around the capacity of the complete forwarding system.

When those pieces are evaluated together, existing MX infrastructure can potentially provide a practical migration path from 100GbE into the 400GbE era.

References

Juniper Networks — MPC10E-15C hardware specifications
Juniper Networks — MX Series Interface Module Reference
Juniper Networks — MPC10E-15C-MRATE hardware documentation

Topics

Juniper MX, Network Engineering, 400GbE, 100GbE, Routing, Service Provider Networks, Data Center Networking

Four QSFP28 interfaces
One QSFP56-DD interface

Across the entire card, that becomes:

Deploying NVIDIA GB300 NVL72: The Infrastructure Checklist Engineers Shouldn't Skip

sonic components — Tue, 01 Sep 2026 15:17:32 +0000

Deploying NVIDIA GB300 NVL72: The Infrastructure Checklist Engineers Shouldn't Skip

The NVIDIA GB300 NVL72 is not a conventional GPU server.

It is a rack-scale AI platform built around 72 NVIDIA Blackwell Ultra GPUs and 36 NVIDIA Grace CPUs.

That distinction matters when you're planning an actual deployment.

The hardware specification may look impressive, but the real engineering challenge is making the compute, networking, storage, power and cooling infrastructure work together.

Here's how I'd approach a GB300 deployment from an infrastructure perspective.

Start With the Workload

Before designing the rack, define what you're trying to run.

Typical GB300 workloads can include:

Large-model training
Post-training
AI inference
Reasoning models
Agentic AI
Generative AI
Multimodal workloads
High-performance computing

Don't size the infrastructure simply because "72 GPUs sounds good."

Determine:

How large are the models?

How much inference concurrency is required?

How quickly will the workload grow?

Will additional GB300 racks be added?

Those answers influence everything downstream.

Understand the 72-GPU Architecture

GB300 NVL72 combines:

72 Blackwell Ultra GPUs

with:

36 Grace CPUs

and creates a large NVLink scale-up domain.

NVIDIA currently specifies 130 TB/s aggregate NVLink bandwidth.

That's important because distributed AI workloads can generate enormous amounts of GPU-to-GPU traffic.

A useful mental model is:

The goal is to keep data moving efficiently between the accelerators.

Don't Treat Networking as an Accessory

This is probably one of the biggest mistakes in AI infrastructure planning.

The GB300 architecture supports high-speed scale-out networking using NVIDIA ConnectX-8 SuperNIC technology.

NVIDIA specifies networking capabilities reaching 800 Gb/s per GPU.

That means the network design has to be considered at the beginning of the project.

You'll need to determine:

InfiniBand or Ethernet
Switch architecture
Number of switch ports
800 Gb/s transceivers
Fiber requirements
DAC/AOC requirements
Cable lengths
Redundancy
Storage connectivity
Management connectivity

The network isn't simply connecting the servers.

It's part of the AI computing system.

Calculate Power Before Ordering Hardware

This sounds obvious, but high-density AI infrastructure can expose facility limitations very quickly.

A rack-scale AI deployment requires the electrical team to validate:

Utility
↓
Electrical Distribution
↓
UPS
↓
PDU
↓
AI Rack
↓
GB300 NVL72

Don't stop at checking whether the rack PDU has enough outlets.

Check:

Available rack power
PDU capacity
Circuit capacity
UPS capacity
Facility electrical capacity
Redundancy
Future rack expansion

A successful AI deployment starts with knowing that the building can actually support it.

Plan Liquid Cooling

GB300 NVL72 is a fully liquid-cooled architecture.

This changes the facility conversation considerably.

The cooling system needs to be designed around the rack rather than treating the AI system like a normal air-cooled enterprise server.

Engineering teams should evaluate:

Coolant distribution
CDU capacity
Heat rejection
Facility water infrastructure
Rack connections
Redundancy
Monitoring
Maintenance procedures

Power and cooling should be designed together.

If you know the electrical load but don't understand the thermal architecture, you don't yet have a complete deployment plan.

Storage Is Another Potential Bottleneck

GPU performance doesn't matter much if the accelerators are constantly waiting for data.

Large AI environments may require high-performance shared storage for:

Training datasets
Model checkpoints
Model weights
Logs
Inference data
Generated content

The storage architecture needs to be evaluated based on actual workload throughput rather than simply total capacity.

Ask:

How much data must reach the GPUs per second?

That question is often more useful than:

How many terabytes do we need?

Memory Changes Model Deployment

NVIDIA lists up to 20 TB of GPU memory for GB300 NVL72 and 17 TB of CPU memory.

GPU memory capacity affects what models can be loaded and how they can be distributed.

It also influences:

Context length
Batch size
KV cache
Inference concurrency
Model parallelism
Data movement

For large models, memory architecture can become a primary system-design consideration.

Think About Expansion Before Deployment

Suppose you deploy one GB300 rack today.

What happens when the AI team needs four?

Or eight?

If the original deployment wasn't designed for expansion, the organization may encounter:

Network-port limitations
Insufficient power
Cooling limitations
Storage bottlenecks
Rack-space constraints

The better approach is to design the AI zone before deploying the first rack.

Think beyond:

"Where will this rack go?"

Think:

"Where will the next ten racks go?"

GB300 NVL72 vs. DGX B300

These platforms should not be treated as interchangeable.

DGX B300 is an integrated eight-GPU AI system.

GB300 NVL72 scales to 72 Blackwell Ultra GPUs in a rack-scale architecture.

For organizations evaluating the two, the question isn't simply which system is faster.

The better question is:

What scale does the AI workload require?

DGX B300 can make sense for organizations building an enterprise AI deployment around individual integrated systems.

GB300 NVL72 is designed for organizations operating at substantially larger AI infrastructure scale.

Sonic Components has published a separate analysis of DGX B300:

NVIDIA DGX B300 — Blackwell Ultra Infrastructure

https://www.soniccomponents.com/nvidia-dgx-b300-blackwell-ultra-infrastructure/

And the complete GB300 article is available here:

NVIDIA GB300 NVL72 — 72-GPU Blackwell Ultra AI Platform

https://www.soniccomponents.com/nvidia-gb300-nvl72/

A Practical GB300 Deployment Checklist

Before approving a purchase, I'd work through this list.

Compute

☐ 72 Blackwell Ultra GPUs
☐ 36 Grace CPUs
☐ GPU memory requirements
☐ CPU memory requirements

NVLink

☐ GPU topology
☐ NVLink architecture
☐ Scale-up requirements

Networking

☐ InfiniBand or Ethernet
☐ ConnectX-8
☐ AI switches
☐ 800 Gb/s connectivity
☐ Transceivers
☐ Fiber
☐ DAC/AOC cables

Storage

☐ Dataset capacity
☐ Dataset throughput
☐ Checkpoint storage
☐ Shared filesystem
☐ Backup

Facility

☐ Rack space
☐ Electrical capacity
☐ UPS
☐ PDU
☐ Liquid cooling
☐ Heat rejection
☐ Service access

Operations

☐ Monitoring
☐ Orchestration
☐ NVIDIA Mission Control
☐ Software stack
☐ Maintenance procedures

What About GB300 Pricing?

Don't build a procurement decision around a random "GB300 price" found online.

Rack-scale systems can involve substantially more than the compute hardware.

The project may include:

GB300 system + networking + switches + optics + cabling + storage + support + installation + facility infrastructure

That's why an enterprise RFQ should specify the actual deployment requirements.

If you're requesting pricing, include:

Quantity
Configuration
Delivery location
Networking requirements
Support requirements
Installation requirements
Required delivery date
Request a GB300 NVL72 RFQ

Sonic Components works with organizations sourcing:

NVIDIA AI infrastructure
GPU systems
Data-center equipment
Enterprise networking
Telecom infrastructure
High-performance computing equipment

For a NVIDIA GB300 NVL72 RFQ, contact:

scs@soniccomponents.com

Include your required configuration, quantity, delivery location and target deployment date.

Final Takeaway

The NVIDIA GB300 NVL72 is an impressive piece of computing infrastructure.

But the hardest part isn't installing 72 GPUs.

The hard part is building the environment around them.

A successful deployment requires coordination between:

Compute

NVLink

Networking

Storage

Power

Cooling

Software

Operations

That's why GB300 NVL72 should be treated as an AI infrastructure project, not simply a server purchase.

As AI reasoning, agentic workloads and large-scale inference continue to increase, rack-scale architectures such as GB300 NVL72 are likely to become increasingly important.

The fundamental shift is already happening:

GPU → Server → Cluster → AI Factory

And the engineers who plan the infrastructure around the GPUs will determine how effectively that compute can actually be used.

DEV tags

nvidia #ai #gpu #datacenter #infrastructure #machinelearning #blackwell #devops

NVIDIA DGX B300

sonic components — Tue, 01 Sep 2026 14:54:40 +0000

What It Takes to Deploy an NVIDIA DGX B300 in a Real Data Center

Buying an AI server is easy compared with deploying one.

The NVIDIA DGX B300 is a good example.

On paper, the specifications are impressive:

8 Blackwell Ultra GPUs
14.4 TB/s aggregate NVLink bandwidth
Up to 800 Gb/s networking
2 BlueField-3 DPUs
8 × 3.84 TB NVMe E1.S drives
10U rack space
Approximately 14 kW power consumption

But if you're the engineer responsible for actually installing it, the interesting questions start after the specification sheet.

Step 1: Check rack capacity

DGX B300 occupies 10U.

That sounds manageable until you start adding:

AI switches
patch panels
cable management
storage
additional compute
power distribution

If you're designing a multi-rack AI environment, don't allocate space based only on the DGX system.

Design the entire rack architecture.

Step 2: Check power

This is probably the first facility question.

NVIDIA's User Guide specifies 14.5 kW power consumption and 12 AC power inlets for the AC configuration.

That is a serious amount of power for a 10U system.

Before deployment, verify:

Rack capacity
↓
PDU capacity
↓
Electrical distribution
↓
UPS capacity
↓
Facility capacity

Don't discover the problem after the hardware arrives.

Step 3: Check cooling

Power becomes heat.

NVIDIA lists approximately 49,476 BTU/hr maximum heat output in the DGX B300 User Guide.

The cooling design therefore needs to be evaluated alongside the electrical design.

A rack that can electrically support DGX B300 may not necessarily have adequate thermal capacity.

Step 4: Design the network

DGX B300 supports networking up to 800 Gb/s using ConnectX-8 VPI networking. It also includes BlueField-3 DPUs supporting up to 400 Gb/s InfiniBand/Ethernet.

That means you need to plan:

Switch ports
Transceivers
DAC/AOC cables
Fiber infrastructure
InfiniBand or Ethernet
Network topology
Redundancy

For multiple systems, the network becomes part of the computing architecture.

Step 5: Understand NVLink

The system provides 14.4 TB/s aggregate NVLink bandwidth.

Why is that important?

Because AI workloads frequently require GPUs to exchange information.

More GPUs aren't necessarily better if the GPUs spend too much time waiting for data.

High-bandwidth GPU interconnects help keep the accelerators working together efficiently.

Step 6: Plan storage

DGX B300 includes:

2 × 1.9 TB NVMe M.2

and:

8 × 3.84 TB NVMe E1.S.

That's useful local storage, but large AI deployments frequently require additional shared storage.

Consider:

Dataset size
Checkpoint storage
Training throughput
Shared filesystem requirements
Backup
Replication
Storage networking
Step 7: Plan for expansion

One DGX B300 might solve today's requirement.

What happens six months later?

If your AI team expects to expand from one system to four, eight or more, design the network, power and cooling architecture accordingly.

Otherwise the first DGX deployment can become an infrastructure constraint.

Step 8: Compare against GB300 NVL72

At some scale, DGX B300 may no longer be the right comparison.

NVIDIA's GB300 NVL72 architecture includes 72 Blackwell Ultra GPUs and 36 Grace CPUs with 130 TB/s NVLink bandwidth.

That's a completely different infrastructure class.

So before buying, ask:

Are we building an AI server deployment or an AI factory?

That distinction can dramatically change the architecture.

Final Takeaway

The NVIDIA DGX B300 is an impressive AI system, but successful deployment requires more than purchasing the hardware.

The engineering checklist should include:

Compute → Interconnect → Network → Storage → Power → Cooling → Operations

When those pieces are designed together, DGX B300 becomes a powerful foundation for enterprise AI.

For organizations sourcing NVIDIA DGX B300 systems, configurations and related AI infrastructure, Sonic Components accepts enterprise RFQs at:

scs@soniccomponents.com

Publishing order I recommend

Don't release all five on the same day.

Day 1: Sonic cornerstone page
Day 2: LinkedIn
Day 3: Medium
Day 5: Substack
Day 7: Hashnode
Day 9: DEV

Then our next major article should be GB300 NVL72, and we repeat the same multi-platform strategy.

This gives Sonic a connected content network around Blackwell → DGX B300 → GB300 → HGX B300 → B200 → H200, rather than six unrelated product articles.