How a switch learns
Start with the simplest possible switch: one bridge, with all four ports in it. Give pc1 and pc2 addresses in 10.10.0.0/24, and pc3 an address in 10.20.0.0/24. There's no router yet.
A new switch knows nothing: its MAC address table (on Linux, the forwarding database or FDB) is empty. It learns by watching source addresses. Whenever a frame arrives on a port, the switch notes "this MAC address is reachable through this port."
Watch what happens when pc1 pings pc2:
- pc1 knows pc2's IP address but not its MAC address, so it sends an ARP request to the broadcast address
ff:ff:ff:ff:ff:ff: "who has 10.10.0.12?" The switch learns pc1's MAC on eth1, and floods the broadcast out of every other port, because broadcasts are for everyone. - pc2 answers directly to pc1. The switch learns pc2's MAC on eth2, and already knows where pc1 is, so the answer goes only to eth1.
- The pings themselves are unicast frames between two known MAC addresses, so they only go between eth1 and eth2.
A capture on pc3 proves it: pc3 sees the ARP broadcast (it's in the same broadcast domain), and nothing else. Afterwards the MAC table holds pc1, pc2, and R1's MAC (R1 is booting on eth4 and has sent a frame or two).
Now try pc3. It's plugged into the same switch, in the same broadcast domain, but it can't reach pc1: Network is unreachable. pc3's address is in 10.20.0.0/24, pc1 is in 10.10.0.0/24, so pc3 would need a gateway, and it doesn't have one. Being on the same switch doesn't put you on the same IP network.
# A plain learning switch: one bridge, every port a member, no VLANs yet.
ip link add br0 type bridge
for port in eth1 eth2 eth3 eth4; do
ip link set "$port" master br0
ip link set "$port" up
done
ip link set br0 up- Line 2: A bridge: Linux's switch.
- Lines 3–6: Every port joins it.
- Line 7: Switch on.
# pc1 and pc2 share a subnet; pc3 is in a different one, on the same switch.
ip netns exec pc1 ip addr add 10.10.0.11/24 dev eth0
ip netns exec pc2 ip addr add 10.10.0.12/24 dev eth0
ip netns exec pc3 ip addr add 10.20.0.13/24 dev eth0- Lines 2–3: pc1 and pc2: same subnet.
- Line 4: pc3: a different subnet, same switch.
root@sw1:~# bridge link
11: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
12: eth2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
13: eth3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
14: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
root@sw1:~# bridge fdb show br br0 | grep -v permanent- Lines 2–5: Each port is a member of br0, forwarding.
- Line 6: The MAC table: empty.
root@pc1:~# ip -br addr show eth0
eth0@if11 UP 10.10.0.11/24
root@pc1:~# ping -c 2 10.10.0.12
PING 10.10.0.12 (10.10.0.12) 56(84) bytes of data.
64 bytes from 10.10.0.12: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 10.10.0.12: icmp_seq=2 ttl=64 time=0.028 ms
--- 10.10.0.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1021ms
rtt min/avg/max/mdev = 0.028/0.032/0.037/0.004 ms
root@pc3:~# timeout 8 tcpdump -lnei eth0 -c 4
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
05:23:40.762209 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.0.12 tell 10.10.0.11, length 28
1 packet captured
1 packet received by filter
0 packets dropped by kernel
root@sw1:~# bridge fdb show br br0 | grep -v permanent
02:00:00:00:00:01 dev eth1 master br0
02:00:00:00:00:02 dev eth2 master br0
52:54:00:01:00:01 dev eth4 master br0- Lines 3–10: pc1 reaches pc2.
- Line 14: All pc3 sees: pc1's ARP broadcast to ff:ff:ff:ff:ff:ff. The pings themselves never reach pc3.
- Line 20: pc1's MAC, learnt on eth1…
- Line 21: …pc2's on eth2…
- Line 22: …and R1's, on eth4.
root@pc3:~# ip -br addr show eth0
eth0@if13 UP 10.20.0.13/24
root@pc3:~# ping -c 2 10.10.0.11
ping: connect: Network is unreachable- Line 2: In a /24 that isn't pc1's
- Line 4: No route to 10.10.0.0/24 and no gateway.
Check your understanding
Why did pc3 see pc1's ARP request but not its pings to pc2?
- ARP requests are broadcasts, which are flooded to every port; the pings were unicast to a MAC address the switch had already learnt
- pc3 was in a different VLAN
- pc3 was in a different subnet
- The capture started too late