LLDP between docker containers

[vdasari]

I have created a docker based test setup using docker-compose. My setup has two containers, “lldp1” and “lldp2”. I have installed lldpd in both containers and started the same. I do see that lldp1 is sending LLDP PDUs on eth1, and expect these frames to pop up on eth1 on lldp2. The problem is, I do not see them.

And I expected to see these PDUs appear on another container. I do not see them.

The destination MAC address used for these is an ethernet multicast address of “01:80:c2:00:00:0e”. I am wondering if this MAC-DA is causing packets not to be forwarded to lldp2.

Any insights on how to solve this problem would be helpful.

I am using Docker for MAC: Docker version 17.12.0-ce, build c97c6d6

[sdetweil (Sam)]

this might help understand the issue… UDP and docker are a challenge

Issue: Cannot receive UDP traffic in Docker container in case of UDP server being located at Docker host

[vdasari]

LLDP packets are plain ethernet multicast packets. No IP is involved. I have gone through the link you provided, I am afraid it is not of much help to me.

[sdetweil (Sam)]

udp packets go to the MAC address of the interface.

the actual network adapter is the HOST, with ITS mac address…
the host network driver software is listening for ITS mac address and not any others. (containers)
so a packet comes in, it does not contain the host mac address and is discarded.

you can run the adapter in promiscuous mode, which skips this check, and then all traffic is processed.
but you will never get a production site to allow this on a non debug machine (network traffic analyzer, whos operator is supervised many times)

the virtual machine vendors create a network driver that chains onto the default driver and CAN accept traffic to specific mac addresses… BUT docker doesn’t not work in the VM for the same reason… needs promiscuous mode to accept the dhcp server udp reply

[sdetweil (Sam)]

see this topic which mentioned udp broadcasts

Exposing privileged ports on private network

Hi again, Thank a lot for your answer. I just made a simple test case similar to yours, and you are absolutely right, it does work exactly as expected. Might have something to do with my use case which is a bit special, so there’s probably something else going on that I have to look into, but I don’t want to waste your time helping me with that I should have made that simple test myself before wasting other peoples time here, but thanks a lot. Kind regards, Kasper

[vdasari]

Thanks again.

I believe the issue is with Bridge PDU’s only (01:80:c2:00:00:XX). These are Ethernet standard reserved PDU MAC addresses.

I used mausezahn to generate packets from container lldp1 to lldp2.

All following packets(whose destination addresses are set with -b option) from lldp1 are received on lldp2.

mz eth1 -d 25msec -t ip -b 00:00:c2:00:00:0e -c 20
mz eth1 -d 25msec -t ip -b ff:ff:ff:ff:ff:ff -c 20
mz eth1 -d 25msec -t ip -b 01:00:c2:00:00:0e -c 20

But the following one has failed
mz eth1 -d 25msec -t ip -b 01:80:c2:00:00:0e -c 20

As you can see, second byte is the only difference between the failed stream(01:80:c2:00:00:0e) and successful(01:81:c2:00:00:0e) stream.

So, bridge code is eating away these PDUs.

[vdasari]

Logged this as an issue in at docker/libnetwork, Issue 2062

---

Ok. Here is to fix on Mac.

This is how my bridges look like, docker_network_lldp_1 is the bridge that needs to forward LLDP frames.

$ docker network ls
NETWORK ID          NAME                      DRIVER              SCOPE
e59b848ee8b4        bridge                    bridge              local
1ce10f319e38        docker_default_lldp_net   bridge              local
56432715dc36        docker_network_lldp_1     bridge              local
e595f359303c        host                      host                local
e6f4c55b2245        none                      null                local

This is how we can get to the Docker VM and fix the bridge setting.

$ docker run -it --privileged --pid=host --rm debian nsenter -t 1 -m -u -n -i sh
/ # brctl show
bridge name bridge id       STP enabled interfaces
docker0     8000.0242578fc103   no      veth6aac176
br-1ce10f319e38     8000.024272d19cef   no      veth0a19755
                            veth7956be4
br-56432715dc36     8000.0242219661af   no      veth7ae38ef
                            veth6c38433
/ # echo 16384 > /sys/class/net/br-56432715dc36/bridge/group_fwd_mask

After executing above command, I started seeing LLDP frames exchanged properly.

Still, I believe it would be good to have some kind of interface to control this property(of providing a wire-like connectivity between containers, where all kinds of packets are exchanged) or make this property enabled by default.