Skip to content

W3·A2 — Ethernet broadcast

Time: 30 min

Needs: A1's topology, with PC1 replaced by an OL9 PC ·

GNS3 project: w03-a1-mac-table (continue in it)

Info

Times listed are approximate and provided as timing guidelines only. Take as much time as you need to complete the activity.

Question

What does a switch do with a frame whose destination it does not know?

Adjust the topology

Replace PC1 with an OL9 PC node renamed PC1.

Log on to PC1 as admin, then: 

sudo nmcli con mod 'System eth0` con-name eth0
sudo nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.11/24
sudo nmcli con up eth0

ping -c1 192.168.10.12

Do this — force a broadcast

On PC1: 

ip neigh replace 192.168.10.12 lladdr <PC2-MAC> dev eth0 nud permanent
ip neigh show

On SW1: 

bridge fdb del <PC2-MAC> dev eth1 master
bridge fdb show br br0 | grep -v permanent

Start a capture on the PC3↔SW1 link. Then on PC1:

ping -c1 192.168.10.12

Read the capture. Then run the ping a second time and read it again.

What just happened

  • PC3 saw the packet, yet this was not a broadcast:
    • Look at the destination address. It is PC2's real address, not ff:ff:ff:ff:ff:ff.
    • PC3 received a frame addressed to somebody else.
    • There was no reply from PC3. It ignored the frame since it was not the intended recipient
  • This is called flooding. The switch did not know where to send the frame, so it sent it out of every port except the port it came from.
  • By the time the second ping arrive, the switch knew where PC2 was, so it sent it there directly. PC3 saw nothing.

Summary

Broadcast Unknown-unicast
Destination MAC ff:ff:ff:ff:ff:ff a real host's address
Why it floods the address means "everyone" the switch does not know where to send the frame
Stops when never — always floods the switch learns that MAC
Who processes it every host one host; the rest discard

Do this — Clean up

On PC1: 

ip neigh del 192.168.10.12 dev eth0

On SW1: 

bridge fdb flush dev br0
bridge fdb | grep -v permanent

Do this - Send a real broadcast

Replace the remaining three VPCS with OL9 PC nodes, rename them accordingly, then re-cable.

Assign the same addresses as before.

By default Linux ignores broadcast pings. Turn that off on our recipients:

# on PC2, PC3 and PC4
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

Start a capture on PC4's link. Then on PC1:

ping -b -c2 192.168.10.255

What just happened

  • The broadcast domain is the set of hosts that answer a broadcast, which is a fancy way of saying the entire network. Each one of our three recipients received the broadcast, processed it and answered. Contract that to the flooding scenario.
  • Power off one of the recipients and do the ping again. The switch will still forward the frame regardless of whether anything is listening.
  • The switch's job is to forward the frames. That's all Layer 2 does. What the recipients do with the frame is their business.
    • if we had kept the icmp_echo_ignore_broadcasts default, one one would have answered the broadcast. The switch doesn't care either way.

Why did we use L2 broadcast address?

255.255.255.255 is Layer 2 broadcast address, i.e. works only within the same link. In contrast, 192.168.10.255 is Layer 3 broadcast (more on this in week 4).

To ping 255.255.255.255, you have to tell the kernel which interface to use:

ping -b -I eth0 255.255.255.255

Record

value
Destination MAC of the flooded frame
Destination MAC of broadcast frame
What stopped the flooding
What stops a real broadcast

If it went wrong

Symptom Cause Fix
ARP frames still appear static entry not applied ip neigh show — the line must read PERMANENT
ping -b refuses you must be root use sudo or log in as root
Zero replies to broadcast frame icmp_echo_ignore_broadcasts still 1 sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0 on the recipients