Hello. > The br0 interface is just another port to the switch. Since traffic > is flowing between two VMs, no traffic will be directed to other > interfaces. It would make more sense to run tcpdump on either the > interfaces connected to VMs or the mirror target.
Jesse, thanks for your reply. With your suggestion, I manage to configure br0 as mirror port as well. Now I am up to comparing the packet capture rates between capturing from a mirror (br0) and capturing directly from one of the tap interfaces. The problem is, although my actual test environment only consists of two virtual machines, there can be more in other cases - and I need to capture the packets from all of them. ;-) > Data isn't copied during packet forwarding. If you mirror a port it > copies the packet metadata and adds a reference. So the performance impact should be rather small when a mirror port? I'm really curious what my performance measurements will show. ;-) While looking into the source to understand how an incoming frame is processed I noticed that you have changed the integration into the Linux network subsystem. As I can see ovs placed its own function (netdev_port_receive) as callback function for br_handle_frame_hook. But as it seems this has been changed for kernels > 2.6.36. Sorry, I don't see how you grab the frames now. Could you please give me a hint what has changed? What reasons lead to this change? Was it only the be able to load the native bridge module at the same time? Thanks for your help! Daniel _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org