Linux kernel Analysis

Kernel version: 2.6.34

Land from the table as the core data structure of the three-layer protocol, understanding it is essential. Previous analysis of crossings by the table, interested can refer to:

Chapter One: Routing table http://blog.csdn.net/qy532846454/article/details/6423496

The basic data structure and basic operation of the routing table are analyzed.

Second: routing table using http://blog.csdn.net/qy532846454/article/details/6726171

The basic usage of routing table is analyzed.

This will be a more practical example to analyze the use of the routing table in the process, note that the following are the description of the routing cache table, because the routing table after the configuration of the network card address will not be changed again (unless the human to change), the test environment as shown below:

Two hosts Host1 and HOST2, respectively configured IP address 192.168.1.1 and 192.168.1.2, the two host between the network cable direct connection. Perform the following actions on both hosts:

1. Ping the host Host2 on the Host1

2. Ping the host Host1 on the Host2

A very simple example of two hosts pinging each other, the following is an analysis of the routing table changes in the process, ready to say that the routing cache changes. First, there are several entries in the routing cache? The answer is not 2 but 3, which is critical, you can view the routing cache table through/proc/net/rt_cache, the following figure is the result of doing the above:

brcm0.1 is the host of the network card device, equivalent to the commonly used Eth0,lo is the loop device. With a little analysis of the results, you can see that entry 1 and item 2 are exactly the same, except that the use of the count is slightly different, because the cache table is stored in the form of a hash table, although the contents are the same, the key values used in the actual insertion are different. The following is a HOST2 host's routing cache table, which is analyzed for each ping process.

Suppose the brcm0.1 device's index = 2

Step 0: Initial landing is empty by cache

Step 1: Host Host1 ping host Host2

HOST2 receives an echo message from Host1 (DST = 192.168.1.2, src = 192.168.1.1)

After the message enters the IP layer, the routing table is queried to determine how the message is received and the corresponding call flow:

Ip_route_input ()-> Ip_route_input_slow ()

Query the routing cache in Ip_route_input () using a key value of [192.168.1.2, 192.168.1.1, 2, id], and because the cache table is empty, the query fails, and the Ip_route_input_slow () is created and inserted into the new cache entry.

hash = Rt_hash (daddr, Saddr, IIF, Rt_genid (net));

Query the routing table in Ip_route_input_slow () because it is sent to the native and matches 192.168.1.2 Items in the local table, res.type==rtn_local the query results.

if (err = fib_lookup (NET, &FL, &res))!= 0) {     
 if (! In_dev_forward (In_dev))     
  goto E_hostunreach;     
 Goto No_route;     
}

Then according to Res.type jump to the Local_input code snippet, create a new route cache entry and insert the land by the cache.

Rth = Dst_alloc (&ipv4_dst_ops);     
..... Rth->u.dst.dev = net->loopback_dev;     
RTH->RT_DST = daddr;     
RTH->RT_SRC = saddr;     
Rth->rt_gateway = daddr;     
RTH->RT_SPEC_DST = SPEC_DST; (SPEC_DST=DADDR)     
..... hash = Rt_hash (daddr, Saddr, Fl.iif, Rt_genid (net));     
Err = Rt_intern_hash (hash, Rth, NULL, SKB, FL.IIF);

So the first cached information that is inserted is as follows:

Key = [DST = 192.168.1.2 src = 192.168.1.1 idx = 2 id = id]

Value = [Iface = lo dst = 192.168.1.2 src = 192.168.1.1 idx = 2 id = ID ...]

Step 2: Host Host2 send echo reply message to host Host1 (DST = 192.168.1.1 src = 192.168.1.2)

Step 2 is followed by step 1, and Host2 immediately replies to the Echo reply message after receiving the ECHO message and invokes the process accordingly:

Icmp_reply ()-> ip_route_output_key ()-> ip_route_output_flow ()-> __ip_route_output_key ()-> Output_slow ()-> Ip_mkroute_output ()-> __mkroute_output ()

In Icmp_reply (), a key data Flowi in a later route lookup is generated, which can be considered the key value of the lookup, because it is a reply to the received message, so the destination and source IP address are known, and the following structure is daddr=192.168.1.1,saddr= 192.168.1.2.

struct Flowi fl = {. Nl_u = {. 

Ip4_u = {     
  . daddr = Daddr,     
  . saddr = Rt->rt_spec_dst,     
  . Tos = Rt_tos (ip_hdr (SKB)->tos)},     
  . proto = ipproto_icmp};

The Routing cache table is queried at __ip_route_output_key (), and the query's key value is [192.168.1.1, 192.168.1.2, 0, id], because there is only one inserted in the routing cache from the 192.168.1.1-> 192.168.1.2 cache entry, so the query fails and continues to walk Ip_route_output_slow () to create and insert a new cache entry.

hash = Rt_hash (FLP->FL4_DST, FLP->FL4_SRC, flp->oif, Rt_genid (net));

Query the routing table in Ip_route_input_slow (), because in the same network segment, the 192.168.1.0/24 entry is matched in the main table, and the query results are res.type==rtn_unicast.

If 

(fib_lookup (NET, &FL, &res)) {     
...     
}