Hiya 
Here’s the scenario:
I have a network interface which is a mirror/SPAN. That interface is part of a bridge, let’s call it br-span
Testing it: tcpdump on both the physical interface and br-span interface outputs the expecting data
I want to create a container that will consume data for that br-span interface. I add the br-span device as a nic of type brige.
tcpdump in the container on that nic device does not show the mirrored trafic.
Anything i’m not doing right ?
It would be helpful if you showed the actual commands you ran, because when you talk about the “br-span interface” it’s not clear what type of interface you’re describing and how you created it, or indeed what kind of bridge you’re using (linux native? ovs?) Similarly, when you talk about “a network interface which is a mirror/SPAN” I can only guess that you mean you have a physical network interface which is connected to a mirror/SPAN port on a physical switch.
When you create a container attached to a bridge, incus will create a new interface and connect that to the bridge. You’ll see it if you compare the output of bridge list when the container is stopped and running, and also in incus info <container>.
However, there is no “mirror” functionality on native Linux bridges that I’m aware of. That means that incoming packets are not going to be flooded to that port, unless they have a destination MAC address which the bridge doesn’t know, in which case it follows the flood flag:
flood on or flood off
Controls whether unicast traffic for which there is no FDB entry will be flooded towards this
given port. By default this flag is on.
But as soon as the bridge has learned which port that MAC address is on (by seeing a frame with that MAC address as the source) then it will no longer flood.
There’s an article about mirroring on bridges here. If you’re not using openvswitch then it gets very tricky very quickly.
Totally,
Here are the requested informations
Here is the bridge information
root@hive:/home/derek# brctl show br-span
bridge name bridge id STP enabled interfaces
br-span 8000.a6498XXXXX no enxc0335XXXXXX
veth86XXXXX
the enx… interface is the physical interface connected to a span port on the switch
The veth… interface is the interface of the container trying to consume data from the span.
As I was saying, tcpdump -i enxc... show the data
Same thing for tcpdump -i br-span
But the interface (veth…) inside the container does not.
brctl setageing br-span 0
made it working
Thanks @raby 
That’s as expected.
Because of the switch mirror port, there are lots of frames arriving at the bridge (therefore tcpdump -i br-span will show them). But the bridge does MAC address learning. If it has seen the destination MAC address before, as the source MAC address on some other port, it associates that MAC address with that port and will only forward frames out of that port. The Linux software bridge has no “mirror port” functionality where it will forward a copy of all frames to a specific port.
Beware that brctl setageing br-span 0 turns off all learning functionality, so it behaves like a hub - all frames received on any port are forwarded out of all other ports.
In the case where I want to use a span/mirror port to analyze network traffic using different tools / containers, I guess this is the expected outcome 
Thanks !
Therefore, what options are there to make available the traffic of a network interface to a process running in a container? Perhaps something like this? Virtual networking 101: bridging the gap to understanding TAP