linux组播程序收包丢帧,Linux KVM SRIOV欺骗数据包丢帧

命令，ctrl 0x0000：信息，发送seq 0，rcv seq 0，标志[Command]，长度46 0x0000：0000 0000 0000 0000 0000 0000 0000 0000 ...........

..... 0x0010：0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0020：0000 0000 0000 0000 0000 0000 0000 ..........

.... 10：36：26.561776 00：00：00：00：00：00> 00：00：00：00：00：00,802.3，长度0：LLC，dsap Null(0x00)个人，ssap Null(

0x00)命令，ctrl 0x0000：信息，发送seq 0，rcv seq 0，标志[命令]，长度46 0x0000：0000 0000 0000 0000 0000 0000 0000 0000 ................

0x0010：0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0020：0000 0000 0000 0000 0000 0000 0000 .............. 10

：36：26.568122 02：00：00：00：00：01> ff：ff：ff：ff：ff：ff，et

hertype ARP(0x0806)，长度60：请求谁有YYY.YYY.YYY.YYY告诉XXX.XXX.XXX.XXX，长度46

在此一个VF处于错误状态期间，所有其他客户将看到与父母相同的数据包。

目前唯一的解决方案是重新启动来宾。

有时会摧毁客人并重新启动它。

以上来自于谷歌翻译

以下为原文

The primary issue is after several hours to upwards of a couple weeks a single VF will get into a bad state for a guest and we will see the following errors on the parent and child.

Versions:

Centos = 7.5.1804

Kernel = 4.4.121-1.el7.centos.x86_64 (Current); Tried 3.10.0, 4.4.75, 4.9.52, 4.14.68

IXGBE = 5.3.7 (Current); Tried 5.3.5, 4.2.1-k, ......

IXGBEVF = 4.3.5 (Current); Tried 2.12.1-k, ....

QEMU = 1.5.3 (Current); Tried 2.0.0

Libvirt = 3.9.0 (Current)

On the parent we will see this error:

ixgbe 0000:05:00.0 ethx: 193 Spoofed packets detected

ixgbe 0000:05:00.0 ethx: 45 Spoofed packets detected

ixgbe 0000:05:00.0 ethx: 3 Spoofed packets detected

ixgbe 0000:05:00.0 ethx: 126 Spoofed packets detectedOn the child you will see an increase in dropped packets.

2: eth0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

link/ether 52:54:00:5e:a9:f8 brd ff:ff:ff:ff:ff:ff

RX: bytes  packets  errors  dropped overrun mcast

455429589913 520093667 0       375674  0       375680

TX: bytes  packets  errors  dropped carrier collsns

463147231075 514071570 0       0       0       0

I don't have a way to view the spoofed packets going out, but I can see the incoming packets getting corrupted and dropped by the guest. Best example is an ARP since it will hit every parent, child. (IPs censored)

Parent capture:

10:36:26.492879 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has ZZZ.ZZZ.ZZZ.ZZZ tell XXX.XXX.XXX.XXX, length 46

10:36:26.540880 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has BBB.BBB.BBB.BBB tell XXX.XXX.XXX.XXX, length 46

10:36:26.553161 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has AAA.AAA.AAA.AAA tell XXX.XXX.XXX.XXX, length 46

10:36:26.559508 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has YYY.YYY.YYY.YYY tell XXX.XXX.XXX.XXX, length 46Child Capture:

10:36:26.501491 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has ZZZ.ZZZ.ZZZ.ZZZ tell XXX.XXX.XXX.XXX, length 46

10:36:26.549499 00:00:00:00:00:00 > 00:00:00:00:00:00, 802.3, length 0: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Command], length 46

0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................

0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................

0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

10:36:26.561776 00:00:00:00:00:00 > 00:00:00:00:00:00, 802.3, length 0: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Command], length 46

0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................

0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................

0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

10:36:26.568122 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has YYY.YYY.YYY.YYY tell XXX.XXX.XXX.XXX, length 46

During the time this one VF is in a bad state, all other guests will see the same packets as the parent. The only current solution is to reboot the guest. Sometimes destroy the guest and start it back up.

0