Bounce Table Walking

There are times when being able to define the table to which you will send a packet is simply not enough. To this point you have specified uses of the RPDB that end in the final routing table destination. You wonder about additional interactions between the rules and route tables.

Example 6.4 ”Throw Routes

Returning to your test network setup you decide to make the two hosts , host1 and host2, appear as two different networks. To make the packet traces obvious, you use 172.16.1.1/24 for host2 and leave host1 on 10.1.1.3/24. On router1 you assign 10.1.1.254/24 and 172.16.1.254/24 to dev eth1 on Network B. After setting up these addresses you verify that host2 can ping all other systems.

So your test setup now has the following machines, addresses, and routes:

 net1     192.168.1.1/24          No Default Route          Static route to 10.1.1.0/24 and 172.16.1.0/24 via router1 router1  eth0: 192.168.1.254/24          eth1: 10.1.1.254/24, 172.16.1.254/24          No additional routes host1    10.1.1.1/24          Default route to 10.1.1.254 host2    172.16.1.1/24          Default route to 172.16.1.254

In order to see how the rules interact with the routing tables you first try a little experiment.

On host2 you add a few additional /32 addresses from the network, say 172.16.1.2-5. These will be the test addresses sending out data to see how the throw route works. You will use the traceroute utility to test using these extra addresses.

What you want to see is how the throw route can be used to bounce out of a routing table back to the rules. To this end on router1 you set up two tables. Each table has a default route pointing to a different router. Then you set up rules that take two of the extra addresses from host2 and send them to different tables. The command setup for this is as follows :

  ip route add default via 10.1.1.2 src 10.1.1.254 table 2   ip route add default via 192.168.1.1 src 192.168.1.254 table 3   ip rule add from 172.16.1.2/32 table 2 prio 15000   ip rule add from 172.16.1.3/32 table 3 prio 15100   ip route flush cache

Now on host2 you issue two different traceroute commands to the same location using the two different addresses. The commands and output you get are as follows:

 [root@host2 /etc]#  traceroute -s 172.16.1.2 192.168.1.1  traceroute to 192.168.1.1 (192.168.1.1) from 172.16.1.2, }         30 hops max, 40 byte packets  1  router1 (10.1.1.254)  20.091 ms  0.566 ms  0.461 ms  2  * * * (and so on) [root@host2 /etc]#  traceroute -s 172.16.1.3 192.168.1.1  traceroute to 192.168.1.1 (192.168.1.1) from 172.16.1.3, }         30 hops max, 40 byte packets  1  router1 (10.1.1.254)  0.976 ms  0.510 ms  0.458 ms  2  net1 (192.168.1.1)  0.700 ms  0.599 ms  0.576 ms

Just as you suspected, the traceroute that uses the 172.16.1.2 source address is sent into routing table 2 on router1. And that routing table contains a default route to host1, which has no knowledge of the destination so the probes just die off. If you look at the packet trace on Network B you will eventually see that an ICMP Destination Unreachable is sent back to 172.16.1.2. Unfortunately, in this case the traceroute program does not ever receive this message but you know that is a problem with the traceroute program itself.

Now you add a throw route to table 2 for the specific traceroute address destination. From Chapter 4 you know that the action of a throw route is to return from the routing table as though the routing lookup has failed. This throw route is added as follows:

  ip route add throw 192.168.1.1/32 table 2

When you now retry that traceroute, it succeeds just like the other address did.

 [root@host2 /etc]#  traceroute -s 172.16.1.2 192.168.1.1  traceroute to 192.168.1.1 (192.168.1.1) from 172.16.1.2, \ =         30 hops max, 40 byte packets  1  router1 (10.1.1.254)  0.982 ms  0.610 ms  0.478 ms  2  net1 (192.168.1.1)  0.679 ms  0.623 ms  0.583 ms

What you logically deduce is that the throw route, being the best match in the routing table, is used for these packets. If you only had a single routing table, this action would have effectively terminated the routing and the packet would have been immediately returned unreachable. But due to the RPDB, the action instead is to evaluate the next rule in the list. In this case the next matching rule is the default rule 32766, which sends the lookup into table main. This table has a route to the destination and the lookup succeeds, with the result that the traceroute then succeeds.

At this point you may be asking yourself why you would ever want to use a throw route. After all, if the routing is set up correctly and Policy Routing is implemented, you should never need to use such a route.

Consider, then, the meshing of Example 6.3 with Example 6.4. What if you had a Web server that was running on a system with multiple addresses and multiple interfaces and routes? Most of the time you want this particular server to route each Web request via a different route depending on the address and interface.

For example, you know that the number one Web server in the Internet, Apache, can assign virtual hosts both to a single address and to multiple addresses. So say you had an Apache server that had two interfaces and each interface had three addresses. The Apache treats each of the six addresses as belonging to a different domain. Furthermore, you have several virtual servers on top of two of the addresses.

Here you are running ten virtual Web servers. Each of these servers has a different set of output files. All of the servers are required to be visible to the corporate network through a single router connection on one of the two networks. This router is specifically set up to only see one of the addresses assigned to the Web server. What you have on the server is a routing table for each address using the loopback rules as in Example 6.3 because each address gets routed through a different router.

You could add a specific route to the corporate network to each router table, but you know that corporate is considering different network schemes for that router and might also add other routers to other parts of the corporate network. In order to simplify your life when corporate changes their mind yet again, you decide to add throw routes to all of these tables for the corporate network. Then you create a new table containing the current routes to corporate and assign a rule after all the other rules that sends the traffic into that table. Now when corporate decides to add routers or change the existing router, you simply change the one table and everything continues to work.

By the way, that is a somewhat real example that I ended up implementing a few years back for a Web server that was both the corporate intranet server and the corporate Internet server. This setup is quite simple and easy to do and highly secure.

Top