[ovs-discuss] Help with OVS flows for mirroring packets
mm6021 at att.com
Tue Dec 3 18:11:32 UTC 2019
We are working on OVS-DPDK mirroring without overlay. We are using Openstack which populate the flows to accomplish this when there is overlay. However we have need to make mirroring work with provider vlan network/no overlay. We are seeking some help to discuss any possible way to transport a mirrored stream of packet on a vlan provider network to a vprobe VM (on same provider network) where the source VM and the vprobe VMs exist on different computes.
Current neutron port mirroring plugin<https://review.opendev.org/gitweb?p=x%2Ftap-as-a-service.git;a=summary> uses vxlan overlay tunnels to achieve packet mirroring for vxlan tenant networks. We need to do the similar for vlan provider networks
· It uses specially generated ids (taas_id) for each mirroring service, which is then used as tunnelling ids in the mirrored packets across computes.
· At source compute, taas_id is copied to the mirrored packets’ tunnelling id via flows in br-tun
· On the destination compute side, there are flows in br-tun which match the packets with that specific tunnelling_id and forwards them to br-tap (a new bridge introduced by taas) instead of br-int for normal packets
· br-tap forwards those packets to br-int and then there are flows in br-int which match the taas_id and based on that forward those mirrored packets to destination port. Please note that the final routing is done based on taas-id rather than dest MAC. So mirrored packets remain intact from source to dest.
# Add flow(s) in br-int
# Add flow(s) in br-tap
actions="output:%s" % str(patch_tap_int_id))
# Add flow(s) in br-tun
for tunnel_type in ovs_consts.TUNNEL_NETWORK_TYPES:
We are trying to find some way to achieve this without having to modify the packet’s dest MAC (basically keeping the mirrored payload packet intact) and get this delivered to vprobe VM across another compute.
If we are able to define right flows for this then we can code that into TaaS.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss