Linux can act as much more than an endpoint on a network. With Linux bridges, network namespaces, and veth pairs, a single Linux host can become a complete virtual networking laboratory containing isolated hosts, virtual Ethernet links, switches, routing boundaries, and packet-capture points.
In the previous CorgiNetwork guide on Linux Network Namespaces, we created isolated networking environments and connected them with veth pairs.
That works extremely well when only two endpoints need a direct connection.
But what happens when three, five, or twenty virtual hosts need to share the same Layer 2 network?
This is where the Linux bridge becomes important.
According to the official Linux kernel Ethernet Bridge documentation, an Ethernet bridge operates at Layer 2 and forwards frames between network segments based on destination MAC addresses.
In practical terms, we can use a Linux bridge much like a virtual Ethernet switch.
This guide builds an end-to-end lab containing three network namespaces connected through a Linux bridge, then examines MAC learning, the forwarding database, ARP, packet capture, routing, Internet access, STP, VLAN filtering, and common bridge failures.
A Linux bridge is a software implementation of Ethernet bridging inside the Linux networking stack.
Conceptually:
Linux Bridge
/ | \
port1 port2 port3
| | |
Host A Host B Host CUnlike a traditional IP router, which primarily makes forwarding decisions using destination IP addresses and routing tables, an Ethernet bridge operates at Layer 2.
The official Linux Ethernet Bridging documentation describes a bridge as connecting network segments and filtering or forwarding frames based on destination MAC addresses.
Therefore, a useful simplified model is:
Router
↓
Destination IP
↓
Routing Tableversus:
Bridge
↓
Destination MAC
↓
Forwarding DatabaseThis distinction is essential when troubleshooting Linux virtual networking.
A Linux bridge behaves in many ways like a software Ethernet switch.
A physical switch might connect:
PC1 ───┐
PC2 ───┼── Ethernet Switch
PC3 ───┘A Linux bridge can connect:
Namespace 1 ───┐
Namespace 2 ───┼── Linux Bridge
Namespace 3 ───┘The major difference is that the switch exists inside the Linux kernel rather than as a separate hardware device.
This makes bridges extremely useful for:
These technologies solve different problems.
A network namespace provides network-stack isolation.
As explained in CorgiNetwork’s Linux Network Namespaces guide, a namespace can have its own interfaces, routing tables, sockets, firewall context, and networking configuration.
A bridge provides Layer 2 connectivity.
Therefore:
Network Namespace
↓
Creates isolated endpointwhile:
Linux Bridge
↓
Connects Ethernet endpointsCombining them gives us:
Namespace A
|
veth
|
+---------+
|
Linux Bridge
|
+---------+
|
veth
|
Namespace BThis is the foundation of our lab.
A veth pair behaves like a virtual Ethernet cable.
The Linux veth(4) documentation describes veth devices as interconnected pairs: packets transmitted on one endpoint are immediately received by the other.
Conceptually:
veth-a <================> veth-bA bridge is different.
It can connect many Ethernet interfaces:
br0
/ | \
v1 v2 v3Therefore:
veth = virtual cable
bridge = virtual switchThis mental model makes Linux virtual networking much easier to understand.
We will build three isolated Linux network environments:
ns-red
10.10.10.11
|
veth-r
|
veth-r-br
|
|
+-------------+
| |
| br0 |
| |
+-------------+
/ \
veth-b-br veth-g-br
| |
veth-b veth-g
| |
ns-blue ns-green
10.10.10.12 10.10.10.13All three namespaces will belong to:
10.10.10.0/24Our Linux host will act as the virtual switch.
Before creating anything, inspect the host:
ip -br linkThen:
ip -br addrCheck existing bridges:
ip link show type bridgeThe ip-link(8) documentation supports bridge as a Linux link type and provides the interface used to create and configure bridge devices.
Never assume that br0 is unused on a production machine.
Virtualization software such as KVM, libvirt, Docker, LXD, or other platforms may already have created bridges.
Create RED:
sudo ip netns add ns-redCreate BLUE:
sudo ip netns add ns-blueCreate GREEN:
sudo ip netns add ns-greenVerify:
ip netns listYou should see:
ns-red
ns-blue
ns-greenBring loopback up inside each namespace:
sudo ip netns exec ns-red ip link set lo up
sudo ip netns exec ns-blue ip link set lo up
sudo ip netns exec ns-green ip link set lo upWe now have three isolated network stacks.
Create:
sudo ip link add br0 type bridgeBring it up:
sudo ip link set br0 upVerify:
ip link show br0You can also list all bridge devices:
ip link show type bridgeAt this stage:
Linux Host
|
br0exists, but no ports are connected to it.
Create:
sudo ip link add veth-r-br type veth peer name veth-rConceptually:
veth-r-br <============> veth-rMove the namespace-facing endpoint:
sudo ip link set veth-r netns ns-redThe topology becomes:
Host ns-red
veth-r-br <=============> veth-rNow attach the host endpoint to the bridge:
sudo ip link set veth-r-br master br0Bring it up:
sudo ip link set veth-r-br upInside RED:
sudo ip netns exec ns-red ip link set veth-r upCreate:
sudo ip link add veth-b-br type veth peer name veth-bMove:
sudo ip link set veth-b netns ns-blueAttach:
sudo ip link set veth-b-br master br0Bring up the host side:
sudo ip link set veth-b-br upThen:
sudo ip netns exec ns-blue ip link set veth-b upCreate:
sudo ip link add veth-g-br type veth peer name veth-gMove:
sudo ip link set veth-g netns ns-greenAttach:
sudo ip link set veth-g-br master br0Bring it up:
sudo ip link set veth-g-br upThen:
sudo ip netns exec ns-green ip link set veth-g upNow we have:
br0
/ | \
/ | \
veth-r-br veth-b-br veth-g-br
| | |
veth-r veth-b veth-g
| | |
ns-red ns-blue ns-greenThe bridge ports can be inspected with the bridge utility documented in the official bridge(8) manual.
Run:
bridge link showYou can also use:
ip link show master br0to show interfaces attached to br0.
RED:
sudo ip netns exec ns-red \
ip addr add 10.10.10.11/24 dev veth-rBLUE:
sudo ip netns exec ns-blue \
ip addr add 10.10.10.12/24 dev veth-bGREEN:
sudo ip netns exec ns-green \
ip addr add 10.10.10.13/24 dev veth-gVerify:
sudo ip netns exec ns-red ip -br addrsudo ip netns exec ns-blue ip -br addrsudo ip netns exec ns-green ip -br addrOur virtual LAN is now:
br0
|
10.10.10.0/24 LAN
/ | \
/ | \
10.10.10.11 10.10.10.12 10.10.10.13
RED BLUE GREENNotice that we have not assigned an IP address to br0.
That is intentional.
A Linux bridge does not require an IP address merely to forward Ethernet frames.
From RED:
sudo ip netns exec ns-red \
ping 10.10.10.12The packet path is approximately:
ns-red
↓
veth-r
↓
veth-r-br
↓
br0
↓
veth-b-br
↓
veth-b
↓
ns-blueTest GREEN:
sudo ip netns exec ns-red \
ping 10.10.10.13Then BLUE to GREEN:
sudo ip netns exec ns-blue \
ping 10.10.10.13If all three work, the bridge is successfully switching Ethernet frames between the namespaces.
Ethernet bridges need to know where destination MAC addresses are located.
Suppose RED sends traffic toward BLUE.
Initially, the bridge sees a frame arriving from:
RED MACon:
veth-r-brThe bridge can learn:
RED MAC → veth-r-brWhen BLUE responds:
BLUE MAC → veth-b-brThe bridge gradually builds a forwarding database.
Conceptually:
MAC Address Bridge Port
RED-MAC → veth-r-br
BLUE-MAC → veth-b-br
GREEN-MAC → veth-g-brThis is one of the most important concepts in Ethernet switching.
Linux exposes the forwarding database through the bridge command.
Run:
bridge fdb show br br0The official bridge(8) documentation provides commands for inspecting and manipulating bridge forwarding database entries, VLAN information, multicast databases, and bridge ports.
Generate traffic between all namespaces and inspect the FDB again:
bridge fdb show br br0You should see dynamic MAC entries associated with bridge ports.
This gives you direct evidence of what the bridge has learned.
Do not confuse:
Bridge FDBwith:
ARP / neighbor tableThey solve different problems.
The bridge FDB maps:
MAC address
↓
bridge portThe ARP/neighbor table maps:
IP address
↓
MAC addressFor example:
ARP
10.10.10.12
↓
AA:BB:CC:DD:EE:FFwhile:
FDB
AA:BB:CC:DD:EE:FF
↓
veth-b-brTogether:
IP
↓
MAC
↓
Bridge PortThis distinction becomes extremely valuable during troubleshooting.
From RED:
sudo ip netns exec ns-red ip neighAfter pinging BLUE you might see an entry representing:
10.10.10.12 → BLUE MACCompare with:
bridge fdb show br br0You now have two perspectives:
Namespace:
IP → MAC
Bridge:
MAC → PortIf you’re troubleshooting unusual neighbor behavior on a multi-NIC host, CorgiNetwork’s Linux ARP Flux and Multiple NICs on the Same Subnet explores the ARP side in greater depth.
Run:
sudo tcpdump -eni veth-r-br arpThen clear RED’s neighbor cache:
sudo ip netns exec ns-red ip neigh flush allGenerate:
sudo ip netns exec ns-red \
ping -c 1 10.10.10.12You should see ARP traffic before normal IP communication.
Conceptually:
RED:
Who has 10.10.10.12?
↓
Broadcast Ethernet Frame
↓
br0
↙ ↘
BLUE GREENBLUE responds with its MAC address.
The bridge then gains additional information about the participating endpoints.
Try:
sudo tcpdump -eni br0Then generate:
sudo ip netns exec ns-red ping 10.10.10.12Packet capture helps answer questions such as:
For deeper packet analysis, continue with CorgiNetwork’s Wireshark Explained guide.
Our bridge currently acts only as a Layer 2 switch.
We can make the Linux host itself participate in the virtual LAN.
Assign:
sudo ip addr add 10.10.10.1/24 dev br0Verify:
ip -br addr show br0Now:
Linux Host
10.10.10.1
|
br0
/ | \
/ | \
RED BLUE GREEN
.11 .12 .13Test from RED:
sudo ip netns exec ns-red \
ping 10.10.10.1The host is now another Layer 3 participant on the bridged network.
Suppose a physical interface becomes a bridge port.
A common Linux bridge architecture is:
Physical NIC
↓
br0Once the interface participates as a bridge port, Layer 3 configuration is generally placed on the bridge interface rather than treated as ordinary independent Layer 3 configuration on the enslaved port.
Conceptually:
Wrong mental model:
eth0 → IP
|
br0
Better model:
eth0
|
br0 → IPThis distinction prevents many bridge configuration problems.
Because:
br0 = 10.10.10.1we can configure it as the gateway.
RED:
sudo ip netns exec ns-red \
ip route add default via 10.10.10.1BLUE:
sudo ip netns exec ns-blue \
ip route add default via 10.10.10.1GREEN:
sudo ip netns exec ns-green \
ip route add default via 10.10.10.1Inspect:
sudo ip netns exec ns-red ip routeExpected conceptually:
10.10.10.0/24 dev veth-r
default via 10.10.10.1Now the Linux host can become the Layer 3 gateway for destinations outside the virtual LAN.
Check:
sysctl net.ipv4.ip_forwardFor a lab where the host intentionally operates as a router:
sudo sysctl -w net.ipv4.ip_forward=1The architecture becomes:
Namespaces
↓
br0
↓
Linux Host Routing
↓
Physical Interface
↓
Upstream RouterAt this point we have combined:
Layer 2 bridging
+
Layer 3 routinginside one Linux machine.
Assume the Linux host has an Internet-facing interface such as:
eth0and the upstream router has no route for:
10.10.10.0/24The host may need source NAT.
The conceptual packet path becomes:
ns-red
10.10.10.11
↓
br0
↓
Linux Routing
↓
Firewall/NAT
↓
eth0
↓
InternetBefore changing firewall configuration, inspect the current nftables rules:
sudo nft list rulesetDo not flush an existing production firewall merely to provide namespace connectivity.
If the upstream router already knows:
10.10.10.0/24 via LINUX_HOSTNAT may not be necessary.
Always distinguish routing from NAT.
This is a critical troubleshooting concept.
Traffic from:
RED → BLUEon the same subnet is bridged:
RED
↓
br0
↓
BLUETraffic from:
RED → Internetuses:
RED
↓
br0
↓
Linux IP routing
↓
uplinkTherefore:
Same Layer 2 network
↓
Bridge forwardingwhile:
Different IP network
↓
RoutingDo not troubleshoot both paths as though they were identical.
Ethernet loops can be dangerous.
Consider:
+------ Switch A ------+
| |
| |
+------ Switch B ------+Layer 2 loops can create repeated frame forwarding and broadcast storms.
Linux bridges support Spanning Tree Protocol configuration.
The official ip-link(8) bridge documentation exposes stp_state as a bridge option.
Inspect detailed bridge information:
ip -d link show br0A bridge can be created with STP enabled, for example:
sudo ip link add br1 type bridge stp_state 1Whether STP should be enabled depends on topology.
For a simple isolated lab with no Layer 2 loops, it may not be necessary.
For networks connected to external switching infrastructure, loop prevention must be designed deliberately.
Linux bridges can also be VLAN-aware.
The ip-link bridge configuration includes:
vlan_filteringand the bridge(8) utility provides VLAN management commands.
Conceptually:
br0
VLAN-aware bridge
/ \
Port A Port B
VLAN 10 VLAN 20Inspect:
bridge vlan showA bridge with VLAN filtering can provide virtual switching architectures that would otherwise require several separate bridges.
This is important for:
A dedicated CorgiNetwork article should cover this separately because bridge VLAN filtering deserves a complete end-to-end lab.
Inspect:
bridge link showThe official bridge(8) manual exposes bridge-port configuration including state, learning, flooding, STP-related parameters, hairpin behavior, multicast handling, isolation, and other attributes.
This makes bridge link one of the most important diagnostic commands when a port appears connected but frames do not behave as expected.
Linux bridge ports normally participate in MAC learning.
Conceptually:
Frame enters port 1
Source MAC = AA:AA:AA:AA:AA:AA
Bridge learns:
AA:AA:AA:AA:AA:AA → port 1Later, a frame destined for that MAC can be sent specifically toward port 1 rather than being flooded unnecessarily.
Inspect:
bridge fdb showGenerate traffic:
sudo ip netns exec ns-red ping 10.10.10.12Then inspect again:
bridge fdb show br br0This is a practical way to watch the virtual switch learn.
Suppose the bridge receives a frame for a destination MAC it has not learned.
Conceptually:
Unknown destination MAC
↓
br0
↙ ↓ ↘
port1 port2 port3The bridge may flood the frame to eligible ports.
Once the destination responds and its location is learned:
Destination MAC
↓
Known bridge portfuture traffic can be forwarded more selectively.
Understanding this explains why packet captures sometimes show traffic on several bridge ports during initial communication.
ARP requests use Ethernet broadcast.
Therefore:
RED
↓
ARP request
↓
br0
↙ ↘
BLUE GREENThis is normal.
If broadcast traffic fails to reach another namespace, inspect:
bridge link showand:
tcpdumpbefore modifying IP routes.
The problem may be Layer 2, not Layer 3.
Start with the endpoint.
Check RED:
sudo ip netns exec ns-red ip -br linkThen:
sudo ip netns exec ns-red ip -br addrCheck its route:
sudo ip netns exec ns-red ip routeThen inspect the host-side port:
ip link show veth-r-brCheck bridge membership:
ip link show master br0Then:
bridge link showFinally:
bridge fdb show br br0This progresses logically from:
Endpoint
↓
veth
↓
bridge port
↓
bridge
↓
destinationA common mistake is creating:
veth-r-brbut forgetting:
sudo ip link set veth-r-br master br0Check:
ip link show master br0If the interface is missing, the bridge cannot forward traffic through it.
Check:
ip -br linkand inside the namespace:
sudo ip netns exec ns-red ip -br linkRemember that both ends matter:
veth-r
↕
veth-r-brDo not assume that creating a veth pair automatically completes the network configuration.
From RED:
sudo ip netns exec ns-red ip neighCapture:
sudo tcpdump -eni veth-r-br arpThen:
sudo tcpdump -eni veth-b-br arpGenerate:
sudo ip netns exec ns-red ping 10.10.10.12Ask:
Does ARP leave RED?
Does it reach br0?
Does it reach BLUE?
Does BLUE respond?
Does the response return?This immediately narrows the problem.
Inspect:
bridge fdb show br br0Identify the destination MAC:
sudo ip netns exec ns-red ip neighThen correlate:
IP
↓
MAC
↓
FDB
↓
Bridge PortThis technique is much more powerful than repeatedly running ping.
If:
RED → BLUEworks but:
RED → Internetdoes not, the bridge is probably functioning.
Move the investigation to Layer 3:
sudo ip netns exec ns-red ip routeThen:
sudo ip netns exec ns-red \
ip route get 8.8.8.8Check the gateway:
sudo ip netns exec ns-red ping 10.10.10.1Then host forwarding:
sysctl net.ipv4.ip_forwardThen:
ip routeand:
sudo nft list rulesetThis prevents wasting time troubleshooting a working bridge.
Suppose your Linux host has:
eth0 → ISP A
eth1 → ISP BThe namespace may correctly reach:
br0while the host sends traffic through the wrong external interface.
Check:
ip route get 8.8.8.8Then:
ip ruleand:
ip route show table allIf the wrong NIC is selected, use CorgiNetwork’s Linux Traffic Uses the Wrong Interface guide.
For deliberate multi-table routing, continue with Linux Policy Routing with ip rule and Multiple Routing Tables.
rp_filterBridging itself is Layer 2, but once the host begins routing between the bridge and other networks, reverse-path filtering can become relevant.
For complex multi-homed or asymmetric environments, inspect:
sysctl -a 2>/dev/null | grep '\.rp_filter'Do not disable it blindly.
If asymmetric return paths are involved, use CorgiNetwork’s Linux rp_filter and Asymmetric Routing to understand how strict and loose reverse-path validation affect traffic.
A particularly powerful design is:
Namespace
↓
veth
↓
Linux Bridge
↓
Host Layer 3
↓
ip rule
↓
Custom Routing Table
↓
Selected GatewayFor example:
ns-red
↓
ISP A
ns-blue
↓
ISP BPolicy routing can select the correct uplink based on source address, firewall mark, or other supported policy criteria.
CorgiNetwork’s Linux Policy Routing guide provides the routing-table layer required for this architecture.
On Ubuntu servers, persistent bridge configuration may be managed using Netplan rather than manually running ip commands after every boot.
This becomes especially relevant when combining:
Bridge
+
Multiple physical NICs
+
Multiple gateways
+
Policy routingFor the gateway side of that architecture, see CorgiNetwork’s Netplan Multiple Default Routes and Policy Routing.
A future dedicated guide can cover persistent Netplan bridge configuration separately.
When Linux bridge networking fails, use this order.
ip netns listsudo ip netns exec NAME ip -br linksudo ip netns exec NAME ip -br addrip -br linkip link show type bridgeip link show master br0bridge link showbridge fdb show br br0sudo ip netns exec NAME ip neighsudo tcpdump -eni PORT arpsudo tcpdump -eni PORT icmpsudo ip netns exec NAME ip routeip routeip rule
ip route show table allsudo nft list rulesetThis follows the packet from source to destination instead of guessing.
Namespace A cannot reach Namespace B
|
v
Interface UP?
/ \
NO YES
| |
Bring UP v
Correct IP?
/ \
NO YES
| |
Fix IP v
veth peer UP?
/ \
NO YES
| |
Bring UP v
Attached to br0?
/ \
NO YES
| |
Attach v
Bridge UP?
/ \
NO YES
| |
Bring UP v
ARP crossing?
/ \
NO YES
| |
Debug L2 v
FDB correct?
/ \
NO YES
| |
Debug MAC v
Check
destinationRemove the namespaces:
sudo ip netns del ns-red
sudo ip netns del ns-blue
sudo ip netns del ns-greenDelete the bridge:
sudo ip link del br0Because the veth namespace endpoints are associated with the namespaces, namespace deletion also cleans up the relevant virtual Ethernet pairs.
Verify:
ip netns listThen:
ip link show type bridgeA Linux bridge is a software Ethernet bridge implemented in the Linux networking stack. It connects Ethernet interfaces and forwards frames primarily according to MAC-address information.
No.
A bridge primarily operates at Layer 2 using Ethernet/MAC information.
A router operates at Layer 3 using IP routing decisions.
A Linux host can perform both functions simultaneously.
No.
A namespace creates an isolated networking environment.
A bridge connects Layer 2 endpoints.
They are commonly used together.
A veth pair is a pair of interconnected virtual Ethernet interfaces.
One endpoint can be placed inside a namespace while the other is connected to a Linux bridge.
Not merely to switch Ethernet frames.
Assigning an IP address to the bridge allows the Linux host itself to participate at Layer 3 on that network.
Use:
sudo ip link add br0 type bridge
sudo ip link set br0 upUse:
sudo ip link set INTERFACE master br0Use:
bridge link showor:
ip link show master br0Use:
bridge fdb show br br0The Forwarding Database associates learned MAC addresses with bridge ports so the bridge can make Layer 2 forwarding decisions.
Yes.
Linux bridges support VLAN-aware configurations, including VLAN filtering and per-port VLAN configuration.
Yes.
Linux bridge configuration supports Spanning Tree Protocol settings.
Yes.
Typically the Linux host must provide appropriate Layer 3 routing, firewall forwarding, and either an upstream route or NAT depending on the network architecture.
Linux bridges, network namespaces, and veth pairs form one of the most useful combinations in advanced Linux networking.
A network namespace gives us:
Isolated network stackA veth pair gives us:
Virtual Ethernet cableA Linux bridge gives us:
Virtual Ethernet switchTogether:
Linux Host
br0
/ | \
/ | \
veth veth veth
| | |
Namespace Namespace Namespace
RED BLUE GREENThe official Linux kernel Ethernet Bridge documentation provides the underlying Layer 2 bridge model, while ip-link(8) documents creation and configuration of bridge interfaces and the bridge(8) utility exposes bridge ports, FDB entries, VLAN configuration, multicast information, and other bridge state.
The most important commands from this lab are:
ip link add br0 type bridge
ip link set br0 up
ip link add veth-host type veth peer name veth-ns
ip link set veth-ns netns NAME
ip link set veth-host master br0
bridge link show
bridge fdb show br br0
bridge vlan showBut troubleshooting should always follow the packet.
If traffic never crosses the veth pair, investigate the endpoint.
If ARP reaches the bridge but not another port, investigate Layer 2 bridge state.
If namespace-to-namespace communication works but Internet access fails, investigate routing, forwarding, firewall rules, NAT, and the upstream return path.
For namespace fundamentals, use CorgiNetwork’s Linux Network Namespaces guide.
For multi-homed routing problems, use Linux Traffic Uses the Wrong Interface.
For multiple routing tables, continue with Linux Policy Routing with ip rule and Multiple Routing Tables.
For reverse-path problems, see Linux rp_filter and Asymmetric Routing.
For unusual ARP behavior, see Linux ARP Flux and Multiple NICs on the Same Subnet.
And for persistent Ubuntu multi-gateway configurations, use Netplan Multiple Default Routes and Policy Routing.
This extends the CorgiNetwork advanced networking cluster:
Linux Routing Problems
↓
Multiple Default Routes
↓
ARP Flux
↓
rp_filter / Asymmetric Routing
↓
Policy Routing
↓
VRF
↓
Network Namespaces
↓
veth
↓
Linux Bridge
↓
Bridge FDB / MAC Learning
↓
VLAN-Aware Linux BridgeThe next logical article is Linux Bridge VLAN Filtering Explained: Build a VLAN-Aware Virtual Switch with Network Namespaces, where we can build VLAN 10 and VLAN 20 on a single Linux bridge, configure access and trunk ports, inspect bridge vlan show, and troubleshoot inter-VLAN isolation.
AI Agents as Code: Managing AI Agent Configurations, Prompts and Tools with Git AI agents…
Data Center Power Distribution Architecture: UPS, PDU, Redundancy and Rack Power Explained Data center power…
DNSSEC Troubleshooting: Fix SERVFAIL & DNSKEY Errors DNSSEC Troubleshooting: How to Fix SERVFAIL, DS, DNSKEY…
Terraform State Management Explained: Remote State, Locking, Backends and Best Practices Terraform makes infrastructure reproducible…
RTO vs RPO Explained: Disaster Recovery Objectives, Examples and Planning A disaster recovery plan is…
Network Intrusion Detection Explained: NIDS, Sensors, Signatures and Traffic Analysis A firewall can decide whether…