Furkan İkkan Türkçe
Back to posts
Post

· Network & System Administrator

How to Control Linux Bridge MAC Table Ageing Time with brctl setageing

Learn how to adjust bridge FDB ageing time using brctl setageing to manage MAC table flush frequency and improve ARP cache stability in Linux networks.

NetworkbridgeARPLinuxbrctl

In my environment, I often see ARP instability pop up on Linux bridges when virtual machines or containers move frequently between hosts. The bridge MAC table starts filling with stale entries, and the ageing time controls how long those entries stick around before being flushed. If it's too low, you get constant relearning and ARP storms; too high, and you risk blackholing traffic after a VM migration. I use brctl setageing to tune this value directly, and it's one of the first knobs I reach for when debugging flapping ARP issues on bridged networks.

Checking Current Bridge Ageing Time

Before changing anything, I always check the current setting. You can see the ageing time for a bridge with brctl show:

brctl show

This outputs something like:

bridge name     bridge id               STP enabled     interfaces
br0             8000.001122334455       yes             eth0
                                                             vnet0
                                                             vnet1

But brctl show doesn't display the ageing time directly. For that, I check the sysfs entry under /sys/class/net/br0/bridge/ageing_time:

cat /sys/class/net/br0/bridge/ageing_time

This returns the value in centiseconds (hundredths of a second). The default is usually 300, which means 30 seconds. If I see frequent MAC flaps in the logs, I might lower this to age out entries faster.

Setting a New Ageing Time with brctl setageing

To change the ageing time, I use brctl setageing <bridge> <time_in_centiseconds>. For example, to set it to 10 seconds (1000 centiseconds):

brctl setageing br0 1000

After running this, I verify the change:

cat /sys/class/net/br0/bridge/ageing_time

It should now return 1000. This change takes effect immediately — no restart needed. I've found that on busy Proxmox or KVM hosts with live migration, dropping the ageing time to 10-15 seconds helps reduce ARP confusion during failover.

Why Ageing Time Affects ARP Cache Stability

You might wonder why a bridge MAC table setting impacts ARP. It's indirect but real. When the bridge ages out a MAC entry too quickly, it floods the next frame for that MAC to all ports. If the device has moved, the ARP reply might come from an unexpected place, causing the host to update its ARP cache incorrectly. Conversely, if the entry lives too long, frames keep going to the old port after a VM migration, leading to packet loss until the entry finally expires.

In my tuning process, I pair brctl setageing with net.ipv4.conf.<interface>.arp_announce settings. I set arp_announce to 2 (only announce from the best local interface) to prevent ARP flapping when multiple IPs are configured on a bridge. As I mentioned before in my post on DSCP marking for VoIP, small kernel tweaks like this often have outsized effects on stability.

Practical Values I Use in Production

Here’s what I’ve settled on after trial and error:

  • Default (300 centiseconds / 30s): Too slow for dynamic VM environments
  • 100-150 (1-1.5s): Useful for testing, but too noisy in production
  • 300-600 (3-6s): My usual starting point for stable bridged networks
  • 1000 (10s): Good for frequent live migration workloads

I never go below 100 unless I'm debugging a specific flapping issue — otherwise, the bridge floods too much and hurts performance.

Verifying the Effect

After changing the ageing time, I monitor two things:

  1. MAC table dynamics: watch -n 1 'brctl showmacs br0'
  2. ARP cache behavior: watch -n 1 'arp -n | grep <target_ip>'

If I see MAC addresses bouncing in and out too fast, I increase the time. If ARP entries keep updating after a VM moves, I might lower it slightly or check arp_announce and arp_ignore settings.

Warning: Don’t Confuse with ARP Garbage Collection

It’s easy to mix up bridge ageing time with ARP cache timers. They’re separate. The ARP cache lives in /proc/sys/net/ipv4/neigh/<device>/gc_stale_time and related settings. I’ve seen admins tweak those hoping to fix bridge-related ARP issues, but it doesn’t touch the bridge FDB. Always verify which layer you’re adjusting.

Final Thoughts

Controlling bridge FDB ageing time with brctl setageing isn’t glamorous, but it’s a precise tool for stabilizing ARP in virtualized environments. I treat it like tuning a shock absorber — small adjustments prevent bigger oscillations. When combined with proper arp_announce values and monitoring, it’s helped me cut down on mysterious packet drops after failover events.

If you're seeing ARP instability on Linux bridges, start by checking the ageing time. It’s one of those low-level knobs that doesn’t get much attention, but in the right scenario, it makes a real difference.

Cover image: USDAgov · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/41284017@N08/52287992217