i have tried to recreate this bug using both nano cirrius images and
a 4 cpu 1GB Ubuntu image and have not been able to reproduce the behavior sited.
i used the the cirros nano image to test live migrating a very small vm which should have a very short time scale.
in the larger image i ran and iperf server and a iperf client connected over the loopback interface to generate a lot of cup load and memory load to test a longer migrations.
bringing up the br-int interface and sniffing for RARP packets show that the RARP packets are correctly vlan tagged in both cases.
sudo tshark -V -i br-int rarp
...
Frame 11: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
Interface id: 0
Encapsulation type: Ethernet (1)
Arrival Time: Aug 26, 2015 11:36:39.533142000 IST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1440585399.533142000 seconds
[Time delta from previous captured frame: 0.350099000 seconds]
[Time delta from previous displayed frame: 0.350099000 seconds]
[Time since reference or first frame: 465.125834000 seconds]
Frame Number: 11
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:vlan:arp]
Ethernet II, Src: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
Address: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 1
000. .... .... .... = Priority: Best Effort (default) (0)
...0 .... .... .... = CFI: Canonical (0)
.... 0000 0000 0001 = ID: 1
Type: RARP (0x8035)
Padding: 0000000000000000000000000000
Trailer: 00000000
Address Resolution Protocol (reverse request)
Hardware type: Ethernet (1)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reverse request (3)
Sender MAC address: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
Sender IP address: 0.0.0.0 (0.0.0.0)
Target MAC address: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
Target IP address: 0.0.0.0 (0.0.0.0)
unless the original reporter can provide more information on how to reproduce
i will mark this as invalid at the end of the week as it appeares to be fixed.
i have tried to recreate this bug using both nano cirrius images and
a 4 cpu 1GB Ubuntu image and have not been able to reproduce the behavior sited.
i used the the cirros nano image to test live migrating a very small vm which should have a very short time scale.
in the larger image i ran and iperf server and a iperf client connected over the loopback interface to generate a lot of cup load and memory load to test a longer migrations.
bringing up the br-int interface and sniffing for RARP packets show that the RARP packets are correctly vlan tagged in both cases.
sudo tshark -V -i br-int rarp 533142000 seconds 3e:47:8b: b0), Dst: Broadcast (ff:ff:ff:ff:ff:ff) broadcast) 0000000000000
...
Frame 11: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
Interface id: 0
Encapsulation type: Ethernet (1)
Arrival Time: Aug 26, 2015 11:36:39.533142000 IST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1440585399.
[Time delta from previous captured frame: 0.350099000 seconds]
[Time delta from previous displayed frame: 0.350099000 seconds]
[Time since reference or first frame: 465.125834000 seconds]
Frame Number: 11
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:vlan:arp]
Ethernet II, Src: fa:16:3e:47:8b:b0 (fa:16:
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/
Source: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
Address: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 1
000. .... .... .... = Priority: Best Effort (default) (0)
...0 .... .... .... = CFI: Canonical (0)
.... 0000 0000 0001 = ID: 1
Type: RARP (0x8035)
Padding: 000000000000000
Trailer: 00000000
Address Resolution Protocol (reverse request)
Hardware type: Ethernet (1)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reverse request (3)
Sender MAC address: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
Sender IP address: 0.0.0.0 (0.0.0.0)
Target MAC address: fa:16:3e:47:8b:b0 (fa:16:3e:47:8b:b0)
Target IP address: 0.0.0.0 (0.0.0.0)
unless the original reporter can provide more information on how to reproduce
i will mark this as invalid at the end of the week as it appeares to be fixed.