Shulou(Shulou.com)06/01 Report--

This article mainly explains "what are the knowledge points of Linux routing table". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what are the knowledge points of Linux routing table.

Routing tables are data files stored in RAM that store information about directly connected and remote networks. The routing table contains the information associated with the network and the next hop. These associations tell the router that to reach a destination in the best way, a packet can be sent to a specific router (that is, the "next hop" on the way to the final destination). The next hop can also be associated with an outgoing or outgoing interface to the final destination.

Linux routing table maintenance

Use the following route command to view the Linux kernel routing table.

# routeDestination Gateway Genmask Flags Metric Ref Use Iface192.168.0.0 * 255.255.255.0 U 000 eth0169.254.0.0 * 255.255.0.0 U 000 eth0default 192.168.0.1 0.0.0 UG 000 eth0

Description of the output item of the route command

The output item describes the Destination target network segment or host Gateway gateway address. "*" indicates that the destination is the network to which the host belongs and does not need to route the Genmask netmask Flags tag. Some possible tags are as follows:

U-routing is active

H-the target is a host

G-Route points to Gateway

R-restore table entries generated by dynamic routin

D-dynamically installed by the routed daemon

M-modified by the routing daemon

!-deny the Metric routing distance, the number of transfers required to reach the specified network (not used in the linux kernel) the number of references to the Ref routing item (not used in the linux kernel) Use the number of times this routing item is looked up by the routing software Iface the output interface corresponding to the routing table entry

Show details

Three routing types of host routin

A host route is a route record in the routing table that points to a single IP address or hostname. The Flags field of the host route is H. For example, in the following example, the local host reaches the host with the IP address 10.0.0.10 through the router with IP address 192.168.1.1.

Destination Gateway Genmask Flags Metric Ref Use Iface--10.0.0.10 192.168.1.1 255.255.255.255 UH 000 eth0 network routing

A network route represents a network that can be reached by a host. The Flags field of the network route is N. For example, in the following example, the local host forwards packets sent to network 192.19.12 to the router with the IP address 192.168.1.1.

Destination Gateway Genmask Flags Metric Ref Use Iface--192.19.12 192.168.1.1 255.255.255.0 UN 000 eth0 default route

When the host cannot find the IP address or network route of the target host in the routing table, the packet is sent to the default route (default gateway). The Flags field of the default route is G. For example, in the following example, the default route is the router with the IP address 192.168.1.1.

Destination Gateway Genmask Flags Metric Ref Use Iface--default 192.168.1.1 0.0.0.0 UG 000 eth0 configure static route route command

You can use the route command to set and view the routing table. The command format for setting the kernel routing table is:

# route [add | del] [- net |-host] target [netmask Nm] [gw Gw] [[dev] If]

Where:

Add: add a routing rule del: delete a routing rule-net: destination address is a network-host: destination address is a host target: destination network or host netmask: network mask for destination address gw: gateway for routing packets dev: network interface specified for routing example route command

Routes added to the host

# route add-host 192.168.1.2 dev eth0:0# route add-host 10.20.30.148 gw 10.20.30.40

Routes added to the network

# route add-net 10.20.30.40 netmask 255.255.255.248 eth0# route add-net 10.20.30.48 netmask 255.255.255.248 gw 10.20.30.4 percent route add-net 192.168.1.0 eth2

Add default rout

# route add default gw 192.168.1.1

Delete a rout

# route del-host 192.168.1.2 dev eth0:0# route del-host 10.20.30.148 gw 10.20.30.4 route del-net 10.20.30.40 netmask 255.255.255.248 eth0# route del-net 10.20.30.48 netmask 255.255.255.248 gw 10.20.30.4 percent route del-net 192.168.1.0 Universe 24 eth2# route del default gw 192.168.1.1 setup packet forwarding

The default kernel configuration in CentOS already includes routing, but it is not enabled by default at system startup. The routing function of Linux can be enabled by adjusting the network parameters of the kernel. To configure and adjust kernel parameters, you can use the sysctl command. For example, to enable packet forwarding in the Linux kernel, you can use the following command.

