qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix devic


From: Tan, Jianfeng
Subject: Re: [Qemu-devel] [dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type
Date: Wed, 29 Nov 2017 00:06:50 +0800
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0



On 11/28/2017 1:01 AM, Aaron Conole wrote:
"Tan, Jianfeng" <address@hidden> writes:

On 11/27/2017 10:27 PM, Yuanhan Liu wrote:
On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
Hi Aaron Conole && Jianfeng,

The stp could not work in ovs-dpdk vhostuser.
Because the attached vhost device doesn't have MAC address.

Now we have two ways to solve this problem.
1. The vhost learns MAC address from packet like as my first patch.
I do agree with Aaron this is not the right way.
I do think it should be the vswitch's responsibility to learn mac of
vhost port.

Except that it's the only feasible way without modifying the spec
(yuanhan already makes it very clear below), we can treat the vswitch
as a phsical switch, VM as a physical server, virtio/vhost port as a
back-to-back connected NICs, the only way of the physical switch to
know the mac of the NIC on the other side is ARP learning.

Might I ask why you don't think it's a right way?
As a quick example, I think a malicious guest in a multi-tenant
environment could send traffic out to manipulate this feature into
learning an incorrect mac address.

Instead, I think it's not right to stop such mac spoofing behavior (suppose someone wants to have such an experiment in an overlay networking). And it actually only affects one “LAN", instead of all "LANs".

And it's usually not the switch's responsibility to detect mac spoofing behavior IMHO.

To get this right requires doing deep packet inspection, and making sure
to only learn based on certain l2 traffic.


Yes, should learn based on ARP packets. Your concern is the performance? I suppose there is not to many such packets.

Thanks,
Jianfeng



reply via email to

[Prev in Thread] Current Thread [Next in Thread]