Sorry for multiple email.

Even we can add a "pre-up sleep 5" to the secondary interfaces. This will
make sure that the always other interface should come up first.
This  workaround is also working fine in your setup and should be fairly
simple to implement in our provisioning code

Thanks and Regards,
Chhandak 

auto p1p2
iface p1p2 inet manual
    down ip addr flush dev p1p2
    bond-master bond0


auto p1p1
iface p1p1 inet manual
    down ip addr flush dev p1p1
    bond-master bond0
    pre-up sleep 5


auto bond0
iface bond0 inet manual
    pre-up ifconfig bond0 up
    post-down ifconfig bond0 down
    bond-slaves none
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit_hash_policy layer3+4


 


On 6/10/15, 12:15 AM, "Chhandak Mukherjee" <email address hidden> wrote:

>Hi Amit,
>
>We can recreate the problem in your setup.
>
>It is known problem in ubuntu 14.04 :
>https://bugs.launchpad.net/ubuntu/+source/ifenslave/+bug/1288196
>
>Followed similar workaround suggested. Added hwaddress in bond config
>which will make sure the consistency of bond mac.
>
>With this change tried restarting network multiple time and never hit the
>problem. 
>
>We should able to push the same through our provisioning script. Leaving
>that open for further discussion.
>
>For now you should not hit the problem with the workaround.
>
>Thanks and Regards,
>Chhandak 
>
>
>
>On 5/13/15, 3:04 AM, "amit surana" <email address hidden> wrote:
>
>>Private bug reported:
>>
>>R2.20 build 13 Ubuntu 14.0.4.
>>
>>
>>Flapping a bond interface can cause its MAC address to change. Other
>>services that rely on this MAC address, should also be restarted so
>>that they can attach to the new MAC address. Details below.
>>
>>
>>Consider a case where the controller/compute node is connected to the IP
>>fabric via a 2 interface bond (LAG). The bond assumes the mac address of
>>one of the slave interfaces (usually the first one that comes up).
>>
>>On the compute, the vhost0 interface also gets assigned the same MAC
>>address as that of the bond interface. This MAC address is also used by
>>keepalived/haproxy as the MAC address corresponding to the VIP.
>>
>>Now, if the bond interface flaps (networking service was restarted for
>>instance) and the MAC address of the bond interface changes to that of a
>>different slave interface, it is seen that vhost0 interface still points
>>to the old MAC and this breaks all the connectivity to the compute. As
>>far as the KA/HAproxy is concerned, though the services are running, the
>>VIP isn't owned by any of the nodes, and so this functionality also
>>breaks.
>>
>>The above scenario was simulated on the solution testbed by having the
>>fab script add a static route to all the nodes on a working cluster.
>>After adding the static route the fab add_static_route script restarts
>>the networking service;  this flaps the bond interface and causes the
>>MAC address of the bond interface to change, which in turn leads to the
>>above noted issues.
>>
>>If vrouter/keepalive services are restarted, the issue is resolved.
>>
>>
>>bond0     Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>vhost0    Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>
>>==restart networking==
>>
>>bond0     Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>vhost0    Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>
>>** Affects: juniperopenstack
>>     Importance: High
>>         Status: New
>>
>>** Affects: juniperopenstack/r2.20
>>     Importance: High
>>         Status: New
>>
>>** Affects: juniperopenstack/trunk
>>     Importance: High
>>         Status: New
>>
>>** Also affects: juniperopenstack/r2.20
>>   Importance: Undecided
>>       Status: New
>>
>>** Also affects: juniperopenstack/trunk
>>   Importance: High
>>       Status: New
>>
>>** Changed in: juniperopenstack/r2.20
>>   Importance: Undecided => High
>>
>>** Changed in: juniperopenstack/r2.20
>>    Milestone: None => r2.20-fcs
>>
>>** Changed in: juniperopenstack/trunk
>>    Milestone: r2.20-fcs => r2.30-fcs
>>
>>** Description changed:
>>
>>- Consider a case where the controller/compute node is connected to the
>>IP
>>- fabric via a 2 interface bond (LAG). The bond assumes the mac address
>>of
>>- one of the slave interfaces (usually the first one that comes up).
>>+ R2.20 build 13 Ubuntu 14.0.4.
>>+ 
>>+ 
>>+ Flapping a bond interface can cause its MAC address to change. Other
>>+ services that rely on this MAC address, should also be restarted so
>>+ that they can attach to the new MAC address. Details below.
>>+ 
>>+ 
>>+ Consider a case where the controller/compute node is connected to the
>>IP fabric via a 2 interface bond (LAG). The bond assumes the mac address
>>of one of the slave interfaces (usually the first one that comes up).
>>  
>>  On the compute, the vhost0 interface also gets assigned the same MAC
>>  address as that of the bond interface. This MAC address is also used by
>>  keepalived/haproxy as the MAC address corresponding to the VIP.
>>  
>>  Now, if the bond interface flaps (networking service was restarted for
>>  instance) and the MAC address of the bond interface changes to that of
>>a
>>  different slave interface, it is seen that vhost0 interface still
>>points
>>  to the old MAC and this breaks all the connectivity to the compute. As
>>  far as the KA/HAproxy is concerned, though the services are running,
>>the
>>  VIP isn't owned by any of the nodes, and so this functionality also
>>  breaks.
>>  
>>  The above scenario was simulated on the solution testbed by having the
>>  fab script add a static route to all the nodes on a working cluster.
>>  After adding the static route the fab add_static_route script restarts
>>- the networking service;  this flaps the bond interface and caused the
>>- MAC address of the bond interface to change, which in turn lead to the
>>+ the networking service;  this flaps the bond interface and causes the
>>+ MAC address of the bond interface to change, which in turn leads to the
>>  above noted issues.
>>  
>>- If vrouter/keepalive services are restarted, the issue is resolved -
>>- which points towards a potential solution.
>>+ If vrouter/keepalive services are restarted, the issue is resolved.
>>  
>>  
>>- bond0     Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>- em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>- em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>- vhost0    Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>+ bond0     Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>+ em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>+ em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>+ vhost0    Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>  
>>  ==restart networking==
>>  
>>  bond0     Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>- em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>- em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>+ em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>+ em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>  vhost0    Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>
>>-- 
>>You received this bug notification because you are a member of Contrail
>>Systems engineering, which is subscribed to Juniper Openstack.
>>https://bugs.launchpad.net/bugs/1454420
>>
>>Title:
>>  [R2.20] Bond interface flap can break haproxy/vrouter networking
>>
>>Status in Juniper Openstack distribution:
>>  New
>>Status in Juniper Openstack r2.20 series:
>>  New
>>Status in Juniper Openstack trunk series:
>>  New
>>
>>Bug description:
>>  R2.20 build 13 Ubuntu 14.0.4.
>>
>>  
>>  Flapping a bond interface can cause its MAC address to change. Other
>>  services that rely on this MAC address, should also be restarted so
>>  that they can attach to the new MAC address. Details below.
>>
>>  
>>  Consider a case where the controller/compute node is connected to the
>>IP fabric via a 2 interface bond (LAG). The bond assumes the mac address
>>of one of the slave interfaces (usually the first one that comes up).
>>
>>  On the compute, the vhost0 interface also gets assigned the same MAC
>>  address as that of the bond interface. This MAC address is also used
>>  by keepalived/haproxy as the MAC address corresponding to the VIP.
>>
>>  Now, if the bond interface flaps (networking service was restarted for
>>  instance) and the MAC address of the bond interface changes to that of
>>  a different slave interface, it is seen that vhost0 interface still
>>  points to the old MAC and this breaks all the connectivity to the
>>  compute. As far as the KA/HAproxy is concerned, though the services
>>  are running, the VIP isn't owned by any of the nodes, and so this
>>  functionality also breaks.
>>
>>  The above scenario was simulated on the solution testbed by having the
>>  fab script add a static route to all the nodes on a working cluster.
>>  After adding the static route the fab add_static_route script restarts
>>  the networking service;  this flaps the bond interface and causes the
>>  MAC address of the bond interface to change, which in turn leads to
>>  the above noted issues.
>>
>>  If vrouter/keepalive services are restarted, the issue is resolved.
>>
>>  
>>  bond0     Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>  em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>  em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>  vhost0    Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>
>>  ==restart networking==
>>
>>  bond0     Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>  em1       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>  em2       Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8b
>>  vhost0    Link encap:Ethernet  HWaddr 08:9e:01:d9:27:8a
>>
>>To manage notifications about this bug go to:
>>https://bugs.launchpad.net/juniperopenstack/+bug/1454420/+subscriptions
>