3 ms·

This post says the route cache was removed. This leads me to the question: What replaced it? Surely if it was simply removed, network performance would drop, w

This post says the route cache was removed. This leads me to the question: What replaced it? Surely if it was simply removed, network performance would drop, which leads me to think caching must have been added somewhere else as it was removed here? Can anyone clarify?

vbernat 12y ago
Nothing replaces it. Lookup performance of the routing table has been increased by using an LC trie since 2.6.39 and the various information which were previously in the cache have been moved to other structures. The performance of the cache was said to be bad (only 10% hit, but that doesn't match at all my experience where the performances of the cache were pretty good, see the article) and being an hash table, it was the target of DOS attacks. Moreover, many information were tied to the cache, triggering some additional problems, like the "neighbor cache overflow".
donavanm 12y ago
The dst/route cache has effectively been replaced by the TCP metrics cache. Values like MSS, SRTT, and cwnd are still useful to preserve across streams between peers. See ip-tcp_metrics(8) for a decent summary. David Miller has a summary of the route cache removal in http://vger.kernel.org/~davem/columbia2012.pdf http://vger.kernel.org/~davem/columbia2012.pdf. The cache exhaustion argument was .. odd. As I recall the cache entry was created on handshake and was keyed off of src ip, dst IP, dst port. Given that the attacker can (effectively) only vary the src ip thats a lot of addresses to control. The other argument was that not hitting a cache was "only" 10% slower in microbenchmarks. Personally Im dubious of the route cache removal, though I havent tested. The 10% hit rate, as I recall, was from Google front end servers which Id expect to have a high cardinality of peers along with a simplistic route table. For servers with multiple interfaces, variable route properties, multiple tables, etc and a high packet rate a fast cache should be quite valuable.
- vbernat 12y ago
  For the 10% hit, I agree with you. For one large French site (but with a national audience only), the efficiency of the route cache was more than 95%.

vbernat 12y ago

Nothing replaces it. Lookup performance of the routing table has been increased by using an LC trie since 2.6.39 and the various information which were previously in the cache have been moved to other structures. The performance of the cache was said to be bad (only 10% hit, but that doesn't match at all my experience where the performances of the cache were pretty good, see the article) and being an hash table, it was the target of DOS attacks. Moreover, many information were tied to the cache, triggering some additional problems, like the "neighbor cache overflow".

donavanm 12y ago

The dst/route cache has effectively been replaced by the TCP metrics cache. Values like MSS, SRTT, and cwnd are still useful to preserve across streams between peers. See ip-tcp_metrics(8) for a decent summary. David Miller has a summary of the route cache removal in http://vger.kernel.org/~davem/columbia2012.pdf http://vger.kernel.org/~davem/columbia2012.pdf. The cache exhaustion argument was .. odd. As I recall the cache entry was created on handshake and was keyed off of src ip, dst IP, dst port. Given that the attacker can (effectively) only vary the src ip thats a lot of addresses to control. The other argument was that not hitting a cache was "only" 10% slower in microbenchmarks. Personally Im dubious of the route cache removal, though I havent tested. The 10% hit rate, as I recall, was from Google front end servers which Id expect to have a high cardinality of peers along with a simplistic route table. For servers with multiple interfaces, variable route properties, multiple tables, etc and a high packet rate a fast cache should be quite valuable.

vbernat 12y ago
For the 10% hit, I agree with you. For one large French site (but with a national audience only), the efficiency of the route cache was more than 95%.