From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13) Date: Tue, 8 Jan 2019 14:51:12 -0800 Message-ID: <20190108145112.65fc554f@hermes.lan> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Linux Kernel Network Developers , jeffrey.t.kirsher@intel.com, Roopa Prabhu , nikolay@cumulusnetworks.com, "linux-kernel@vger.kernel.org" To: Ian Kumlien Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, 8 Jan 2019 23:10:04 +0100 Ian Kumlien wrote: > On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien wrote: > > > > [Sorry for the repost, screwed up the netdev address...] > > > > Hi, > > > > Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s. > > > > My firewall (which also runs the dhcpd) runs VM:s and it does this by > > having physical > > interfaces attached to bridges - which the VM:s in turn attach to. > > > > Since 4.20 the VM:s can't use DHCP, it's odd since the requests are > > seen - a response is sent but > > it never enters the interface attached to the bridge. > > > > Basically: > > VM vnet2: -> br0 -> eno2 -> switch -> eno1 (dhcpd) > > dhcpd eno1 -> siwtch and... gone. > > > > Any clues? > > > > All the nics are handled by ixgbe > > So, doing similar tests at work with other drivers works - could it be > related to the mac address filter that was added? > I don't *really* use VF:s though... (can't really find anything else atm) > > Will try to test, but the VM:s on this machine is in use. The default MAC address of the bridge device is the first device assigned to the bridge. Remember most VF interfaces will only allow single MAC address and no promiscious mode. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2C4EC43387 for ; Tue, 8 Jan 2019 22:51:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7E5E32146F for ; Tue, 8 Jan 2019 22:51:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="Ufv4z6NI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730239AbfAHWvX (ORCPT ); Tue, 8 Jan 2019 17:51:23 -0500 Received: from mail-pg1-f196.google.com ([209.85.215.196]:42339 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729570AbfAHWvW (ORCPT ); Tue, 8 Jan 2019 17:51:22 -0500 Received: by mail-pg1-f196.google.com with SMTP id d72so2371560pga.9 for ; Tue, 08 Jan 2019 14:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=z1s6TSGDjP6SNuli3YtUtMnOPSMApQhQ8/VHYSzE1QM=; b=Ufv4z6NIYoGMh+ULLdEDR779mrYWYbbLuz7tP+YxmsMT6EqSRAjiRs0Al9OTzjWuSK bajywjTL9kYIK3+HcHAPg7jdbVz2Ms5LfgbF9RfounLnXhexjczBeOOjqndApBKX/tvG ZZvqBeEpWInxQ1+mdnShrpUhETsHrx7r+AJ55dxcimEQRkmGJCYSDvCLd+jPlsBRF6pw /gMu1sQzywkPKAoT6tpAtnVDJ6bxeFoTnKYlNBliY0Qv5/mHtx7UHas+NuvTxJDlXaW+ PYxf6eUn5lS5zVMdVGmNtlEbtoCC/gj8JkM22ZO6XZuSV0cysuRO5FqaLWDO8a870nWY kovA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=z1s6TSGDjP6SNuli3YtUtMnOPSMApQhQ8/VHYSzE1QM=; b=U5F/O+vxmIspfZG++6KERtxJS7QU48yxXepOAQFA/fR/cWPOH4Mvz/y7+pQout2X4I F+ESdYWZ/uiNmEjIPh2Vg5NXYodA5rr+1NgMV4/O99ZHHHg0zuXyVGXMDwz3I7/G2Prv hZf8gMGqlR7xtpnCv6RDfzT8VRUJLLnJwHv5k8LkubItzCyH49M06wf/0XtNrBSAMzdc OFh7ybsIMPMA34fkm04WSd/PeIvqiaYBFW0fcQsvQH6l567IzXT8qZHGVYHmSd7ckSUq 7XgN96/nGf2AKgmsD7S6USlMxwAFTqsJUE/akX2B/k2pSjuiEoXMhLlnAxYmI8KhIQn+ SbEQ== X-Gm-Message-State: AJcUukeKJGxIpd+NGtLyFJk/cqiTjtnSmWUzxQjiHcNy7xMCMkppCFqK oqWl3bsdZOSjKr4tTM2tgxxOHQ== X-Google-Smtp-Source: ALg8bN6ARyPR+LzaLDp+r/5Dd5PYt+2IdqGyxXIJivm8zSTmYknemtlluytBENpySO8GEyU7IBQI/g== X-Received: by 2002:a62:6b8a:: with SMTP id g132mr3596032pfc.201.1546987881602; Tue, 08 Jan 2019 14:51:21 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id i184sm98316555pfc.41.2019.01.08.14.51.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 Jan 2019 14:51:21 -0800 (PST) Date: Tue, 8 Jan 2019 14:51:12 -0800 From: Stephen Hemminger To: Ian Kumlien Cc: Linux Kernel Network Developers , jeffrey.t.kirsher@intel.com, Roopa Prabhu , nikolay@cumulusnetworks.com, "linux-kernel@vger.kernel.org" Subject: Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13) Message-ID: <20190108145112.65fc554f@hermes.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Message-ID: <20190108225112.TXngaFBfygLtjtv4lMteUrLs-jz2WPIy0Ns1MkiG2ks@z> On Tue, 8 Jan 2019 23:10:04 +0100 Ian Kumlien wrote: > On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien wrote: > > > > [Sorry for the repost, screwed up the netdev address...] > > > > Hi, > > > > Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s. > > > > My firewall (which also runs the dhcpd) runs VM:s and it does this by > > having physical > > interfaces attached to bridges - which the VM:s in turn attach to. > > > > Since 4.20 the VM:s can't use DHCP, it's odd since the requests are > > seen - a response is sent but > > it never enters the interface attached to the bridge. > > > > Basically: > > VM vnet2: -> br0 -> eno2 -> switch -> eno1 (dhcpd) > > dhcpd eno1 -> siwtch and... gone. > > > > Any clues? > > > > All the nics are handled by ixgbe > > So, doing similar tests at work with other drivers works - could it be > related to the mac address filter that was added? > I don't *really* use VF:s though... (can't really find anything else atm) > > Will try to test, but the VM:s on this machine is in use. The default MAC address of the bridge device is the first device assigned to the bridge. Remember most VF interfaces will only allow single MAC address and no promiscious mode.