Hi,
We am seeing a behavior that we are unable to work around when using VLAN
tagged ports inside an OVS bridge.
Environment: The 'br-int' bridge in an OpenStack Compute node, where OVS is
managed by the Neutron OVS agent.
Our aim is to mirror (unicast) packets moving from OVS toward a VM instance's
vNIC. To detect such packets, we have added flows which comprise of the
following:
dl_vlan==<port-vlan-id>, dl_dst=<port_mac_addr>
As per the OpenStack Neutron implementation:
1. Each virtual network is assigned a host-local VLAN id.
2. The MAC address of a port is unique within the scope of the virtual
network it belongs to.
What we are seeing is the following:
1. Traffic originating from outside the host that is destined to the port
in question matches the rule above.
The packets have the expected VLAN tag.
2. Traffic originating from inside the host but from a port not in the
same virtual network (and consequently having a different VLAN tag) that is
destined to the port in question matches the rule above.
The packets have the expected VLAN tag.
3. Traffic originating from inside the host but from a port in the same
virtual network (and consequently having the same VLAN tag) that is destined to
the port in question does not match the rule above.
The packets don't appear to have a VLAN tag.
Examining case (3) further, we noticed that packets flowing between ports on
the same host that are tagged with the same VLAN id can be matched by the
following rules:
dl_dst=<port_mac_addr>
or
dl_vlan= 0xffff, dl_dst=<port_mac_addr>
The problem with using either of these latter options is that we end up
breaking OpenStack Neutron's requirement that port MAC addresses are unique to
only a single virtual network.
I was wondering if anyone here could suggest some options that we could pursue
to get around this problem we are seeing.
Note: We are using explicit flows to mirror traffic, instead of OVS's
port-mirroring option, because we intend to support pre-capture filtering and
the OVS port-mirroring feature doesn't support this (at least as far as we
know).
Thanks and kind regards,
Anil
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
