From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ido Schimmel Subject: Re: Bridge connectivity interruptions while devices join or leave the bridge Date: Wed, 19 Sep 2018 13:07:55 +0300 Message-ID: <20180919100755.GA26424@splinter> References: <7e7e9b1d-b6b5-b72f-efe6-52d700ad1ffc@techfak.uni-bielefeld.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: Johannes Wienke Return-path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:35205 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727605AbeISPpL (ORCPT ); Wed, 19 Sep 2018 11:45:11 -0400 Content-Disposition: inline In-Reply-To: <7e7e9b1d-b6b5-b72f-efe6-52d700ad1ffc@techfak.uni-bielefeld.de> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Sep 19, 2018 at 11:10:22AM +0200, Johannes Wienke wrote: > Can someone explain what is happening here and why adding and removing > devices to a bridge results in the connectivity issues? How to avoid > this behavior? I'd be glad for any hint on that. The MAC address of the bridge ('brtest' in your example) is inherited from the bridge port with the "smallest" MAC address. Thus, when you generate veth devices with random MACs and enslave them to the bridge, you sometimes change the bridge's MAC address as well. And since the bridge is the default gateway sometimes packets are sent to the wrong MAC address. You can avoid randomly changing the bridge's MAC by setting it explicitly: # ip link set dev brtest address