DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: Aaron Conole <aconole@redhat.com>
Cc: Yuanhan Liu <yliu@fridaylinux.org>,
	Chen Hailin <chenhl@arraynetworks.com.cn>,
	"ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	cloud <cloud@arraynetworks.com.cn>,
	qemu-devel <qemu-devel@nongnu.org>, dev <dev@dpdk.org>
Subject: Re: [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	[thread overview]
Message-ID: <c424711c-6214-18cf-a494-17200abda76b@intel.com> (raw)
In-Reply-To: <f7tfu8zodu2.fsf@dhcp-25-97.bos.redhat.com>



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

  reply	other threads:[~2017-11-28 16:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20171117063635.9244-1-chenhl@arraynetworks.com.cn>
     [not found] ` <f7tine8z6pj.fsf@dhcp-25-97.bos.redhat.com>
2017-11-24  9:59   ` Chen Hailin
2017-11-27 14:27     ` Yuanhan Liu
2017-11-27 15:34       ` Tan, Jianfeng
2017-11-27 17:01         ` Aaron Conole
2017-11-28 16:06           ` Tan, Jianfeng [this message]
2017-11-27 16:14       ` Aaron Conole
2017-11-27 16:35         ` Tan, Jianfeng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c424711c-6214-18cf-a494-17200abda76b@intel.com \
    --to=jianfeng.tan@intel.com \
    --cc=aconole@redhat.com \
    --cc=chenhl@arraynetworks.com.cn \
    --cc=cloud@arraynetworks.com.cn \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.com \
    --cc=ovs-dev@openvswitch.org \
    --cc=qemu-devel@nongnu.org \
    --cc=yliu@fridaylinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).