In a text I wrote a few days ago, I described a failed experience, and for me who cared about the process, I described it as a success. However, I had to go back to the DXR and look at its essence rather than its algorithmic thinking. The reason why I failed, is because of my rebellious psychology in mischief, I really did not study the nature of the DXR began to do, no doubt in a unprepared and the opponent completely do not understand the Wu Zhang, if not enough, the result must be as tragic as the original death knock Bloom!
The DXR nature of DXR does not invent a new algorithm, it is efficient because it separates the
Route prefix and next hopThese two basic elements. On the basis of this, it can use three of tables to achieve their own efficiency and occupy small space for the purpose. Let me summarize:
The prerequisite for the DXR algorithm is that the routing prefix and the next hop are separated. This premise and its importance! Separating the prefix and the next hop can eliminate data redundancy, and the goal of building a lookup table transforms from building a simple lookup match table to a mapping between a section of the IPV4 address and the next hop table, which leads directly to the interval lookup. Let's look at a very similar trie tree lookup algorithm, where the prefix and the next hop are bound together as a "route item", so the process of finding is an exact match + backtracking process. The DXR algorithm eliminates the backtracking process.
Facilities of the DXR algorithm: Direct index table, interval table, next hop table. I'll say it later, but remember, it's not the core, it's just a way of achieving it.
DXR algorithm table design: Direct Index table meaning the direct Index table incorporates a large IPv4 address interval so that the interval table is searched more quickly in a much smaller number of merged intervals, with the purpose of two tables being the index of the downward-hop table. This establishes the mapping of the interval to the next hop.
Dividing a IPv4 address space into intervals with a route prefix if you don't know what the DXR algorithm is, it doesn't matter, but its thought is simple. The end result of the routing table is to correspond a contiguous address segment to a certain next hop (no discontinuous masks are allowed ...), so the routing table actually divides the entire IPv4 address space into a number of intervals, each of which is associated with only one next hop. I put the correct picture in the article on the record failure experience as follows:
Take the target IP address when the index, go right, hit the first route item is the result. The logic of the longest mask is fully reflected in the Insert/delete process, that is, the left-to-right prefix is shortened sequentially, the long-prefixed route entry is covered by the short prefix of the route entry, which is the core idea. Although I have now denied to take IPV4 address directly to do index, but the core idea has not changed, that is, "take xx map to specific next jump", in the failure record, XX is the IPV4 address index, and in the correct practice, XX is the interval. In fact, in the HIPAC firewall, it is also the use of this idea, that is, interval lookup. In the HIPAC algorithm, the interval is the match field, and the next hop corresponds to rule.
Then, the DXR algorithm is a step-by-step optimization for the above diagram. In order to better illustrate the DXR, I give the transformation form again:
Interval Lookup If you follow the above diagram, the entire IPV4 address space is divided into n intervals, and the final goal of the routing lookup is to correspond a IPV4 address to a certain interval! So far, the work is done. But there is a premise that you need to find out or achieve a high-performance "interval matching algorithm"! , that is, to create a interval table, the internal storage of n interval items, each interval item corresponding to a next-hop index, such as the interval m corresponding to the next hop C, our goal is to give a IPv4 address, to determine which interval it belongs to. Such algorithms abound, their own implementation of a seemingly not difficult, such as dichotomy, hashing algorithm, etc., so this article does not pay attention to these. However, the DXR does not seem to satisfy the discovery, of course I am not satisfied. The DXR seems to want to find a more optimized way to achieve this interval match.
Before we give the framework of the DXR, we find that the DXR is essentially using interval matching to match a target IPv4 address to an interval, and then take out the corresponding next hop for that interval!
Dividing sub-range if the target IPV4 address for each incoming packet is matched in n intervals, it does not seem elegant. If the n interval can be divided into a number of sub-ranges, then the number of matching intervals per match will be greatly reduced, such as n is 100, if the entire IPV4 address space can be divided into 20 equal sub-range, then each matching interval will be 5, not 100!! But here again there is the premise that the cost of the zoning must be offset by the reduction in the number of intervals, and the benefits will be greater!
This time, if you understand the Level two page table is good, a page catalog item contains 1024 page table items, a page table entry points to a 4096-byte size page. The page directory of the entire 32-bit virtual address space is divided into 1024 of the same size of the interval segment, each interval of the size of the 4096*1024,32-bit virtual address corresponding to the 32-bit IPV4 address, this is not the case? However, the Level two page table or multi-level page table solves the problem of sparse address, if it is a first-level page table, then there will be a lot of "holes", this is because the process how to arrange virtual address in the kernel and the MMU seems to be out of control. And for the problems we are encountering, the use of similar grading method is to divide the sub-range so as to improve the efficiency of each interval matching, note that this is not an index for the purpose, I mistakenly indexed as a purpose rather than means, so fell to the abyss of Perdition!
However, for the IPV4 address, do not use 10bit (which is based on the characteristics of virtual address addressing and the size of the page) such a partitioning method, but the K bit partitioning method, note that the routing table does not exist the concept of the page! If K equals 16, then the high 16 bits of the IPV4 address becomes an index, and because of the presence and free value of the low 16 bits, each index table entry includes 16 bits of the IPV4 address, or 65,535 IPv4 addresses. The current interval lookup table becomes the following:
To know, the IPV4 address high 16-bit address can be indexed at a moment, this is an instantaneous operation! Then the following question is "how to properly lay out these sub-zones".
How the Sub-interval layout is structured into a compact structure matters because the compact data structure means that the CPU can be loaded into the cache!
As an example of the last picture above, we certainly want all the intervals to be kept in a row, which seems to be the only way to be compact. We call this compact merged sub-interval table called the interval table, as shown in:
At this time, how can the high 16-bit index table of the IPV4 address differentiate between the 65,535-address intervals in which they are indexed? The answer, of course, is to indicate a starting position and number of intervals. If we show all the illustrations as a final way, then look at:
The above diagram contains only three tables, an index table, a range table, and a next-hop table. About the next hop chart is not drawn, this is because its content is not fixed, can be just an IP address, can also have device information and status information, etc., can also be a linked list for load balancing, of course, can also point to something else. The most critical of these is the first two tables, the index table and the interval table. Both tables can be placed in a very compact space, taking up very little memory, and these two tables will be volunteered to be loaded into the CPU Cache with maximum capacity.
What the DXR is like is a little embarrassed. Because it says it all and says it all.
In fact, the DXR is what the above picture says! Just in the DXR:
The x in 1.DxR refers to the K in the above, in my case, I take 16, in fact it can take a different value. But generally, greater than or equal to 16. 2. The third part of the index table in the figure, the coding optimization data, which can be optimized for definition, makes these tables more compact. 3. If the number of interval tables positioned in the index table is 1, then the Index table can point directly to the next-hop index. Generally speaking, the larger the K value, the larger the index table occupies, if the K value of 32, then embarrassed, the Index table entry is 4G, the interval table no longer exists, because all the IP address to the next hop mapping is clearly refined, this is my own design of the simulation MMU final result, in short, the larger the index table, The more IP address to the next hop mapping of the refinement, the size of the interval table in the statistical sense will be smaller, this is also the embodiment of space change time ... Fixed index table size, the size of the interval table is not fixed, depending on your routing table routing item layout, so you want to use the DXR, not a bit of routing planning ability is not possible, for example, you want to use such as a summary of techniques, in order to make the route can be summarized, you may also need to re-cabling, Let the routes that can be summarized share the next hop connected to the same interface, which in turn involves the ability to route distribution, especially when you are mixing dynamic and static routes. In short, IP routing is more complex, involving the synthesis of capabilities, algorithms, IP address understanding, address planning, routing distribution, dynamic routing, configuration commands, and even integrated cabling ...
I did not say how this table to increase the deletion, which I think can be analyzed by itself, it is mainly affected by dynamic routing, after all, if the line status is not constantly changing, the routing table is generally stable.
The failure of a routing table from analog MMU to the regression of the DXR
