How to recognise a Docker container by its MAC address

Short answer: a MAC address beginning 02:42 is consistent with an address generated by Docker for a container network interface. On the usual IPv4 bridge network, the remaining four bytes are the container's IPv4 address written in hexadecimal. But 02:42 is not an IEEE-registered Docker OUI, and the prefix alone cannot prove that a device is a Docker container.

How the 02:42 pattern works

02 marks the address as both unicast and locally administered. That matters because Docker is assigning a software-defined interface; it is not using a globally registered vendor block. 42 is Docker's conventional second byte. For an automatically generated, IPv4-based address, the next four bytes are the interface's four IPv4 octets.

To decode 02:42:ac:11:00:02, ignore 02:42 and convert each remaining hexadecimal byte to decimal:

ac = 172
11 = 17
00 = 0
02 = 2

02:42:ac:11:00:02  →  172.17.0.2

The reverse works too. Convert 10.0.0.7 to hexadecimal (0a:00:00:07) and prepend 02:42, producing 02:42:0a:00:00:07. Moby maintainers describe these as IP-based MAC addresses, used so that MAC and ARP state stay aligned when an IP is recycled; their explanation and an inspect example are in the Moby issue tracker.

How to verify the container

If you can access the Docker host, do not stop at the prefix. Ask Docker for the mapping directly:

docker network inspect bridge

Under Containers, compare each endpoint's MacAddress and IPv4Address. Docker documents the full JSON output and formatting options in the official docker network inspect reference. To check one known container across all of its attached networks:

docker inspect --format '{{range $name, $net := .NetworkSettings.Networks}}{{$name}}  {{$net.MacAddress}}  {{$net.IPAddress}}{{println}}{{end}}' CONTAINER

From inside a Linux container, ip link show displays its interfaces and ip addr show displays their IP addresses. A container may be attached to several networks, so it can have several MAC addresses; there is no single MAC address for the container as a whole.

Why 02:42 is evidence, not identification

• It is locally administered, not a Docker-owned OUI. An IEEE vendor lookup will not identify Docker from 02:42. Anyone can generate the same prefix.
• A custom MAC can be anything. Docker's docker run network options allow an administrator to supply mac-address. A genuine container may therefore have no 02:42 prefix at all.
• The network driver matters. Bridge and overlay endpoints commonly expose Docker-generated addresses, while host networking does not give the container its own network namespace and MAC. Macvlan and ipvlan deliberately behave differently and may expose addresses on the physical network.
• IPv6 does not fit the four-byte shortcut. A 48-bit MAC cannot contain a 128-bit IPv6 address. Treat the decode rule specifically as an IPv4 pattern.
• Old or copied configuration can create exceptions. Persisting an automatically generated MAC while Docker later assigns a different IP can even create duplicate addresses. The MAC-to-IP relationship is a diagnostic clue, not a permanent container identity.

A practical detection rule

1. Normalize the address to six hexadecimal bytes.
2. Check that the first two bytes are 02:42.
3. Decode the last four bytes as IPv4 and ask whether that address belongs to a Docker subnet visible in your route, ARP, capture, or inventory data.
4. When the host is available, confirm the pair with docker network inspect or docker inspect.

Report the result as “likely Docker-generated” until the host-side mapping confirms it. That wording preserves what the pattern is genuinely good at without turning a convention shared by locally administered addresses into a false vendor guarantee.

For the underlying bit test, see how MAC addresses are structured. If an address is locally administered but does not fit Docker's pattern, MAC address randomization explains another common cause.