Arista EOS MAC Address Table: Show Commands and Aging

When a host "is on the wrong port" or traffic to a quiet server suddenly floods, the Arista EOS MAC address table (FDB) is where the truth lives: which MAC was learned on which VLAN and port, whether it is dynamic or static, and how long since it moved. Two platform facts frame every FDB problem: EOS ages dynamic MACs after 300 seconds by default, while the ARP timeout runs 4 hours - so a quiet host can lose its MAC-to-port mapping while its IP-to-MAC entry persists, producing intermittent "unreachable" behavior. This guide covers the essential show mac address-table commands, aging/static management, and the common failure modes.

Reading the MAC Address Table

The base command prints the forwarding database exactly as the hardware has it programmed:

switch# show mac address-table
Mac Address Table
------------------------------------------------------------------
Vlan    Mac Address       Type        Ports      Moves   Last Move
----    ------------      ----        -----      -----   ---------
10      0000.0000.0001    DYNAMIC     Po67       1       0:00:56 ago
10      0011.2233.4455    DYNAMIC     Ethernet3  0       0:04:11 ago
20      4455.6677.8899    DYNAMIC     Vxlan1     3       0:00:02 ago
99      0c00.0f00.0001    STATIC      Ethernet49 0       never
Total Mac Addresses for this criterion: 4

Each column answers a specific troubleshooting question, so it pays to read them deliberately rather than scanning for a MAC:

• Vlan - the broadcast domain the frame was received in, not the VLAN the host "should" be in. A MAC showing up under an unexpected VLAN almost always means a trunk/native-VLAN mismatch upstream.
• Mac Address - the 12-hex-digit, three-group (H.H.H) format EOS displays. Note that EOS is case-insensitive on input, so aaaa.bbbb.cccc and AAAA.BBBB.CCCC address the same entry.
• Type - DYNAMIC (learned from a source MAC, subject to aging), STATIC (manually configured, never ages, survives reload), or SECURE (installed by port security).
• Ports - the physical port (Ethernet3), a port-channel (Po67), a VXLAN tunnel interface (Vxlan1 for EVPN-learned remote MACs), or a peer-link-facing interface on an MLAG pair.
• Moves - how many times the entry has moved between ports during its lifetime in the table. A non-zero, growing counter is the single most useful signal that something is wrong.
• Last Move - age of the most recent move. Combined with Moves, it tells you whether flapping is current or historical.

Purpose-built queries let you ask the switch a narrower question instead of grepping a full dump:

show mac address-table vlan 10
show mac address-table address aaaa.bbbb.cccc
show mac address-table interface Ethernet1
show mac address-table dynamic
show mac address-table static
show mac address-table | include <mac-or-port>
show mac address-table | grep -i 4455

The Moves/Last Move columns are gold for troubleshooting: a MAC that keeps moving between two ports (or shows a high move count) indicates a loop, a bridge misconfiguration or two devices sharing one MAC.

Counts, Capacity and Per-VLAN Views

Before hunting individual entries, get the shape of the table. show mac address-table count reports how many entries exist in total and breaks them down by type; run it per VLAN to find which broadcast domain is consuming the hardware table:

switch# show mac address-table count
Mac Address Entries
Total Mac Addresses:        1432
Total Dynamic Addresses:    1388
Total Static Addresses:     44

switch# show mac address-table count vlan 10
switch# show mac address-table learning

Scale symptoms are easy to misdiagnose: if the L2 table fills, the switch stops learning new source MACs and starts flooding unknown unicast, which looks exactly like a broken VLAN or an ARP problem. A table that sits at some suspiciously round number (8192, 16384, 32768) and never grows beyond it is a capacity limit, not a forwarding bug - see the hardware section below.

Dynamic Entries, Aging and the FDB/ARP Gap

• Dynamic entries are learned from source MACs and age out (default 300 s on EOS). A host that sends nothing for 5 minutes is removed from the table; the switch then floods its unicast traffic until the host sends again - which matters for servers with aggressive power-saving NICs.
• The ARP cache on the router/host side can still point at the same IP for hours (4-hour ARP timeout is common), so from the host's perspective nothing changed while the switch no longer knows where the MAC lives. Cross-check show ip arp <IP> against show mac address-table address <MAC> when "endpoint location" seems wrong.
• Change aging globally with mac address-table aging-time <seconds> (and disable with 0 only deliberately - entries then never expire until the table fills).

The FDB/ARP asymmetry is the root cause behind a whole class of tickets. Consider a NAS that serves backups once a day and is otherwise silent. Its MAC ages out after 300 seconds; its ARP entry persists for four hours; the L3 switch therefore still forwards the IP packet, but it now floods the frame to every port in the VLAN. If the VLAN is large, that flooded frame reaches hundreds of ports before the reply arrives and re-learns the MAC. Raising aging to 900-1800 seconds on access switches that serve bursty or quiet endpoints is a legitimate tuning step; the cost is slower convergence when a MAC genuinely moves, because the stale entry lingers and the switch keeps sending frames to its old port until it expires (or the new source frame triggers a move, which refreshes it immediately).

Inspect the current value and per-interface learning state with:

show mac address-table aging-time
show interfaces Ethernet3 mac address-table

Limit Learning Per Interface and Per VLAN

A single misbehaving host or a mirror port can flood the table with thousands of bogus source MACs (a MAC-flooding attack, or simply a virtualization host stuck in a loop). Two controls help:

