Manage Link-Layer Multicast Addresses with ip maddress

People expect ip maddress to join an IPv4 or IPv6 multicast group, and it does not. It manages link-layer multicast addresses, one level down from where applications actually subscribe. A program that needs a protocol group still has to join it through its own socket API.

This guide inspects an interface's multicast addresses, attaches one static link-layer multicast address, and removes it again. Allow about ten minutes. You need the iproute2 package, a real interface name, and root for changes. Checked against iproute2 6.1.0, package version 6.1.0-1ubuntu6.4.

1. Find the interface name

Use ip -brief link to find the interface that should receive the multicast traffic. Read-only inspection normally needs no elevated privilege:

$ ip -brief link
lo               UNKNOWN        00:00:00:00:00:00
enp0s31f6        UP             90:1b:0e:da:cc:ef
docker0          UP             42:88:f8:b7:5e:86

Swap enp0s31f6 below for the interface that actually belongs to your network. Do not lift a name from an old config file, predictable names differ between machines, and a bridge, container veth or wireless interface can behave differently from the physical interface you meant.

2. Inspect the current entries

Show everything ip knows about:

$ ip maddress show

Narrow it to one interface with dev:

$ ip maddress show dev enp0s31f6
2: enp0s31f6
    link  33:33:00:00:00:01
    link  01:00:5e:00:00:01
    inet  224.0.0.1
    inet6 ff02::1

The list depends on the interface, its addresses, and whatever services use it. inet and inet6 lines are protocol multicast memberships reported alongside the link-layer entries; the link lines are the static or kernel-managed link-layer addresses this command actually deals with.

Checkpoint: record this output for the target device before changing anything. It is how you confirm a later deletion removed only what you added.

3. Add one static link-layer address

Adding an address changes the interface's receive filter and needs elevated privileges. This example uses 01:00:5e:00:00:fb, an Ethernet multicast MAC in the IPv4 multicast range:

$ sudo ip maddress add 01:00:5e:00:00:fb dev enp0s31f6

Success is normally silent. This is a real network change, not a harmless label: packets sent to that link-layer destination can now reach the interface. Check it immediately:

$ ip maddress show dev enp0s31f6 | grep -F '01:00:5e:00:00:fb'
    link  01:00:5e:00:00:fb

Use an address your network design assigned, not this one copied blindly. The command accepts a link-layer multicast address, it does not derive one from an IP group, validate your protocol, or make a service actually listen.

4. Remove the address you added

Remove the exact address from the exact device once the test or service no longer needs it:

$ sudo ip maddress del 01:00:5e:00:00:fb dev enp0s31f6
$ ip maddress show dev enp0s31f6 | grep -F '01:00:5e:00:00:fb' || echo 'address is absent'
address is absent

Warning: only undo an address that was your addition. Do not delete an entry just because it looks unfamiliar, another service, a bridge, IPv6 neighbour discovery or a network manager may depend on it. Compare the before and after output and remove only the address and device pair you own.

These are generally runtime changes. A network manager, container runtime or interface restart can restore its own entries or quietly discard your manual one. If the address needs to survive reboot, put the equivalent operation in the system's normal network configuration and treat that as the source of truth.

Common traps

• Device cannot be found. Usually a wrong or renamed interface, or one that has disappeared. Re-run ip -brief link and check for renames, bridges and container lifetimes.
• Operation not permitted. The shell lacks the capability to change link configuration. Use sudo on the specific command only, after confirming the target.
• Address already exists on add. Inspect it instead of repeatedly adding it. Duplicate attempts do not create a protocol multicast subscription.
• Address missing on delete. It may already have been removed by an interface restart or another network manager. Refresh the device-specific listing before deciding what to do.
• Wrong tool for the job. This is not a substitute for an application's multicast join. For a protocol group, configure the application or its socket options, then confirm with packet capture or application logs. Reach for ip maddress only when the requirement specifically names a static link-layer multicast filter entry.

Done means

• Real interface selected from current ip -brief link output.
• Before listing saved with ip maddress show dev NAME.
• sudo used only for the add or delete that changes network state.
• Address verified immediately after adding it.
• Only your own address removed, or the runtime change recorded for the system's network configuration.
• Layers kept separate: static link-layer filtering versus application-level multicast group membership.