I believe the patch fixed this issue, closing bug. Please re-open if
necessary.
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1831404
Title:
rarp packet will be dropped in flows cause vm connectivity broken
after live-migration
Status in neutron:
Fix Released
Bug description:
When we live-migration a VM, at the moment of VM start in destination
nodes, the VM will send 5 rarp packets(broadcast) to trigger mac learn
for switch, then other same network VMs can send packets to this VM
directly, but actually these rarp packets will be dropped in flows of
br-int, they won't trigger mac learn for switch, then the connectivity
of other VMs to this VM will be broken, they need a broadcast to
search the new position of this VM, it will waste some few seconds.
Without live-migration, you can use nping command in VM to simulate rarp
packets sent from VM:
nping --arp --arp-type rarp --arp-target-mac <vm-mac> --ether-type rarp
<vm-dhcp-host-ip>
For example:
nping --arp --arp-type rarp --arp-target-mac fa:16:3e:02:49:d3 --ether-type
rarp 192.168.111.2
And you can use tcpdump to capture these packets, and also you can see
these packets are dropped in (table 71 , priority=10, in_port=16), 16
is the tap device port in br-int
# ovs-ofctl show br-int | grep 02:49:d3
16(tap80be4c89-6d): addr:fe:16:3e:02:49:d3
#
# ovs-ofctl dump-flows br-int | grep table=71 | grep in_port=16 | grep
priority=10
cookie=0xbb76a2777919bc71, duration=1037.306s, table=71, n_packets=13,
n_bytes=594, idle_age=12, priority=10,ct_state=-trk,reg5=0x10,in_port=16
actions=drop
#
# tcpdump 'rarp or arp' -i tap80be4c89-6d -nne
tcpdump: WARNING: tap80be4c89-6d: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap80be4c89-6d, link-type EN10MB (Ethernet), capture size 65535
bytes
10:11:11.895958 fa:16:3e:02:49:d3 > ff:ff:ff:ff:ff:ff, ethertype Reverse ARP
(0x8035), length 42: Reverse Request who-is fa:16:3e:02:49:d3 tell
fa:16:3e:02:49:d3, length 28
10:11:12.896280 fa:16:3e:02:49:d3 > ff:ff:ff:ff:ff:ff, ethertype Reverse ARP
(0x8035), length 42: Reverse Request who-is fa:16:3e:02:49:d3 tell
fa:16:3e:02:49:d3, length 28
10:11:13.897538 fa:16:3e:02:49:d3 > ff:ff:ff:ff:ff:ff, ethertype Reverse ARP
(0x8035), length 42: Reverse Request who-is fa:16:3e:02:49:d3 tell
fa:16:3e:02:49:d3, length 28
10:11:14.898815 fa:16:3e:02:49:d3 > ff:ff:ff:ff:ff:ff, ethertype Reverse ARP
(0x8035), length 42: Reverse Request who-is fa:16:3e:02:49:d3 tell
fa:16:3e:02:49:d3, length 28
10:11:15.900093 fa:16:3e:02:49:d3 > ff:ff:ff:ff:ff:ff, ethertype Reverse ARP
(0x8035), length 42: Reverse Request who-is fa:16:3e:02:49:d3 tell
fa:16:3e:02:49:d3, length 28
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
# ovs-ofctl dump-flows br-int | grep table=71 | grep in_port=16 | grep
priority=10
cookie=0xbb76a2777919bc71, duration=1063.414s, table=71, n_packets=18,
n_bytes=804, idle_age=8, priority=10,ct_state=-trk,reg5=0x10,in_port=16
actions=drop
You can see 5 rarp packets are captured by tcpdump, and in the drop
flow, the count of n_packets was increased from 13 to 18, this means
these 5 rarp packets are dropped by this flow.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1831404/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
