From owner-freebsd-net@freebsd.org Sun Sep 22 14:52:11 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D005124299 for ; Sun, 22 Sep 2019 14:52:11 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail.allbsd.org (mx.allbsd.org [IPv6:2001:2f0:104:e001::41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46br5Q1gPzz3N1N; Sun, 22 Sep 2019 14:52:09 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail-d.allbsd.org ([IPv6:2409:11:a740:4700:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id x8MEpjAj091006 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) (Client CN "/CN=mail-d.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Sun, 22 Sep 2019 23:51:55 +0900 (JST) (envelope-from hrs@allbsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=allbsd.org; s=20190220; t=1569163927; bh=vUHB4tl5991L6cAJBl0i9os3Rlmu7hSbPUXRQaqL04Q=; h=Date:To:Cc:From:In-Reply-To:References; b=dh94cMq/2kzC4AAOp6h0sKGFZXG4ZC+0PedjrAreEkxayrRv7BHzoRBJw7Oljuj4b JeXmQQXjyoYfLkZj7TdI3atLpN4VVwWgefkmchk3KdH0LD1o1/x7o/yNQMpOsAtBfQ JyAXvEUPexSiEV+SEtj1iWEXybQRWxhdWwZEcQYs= Received: from alph.d.allbsd.org ([IPv6:2409:11:a740:4700:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id x8MEpd5A053115 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 22 Sep 2019 23:51:40 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id x8MEpcZB053110; Sun, 22 Sep 2019 23:51:39 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Sun, 22 Sep 2019 23:50:47 +0900 (JST) Message-Id: <20190922.235047.562191741306834004.hrs@allbsd.org> To: akgupt3@gmail.com Cc: freebsd-net@freebsd.org, hrs@FreeBSD.org Subject: Re: Link flap for setting ether/MAC address From: Hiroki Sato In-Reply-To: References: X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.2 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Sun_Sep_22_23_50_47_2019_632)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [IPv6:2001:2f0:104:e001:0:0:0:41]); Sun, 22 Sep 2019 23:52:07 +0900 (JST) X-Rspamd-Queue-Id: 46br5Q1gPzz3N1N X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=allbsd.org header.s=20190220 header.b=dh94cMq/; dmarc=none; spf=pass (mx1.freebsd.org: domain of hrs@allbsd.org designates 2001:2f0:104:e001::41 as permitted sender) smtp.mailfrom=hrs@allbsd.org X-Spamd-Result: default: False [-5.31 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[allbsd.org:s=20190220]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[allbsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[allbsd.org:+]; MID_CONTAINS_FROM(1.00)[]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7514, ipnet:2001:2f0::/32, country:JP]; IP_SCORE(-2.21)[ip: (-9.12), ipnet: 2001:2f0::/32(-4.24), asn: 7514(2.32), country: JP(-0.02)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2019 14:52:11 -0000 ----Security_Multipart(Sun_Sep_22_23_50_47_2019_632)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anish wrote in : ak> Hi all, ak> Got a very basic question, why physical link is flapped when we set the ak> address ak> ak> # dmesg -c ak> # ifconfig ix1 ether 70:6d:15:1f:12:72 ak> ..wait.. ak> # dmesg ak> ix1: link state changed to DOWN ak> ix1: link state changed to UP ak> # ak> ak> is this a bug or expected behavior? We could update our MAC in next ARP ak> request without link flap or some other system like switch etc expect the ak> link flap to update ARP. Is this the behavior for other systems? I think this depends on the driver. Some drivers reset the NIC when the MAC address is changed mostly because it is an easy way to re-configure the multicast filtering rules or the other settings which must be updated for the new MAC address. It causes a link flap. For upper layers above the NIC driver, you are correct. -- Hiroki ----Security_Multipart(Sun_Sep_22_23_50_47_2019_632)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMcEABMKAC0WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXYeKRw8caHJzQGFsbGJz ZC5vcmcACgkQ27B9xm8fc3+yZAII89E4Kh/Q7hEOPIZt0xgjtnCsG9cxrcHGLRjE bJ3Jo/z1EgBdqpj7TWzgQdhnOm75oaI5bNphJNmtJlBdEjVjd6ICCOiGEUUvRapX VrH7nRJg7TNMF0KFZd4nM9P9TioMSQfzo0S/eIK6TT8O+bG3iibNdNBlfosVmC1Y mEUOE7cDElOs =pY5S -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Sep_22_23_50_47_2019_632)----