From owner-freebsd-arm@freebsd.org Fri Nov 11 12:12:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34602C3A6C3 for ; Fri, 11 Nov 2016 12:12:19 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C706B1287 for ; Fri, 11 Nov 2016 12:12:18 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id 6cCF1u0014VixDu01cCGzY; Fri, 11 Nov 2016 13:12:16 +0100 Reply-To: From: "John W. Kitz" To: References: <005701d23a7d$71400630$53c01290$@Kitz@xs4all.nl> <20161110065105.77a19e3b@X220.alogt.com> <000c01d23b3a$c06e1ef0$414a5cd0$@Kitz@xs4all.nl> <20161111094930.46f55a60@X220.alogt.com> In-Reply-To: <20161111094930.46f55a60@X220.alogt.com> Subject: RE: How to change MAC address on RPI-B? Date: Fri, 11 Nov 2016 13:12:19 +0100 Message-ID: <000f01d23c14$da3a6c00$8eaf4400$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdI7vd7MQYUHOX7aSpyC5iH/0Duy4AAVNyHw Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 12:12:19 -0000 Erich, > > To the best of my recollection at the time there was no need > > whatsoever to configure these NICs into promiscuous mode, which in > > you need this for fault-tolerant computing. A machine or a device with > a known goes down, the failure will be detected and another device or > machine is configured to take over the other's task by also taking > over the other's MAC address. The communication partners will only a > delay but not a failure. > > JKi: I'm curious, would, in your experience, the impact of any delay > incurred by tinkering with addresses at both layer-3 AND layer-2 in a > failover situation be less in comparison to any delay incurred when > tinkering with the addresses at layer-3 ONLY and leave the recovery of > addressing issues at layer-2 to the relevant protocols? > it depends of what you want. When the machine connecting to the fault-tolerant machine is not fault-tolerant, it will not be able to change any addresses. All it will do is repeating requests. A watch-dog should have realised by then that either the interface or the machine with the interface is down and should have activated either a different interface or a different machine. It is just one of many option you have. And it is a cheap option as you can make even FreeBSD fault-tolerant with this as the operating system does not play any part in this kind of fault-tolerance. JKi: The point I was trying to make is that locally administered MAC addresses serve a purpose in the recovery of hardware failures, e.g. in its basic form when one needs to replace a broken NIC thereby ending up with a system with a different MAC address, in those situations where the higher layer protocol (addressing or rather lack thereof, such as can be the case in SNA / VTAM installations) doesn't. The other point, which you're not answering, is assuming that one would rely on the use of both lower and higher layer addressing in the recovery from hardware failures is there, in your experience, a noticeable gain in recovery time to be made by applying both techniques. Regards, Jk.