Bridge Interface Calculator
Calculate throughput and MAC table capacity for a Linux bridge interface.
About Bridge Interface Calculator
A Linux software bridge (or hardware switch) forwards frames between ports at Layer 2, and the effective throughput between any two ports is capped by whichever of the two is slower — connecting a Gigabit and a Fast Ethernet port through a bridge means traffic between them can never exceed 100 Mbps regardless of the Gigabit port's own capacity. The bridge also maintains a forwarding database (FDB) mapping learned source MAC addresses to the port they were seen on, and this table's memory footprint scales with the number of distinct active MAC addresses the bridge has learned.
Formula
Bridge throughput ceiling
bridge_throughput = min(all_port_speeds)
- S_i
- speed of bridge port i
Worked example
With the default values below, Bridge Interface Calculator returns Bridge Throughput Ceiling (Mbps) of 100. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Bridge Port Speeds (comma-separated Mbps)
- 1000, 1000, 100
- Active MAC Addresses Seenminimum 0
- 250
Results
- Bridge Throughput Ceiling (Mbps)
- 100
- Estimated Forwarding Table Memory (KB)
- 31.25
- Bridge Port Count
- 3
Step by step
- 1Values used
- 2Bridge throughput ceiling
- 3Bridge Throughput Ceiling (Mbps)= 100
- 4Estimated Forwarding Table Memory (KB)= 31.25
- 5Bridge Port Count= 3
Assumptions and limits
- The result is derived only from the 2 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How do I inspect a Linux bridge's forwarding table?
`bridge fdb show` (from iproute2) or the legacy `brctl showmacs <bridge>` lists learned MAC-to-port mappings, including their aging status. `ip -s -d link show <bridge>` shows bridge-level statistics.
Why would two ports of the same nominal speed still bottleneck each other?
Even matched port speeds share the bridge's internal forwarding capacity and, for software bridges, CPU cycles for frame processing — under heavy multi-port load, aggregate throughput across all ports can be limited by CPU rather than any single port's link speed.
How does FDB aging affect memory usage over time?
Entries not refreshed within the aging timeout (default 300 seconds, tunable via `ip link set <bridge> type bridge ageing_time <seconds>`) are removed, so a bridge's actual FDB size fluctuates with how many distinct hosts have communicated through it recently rather than growing unbounded.