| 2016-05-24 11:16:59 |
Rossella Sblendido |
bug |
|
|
added bug |
| 2016-05-24 11:17:46 |
Rossella Sblendido |
neutron: importance |
Undecided |
High |
|
| 2016-05-24 11:17:53 |
Rossella Sblendido |
neutron: assignee |
|
Rossella Sblendido (rossella-o) |
|
| 2016-05-24 11:30:12 |
B. A. |
bug |
|
|
added subscriber B. A. |
| 2016-05-24 14:45:04 |
Carl Baldwin |
neutron: assignee |
Rossella Sblendido (rossella-o) |
Swaminathan Vasudevan (swaminathan-vasudevan) |
|
| 2016-06-08 15:25:52 |
Swaminathan Vasudevan |
tags |
|
l3-dvr-backlog |
|
| 2016-06-09 09:52:51 |
OpenStack Infra |
neutron: status |
New |
In Progress |
|
| 2016-06-09 09:52:51 |
OpenStack Infra |
neutron: assignee |
Swaminathan Vasudevan (swaminathan-vasudevan) |
Rossella Sblendido (rossella-o) |
|
| 2016-06-10 19:24:20 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Released |
|
| 2016-06-12 08:45:46 |
Dongcan Ye |
bug |
|
|
added subscriber Dongcan Ye |
| 2016-06-14 11:36:09 |
OpenStack Infra |
tags |
l3-dvr-backlog |
in-stable-mitaka l3-dvr-backlog |
|
| 2016-06-14 11:38:25 |
OpenStack Infra |
tags |
in-stable-mitaka l3-dvr-backlog |
in-stable-liberty in-stable-mitaka l3-dvr-backlog |
|
| 2016-11-27 08:33:54 |
longxingmiao |
description |
On a cloud running Liberty, a VM is assigned a floating IP. The VM is live migrated and the floating IP is no longer reachable from outside the cloud. Steps to reproduce:
1) spawn a VM
2) assign a floating IP
3) live migrate the VM
4) ping the floating IP from outside the cloud
the problem seems to be that both the node that was hosting the VM before the migration and the node that hosts it now answers the ARP request:
admin:~ # arping -I eth0 10.127.128.12
ARPING 10.127.128.12 from 10.127.0.1 eth0
Unicast reply from 10.127.128.12 [FA:16:3E:C8:E6:13] 305.145ms
Unicast reply from 10.127.128.12 [FA:16:3E:45:BF:9E] 694.062ms
Unicast reply from 10.127.128.12 [FA:16:3E:45:BF:9E] 0.964ms
on the compute that was hosting the VM:
root:~ # sudo ip netns exec fip-c622fafe-c663-456a-8549-ebd3dbed4792 ip route
default via 10.127.0.1 dev fg-c100b010-af
10.127.0.0/16 dev fg-c100b010-af proto kernel scope link src 10.127.128.3
10.127.128.12 via 169.254.31.28 dev fpr-7d1a001a-9
On the node that it's hosting the VM:
root:~ # sudo ip netns exec fip-c622fafe-c663-456a-8549-ebd3dbed4792 ip route
default via 10.127.0.1 dev fg-e532a13f-35
10.127.0.0/16 dev fg-e532a13f-35 proto kernel scope link src 10.127.128.8 9
10.127.128.12 via 169.254.31.28 dev fpr-7d1a001a-9
the entry "10.127.128.12" is present in both nodes. That happens because when the VM is migrated no clean up is triggered on the source host. Restarting the l3 agent fixes the problem because the stale entry is removed. |
On a cloud running Liberty, a VM is assigned a floating IP. The VM is live migrated and the floating IP is no longer reachable from outside the cloud. Steps to reproduce:
1) spawn a VM
2) assign a floating IP
3) live migrate the VM
4) ping the floating IP from outside the cloud
the problem seems to be that both the node that was hosting the VM before the migration and the node that hosts it now answers the ARP request:
admin:~ # arping -I eth0 10.127.128.12
ARPING 10.127.128.12 from 10.127.0.1 eth0
Unicast reply from 10.127.128.12 [FA:16:3E:C8:E6:13] 305.145ms
Unicast reply from 10.127.128.12 [FA:16:3E:45:BF:9E] 694.062ms
Unicast reply from 10.127.128.12 [FA:16:3E:45:BF:9E] 0.964ms
on the compute that was hosting the VM:
root:~ # sudo ip netns exec fip-c622fafe-c663-456a-8549-ebd3dbed4792 ip route
default via 10.127.0.1 dev fg-c100b010-af
10.127.0.0/16 dev fg-c100b010-af proto kernel scope link src 10.127.128.3
10.127.128.12 via 169.254.31.28 dev fpr-7d1a001a-9
On the node that it's hosting the VM:
root:~ # sudo ip netns exec fip-c622fafe-c663-456a-8549-ebd3dbed4792 ip route
default via 10.127.0.1 dev fg-e532a13f-35
10.127.0.0/16 dev fg-e532a13f-35 proto kernel scope link src 10.127.128.8 9
10.127.128.12 via 169.254.31.28 dev fpr-7d1a001a-9
the entry "10.127.128.12" is present in both nodes. That happens because when the VM is migrated no clean up is triggered on the source host. Restarting the l3 agent fixes the problem because the stale entry is removed. |
|