# sysctl-w net.ipv4.ip_forward=1

After this setting, the current system can achieve packet forwarding, but it will fail the next time the computer is started. To make it still valid the next time you start the computer, you need to write the following line to the configuration file / etc/sysctl.conf.

# vi / etc/sysctl.confnet.ipv4.ip_forward = 1

Users can also use the following command to see if the current system supports packet forwarding.

# sysctl net.ipv4.ip_forward

=

Structure and algorithm Analysis of Linux routing Table

Huang Yiwen

Routing is the core part of the network stack. The design of the routing table itself affects the performance of the routing to a great extent, and a good design can reduce the consumption of system resources, especially in the routing table lookup. At present, there are two kinds of lookup algorithms in kernel routing, one is HASH algorithm, the other is LC-trie algorithm, the former is the default algorithm used by kernel at present, while the latter is more suitable for super-large routing table, it not only improves the lookup efficiency, but also greatly increases the complexity of the algorithm itself and memory consumption. To sum up, these two algorithms have their own applicable occasions. This paper analyzes the implementation of the routing table structure of the HASH algorithm based on the 2.6.18 kernel routing code, and gives a simple application of policy routing at the end of the article.

I. the structure of the routing table

To support policy routing, Linux uses multiple routing tables instead of one, and even without policy routing, Linux uses two routing tables, one for uploading to the local upper layer protocol and the other for forwarding. Linux uses multiple routing tables instead of one, so that routes with different strategies are stored in different tables, which effectively avoids searching huge routing tables, and improves the search efficiency to a certain extent.

The routing table itself is not represented by a single structure, but by a combination of multiple structures. The routing table can be said to be a hierarchical combination of structures. In the first layer, it divides all routes into 33 parts (structfn_zone) according to the length of the subnet mask (netmask) (0,32), and then divides the routes into the second layer (struct fib_node) in the same subnet mask (the same layer) according to the different subnets (such as 10.1.1.0 and 10.1.2.0). In the same subnet, different routes may be used due to different attributes such as TOS. This is layer 3 (structfib_alias). The layer 3 structure represents a routing table entry, and each routing table entry includes a corresponding parameter, such as protocol, next-hop routing address, and so on. This is layer 4 (structfib_info). The benefits of layering are obvious: it makes routing tables more optimized, logically cleaner, and enables data to be shared (such as structfib_info), thereby reducing data redundancy.

Struct fib_table * fib_ tables [RT _ TABLE_MAX+1]; / / RT_TABLE_MAX is 255

Figure 1 shows the overall structure of a routing table. From top to bottom, looking from left to right, it is first an array of fib_table structure pointers, which is defined as:

