Disable routing cache in Linux

Linux Kernel 3.6 officially removes the route cache because, as mentioned by the author, it is not suitable to exist as a part of the route table. It is highly related to traffic patterns, it should be used as an optimization in external implementation, such as the implementation of forwarding tables based on ASIC hard cards. Moreover, the existing routing cache does not bring significant performance improvement in most cases, if you frequently flush the cache, the performance will decrease, many of the factors are caused by the flush operation itself and the lookup read lock. However, if you are using a kernel earlier than version 3.6, you will have to face the routing cache. Since it cannot give you too many benefits, if it brings you disadvantages, your attitude towards it is not just a curse!
Dangers of a route Cache

The mismatch between the routing cache and the mark-Based Policy Routing caused a bug in the product, which caused me to get into trouble for several consecutive days! We know that Mark can only be marked by the netfilter hook, while the mark at prerouting is marked before routing. in Linux, whether it is iptables rule or a Policy Routing item, they take effect immediately after configuration, and the two operations cannot be merged into a separate atomic operation, which causes the problem:
1. Now we need a rule to mark packet, and a Policy Routing item to route based on this mark, so there are two Linux commands;
2. Prior to executing the preceding two commands, packets of interest continued to pass through the box, resulting in a route cache;
3. The mark rule is executed first. At this time, when the Policy Routing item is not executed, a packet of interest matches the mark, but the policy routing is not matched;
4. If your policy routing table is configured with fall though, the problem arises. lookup enters the main table, configures the original route, and is cached;
5. If there is a continuous stream of interest, the above mark-Policy Routing will never take effect.
You may say that you can swap the Setting Order of the Mark rule and Policy Routing item. However, even if your implementation is stateful, you still need to face another cache, that is, the conntrack cache problem. You may also say that fall though can be replaced by default unreachable, but that will be very different from the implementation semantics. Therefore, it is imperative to disable route cache!
How to disable route Cache

It's a tough journey! The parameters in/proc/sys/NET/IPv4/route/fail to be adjusted once. Route-C-N still shows a lot of disgusting things. So Google and the code found the following parameters:
Rt_cache_rebuild_count-integer
The per net-namespace route cache emergency rebuild threshold.
Any net-namespace having its route cache rebuilt due
A hash bucket chain being too long more than this frequently times
Will have its route caching disabled
As a confirmation, in the IP input/output in route. C, there is a judgment before searching for the cache:

if (!rt_caching(net))        goto skip_cache;

In this way, the cache query is skipped, and the implementation of rt_caching is super simple:

static inline bool rt_caching(const struct net *net){    return net->ipv4.current_rt_cache_rebuild_count <=        net->ipv4.sysctl_rt_cache_rebuild_count;}

In addition, sysctl_rt_cache_rebuild_count is of the int type. You only need to ensure that the above function always returns 0. Therefore, set sysctl_rt_cache_rebuild_count to-1, and the route cache is disabled successfully!
Summary

Do not naively think that any cache will increase the efficiency. In the Linux route cache example, the query route table is the hash/trie table, and the query cache is also a hash table, in addition, if your route table has only one default route, the number of cache items is much greater than the number of route table items. In this case, the cache simply uses dst_entry, instead of rolling out the field of the route table entry from the result to the newly applied dst_entry, this is a result of a waste of time on the table... in fact, as long as there are route table items with a prefix of less than 32 characters in the route table, the above situation may occur. Therefore, when there is no essential difference between the cache lookup mechanism and the route table lookup mechanism, the routing cache did not achieve the expected results! On the contrary, the routing cache should be performed during prerouting, instead of during routing. In prerouting, netfilter can be conveniently used to implement the cache in a hard card.
When determining the behavior, the cache will improve the efficiency. When the behavior mode is not fixed, the cache is used to waste resources and disrupt the audio and video! The teacher Fined you for writing "Pig Blood" ten times in a row. Now you can write 10 "Pig Blood" consecutively, and then write 10 "blood" continuously ", it must be faster than writing 10 "Pig Blood". However, if you are a simultaneous interpreter or stenographer, never remember what you just heard in your mind...