W3·A1 — The MAC address table

Time: 30 min

Needs: one OL9 Switch + 4 VPCS

GNS3 project: w03-a1-mac-table

Build it

• Drag an Ethernet Switch and 4 VPCS on to the canvas and cable them
• Run the topology and assign address to each PC:

On PC1/ PC2 / PC3 / PC4:

ip 192.168.10.11/24     # .12 / .13 / .14
save

Start a capture on PC4 cable.

On PC1:

ping 192.168.10.12

What just happened

• PC1 starts by sending an ARP broadcast which everyone sees, including PC4.
  • Everyone processes the broadcast, but only one, PC2, answers
• The ICMP packet is then sent unicast to PC2, and to no one else. How did the switch know where PC2 is located?
• In Wireshark, select the ICMP packet and click on the Ethernet row in the details pane. The frame consists of the source MAC address, destination MAC address and a type (what the frame is carrying).
• In Wireshark, select the ARP packet and click on the Ethernet row in the details pane. In addition to the aforementioned fields, there is some padding and the FCS.
  • Ethernet requires a minimum size of 64 bytes.
  • The frame headers themselves cost 14 bytes (6 for each MAC address, and 2 for the type), plus FCS's 4 bytes.
  • The ARP payload is too small to satisfy the minimum size requirement, so Ethernet pads the remaining bytes with zeros.
• That, in a nutshell, is what an Ethernet frame is. Layer 2 devices (switch, NIC) only process frames and never read the payload content.

Do this

• Start by importing the OL9 Switch appliance.
• Delete SW1 and replace it with an OL9 Switch 1.0, renaming it SW1. Then re-cable the 4 VPCS.
• Configure the bridge

Log on to SW1 as root, then:

nmcli con add type bridge con-name br0 ifname br0 connection.autoconnect-slaves 1
nmcli con mod br0 ipv4.method disabled ipv6.method disabled

for i in eth0 eth1 eth2 eth3; do
    nmcli con add type bridge-slave ifname $i con-name port-$i master br0
done

nmcli con up br0

bridge link show

Predict first

1. Before any traffic, how many entries are in the bridge's table? _______
2. After PC1 pings PC2, what does the bridge know (i.e. whose address is in its table)? _______
3. Which packet taught the switch where PC2 is — PC1's request or PC2's reply? _______

Do this — collect the MACs first

Run show ip on each VPCS and record its MAC. Without these, the MAC table will be unreadable.

Do this — read the table

• First, ensure PC1 can ping the other three

On SW1, flush the MAC table:

bridge fdb flush dev br0

Read the table:

bridge fdb | grep -v permanent

We're ignoring entries marked as "permanent" since these are the bridge's own port addresses, not learned ones.

On PC1:

clear arp
ping 192.168.10.12 -c 1

And immediately on SW1, show the MAC table again.

What just happened

• Two entries, and only two: PC1's MAC on eth0, PC2's on eth1 (verify them against your own table recorded earlier). Notice that PC3 and PC4 are absent from the table for now.
  • a bridge learns from the source address of frames that arrive, and forwards on the destination.
  • PC2 entry came from PC2's reply, not from PC1 request. The request taught it only about PC1.

Do this — watch it forget

Entries in a bridge's MAC table have an expiry date. Ageing is in centiseconds, so 30 seconds is 3000. The default is 30000

On SW1:

ip link set dev br0 type bridge ageing_time 1000

Then ping from PC1 and read the table. The entries should disappear after 10 seconds.

Put it back: ip link set dev br0 type bridge ageing_time 30000.

What just happened

• The dynamic entries vanished on their own. Nothing deleted them and nothing went wrong.
• A MAC table is a cache and caches expire. What this means is that nothing the switch knows is correct forever; it is only recently correct. Also, a switch that has been idle knows nothing. There is a parallel to be made with ARP caches. The general idea is that networks are dynamic and the discovery mechanisms reflect this.
• There is a balancing act is choosing the right ageing time: too short and the switch floods constantly; too long and it keeps sending frames to the wrong port.

Do this — move a host

With ageing back at 300 s:

• ping from PC4 so the switch learns it. Then swap PC4 and PC3
• without sending any traffic from it - check the table. Then ping from PC4 and check again.

What just happened

• The entry still named the old port, and would have until it aged out. A switch cannot detect a move; it can only be told by sending traffic through it.
• The switch is constantly updating its table on every arriving frame. That's why PC4 arriving frame corrected its entry instantly.

Record

If it went wrong