Struct fib_table {unsigned char tb_id;unsigned tb_stint (* tb_lookup) (struct fib_table * tb, const struct flowi * flp, struct fib_result * res); int (* tb_insert) (struct fib_table * table, struct rtmsg * r, … Void (* tb_select_default) (struct fib_table * table,const struct flowi * flp, struct fib_result * res); unsigned char tb_data [0];}

Each fib_table structure represents a routing table in the kernel:

+

Figure 1 (quoted from [1])

This structure includes the ID of this table, as well as some of the main function pointers used to manipulate the routing table. Here we are only concerned with the last field, tb_data [0], which is a zero-length array, which is also common in the kernel.

Struct fn_hash {struct fn_zone * fn_zones [33]; struct fn_zone * fn_zone_list;}

Point to the end of this structure. As you can see in figure 1, the end of this structure is followed by a struct fn_hash structure, which is assigned along with the fib_table structure, so fib_table- > tb_data is fn_hash.

Struct fn_zone {struct fn_zone fz_next; / Next not empty zone * / struct hlist_head fz_hash; / Hash table pointer / int fz_nent; / Number of entries / int fz_divisor; / Hash divisor / U32 fz_hashmask; / (fz_divisor-1) / # define FZ_HASHMASK (fz) ((fz)-> fz_hashmask) int fz_order; / Zone order * / U32 fz_mask;#define FZ_MASK (fz) ((fz)-> fz_mask)}

This fn_ domain is our earlier structure to split the route into 33 parts according to the length of the subnet mask, where fn_zones [0] is used for the default gateway. The fn_zone_list domain is to link the fn_zone being used into a linked list. Then go deep into the struct fn_zone structure:

There are two important fields in this structure, one is the fz_ hash domain, which points to the header of a HASH table, and the length of the HASH is fz_divisor. And the length of the HASH table is variable, when the table length reaches a limit, the HASH table will be rebuilt to avoid the excessive length of the HASH conflict table, which will reduce the search efficiency.

In order to improve the efficiency of lookup, the kernel uses a large number of HASH tables, and the routing table is an example. As you can see in figure 1, the route of the equal subnet mask is stored in the same fn_zone, and it is HASH into the corresponding linked list according to the route key value (fn_key) to different subnets (fib_node).

Struct fib_node {struct hlist_node fn_hash;struct list_head fn_alias;u32 fn_key;}

The key value is actually the subnet value (for example, 10.1.1.0 to 24, then the subnet value is 10.1.1). The key value obtained through the n = fn_hash () function HASH is the hash value corresponding to this subnet, and then can be inserted into the corresponding fz_hash [n] linked list. The conflicting fib_node is linked by the fn_ hash domain, and the fn_alias points to the route to this subnet.

Struct fib_alias {struct list_head fa_list;struct rcu_head rcu;struct fib_info * fa_info;u8 fa_tos;u8 fa_type;u8 fa_scope;u8 fa_state;}

When routes to this subnet can have multiple routes due to different attributes such as TOS, they chain these routing tables into a linked list through the fa_ list field in fib_alias. Another field in this structure, fa_info, points to a fib_info structure, which is the structure that holds really important routing information.

Struct fib_info {struct hlist_node fib_hash;struct hlist_node fib_lhash;. Int fib_dead;unsigned fib_flags;int fib_protocol;u32 fib_prefsrc;u32 fib_priority;... Int fib_nhs;struct fib_nh fib_nh [0]; # define fib_dev fib_nh [0] .nh _ dev}

Show details

Inside this structure is a flag and attribute for routing, and the most important field is fib_nh [0]. Here, we see the application of zero-length array again, which realizes the function of variable-length structure through zero-length. Because we need a fixed-length fib_info structure, but at the end of this structure, the number of fib_nh structures we need is uncertain, which is determined at run time. In this way, we can use this structure to allocate several required fib_nh structure arrays at the end of the runtime when allocating space for fib_info, and this structure array can be accessed through fib_info- > fib_ NH [n], and the fib_nhs field is set to the length of this array after the allocation of fib_info is completed.

On the other hand, fib_info is also an application of HASH table. There are two fields in the structure, fib_hash and fib_lhash, both of which are used in HASH linked lists. After the allocation is completed, this structure will be linked to the fib_info_ hash table using the fib_hash domain, and if the route has a preferred source address, the fib_info will also be linked into the fib_info_ laddrhash table using fib_lhash. In this way, you can find it quickly according to different purposes.

Structfib_nh is also an important structure. It stores the address of the next-hop route (nh_gw). As just mentioned, a route (fib_alias) may have multiple fib_nh structures, which indicates that the route has multiple next-hop addresses, that is, it is multipath. There are also a variety of algorithms for next-hop address selection, all of which are based on the nh_weight,nh_ power domain. The nh_ hash field is used to link nh_hash into the HASH table.

Struct fib_nh {struct net_device * nh_dev;struct hlist_node nh_hash;struct fib_info * nh_parent;unsigned nh_flags;unsigned char nh_scope;#ifdef CONFIG_IP_ROUTE_MULTIPATHint nh_weight;int nh_power;#endif#ifdef CONFIG_NET_CLS_ROUTE__u32 nh_tclassid;#endifint nh_oif;u32 nh_gw;}

Show details

Second, route lookup

The lookup speed of the route directly affects the performance of the route and the whole network stack. Of course, the lookup of the route first occurs in the route cache, and when the lookup fails in the cache, it goes to the routing table for lookup, which is the focus of this article.

The composition of the routing table has been described in detail in the previous section. When a main IP layer is about to send or receive an IP packet, it will call the routing subsystem to complete the route lookup work. Routing table lookup is to find the appropriate address of the next hop route in a routing table according to the given parameters.

As mentioned above, when a host does not support policy routing, it only uses two routing tables, one is ip_fib_local_table for local use, and the other is ip_fib_main_table for receiving and sending. It will look for ip_fib_main_table only if it does not find a matching route (not sent locally) when looking up the ip_fib_local_table table. When a host supports policy routing, it may have multiple routing tables, so the choice of routing table is part of the lookup. The choice of the routing table is determined by the policy, and the policy is specified by the application (user), such as through the iprule command:

Ip rule add from 10.1.1.0/24 table TR1ip rule add iff eth0 table RT2

As above, the first command creates a policy based on source address routing, which uses the RT1 routing table, and the second command creates a policy based on packet entry, which uses the RT2 routing table. When the specified routing table does not exist, the corresponding routing table is created.

The second step is to traverse the fn_zone of the routing table, starting with the fn_zone with the longest prefix (the longest subnet mask) until it is found or an error occurs. Because the longest prefix is the best match. Suppose you have the following routing table:

Dst nexthop dev10.1.0.0/16 10.1.1.1 eth010.1.0.0/24 10.1.0.1 eth2

It first finds the second route and then chooses 10.1.0.1 as the next-hop address. However, if the subnet (fib_node) located in step 2 has more than one route, it is as follows:

Dst nexthop dev10.1.0.0/24 10.1.0.1 eth210.1.0.0/24 10.1.0.2 eth2

There are two optional routes to the same subnet, which cannot be determined by the destination subnet alone, so it needs more information to determine the route choice, which is why the structflowi used to find the route includes other information (such as TOS). In this way, it can locate an fib_alias instance corresponding to a route. And the fib_info it points to is the information needed for routing.

Finally, if the kernel is compiled to support multipath (multipath) routing, there are multiple fin_nh in the fib_info, so it has to select the most appropriate fib_nh from the fib_nh array as the next-hop route.

III. Insertion and deletion of routes

The insertion and deletion of the routing table can be seen as an application of routing lookup, and the process of inserting and deleting itself also includes a process of lookup. Both operations need to check whether the inserted or deleted routing table entry exists. Inserting an existing routing table entry requires special processing, and deleting a non-existent routing table entry will certainly make an error.

Let's look at an example of routing table insertion:

Ip route add 10.0.1.0/24 nexthop via 10.0.1.1 weight 1nexthop via 10.0.1.2 weight 2table RT3

This command creates a new route in the kernel. It first looks for a fn_zone with a subnet mask of 24 in the routing table RT3, and if it cannot find it, it creates a fn_zone. Next, continue to look for the fib_node with subnet 10.0.1, and again, if it doesn't exist, create a fib_node. Then it creates a new fib_info structure, which contains an array of two fib_nh structures (because there are two nexthop), initializes the structure based on the information passed from user space, and finally the kernel creates a fib_alias structure (if it already exists, an error), initializes the corresponding domain with fib_nh, and finally chains itself into the fib_node chain. In this way, the route insertion operation is completed.

The route deletion operation is the reverse process of the insert operation, it includes a series of search and memory release operations, the process is relatively simple, so I will not repeat it here.

Fourth, a simple application of policy routing

Linux systems will use multiple routing tables when policy routing is turned on. Unlike some other systems, it only uses a single routing table in all cases. Although policy routing can also be implemented using a single routing table, as mentioned earlier in this article, better performance can be achieved by using multiple routing tables, especially in a large routing system. The following is only a simple case to illustrate the application of policy routing under Linux.

As shown in figure 2, there is an application requirement with three network interfaces on the gateway server. The IP of interface 1 is 172.16.100.1, the subnet mask is 255.255.255.0, the gateway gw1 is a.b.c.dline 172.16.100.0x24, and the IP of interface 2 is 172.16.10.1, the subnet mask is the same as interface 1, and the gw2 of the gateway is e.f.g.h.172.16.10.10.24. Hosts in this segment can access the Internet through this gateway. The IP of interface 0 is 192.168.1.1, and the hosts in this segment need to be routed out through the faster gateway e.f.g.h due to the need for network bandwidth.

Img

Figure 2

Step 1: set the IP of each network interface and the default gateway:

Ip addr add 172.16.100.1/24 dev eth2ip route add default via a.b.c.d dev eth2

The other interface IP has the same settings as the first interface, and if there is no other setting, all data is routed out through this default gateway.

Step 2: make the subnet 172.16.10.Universe 24 routed out via gw2

Ip route add 172.16.10.0/24 via e.f.g.h dev eth3

Step 3: add a routing table

Echo "250 HS_RT" > > / etc/iproute2/rt_tables

Step 4: use policy routing to enable hosts in the network segment of 192.168.1.0 to access the Internet through the gateway e.f.g.h.

Ip rule add from 192.168.1.0 dev eth0 table HS_RT pref 32765ip route add default via e.f.g.h dev eth3iptables 24 dev eth0 table HS_RT pref 32765ip route add default via e.f.g.h dev eth3iptables-t nat-A POSTROUTING-s 192.168.1.0 Accord 24-j MASQUERADE

Step 5: refresh the routing cache to make the new routing table effective

Ip route flush cache

In this way, the policy routing required above can be implemented, and the traceroute tool can be used to check whether the above settings work properly.

* *

**

I will not say how to set up the linux dual network card. I am talking about the traffic problem of the linux dual network card. Maybe this question is biased. You may not need it. I still have to say...

Problem description, a linux host, the above two network cards..:)

The output of route-n looks like this.

Destination Gateway Genmask Flags Metric Ref Use Iface 61.132.43.128 0.0.0.0 255.255.255.192 U 0 0 0 eth2127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo0.0.0.0 61.132.43.134 0.0 . 0.0 UG 0 0 0 eth0

Explain here... The first line says that if you want to access the network segment 61.132.43.128 with a mask of 255.255.255.192. Get out of the network card e th2.. The second line is about the local machine. Visit yourself and go from the virtual local network card lo.. The third line is that if you want to go anywhere.. Exit the gateway 61.132.43.134. And the network card is eth0.

Here we see.. Apart from going to 61.132.43.128, the network is from eth2.. I go to other places from eth0 places.

Is this a waste of dual network cards? That's right. It's wasteful. Because no matter which monitoring tool you use to check the traffic.. It's all eth0. But other network cards do not … Oh, my God... I took great pains to do this. I even wonder if the network card is broken. Because on win2k, this kind of worry supports ⑸.:)

So how do we solve this problem? Some people may say that just give a different gateway and let another network card use another gateway.. It is the strong tip.. But the problem is that my ip is all on the same network segment.. Where are the different gateways coming from? The gateway is only 61.132.43.134.

Fortunately, the linux system provides us with a good routing suite-iproute2.

Let's familiarize ourselves with. Iproute2 consists of several common commands.. Ip ro ls ip is the ip command, ro is written by route, and ls is the abbreviation of list. The whole command is to list the routing table of the system.. This is similar to the effect of route-n.. But it is more clear how the route of the system is..

Let's take a look:

[root@localhost root] # ip ro ls 61.132.43.128/26 dev eth2 proto kernel scope link src 61.132.43.136 127.0.0.0/8 dev lo scope link default via 61.132.43.134 dev eth0

Is it the same? It is different from several places.. A src is added to the first entry, which increases the choice of source packets, and the subnet mask is changed to / 26. (refer to the ip address book) the last one is still the gateway.

Now we just need to make a little effort to keep the traffic from 61.132.43.136 from eth0.. Let him go eth2 and we will add a custom routing table.

Ip ro add default via 61.132.43.134 table 200

Here is just a default route to a custom routing table 200, the maximum value is 255, but you do not use 255, because that is the system default. You can use less than 200. The specific routing table is in / etc/iproute2/rt_tables

To view the routing table just established, you can use ip ro ls table 200.

[root@localhost root] # ip ro ls table 200 default via 61.132.43.134 dev eth2

Did you see that? Although I didn't specify what dev is. But the system automatically assigns an eth2 to the routing table because eth0 is already used in the primary routing table. This also shows that it is really impossible to have the same gateway in the same routing table. Although it can be set, it has no effect.

Then we're going to use a rule to boot the matching packet into the routing table that we just created.:)

Ip ru add from 61.132.43.136 table 200

Here ru is the abbreviation of rule. From is a matching action. It is the packet whose source address is 61.132.43.136. Please customize the settings of Killer.:)

Check it out

[root@localhost root] # ip ru ls 0: from all lookup local 32765: from 61.132.43.136 lookup 200 32766: from all lookup main 32767: from all lookup 253

Ip ro flush cache

Under linux, double network cards have the same network segment, and you can turn on IP_FORWARD, so that one network card down data will go out from another network card = linux routing table

Wednesday, 18 August 2010, 17:44

The macro config _ IP_MULTIPLE_TABLES represents a routing policy, and when this macro is defined, it means that the kernel is configured with a routing policy. The biggest difference is that the kernel can use up to 256 FIB. In fact, the representation of these 256pieces of FIB in the kernel is a global array: struct fib_table * myfib_ tables [RT _ TABLE_MAX+1], while the macro RT _ TABLE_MAX is defined as follows:

Enum rt_class_t {undefined RT_TABLE_UNSPEC=0, RT_TABLE_DEFAULT=253, RT_TABLE_MAIN=254, RT_TABLE_LOCAL=255, * * RT_TABLE_MAX}; # define RT_TABLE_MAX (* * RT_TABLE_MAX-1)

We can see that although there are 256 items in this table, there are only three most commonly used representations given by the enumerated type rt_class_t, and there are only two routing tables generated by the kernel configuration at system initialization. The main table holds all route entries with the route type RTN_UNICAST, that is, gateways or directly connected routes.

The main entry is added to the myfib_add_ifaddr function as follows: for an IP address of a network device interface, if the network number of the destination address is not zero network (network number and subnet number are both zero), and it is a primary address, it is not a class D address (network number and subnet number occupy 32 bits). The final condition is that it is not a loopback address (there is a flagIFF_LOOPBACK on device). Then, it is added as a main entry, or if it is a loopback address, as a table entry of the local table. In our system, there are two open network device interfaces eth0 and lo,eth0 that are configured with primaryIP address 172.16.48.2, so there is only one entry in the main table accordingly. When you add a route entry to the main table, the destination address of the route entry is all hosts in the subnet (zeroing out some bytes of the host number), and corresponding to lo, there is also an entry in the local table of type RTN_LOCAL. The other routing items are all classified into the local table, mainly broadcast routing items and local routing items. In our system environment, there are seven items in the local table and three items for each network device interface. They are local address (source is the same as destination address), subnet broadcast address (host number is all 1), subnet broadcast address (host number is zero). Plus a RTN_LOCAL entry for lo.

Now let's look at the route addition strategy of the myfib_add_ifaddr function. For an incoming ip address (represented by a structural structin_ifaddr), if it is an secondary address, first make sure that there is an primary address of the same type on the same network device interface (the network number is exactly the same as the subnet number), because the source address in the information of the route entry is all primary, and the secondary address is not actually used, and it will not generate a routing entry in the routing table. Then, add an entry to the local table with its own address and a routing entry of type RTN_LOCAL; if a broadcast address exists in the ip address structure and is not a restricted broadcast address (255.255.255.255), add a broadcast routing entry to the local table Then, it is judged that the conditions for joining the main table are met. If so, in addition to adding the main table, finally, if it is not a class D address, two broadcast addresses should be added (in fact, there is already overlap with the previous address, and in many cases, the join action will not be actually triggered. Just remember that there are at most two broadcast addresses corresponding to an ip address entry).

Multiple routing tables (multiple Routing Tables)

Traditional routing algorithms use only one routing table. But in some cases, we need to use multirouting tables. For example, a subnet is connected to the outside world through a router, and the router is connected to the outside world by two lines, one of which is faster and the other is slower. For most users in the subnet, there are no special requirements for speed, so they can use slower routes, but there are some special users in the subnet who are more demanding on speed. so they need to use faster routes. The above requirements cannot be achieved by using a routing table, and if different routing tables are used for different users according to the source address or other parameters, the performance of the router can be greatly improved.

Rules (rule)

Rule is a strategic and critical new concept. We can describe rules like this in natural language. For example, we can specify rules like this:

Rule 1: "all IP packets from 192.16.152.24 use routing table 10, and the priority of this rule is 1500"

Rule 2: "all packets, use routing table 253, the priority of this rule is 32767"

We can see that the rule contains three elements:

What kind of package will apply this rule (the so-called SELECTOR, maybe filter can better reflect its function)

What action (ACTION) will be taken by packages that comply with this rule, such as using that table

The priority of this rule. The higher the priority, the earlier the rules match (the smaller the value, the higher the priority).

The configuration method of Strategic routing

The traditional tool for configuring routing under linux is route, while the tool for implementing strategic routing configuration is the iproute2 toolkit. This package is developed by Alexey Kuznetsov and the main website of the package is ftp://ftp.inr.ac.ru/ip-routing/. Here is a brief introduction to the configuration of strategic routing in order to better understand the content of the second part. For detailed usage, please refer to the ip-cfref document written by Alexey Kuznetsov. The configuration of strategic routing mainly includes interface address configuration, routing configuration and rule configuration.

Configuration IP Addr of interface address

The configuration of the interface can be done with the following command:

Usage: ip addr [add | del] IFADDR dev STRING

For example:

Router > # ip addr add 192.168.0.1 hand 24 broadcast 192.168.0.255 label eth0 dev eth0

According to the above, the 192.168.0.1 mask given to the interface eth0 is 255.255.255.0 (24 represents the number of 1s in the mask), and the broadcast address is 192.168.0.255.

Configuration IP Route of rout

Linux can support up to 255routing tables, three of which are built-in:

Table 255 Local routing Table (Local table) Local interface address, broadcast address, and NAT address are all placed in this table. The routing table is automatically maintained by the system and cannot be modified directly by the administrator.

Table 254Primary routing Table (Main table) if it does not specify the table to which the route belongs, all routes are placed in this table by default, and generally speaking, routes added by old routing tools (such as route) will be added to this table. It's usually an ordinary route.

Table 253 default routing table (Default table) generally default routes are placed in this table, but all gateway routes can also be placed if specified.

Table 0 reserved

The format of the route configuration command is as follows:

Usage: ip route list SELECTOR ip route change del | add | append | replace | monitor ROUTE

If you want to view the contents of the routing table, you can use the command:

Ip route list table table_number

Operations for routing include change, del, add, append, replace, monitor and so on. For example, you can add a route by:

Router > # ip route add 0 table main router 0 via 192.168.0.4 table main router > # ip route add 192.168.3.0 table 24 via 192.168.0.3 table 1

The first command is to add a route to the primary routing table (main table), table 254, which sets 192.168.0.4 as the gateway.

The second command adds a route to routing table 1. The gateway for subnet 192.168.3.0 (subnet mask 255.255.255.0) is 192.168.0.3.

In a multi-routing table routing system, all routing operations, such as adding routes to the network routing table, or looking for specific routes in the routing table, need to specify the routing table to operate, and all do not specify the routing table. The default is to operate on the primary routing table (Table 254). In the single-table system, the routing operation does not need to specify the routing table.

Thank you for your reading. These are the contents of "what are the knowledge points of the Linux routing table". After the study of this article, I believe you have a deeper understanding of the knowledge points of the Linux routing table, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.