Packet Forwarding FAQ: Jumbo Frames and Core Routing Specs of switching capacity Mbps PPS

Overview & Thematic Scope

In core routing and high-performance switching, two metrics dominate performance discussions: switching capacity (measured in Mbps/Gbps) and packet forwarding rate (PPS). While Mbps defines raw data throughput, PPS reveals how a switch handles small packets—the real bottleneck in VOIP, gaming, and financial trading networks. This FAQ focuses on packet forwarding bottlenecks, jumbo frame support, and non-blocking fabric design for datacenter and ISP core environments.

Frequently Asked Questions

Q1: What is the difference between switching capacity (Mbps/Gbps) and packet forwarding rate (PPS), and why does PPS matter for core routing?

Switching capacity (Mbps) measures maximum raw data throughput, while packet forwarding rate (PPS) measures how many packets per second the switch can process. PPS is critical because small packets (e.g., 64-byte VOIP or ACK packets) create far more forwarding decisions per megabit than large packets. A switch with 1 Gbps capacity but low PPS will drop small packets under load, causing latency and retransmissions. For core routing, always verify both metrics: a non-blocking switch must meet line-rate PPS for minimum frame size on all ports simultaneously.

Q2: How do I calculate the required switching capacity and PPS for a 48-port 10GbE core switch?

For 48 ports of 10GbE full duplex, total switching capacity = ports × port speed × 2 (duplex) = 48 × 10 Gbps × 2 = 960 Gbps (0.96 Tbps). Required PPS for 64-byte frames: each 10GbE port at line rate handles 14.88 Mpps (million packets per second). Total PPS = 48 × 14.88 Mpps = 714.24 Mpps. A true non-blocking switch must exceed both values simultaneously. If the datasheet shows 960 Gbps but only 400 Mpps, the switch cannot handle 64-byte traffic at line rate—a common hidden bottleneck.

Q3: What is jumbo frame support, and how does it affect switching capacity and PPS requirements?

Jumbo frames (typically 9000–9216 bytes) increase the payload per packet, reducing the number of packets per second required for a given throughput. For example, at 10 Gbps, 64-byte frames require 14.88 Mpps, while 9000-byte jumbo frames require only ≈0.14 Mpps. This dramatically lowers CPU and ASIC load. However, jumbo frames require end-to-end support (NICs, switches, routers). When deploying jumbo frames, switching capacity (Mbps) remains the same, but effective PPS utilization drops, allowing older switches to handle high-bandwidth flows without packet loss. Always test jumbo frame support with ICMP ping of size 9000 bytes before production.

Q4: What does ‘non-blocking fabric’ mean in switching capacity specifications?

A non-blocking fabric means the switch’s internal backplane or ASIC can simultaneously handle full line-rate traffic on all ports without dropping packets. Mathematically: switching capacity (full duplex) ≥ sum of (port speed × 2) for all ports. For a 24-port Gigabit switch: required capacity ≥ 24 × 1 Gbps × 2 = 48 Gbps. Many low-cost switches oversubscribe (e.g., 48 Gbps switching capacity but 72 Gbps port sum leads to blocking). Non-blocking is mandatory for core and aggregation layers. Check both switching capacity and PPS: a switch can be non-blocking for large packets but blocking for 64-byte frames if PPS is insufficient.

Q5: How do I troubleshoot packet loss caused by switching capacity or PPS exhaustion?

First, identify the bottleneck: monitor port counters for output drops (indicates oversubscription or buffer exhaustion) and input drops (indicates PPS limit of ingress ASIC). Use small-packet tests: send 64-byte UDP floods between port pairs. If loss occurs at low Mbps but line-rate PPS claims are higher, the switch likely has a shared PPS bottleneck. Check if loss appears on multiple ports simultaneously—a sign of fabric blocking. Solutions: enable jumbo frames if traffic allows, implement flow control (802.3x), upgrade to a switch with higher PPS, or redistribute traffic across multiple uplinks using LAG (Link Aggregation) to reduce per-port PPS load.

Q6: What switching capacity and PPS do I need for a spine-leaf datacenter network with 100GbE uplinks?

For a leaf switch with 48 x 25GbE downlinks and 8 x 100GbE uplinks: total switching capacity required = (48 × 25 Gbps × 2) + (8 × 100 Gbps × 2) = 2400 Gbps + 1600 Gbps = 4 Tbps full duplex. Minimum PPS for 64-byte frames: 25GbE port = 37.2 Mpps, 100GbE port = 148.8 Mpps. Total = (48 × 37.2) + (8 × 148.8) = 1785.6 Mpps + 1190.4 Mpps = 2976 Mpps. Modern spine-leaf ASICs (e.g., Tomahawk 4, Trident 4) exceed these values. Always allocate 20-30% headroom for burst traffic and protocol overhead. For layer-3 leaf routing, add CPU PPS for ARP, BGP keepalives, and ECMP hashing.

Q7: Can I mix different port speeds (1GbE, 10GbE, 25GbE) and maintain non-blocking switching capacity?

Yes, but only if the switch ASIC supports per-port speed configuration without blocking. Calculate total capacity as sum of (each port’s configured speed × 2). For example, mixing 24×1GbE + 12×10GbE + 4×25GbE requires: (24×1×2) + (12×10×2) + (4×25×2) = 48 + 240 + 200 = 488 Gbps switching capacity. However, many fixed-configuration switches have oversubscribed uplink groups (e.g., four 25GbE uplinks sharing a single 100GbE fabric channel). Verify that the PPS specification covers the worst-case scenario: all ports receiving minimum-size frames. Some ASICs (like Broadcom Trident) handle mixed speeds efficiently, while others require traffic shaping or port groups.

Q8: What is the impact of PPS on latency and real-time applications like financial trading?

PPS directly affects store-and-forward latency: when a switch’s PPS limit is approached, packets queue in ingress buffers, adding variable queuing delay (jitter). For high-frequency trading (HFT), even microseconds matter. A switch rated for 1000 Mpps but running at 950 Mpps will have consistent low latency. At 1000+ Mpps, the switch either drops packets (cut-through disabled) or dramatically increases latency (store-and-forward mode). For trading, use switches with cut-through switching and PPS headroom of ≥50% above peak expected load. Also prioritize switches with configurable PPS storm control and per-queue PPS limits to isolate chatty protocols from latency-sensitive flows.