How to Inspect and Manage Link-Layer Multicast Addresses in Linux Using ip maddress

In modern computer networking, multicast transmission delivers IP packets to a group of interested hosts simultaneously without flooding unconcerned endpoints or burdening network switches with redundant unicast replicas. While standard unicast IP administration involves tools like ip addr and ip route, multicast operates across two coordinated layers: Layer 3 (IP multicast groups such as 224.0.0.1 or ff02::1) and Layer 2 (Ethernet MAC-level multicast addresses, such as 01:00:5e:xx:xx:xx for IPv4 and 33:33:xx:xx:xx:xx for IPv6).

To inspect and manipulate the kernel’s active link-layer multicast membership tables, Linux administrators use the ip maddress subsystem provided by the modern iproute2 suite. In this tutorial, you will learn how to audit active multicast group memberships, add and delete static link-layer multicast MAC addresses, and troubleshoot network appliances and cluster nodes running on Linux.

Understanding Multicast Filtering and Link-Layer Addressing

When an application subscribes to a multicast IP stream—such as PTP (Precision Time Protocol), OSPF routing hellos, mDNS service discovery (Avahi/Bonjour), or high-availability cluster heartbeat protocols like Corosync—the Linux kernel must instruct the physical Network Interface Card (NIC) hardware to accept incoming Ethernet frames directed to that multicast MAC address.

Modern Ethernet cards implement hardware-level multicast hash filtering tables. If a packet arrives with a destination MAC address not present in the NIC’s multicast filter list, the hardware discards the frame before passing it to the CPU, saving processor cycles. The ip maddress utility allows you to inspect what the kernel and NIC have registered in this filter, and manually force interfaces to join specific multicast MAC groups when running testing or custom packet sniffing tools.

Step 1: Listing Active Multicast Addresses Across All Interfaces

To display all link-layer multicast addresses currently registered across all active network interfaces on your Linux host, execute:

ip maddress show

You can also abbreviate the command to ip maddr or ip maddress.

The console output organizes information by interface index and device name:

1:  lo
    inet  224.0.0.1
    inet6 ff02::1
    inet6 ff01::1
2:  eth0
    link  01:00:5e:00:00:fb
    link  01:00:5e:00:00:01
    link  33:33:00:00:00:01
    link  33:33:ff:12:34:56
    inet  224.0.0.251
    inet  224.0.0.1
    inet6 ff02::fb
    inet6 ff02::1:ff12:3456
    inet6 ff02::1

Key elements of this report include:

• inet 224.0.0.1: The standard “all hosts” IPv4 multicast group.
• inet 224.0.0.251 and link 01:00:5e:00:00:fb: The mDNS (Multicast DNS) group used by local service resolution engines.
• inet6 ff02::1 and link 33:33:00:00:00:01: The IPv6 “all nodes” link-local multicast group.
• link 33:33:ff:...: The Solicited-Node multicast address required by IPv6 Neighbour Discovery (NDP).

Step 2: Inspecting Multicast Addresses for a Specific Interface

If your system contains numerous virtual ethernet pairs, bridges, or VLANs, filter the output directly by specifying the target device:

ip maddress show dev eth0

Step 3: Manually Adding a Static Link-Layer Multicast Address

In specialised industrial environments, high-frequency financial trading systems, or custom telemetry testing scenarios, an appliance may broadcast non-IP or raw Ethernet frames using a proprietary multicast MAC address. If the host NIC does not have promiscuous mode enabled, the hardware will silently drop these frames.

You can instruct the Linux kernel and network card to accept a specific multicast MAC address using ip maddress add:

sudo ip maddress add 01:00:5e:01:02:03 dev eth0

After executing this command, verify that the entry has been appended to the link table:

ip maddress show dev eth0

You will now see link 01:00:5e:01:02:03 listed under the active device. The NIC hardware will now capture and pass these frames into the network stack without requiring the interface to be placed into full promiscuous mode.

Step 4: Deleting a Static Multicast MAC Address

When testing is concluded or when an interface should no longer process an auxiliary multicast group, delete the entry using ip maddress del:

sudo ip maddress del 01:00:5e:01:02:03 dev eth0

Confirm the deletion with ip maddress show dev eth0. The address will be removed from the link-layer hardware filter immediately.

Monitoring Multicast Sockets and Network Traffic

While ip maddress inspects the link-layer hardware registrations, you can correlate these entries with higher-layer protocols using complementary Linux utilities:

• Reviewing IP-Level Group Memberships (/proc/net/igmp): To see which processes and IP sockets have joined IGMP groups, inspect the kernel proc filesystem:

  cat /proc/net/igmp
  cat /proc/net/igmp6

• Capturing Multicast Packets with tcpdump: To monitor raw multicast traffic transiting the wire, run tcpdump filtering for multicast destination addresses:

  sudo tcpdump -ni eth0 multicast

Troubleshooting Common Multicast Issues in Linux

• NIC Hash Collisions (Multicast Over-Reception): Standard Ethernet hardware filters often use 64-bucket or 512-bucket CRC hash tables rather than exact MAC matches. When a host joins many multicast groups, hash collisions may occur, causing the card to accept frames for groups the host did not join. The Linux kernel discards these non-matching frames in software, but heavy multicast streams may cause elevated softirq CPU usage.
• Reverse Path Forwarding (rp_filter) Dropping Multicast Packets: Linux kernel rp_filter settings frequently block incoming multicast traffic if symmetric routing is not detected. If multicast UDP datagrams are dropped, adjust the sysctl reverse path filter:

  sudo sysctl -w net.ipv4.conf.eth0.rp_filter=2

  A value of 2 (loose mode) allows multicast packets arriving from valid subnets to pass inspection.
• Cannot Delete System-Assigned Multicast Groups: Attempting to run ip maddress del against kernel-managed addresses—such as 01:00:5e:00:00:01 (All Hosts) or 33:33:00:00:00:01—will be rejected by the netlink subsystem, as these are mandatory for IPv4 ARP and IPv6 core stack operation.

Frequently Asked Questions

What is the difference between ip maddress and ip mroute?

ip maddress manages local link-layer and IP multicast memberships on host interfaces (determining which multicast packets this specific machine receives). In contrast, ip mroute manages multicast routing tables used by Linux routers to forward multicast packets between different subnets using protocols like PIM-SM.

Can I add IPv3 or IPv4 multicast IP addresses directly with ip maddress?

The ip maddress add command is engineered specifically to configure link-layer (MAC) addresses. IP multicast memberships (IGMP/MLD) are normally managed automatically by user-space applications binding to multicast sockets via the IP_ADD_MEMBERSHIP socket option.

Do changes made via ip maddress persist across system reboots?

No. Entries created via ip maddress add exist only in kernel memory and the active NIC registers. If you require permanent static multicast MAC bindings, append the ip maddress add command to a systemd startup unit or network-up script.

Does enabling promiscuous mode disable the need for ip maddress?

Promiscuous mode instructs the network card to accept all packets regardless of destination MAC, effectively bypassing the multicast hardware filter. However, promiscuous mode places a heavy interrupt burden on the host CPU. Using ip maddress allows targeted multicast packet acceptance while keeping the NIC in efficient filtering mode.