Can netdata map docker container networks of type macvlan?

[tkarls]

I have docker containers with several interfaces attached. Some internal docker networks (driver bridge) and some attached to macvlans (driver macvlan).

The internal networks appear under each container in the dashboard as they should. But the macvlan interfaces do not.
Instead I have a buch of them under the network section in the dashboard. These interfaces start with br-

Is it possible to map also these macvlan interfaces under the correct container instead?

[ilyam8]

Hey, @tkarls. My understanding of macvlan is pretty basic: I think it is not possible, because N containers can share a macvlan interface, it doesn't always belong to a specific container.

[tkarls]

Hi @ilyam8
Sorry for late reply, it got drowned in my inbox :)

Hmm, I see.

It's true that several containers can be connected to one macvlan network.

However, each container attached to a macvlan network behave as if it is directly connected to the outside using its own PHY with its own MAC address and all. So traffic is immediately routed to the correct container based on MAC very early in the kernel network stack. Two containers cannot share this imaginary "PHY" device as I understand it.

I was therefore hoping that this "device" in the container could be inspected directly. But now when looking closer into my config and all the virtual interfaces I cannot seem to find any visible connection on the host.

Example:
If I run ip a inside the container I can get:

812: eth2@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:06:0b brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.6.11/24 brd 192.168.6.255 scope global eth2

ip a on the host then reveal that if2 is:

2: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:3d:c8:e6 brd ff:ff:ff:ff:ff:ff
altname enp2s1
inet 192.168.6.10/24 brd 192.168.6.255 scope global noprefixroute lan

it may be possible to monitor the device from inside the container namespace, but it doesn't seem to be a "connection" on the host unique to each container as it does with the standard bridge interfaces.

[ilyam8]

but it doesn't seem to be a "connection" on the host unique to each container as it does with the standard bridge interfaces

Yes. For mapping a veth interface (the host network namespace) to the container's interface we do the following:

• find all double-linked interfaces in the host ns (iflink != ifindex).
• find a process PID running inside the container
• switch to the network ns of the PID.
• find all double-linked interfaces in the container's net ns (iflink != ifindex).
• find host net ns interfaces with host.ifindex == container.iflink && container.ifindex == host.iflink => these host interfaces mapped to the container.