[openstack-dev] [neutron] [ovs] How to update flows inbr-tun proactively

Xiao Ma (xima2) xima2 at cisco.com
Thu Feb 18 03:44:26 UTC 2016


Hi, JingTing

Normally , when the vm is migrated to destination compute node, the rarp will be send by qemu, and the flow tables of other nodes will be caused to be updated by rarp.
This is done immediately after the vm is migrated to destination node, then rarps will be received by other nodes, the flows learned will be updated quickly, the problem should not exist.

So I think the focus is whether the rarps has been received by other nodes.If not received by other nodes, the problem maybe the ovs-agent config the vlan and vxlan flow tables too slowly.


Xiao Ma (xima2 at cisco.com<mailto:xima2 at cisco.com>)
马啸
SDN Architect & OpenStack specialist
Hybrid Cloud
Cisco System (China)
Mobile: (+86) 18911219332




在 2016年2月18日,上午11:13,康敬亭 <jingting at unitedstack.com<mailto:jingting at unitedstack.com>> 写道:

Hi Maxiao:

Thanks for your reply.
This flow indeed been updated, when ovs receive any packets sent from migrated vm. The flow in table10(br-tun) is used to learn the mac address, and put the learned flow into table20. It just takes longer to complete.
And is there any way to update the flow faster? thanks!

jingting
From:  "Xiao Ma (xima2)"<xima2 at cisco.com<mailto:xima2 at cisco.com>>;
Date:  Wed, Feb 17, 2016 07:10 PM
To:  "OpenStack Development Mailing List (not for usage questions)"<openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>;
Subject:  Re: [openstack-dev] [neutron] [ovs] How to update flows inbr-tun proactively

Hi, JingTing

The flow should be updated after the rarp broadcast packet be send by qemu.
So I think you should make sure whether the broadcast packet has been send and received by the host.


Best regards,

Xiao Ma (xima2 at cisco.com<mailto:xima2 at cisco.com>)
马啸
SDN Architect & OpenStack specialist
Hybrid Cloud
Cisco System (China)
Mobile: (+86) 18911219332




在 2016年2月17日,下午3:57,康敬亭 <jingting at unitedstack.com<mailto:jingting at unitedstack.com>> 写道:

Hi guys:

The bug has be reported on https://bugs.launchpad.net/neutron/+bug/1541738

The flow in br-tun as below is generated by learning flow, and not updated immediately after vm live migration.

Original flow:
cookie=0x0, duration=194.884s, table=20, n_packets=0, n_bytes=0, hard_timeout=300, idle_age=194, priority=1,vlan_tci=0x0306/0x0fff,dl_dst=5a:c6:4f:34:61:06 actions=load:0->NXM_OF_VLAN_TCI[],load:0x1ef->NXM_NX_TUN_ID[],output:24

Updated flow:
cookie=0x0, duration=194.884s, table=20, n_packets=0, n_bytes=0, hard_timeout=300, idle_age=194, priority=1,vlan_tci=0x0306/0x0fff,dl_dst=5a:c6:4f:34:61:06 actions=load:0->NXM_OF_VLAN_TCI[],load:0x1ef->NXM_NX_TUN_ID[],output:26

Anyone has idea how to update this flow proactively.thanks!

jingting
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/1fe33ebb/attachment.html>


More information about the OpenStack-dev mailing list