Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Jan 2018 16:52:09 -0500
From:      Ryan Stone <rysto32@gmail.com>
To:        freebsd-net <freebsd-net@freebsd.org>,  "<freebsd-transport@freebsd.org>" <freebsd-transport@freebsd.org>
Subject:   3 ARP cache related reviews
Message-ID:  <CAFMmRNzXvwuHqyqJUte6FsPcR7hknSnc4Q8J67yumETnHyaCSQ@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNzXvwuHqyqJUte6FsPcR7hknSnc4Q8J67yumETnHyaCSQ>