[dpdk-dev] [ovs-dev] [PATCH RFC] netdev-dpdk: Fix device obtain mac address when received first packet in vhost type

Tan, Jianfeng jianfeng.tan at intel.com
Tue Nov 28 17:06:50 CET 2017



On 11/28/2017 1:01 AM, Aaron Conole wrote:
> "Tan, Jianfeng" <jianfeng.tan at intel.com> 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


More information about the dev mailing list