From owner-freebsd-bugs@freebsd.org Sun Jul 22 10:05:17 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 161821046729 for ; Sun, 22 Jul 2018 10:05:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 99B9F8F66B for ; Sun, 22 Jul 2018 10:05:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5A14D1046728; Sun, 22 Jul 2018 10:05:16 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35CAD1046727 for ; Sun, 22 Jul 2018 10:05:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1E238F66A for ; Sun, 22 Jul 2018 10:05:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E263F1C14C for ; Sun, 22 Jul 2018 10:05:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6MA5Ewi047391 for ; Sun, 22 Jul 2018 10:05:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6MA5Ejw047390 for bugs@FreeBSD.org; Sun, 22 Jul 2018 10:05:14 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 229957] [epair] MAC addresses all the same, no randomness Date: Sun, 22 Jul 2018 10:05:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ohartmann@walstatt.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 10:05:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229957 Bug ID: 229957 Summary: [epair] MAC addresses all the same, no randomness Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: ohartmann@walstatt.org On recent CURRENT (FreeBSD 12.0-CURRENT #248 r336596: Sun Jul 22 09:31:53 C= EST 2018 amd64), having vnet jails (VIMAGE kernel) owning their private epair pseudo NIC and having their external end being part of a bridge(4), results= in a weird behaviour since CURRENT creates on ALL external parts of the epair = pair (b-part in my case) the very same MAC address! Each vnet jail then gets the appropriate internal part of the epair pair (a-part in my case) but since I group them on bridge(4) if-devices, then there is a MAC address problem and this results in a very undpredictable, weirsd behaviour on FreeBSD (nothing= is reported to the console/log/kernel so far). This is my ifconfig result after creating a bunch of epairs: epair3b: flags=3D8943 metri= c 0 mtu 1500 options=3D8 ether 02:48:e2:b0:8c:0b groups: epair=20 media: Ethernet 10Gbase-T (10Gbase-T ) status: active epair52b: flags=3D8943 metr= ic 0 mtu 1500 options=3D8 ether 02:48:e2:b0:8c:0b groups: epair=20 media: Ethernet 10Gbase-T (10Gbase-T ) status: active epair10013b: flags=3D8943 m= etric 0 mtu 1500 options=3D8 ether 02:48:e2:b0:8c:0b groups: epair=20 media: Ethernet 10Gbase-T (10Gbase-T ) status: active epair17b: flags=3D8943 metr= ic 0 mtu 1500 options=3D8 ether 02:48:e2:b0:8c:0b groups: epair=20 media: Ethernet 10Gbase-T (10Gbase-T ) status: active epair10015b: flags=3D8943 m= etric 0 mtu 1500 options=3D8 ether 02:48:e2:b0:8c:0b groups: epair=20 media: Ethernet 10Gbase-T (10Gbase-T ) status: active One of the jails: root@ns01:~ # ifconfig lo0: flags=3D8049 metric 0 mtu 16384 options=3D680003 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 enc0: flags=3D0<> metric 0 mtu 1536 groups: enc=20 epair3a: flags=3D8843 metric 0 mtu = 1500 options=3D8 ether 02:48:e2:b0:8c:0a inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255=20 groups: epair=20 media: Ethernet 10Gbase-T (10Gbase-T ) status: active And another jail on the very same bridge pseudo device: root@db01:~ # ifconfig lo0: flags=3D8049 metric 0 mtu 16384 options=3D680003 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 enc0: flags=3D0<> metric 0 mtu 1536 groups: enc=20 epair52a: flags=3D8843 metric 0 mtu= 1500 options=3D8 ether 02:48:e2:b0:8c:0a inet 192.168.0.52 netmask 0xffffff00 broadcast 192.168.0.255=20 groups: epair=20 media: Ethernet 10Gbase-T (10Gbase-T ) status: active There was an issue earlier with broken epair code on CURRENT (and prior) wh= ich has been supposedly "fixed" a couple of time ago, but it seems the "fix" br= oke more than it fixed. I tried to solve the problem by applying manually MAC addresses via the ifconfig "ether" option to guarantee different MACs on each collision doama= in but there is a weird behaviour now using IPFW. While the setup I use includ= ing the workaround with the manually set "ether" on each epair works perfectly = on 11.2-RELENG, I have trouble in CURRENT: Although OPEN firewall (ipfw) setti= ng in each jail, pinging the host owning the physical NIC which is part of the bridge from any jail also member of the bridge doesn't work until the host owning the physical NIC is pinging first that jail's address. I can not say whether this is an IPFW issue or also related to the corrupt epair handling. --=20 You are receiving this mail because: You are the assignee for the bug.=