Open Stack

Hi Maxiao:


I think the flow is not updated by rarp, as I didn't capture any packet related to rarp. please check attachment.
Because it is live migration, the memory data of vm will be retained(arp cache, etc.), it would keep normal communication. 
So I think ovs will update the flow in br-tun in both network node and compute node by mac address of packets sent from vm migrated.
 
------------------ Original ------------------
From:  "Xiao Ma (xima2)"<xima2 at cisco.com>;
Date:  Thu, Feb 18, 2016 11:44 AM
To:  "康敬亭"<jingting at unitedstack.com>; 
Cc:  "openstack-dev"<openstack-dev at lists.openstack.org>; 
Subject:  Re: [openstack-dev] [neutron] [ovs] How to update flows inbr-tunproactively

 
 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)
 马啸
 SDN Architect & OpenStack specialist
 Hybrid Cloud 
 Cisco System (China)
 Mobile: (+86) 18911219332
 
 
 
 
 
 
 
   在 2016年2月18日，上午11:13，康敬亭 <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>;
 Date:  Wed, Feb 17, 2016 07:10 PM
 To:  "OpenStack Development Mailing List (not for usage questions)"<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)
 马啸
 SDN Architect & OpenStack specialist
 Hybrid Cloud 
 Cisco System (China)
 Mobile: (+86) 18911219332
 
 
 
 
 
 
 
   在 2016年2月17日，下午3:57，康敬亭 <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?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/2b29ac95/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: migration_pcap.jpg
Type: application/octet-stream
Size: 533841 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/2b29ac95/attachment-0001.obj>