Another part of the iproute2 software package, ip rule is the single tool for manipulating the routing policy database under linux (RPDB). For a fuller discussion of the RPDB, see Section 10.3, “Using the Routing Policy Database and Multiple Routing Tables”. The RPDB can be displayed with ip rule show. Particular rules can be added and removed with (predictably, if you have been reading the sections on the other iproute2 tools) ip rule add command and the ip rule del command. We'll make a particular example of the ip rule add nat.
Briefly, the RPDB mediates access to the routing tables. In the overwhelming majority of installations (most workstations, servers, and even routers), there is no need to take advantage of the RPDB. A single IP routing table is all that is required for basic connectivity. In more complex networking configurations, however, the RPDB allows the administrator to programmatically select a routing table based on characteristics of a packet.
Along with this freedom and flexibility comes the power to break networking in strange and unexpected ways. I will reiterate: IP routing is stateless. Because IP routing is stateless, the network architect, planner or administrator needs to be aware of the issues involved with using multiple routing tables.
For a fuller discussion of some of these issues, be sure to read Section 10.3, “Using the Routing Policy Database and Multiple Routing Tables”. Now, let's look at some of the ways to use ip rule.
To display the RPDB, use the command ip route show. The output of the command is a list of rules in the RPDB sorted by order of priority. The rules with the highest priority will be displayed at the top of the output.
Example D.28. Displaying the RPDB with ip rule show
[root@isolde]# ip rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup 253
|
There are some interesting items to observe here. First, these are the three default rules in the RPDB which will be available on any machine with an RPDB. The first rule specifies that any packet from any where should first be matched against routes in the local routing table. Remember that the local routing table is for broadcast addresses on link layers, network address translation, and locally hosted IP addresses.
If a packet is not bound for any of these three destinations, the kernel will check the next entry in the RPDB. In the simple case above, on isolde, a packet bound for 205.254.211.182 would first pass through the local routing table without matching any of the local destinations. The next entry in the RPDB recommends using the main routing table to select a destination route.
In isolde's main routing table, it is likely that there is no host nor network match for this destination, thus the packet will match the default route in the main routing table.
FIXME!! Can anybody (somebody?) explain to me why there is a rule priority 32767 which refers to table 253? I'm still confused about this.
Adding a rule to the routing policy database is simple. The syntax of the ip rule add command should be familiar to those who have read Section D.2, “ip route” or have used the ip route to populate routing tables.
A simple rule selects a packet on the the packet's characteristics. Some characteristics available as selection criteria are the source address, the destination, the type of service (ToS), the interface on which the packet arrived, and an fwmark.
One great way to take advantage of the RPDB is to split different types of traffic to different providers based on packet characteristics. Let's assume two network connections on masq-gw, one that is a highly reliable high cost connection, and a much lower cost less reliable connection. Let's also assume that we are using Type of Service flags on IP packets on the internal network.
We might want to prefer a low-latency, highly reliable link for one type of packet. By using tos as a selection criterion with ip rule we can effectively route these packets via our faster and more reliable internet connection.
Example D.29. Creating a simple entry in the RPDB with ip rule add [56]
[root@masq-gw]# ip route add default via 205.254.211.254 table 8
[root@masq-gw]# ip rule add tos 0x08 table 8
[root@masq-gw]# ip route flush cache
[root@masq-gw]# ip rule show
0: from all lookup local
32765: from all tos 0x08 lookup 8
32766: from all lookup main
32767: from all lookup 253
|
Note that the rule we inserted was added to the next available higher priority in the RPDB because we did not specify a priority. If we wished to specify a priority, we could use prio.
Now any packet with an IP ToS field matching 0x08 will be routed according to the instructions in table 8. If no route in table 8 applies to the matched packet (not possible, since we added a default route), the packet would be routed according to the instructions in table "main".
The selection criteria for matching a packet can be grouped. Let's look at a more complex example of ip rule where we use multiple selection criteria.
Example D.30. Creating a complex entry in the RPDB with ip rule add
[root@masq-gw]# ip rule add from 192.168.100.17 tos 0x08 fwmark 4 table 7
|
Frankly, that's a very complex rule! I do not know if I could describe a scenario where this particular rule would be required. The point, though, is that you can have arbitrarily complex selection criteria, and multiple rules which lookup routes in as many of the 253 routing tables as you wish.
ip rule add, while a powerful tool, can quickly make a routing table or router too complex to easily understand. It's important to try to design and implement the simplest configuration to maintain on your router. If you cannot avoid using multiple routing tables and the RPDB, at least be systematic about it.
As discussed more thoroughly in Chapter 5, Network Address Translation (NAT), this is the other half of iproute2 supported network address translation. The two components are ip route add nat and ip rule add nat.
ip rule add nat is used to rewrite the source IP on packets during the routing stage. Each packet from the real IP is translated to the NAT IP without altering the destination address of the packet.
NAT is commonly used to publish a service in an internal network on a public IP. Thus packets returning to the public network need to be readdressed to appear with a source address of the publicly accessibly IP.
Example D.31. Creating a NAT rule with ip rule add nat
[root@masq-gw]# ip rule add nat 205.254.211.17 from 192.168.100.17
[root@masq-gw]# ip rule show
0: from all lookup local
32765: from 192.168.100.17 lookup main map-to 205.254.211.17
32766: from all lookup main
32767: from all lookup 253
|
In more complex situations, entire subnets can be translated to provide NAT for a range of IPs. The example below shows how to specify the ip rule add nat to complete the NAT mapping in Example D.22.
Example D.32. Creating a NAT rule for an entire network with ip rule add nat
[root@masq-gw]# ip rule add nat 205.254.211.32 from 192.168.100.32/29
[root@masq-gw]# ip rule show
0: from all lookup local
32765: from 192.168.100.32/29 lookup main map-to 205.254.211.32
32766: from all lookup main
32767: from all lookup 253
|
Notice the ip rule synonym for the nat option. It is valid to substitute map-to for nat.
Naturally, no iproute2 tool would be complete without the ability to undo what has been done. With ip rule del, individual rules can be removed from the RPDB.
It is at first quite confusing that the word all in the ip rule show output needs to be replaced with the network address 0/0. I do not know why all is not acceptable as a synonym for 0/0, but you'll save yourself some headache by getting in the habit of replacing all with 0/0.
By replacing the verb add in any of the command lines above with the verb del, you can remove the specified entry from the RPDB.
Example D.33. Removing a NAT rule for an entire network with ip rule del nat
[root@masq-gw]# ip rule del nat 205.254.211.32 from 192.168.100.32/29
[root@masq-gw]# ip rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup 253
|
The ip rule utility can be a great boon in the manipulation and maintenance of complex routers.
[56] Please note that this is an incomplete example. Simply put, I'm not dealing with the issues of inbound packets or packets destined for locally connected networks in this example. Keep in mind the instructional nature of this example, and plan your own network accordingly. For a fuller discussion of the issues involved with handling multiple Internet links, see Section 10.4, “Multiple Connections to the Internet”. Note also, that there is no corresponding network connection in the example network for this network connection.