switch(config)# mac address-table learning vlan 20
switch(config)# no mac address-table learning vlan 999
switch(config-if)# switchport port-security
switch(config-if)# switchport port-security maximum 4
switch(config-if)# switchport port-security violation protect
switch(config-if)# switchport port-security mac-address sticky

Disabling learning on a VLAN forces the switch to flood everything in it - useful for a transit or BGP-only VLAN that carries no endpoints, dangerous elsewhere. Port security caps the number of MACs per port and, with sticky learning, converts learned addresses into SECURE entries in the same table you are already reading. Remember that SECURE entries are not dynamic and will not age out, so a port-security maximum that is too low starts dropping legitimate traffic as soon as a host behind a mini-switch or hypervisor appears with extra MACs.

Static and Blackhole Entries

Static entries are the manual override. They are pinned to a port, never age, and survive reloads - which makes them ideal for a handful of infrastructure MACs and harmful when used broadly, because a misconfigured static entry silently blackholes an endpoint even after it moves:

switch(config)# mac address-table static aaaa.bbbb.cccc vlan 10 interface Ethernet1
switch(config)# mac address-table static dead.beef.0001 vlan 10 drop
switch(config)# mac address-table aging-time 600
switch# clear mac address-table dynamic        ! flush learned entries
switch# clear mac address-table dynamic interface Ethernet1
switch# clear mac address-table dynamic address aaaa.bbbb.cccc
switch# clear mac address-table dynamic vlan 10

A static entry with the drop keyword is a blackhole: frames destined to that MAC are discarded rather than flooded. That is the correct way to quarantine a MAC that is being spoofed, and it is much safer than disabling learning on the whole VLAN.

Static entries survive reboots and are unaffected by aging - use them sparingly for infrastructure MACs (or for security, where Cisco's equivalent tooling is port security/sticky MAC, covered in our Cisco port security guide). Clearing the dynamic table is the standard move after moving a cable or fixing a loop: it forces re-learning and drops stale forwarding state immediately.

Where the Table Actually Lives: Hardware Limits

On Arista switches the FDB is not a software list - it is programmed into merchant-silicon L2 tables (the Trident, Tomahawk and Jericho families). That has three consequences worth knowing:

• The table is finite. Entry capacity depends on the chip and the forwarding profile: a fixed half of the available L2 hardware slots, with the rest reserved for routes, tunnels, ACLs and MPLS labels. When the hardware table is full, new MACs simply cannot be programmed - no error is logged on every frame, and forwarding degrades to flooding.
• Aging frees hardware slots. Lowering the aging timer is the fastest way to reclaim capacity in a table that has filled from a MAC flood or a badly behaved hypervisor host.
• EVPN/VXLAN MACs share the same table. Remote MACs learned over VXLAN appear as entries on the Vxlan1 interface and occupy hardware slots too, so a large L2 EVPN domain can exhaust a table that looked generously sized for a single site.

Exact capacity and current utilisation are platform-specific; consult the Arista EOS User Manual for MAC address tables for your hardware family and use show platform family commands on the specific platform to read hardware table depth.

Troubleshooting Scenarios

• MAC missing on the expected switch: it aged out (host silent > 300 s) or moved - check show mac address-table address across the path and the ARP table for the IP.
• MAC flapping between ports: look for an L2 loop or two switches bridging the same segment; the Moves counter quantifies it. Ninety percent of the time the culprit is a second uplink that was supposed to be blocked by STP but is forwarding, or a host with two NICs cabled into the same VLAN.
• Traffic flooding to all ports: the destination MAC is not in the FDB (aged out, or the host is behind a different VLAN than expected - verify with show vlan and the VLAN/SVI configuration guide).
• MAC on a port-channel: the port column shows PoNN - the MAC learned through the bundle, confirming the port-channel/LACP config carries that VLAN.
• MAC learned on the peer-link after an MLAG change: entries pointing at the peer-link interface instead of a member port usually mean the MLAG peer link is up but the member link failed over - check the peer-link state and dual-primary conditions in our MLAG troubleshooting guide.
• Two hosts fighting over one MAC: two entries in the same VLAN with a high Moves count between two access ports means duplicate MAC addresses (cloned VM, or a random MAC reused after a snapshot restore). Locate both ports, then fix the address on one host rather than chasing the switch.

A Repeatable Verification Workflow

When an "endpoint location" complaint arrives, work top-down and let the table tell you the layer:

show ip arp 10.10.10.44                    ! IP -> MAC
show mac address-table address 0000.0000.0001   ! MAC -> port and VLAN
show mac address-table interface Ethernet3      ! what else lives on that port
show mac address-table count vlan 10            ! is the VLAN consuming the table
show interfaces Ethernet3 status                ! port up/errdisabled
show vlan 10                                     ! is the port even a member
show mac address-table move update              ! MAC move notifications

Read in that order, the sequence separates the problem cleanly: if ARP resolves but the MAC entry is absent, you are looking at an aging or learning issue; if the MAC exists on the wrong port, you are looking at a loop, a cabling change or duplicate addresses; and if the MAC exists on the right port but traffic still fails, the problem is above Layer 2. Before blaming the switch, always confirm the physical layer first - an errdisabled or half-configured trunk port produces exactly the same "MAC not learned" symptom as a software fault, but takes ten seconds to rule out.

原文链接：https://netdata.cloud/guides/network/network-fdb-mac-staleness · Arista EOS User Manual: MAC Address Tables