<div dir="ltr"><div><div><div><div>Anil and all Hi,<br><br></div>Continuing the discussion from the IRC about the problem with the mirrored traffic incoming to a VM not being mirrored. Indeed, it does look like the bug mentioned on <a href="https://bugs.launchpad.net/tap-as-a-service/+bug/1544176">https://bugs.launchpad.net/tap-as-a-service/+bug/1544176</a>.<br></div><div>I am using Liberty, ovs 2.0.2, Devstack, Single node.<br></div><div><br>As I mentioned, the problem is due to a rule match including the vlan tag. Since the VM port is receiving data, after the ovs stripped the vlan of the virtual network, there is no reason for doing match on a vlan, this rule does not have any hits:<br><br><i>cookie=0x0, duration=59625.138s, table=0, n_packets=0, n_bytes=0, idle_age=59625, priority=20<b>,dl_vlan=3</b>,dl_dst=fa:16:3e:d3:60:16 actions=NORMAL,mod_vlan_vid:3901,output:11</i><br><br></div><div>IMHO, the solution should be a rule where there is no vlan in match AND an action where output port is the destination port. Since you already have a match of a destination mac, why not output it to the destination vm interface, together with the patch-int-tap interface? This rule works for me:<br></div><br><i>cookie=0x0, duration=20.422s, table=0, <b>n_packets=42</b>, n_bytes=3460, idle_age=1, priority=20,dl_dst=fa:16:3e:d3:60:16 actions=<b>output:14</b>,mod_vlan_vid:3901,<b>output:11</b></i><br><br></div>As you can see, there is no vlan in match, and two output ports - 14 for the vm interface, and 11 for the patch interface together with the vlan.<br><br>Simhon Doctori<br></div>imVision Technologies.<br></div>