Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Hi Fresher, I have not been investigating this problem since then, but this is what I have done as a workaround (using port mirroring in one direction, and the following for the other one):

Let’s say you have VM-3823:

  1. Search for the interfaces of the VM on controller, and find the related segmentation_id’s of the networks.

    nova show VM-3823 | grep network | awk '{print "neutron net-show " $2}' | sh | grep segmentation

| provider:segmentation_id | 1002 | | provider:segmentation_id | 1003 |

  1. Search OVS rules for these interfaces on compute

    ovs-ofctl dump-flows br-int | grep "1002\|1003"

cookie=0x0, duration=583279.444s, table=0, n_packets=5501839, n_bytes=1517799423, idle_age=0, hard_age=65534, priority=3,in_port=26,dl_vlan=1002 actions=NORMAL cookie=0x0, duration=583279.859s, table=0, n_packets=11027079, n_bytes=1334139221, idle_age=0, hard_age=65534, priority=3,in_port=26,dl_vlan=1003 actions=NORMAL

  1. Create „mirror” port in OVS (simple internal port now, but we will use it for mirroring)

    ovs-vsctl add-port br-int mirror_tap -- set interface mirror_tap type=internal

ip link set dev mirror_tap up

ovs-ofctl show br-int | grep mirror_tap

107(mirror_tap): addr:00:00:00:00:00:00  this is the created openflow port number

  1. Transform the rule printouts to OVS flows e.g. cookie=0x0, duration=583279.444s, table=0, n_packets=5501839, n_bytes=1517799423, idle_age=0, hard_age=65534, priority=3,in_port=26,dl_vlan=1002 actions=NORMAL  the beginning is only stat, not important now, the first highlighted section is the MATCH, and the second one is the ACTION field

So this is how the related OVS rule looks like when it was created:  ovs-ofctl add-flow br-int priority=3,in_port=26,dl_vlan=1002,actions=NORMAL

And this is what we want to create:  ovs-ofctl add-flow br-int priority=3,in_port=26,dl_vlan=1002,actions=output:107,NORMAL

Now it should be safe to run this last command, because OVS will search for matching rules, and modify the rule accordingly... so in our case it will add one more action (to send the traffic to our mirror port as well). So here is the bad thing with this workaround: all traffic on this network will be forwarded to the mirror port, so if we have another interface of the same network on this compute, it makes it difficult to filter... but we can do so at the end by using filters when running tcpdump... 

  1. tcpdump –n –i mirror_tap <filters>

Hi Fresher, I have not been investigating this problem since then, but this is what I have done as a workaround (using port mirroring in one direction, and the following for the other one):

Let’s say you have VM-3823:

  1. Search for the interfaces of the VM on controller, and find the related segmentation_id’s of the networks.

    $ nova show VM-3823 | grep network | awk '{print "neutron net-show " $2}' | sh | grep segmentation

    segmentation | provider:segmentation_id | 1002 | | provider:segmentation_id | 1003 |

| provider:segmentation_id | 1002 | | provider:segmentation_id | 1003 |

  1. Search OVS rules for these interfaces on compute

    $ ovs-ofctl dump-flows br-int | grep "1002\|1003"

"1002\|1003" cookie=0x0, duration=583279.444s, table=0, n_packets=5501839, n_bytes=1517799423, idle_age=0, hard_age=65534, priority=3,in_port=26,dl_vlan=1002 actions=NORMAL cookie=0x0, duration=583279.859s, table=0, n_packets=11027079, n_bytes=1334139221, idle_age=0, hard_age=65534, priority=3,in_port=26,dl_vlan=1003 actions=NORMAL

  1. Create „mirror” port in OVS (simple internal port now, but we will use it for mirroring)

    $ ovs-vsctl add-port br-int mirror_tap -- set interface mirror_tap type=internal

type=internal $ ip link set dev mirror_tap up

up $ ovs-ofctl show br-int | grep mirror_tap

mirror_tap 107(mirror_tap): addr:00:00:00:00:00:00  this is the created openflow port number

  1. Transform the rule printouts to OVS flows e.g. cookie=0x0, duration=583279.444s, table=0, n_packets=5501839, n_bytes=1517799423, idle_age=0, hard_age=65534, priority=3,in_port=26,dl_vlan=1002 actions=NORMAL  the beginning is only stat, not important now, the first highlighted section is the MATCH, and the second one is the ACTION field

So this is how the related OVS rule looks like when it was created: $ ovs-ofctl add-flow br-int priority=3,in_port=26,dl_vlan=1002,actions=NORMAL

And this is what we want to create: $ ovs-ofctl add-flow br-int priority=3,in_port=26,dl_vlan=1002,actions=output:107,NORMAL

Now it should be safe to run this last command, because OVS will search for matching rules, and modify the rule accordingly... so in our case it will add one more action (to send the traffic to our mirror port as well). So here is the bad thing with this workaround: all traffic on this network will be forwarded to the mirror port, so if we have another interface of the same network on this compute, it makes it difficult to filter... but we can do so at the end by using filters when running tcpdump... 

  1. tcpdump –n –i mirror_tap <filters>