Sorry ignore my previous post, I’m getting confused with the IP scheme.
So to summarise:
host ens6f0: 10.50.1.129/25 - you can see packets arriving from 10.50.1.10 on this nic to 10.50.5.1.
host ens6f1: 10.50.1.1/25 - you can see packets arriving from 10.50.1.10 on this nic to 10.50.5.129.
ct data0: 10.50.5.1/16 (parent ens6f0)
ct data1: 10.50.5.129/16 (parent ens6f1)
target *: 10.50.1.10
Because you can see streams arriving to the host on both NICs to the IPs of the container’s macvlan interfaces, this suggests to me that MACVLAN is working OK (at least inbound), because if it wasn’t then ARP resolution wouldn’t have taken place and those packets wouldn’t arrive at the host.
You should be able to get tcpdump or tshark working inside the containers.
I’m impressed with tshark it works in the container. I can see both streams of data, so definitely not a macvlan problem. I now need to work out why I can’t listen to the stream on data0, I can only listen on data1.
I finally found the answer. By default Ubuntu enables a reverse packet filter which drops all packets from a remote host that the machine has no reverse route to. This is to mitigate against denial of service attacks. In my case the problem can be solved by either disabling the filter or creating a valid reverse route. The full details are here:
