From owner-freebsd-net@freebsd.org Fri Jan 19 21:52:11 2018 Return-Path: Delivered-To: freebsd-net@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 F3755ECAA4E; Fri, 19 Jan 2018 21:52:11 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C11E97797B; Fri, 19 Jan 2018 21:52:11 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qt0-x230.google.com with SMTP id e2so7419348qti.0; Fri, 19 Jan 2018 13:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xILgYEqRwmFxrKnvLmu/txJCeJGSgGv4P9Ig8P5ZrIM=; b=ET7Wsd1gsBXc3p9iGcKQZSS/XreGcMZJwfegRCpfdhLey6fZ6hS80Sr+eHALj2NeWz 1rbCcym72if6W0I4Z+oBFwfQEoQfvEiBB/Y9Ikcz0KKPmUSN8m0Uu154DZzoZggo3XzE Ad8eGK3jIZJ4VSSH0tLrUYe193fXuBkkkjfPwHOty7fmnYj+lQyWA2m6HoTE9GRPhVtD Kbkalr4Xa51Ftomi4FesEcQCg+rXjc1X2dHLZdY0ZLmDuIupj6KLCfarrc96V50TAFyj ADzf2Cm0HqBOxSQMP575ml6r9Vu+KKZIhYpJz1SiuzA0vJKDkbizPwJX/vyUgLFnOViN NW5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xILgYEqRwmFxrKnvLmu/txJCeJGSgGv4P9Ig8P5ZrIM=; b=VHRAfGtWHLAfXTWw71BEM1cxUAnlLKfuz98O4H01d/gBBhLLuSfx1GMVquKqrqIILa KApGAZZWA7rvFVpn6eqk0qF7YkiSmK1JfkK8Q/EttdXkiK2WJNr2kFSIxRvfrbqj9nOk ucV/vMzd+2G4dX5rgQSdWiTqsDHiEo78blsU9/pu7Rs9Q6udXRln8jHlaqRb35qCX8wa Rh4W2cR3BY+OyJlAD8SyHmXJiyk7y09DQCNnli983oHBWTjGhpoELDoX93ISBcFe6b0l vcuNA1YdEEiEYUxz0Bv1qV0T1knndOziY7vVqbh6hvf9UPnECn712TdeGdbvrW7nKhyt Kp0w== X-Gm-Message-State: AKwxytekbJa+o8Q50/hCt9QxkjiaiHuRho5P9zhKneJxiLBa2GlCD71q Qryg6IE2jE/Hd6jz8IGc2sLF1eAEV4pKggDrN9VXGw== X-Google-Smtp-Source: ACJfBotJfGbIcbO80C0s9ODMA4vCBgxgwQFy5F7SaC37tKZYP2Ji4H29u39zlij7BHu3+qh68+gE/2Yi8kD5X5FxdSg= X-Received: by 10.200.64.219 with SMTP id f27mr32863405qtm.227.1516398730240; Fri, 19 Jan 2018 13:52:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.2 with HTTP; Fri, 19 Jan 2018 13:52:09 -0800 (PST) From: Ryan Stone Date: Fri, 19 Jan 2018 16:52:09 -0500 Message-ID: Subject: 3 ARP cache related reviews To: freebsd-net , "" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 21:52:12 -0000 I've opened 3 phabricator reviews fixing issues with the inpcb llentry caching. https://reviews.freebsd.org/D13988 This fix invalidates the llentry cache after the L3 route cache was invalidated by the routing table's generation count incrementing. Without this fix existing connections would continue to use stale L2 headers after the routing table was updated. I tried a simple test where I added a new route that would change the routing of an active TCP connection and confirmed with tcpdump that without this fix, the stack continues to use the old src/dst MAC for the original route. This caused the traffic to be blackholed at the new gateway as the MAC did not match. https://reviews.freebsd.org/D13989 This is a simple cleanup of the inpcb cache invalidation. Rather than copy-and-pasting the separate invalidation of the L2 cache and the L3 cache, I move the invalidation into a single macro and invoke it everywhere that needs to drop the cache. This will hopefully prevent future bugs like D13988 from occurring in new code. https://reviews.freebsd.org/D13990 This fixes an issue where the inpcb L2 cache was not updated following a change to a route's gateway. This led the connection to continue to use the old gateway. If the old gateway stopping routing traffic this would cause the connection to be blackholed. My fix here is more heavy-handed than it needs to be, as I just increment the route table generation count, which will cause all connections to drop their L2 and L3 caches. This could be made more selective by adding a generation count to each route entry, but I don't believe that route table modifications will happen frequently enough for anybody to care. Please speak up if you believe differently. If you're interested in one or more of these changes, please subscribe yourself to the reviews. I don't subscribe mailing lists to reviews to reduce the spam on the lists. Thanks, Ryan