[openstack-dev] [neutron][taas] Problem receiving mirrored ingress traffic and a solution suggestion
anil.rao at gigamon.com
Thu Apr 14 18:12:23 UTC 2016
We are aware of this problem. The main issue is that packets entering br-int from br-ex aren’t tagged with a VLAN id (unlike packets entering br-int from br-tun). Since our overall design is meant to support multi-node production environments we have to consider the packets coming in from br-tun. Your suggested fix might suffice for a single-node DevStack environment but I don’t think it is generic enough to support the multi-node situation.
We are looking into this and hope to come up with a fix that works for both cases. We’ll keep you updated.
From: Simhon Doctori שמחון דוקטורי [mailto:simhond at gmail.com]
Sent: Wednesday, April 13, 2016 12:56 AM
To: openstack-dev at lists.openstack.org
Cc: yossi barshishat יוסי ברששת
Subject: [openstack-dev] [neutron][taas] Problem receiving mirrored ingress traffic and a solution suggestion
Anil and all Hi,
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 https://bugs.launchpad.net/tap-as-a-service/+bug/1544176.
I am using Liberty, ovs 2.0.2, Devstack, Single node.
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:
cookie=0x0, duration=59625.138s, table=0, n_packets=0, n_bytes=0, idle_age=59625, priority=20,dl_vlan=3,dl_dst=fa:16:3e:d3:60:16 actions=NORMAL,mod_vlan_vid:3901,output:11
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:
cookie=0x0, duration=20.422s, table=0, n_packets=42, n_bytes=3460, idle_age=1, priority=20,dl_dst=fa:16:3e:d3:60:16 actions=output:14,mod_vlan_vid:3901,output:11
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev