IP Routes
IP Routes
The second major building block of Policy Routing is the usage and concept of IP routes. Under traditional routing this is the only element that is considered , and it is relegated to a single use. Traditionally, all routes were destination based. As discussed in Chapter 2 and fit into the Policy Routing hierarchy in Chapter 3, routes may be based on any and all parts of an IP network packet. Additionally, routes no longer just specify where a packet may be forwarded, but specify additional actions as well.
The full coverage of Policy Routing allows actions on the route both at the host and at the router level. The router level is obvious but why would a host have any participation? The host level is often where the initial participation in the network can be very fruitful. If you recall the analogy to the driveway as used in the beginning of Chapter 2, then you see the place for the host system to participate in the routing structure.
When you consider the host system participation you may assume one of several network configurations. The simplest is the multiple router scenario, where you are interested in placing the policy logic on the host because you may have several traditional routers in place. Additionally, you may have to consider the multiple network scenario where your host system has one interface but there are several logical IP networks coexistent on the physical network. You saw a limited example of this in the IP addressing earlier.
Example 5.3: Host Routing
To illustrate both of these scenarios, consider that you have a host system with a single Ethernet interface. This interface is configured as in Example 5.1, so you have a single interface with the following three IP addresses defined:
etho: 10.1.1.1/8 172.16.1.1/16 192.168.1.1/24
You happen to know that most of the other machines are addressed within the 10/8 network scope because that is the defined corporate standard network. The 172.16/16 scope is used by the system administration group and the 192.168.1/24 scope is used by the engineering testing lab group .
The core router for the corporation connecting to the outside world has an address of 10.254.254.254. It should be the default router for all traffic to the Internet. Additionally, you know that this core router also has an address of 172.16.254.254, which is used as the management address for the router by the administrative group. A second router exists with address 192.168.1.254 and it connects to the engineering test lab systems, which exist within scope 192.168.2/24.
At this point with only the addresses defined on your eth0 interface you can ping and receive responses from all of the routers you know about on the network. But why can you ping, for example, the 172.16.254.254 router interface and receive a response? Or indeed why do any of the addresses respond to you?
This is a function of the automatic route creation that occurs whenever you add an IP address to the system that defines a scope with more than one member. Earlier when you defined your IP addressing scopes you used a CIDR mask that as a network mask defined more than just your sole IP address. In other words, 192.168.1.1/24 defines a scope that includes any address from 192.168.1.0/24 through 192.168.1.255/24 inclusive. Under Linux Policy Routing, this automatically defines the corresponding network route to the route table. This is why the scope is what ties together the notion of address and network.
Look at the current routing table on this system as shown by ip route list:
10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.1.1 172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.1.1 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 127.0.0.0/8 dev lo scope link
Note especially how the routes for the additional addresses are coded. In all of these cases there is a field that tells the system which source address to use on the packet. So when you ping 10.254.254.254, you use a source address of 10.1.1.1. What if you wanted complete control over the route creation? Think then of the definition of scope. The address scope is what ties together the address with the network. The smallest definable network then consists of a single address, and the route to a single address is the address itself. So to turn off automatic route creation you can simply specify all of your addresses as host addresses.
To try this, run through the following command sequence. First you will clear all your addresses, then you will add in your addresses with full /32 scopes, and then you will view the output of your route table.
ip addr flu dev eth0 ip addr add 10.1.1.1/32 dev eth0 brd 10.255.255.255 ip addr add 172.16.1.1/32 dev eth0 brd 172.16.255.255 ip addr add 192.168.1.1/32 dev eth0 brd 192.168.1.255 ip ro list 127.0.0.0/8 dev lo scope link
Note that the output of your route table contains only the loopback device route. None of the addresses you entered are in the route table. Now you want to add the routes that had been autocreated before. This will show you what the full standard route commands do.
ip ro add 10/8 proto kernel scope link dev eth0 src 10.1.1.1 ip ro add 172.16/16 proto kernel scope link dev eth0 src 172.16.1.1 ip ro add 192.168.1/24 proto kernel scope link dev eth0 src 192.168.1.1
Now if you do a ip ro list you will see that your routing table is exactly the same as when you ran ip route list . Just for kicks, what do you suppose will happen if you change the src parameter? Try the following commands:
ip ro del 172.16/16 proto kernel scope link dev eth0 src 172.16.1.1 ip ro add 172.16/16 proto kernel scope link dev eth0 src 192.168.1.1
When you look at your route table with ip ro list you see that the route to 172.16.0.0/16 is coded using a src of 192.168.1.1. Now could you ping the 172.16.254.254 router? Probably not. As you recall from the intro to this exercise it only had a 10/8 and a 172.16/16 address defined. So when your packet with a source address of 192.168.1.1 hits it, it does not know how to respond ”that is, if your packet even gets to the router interface in the first place. And yes this is a complicated way to spoof an address.
The most important part of this illustration is that you can now play what I refer to as loopy routing. For example, suppose the core router, 10.254.254.254, had a connection to the engineering 192.168.2.0/24 network and that it had a route to 192.168.1.0/24 via the engineering router. So when you now send out your ping to 172.16.254.254 it responds by sending back a packet to you through the engineering network. Your packet travels through the network to the router one way and returns by a completely different path . That is Policy Routing using addresses and routes.
Example 5.4: Basic Router Filters
You have seen some of the ways you can use the route commands to change the outgoing source address on your host system. Turning to the other half, the router or multiconnected host, you see how the route command can do more than just indicate destination. You can use simple route commands to implement security and other advanced policies using Policy Routing as you will see in the following examples.
Recall from Chapter 4 that the route subcommand had several types that could be defined for routes. The unicast, local, broadcast , and multicast types are for specific use as you will see when using multiple routing tables and rules. The nat type will be covered in Chapter 8. What you will use here are the throw, unreachable, prohibit , and blackhole types.
These four types of routes have the following attributes:
throw - returns ICMP Type 3 Code 0 (net unreachable) unreachable - returns ICMP Type 3 Code 1 (host unreachable) prohibit - returns ICMP Type 3 Code 13 \ (communication administratively prohibited) blackhole - drops the packet with no message
Since each ICMP error code returned has a different message, what you use depends on whether you have a specific purpose for denying the route. Considering the router setup from Example 5.3, what if you are in charge of the core, accounting, and engineering routers as shown in Figure 5.1. The engineering router connects to the engineering test network, 192.168.2.0/24. The accounting router connects to the accounting network, 172.17.0.0/16. All the client devices have a default route pointing to the core router, 10.254.254.254. The core router then has routes that point to the engineering, 10.254.254.253, and the accounting, 10.254.254.252, routers.
Figure 5.1. Basic router filter's network diagram.
Most traffic from the main 10/8 network is not allowed onto either of these networks. The accounting network is to be administratively denied to anyone with the exceptions that the range of addresses 10.2.3.32/27 and 10.3.2.0/27 are allowed to access the accounting network. The engineering test network may be accessed by anyone on 10.10.0.0/14. All others do not even know the network exists.
This set of network security policies sounds like a firewall type of decision, but this is a common routing security structure. This is very easily done through routes on a policy router. First, you have to decide what messages you want to send back to the originating machine. In the case described above I would use the following setups (see Listing 5.4).
Listing 5.4 Basic Router Filter's Simple Planners simple planner
From accounting network - 172.17.0.0/16 10.2.3.32/27 - full route 10.3.2.0/27 - full route 10/8 - prohibit 172.16/16 - prohibit From Engineering test network - 192.168.2.0/24 10.10/14 - full route 10/8 - blackhole 172.17/16 - blackhole 172.16/16 - blackhole
Note that these are coded in terms of "From" the respective network. This is due to the routes you are using still operating in terms of destination-based routing. Even though the types are Policy Routing, the routes themselves only code for destinations. This usage serves two purposes: First, these routes can operate on a non-Policy Routing system; second, the routing structure within the OS itself can remain streamlined in operation. As you saw in Chapter 3, the less structure placed into any one segment of the packet path, the faster the routing decision.
To apply these routes to the routers you need to consider the current connectivity of the routers. Each of the engineering and accounting routers has two interfaces: eth0 on the corporate backbone and tr0 on the respective private network. You will start from the bare system without any addressing and set up the routers.
Starting with the engineering system first you have two addresses assigned and the security policy as stated in the beginning of this example. You can set up this router in several different ways. Consider first the following command sequence:
ip addr add 192.168.2.254/24 dev tr0 brd + ip addr add 10.254.254.253/32 dev eth0 brd 10.255.255.255 ip ro add 10.10/14 scope link proto kernel dev eth0 src 10.254.254.253
Now you have added in the IP addresses and turned off the autoroute configuration for only the 10/8 network by using the /32 scope mask. Then you define a route for all traffic returning to 10.10/14 networks. The autoroute is installed for the 192.168.2.0/24 network as you wanted. Since no other routes are defined, then any other packet, such as for 172.17/16 or other 10/8 addresses, would not be routed by the system. But what happens when a router does not have a route for a packet? It will return an ICMP Type 3 Code 0, which is a "Net unreachable" message. But you do not want any errors returned to any of your other networks or to the engineering network itself. So you then add the following routes:
ip ro add blackhole 10/8 ip ro add blackhole 172.17/16 ip ro add blackhole 172.16/16
Now any packets that specifically try to return to any of those networks are silently dropped.
Now you consider the accounting router setup. Again you have two interfaces with addresses and the security policy statement. But in the security policy statement for this network you want to send back an ICMP Type 3 Code 13 "communication administratively prohibited" message. So you set up the accounting router as follows :
ip addr add 10.254.254.252/32 dev eth0 brd 10.255.255.255 ip addr add 172.17.254.254/16 dev tr0 brd + ip ro add 10.2.3.32/27 scope link proto kernel dev eth0 src 10.254.254.252 ip ro add 10.3.2.0/27 scope link proto kernel dev eth0 src 10.254.254.252 ip ro add prohibit 10/8 ip ro add prohibit 172.16/16 ip ro add prohibit 192.168.2/24
As noted previously, all of these routes take effect on communications that are exiting from the subnetwork. So the ICMP errors are actually returned to the systems that exist in the subnetwork itself. This is due to the routes being valid for forwarding operations only. They are destination based. When you start working with the final member of the Policy Routing triad , rules, you will see where the other packet selection mechanisms come into play.
Example 5.5: Multiple Routes to Same Destination
Now that you have set up the security policies using the Policy Routing route structure, you turn to the setup on the core router. Recently your company has obtained two Internet connections from two different service providers. Each connection is a T1 with an independent router and an independent assigned address scope. You want to set up load balancing for the Internet traffic.
The global information you will need is about the two different ISPs, and you will set up the multiple addresses you need on your router's external interface, eth1, as shown in Listing 5.5.
Listing 5.5 Multiple Address Assignments
ISP #1: Router Interface = 1.1.1.30/27 ISP #2: Router Interface = 2.2.2.30/27 Your router eth1 ip addr add 1.1.1.1/27 dev eth1 brd + ip addr add 2.2.2.1/27 dev eth1 brd +
Even though you have two different routes to the Internet, you would think that you can only have one default route. But you can have as many default or other routes as you would like. There are several different ways to code multiple routes to the same destination. Each method depends on the behavior you would like to have.
The first method is to use a per-packet method of multiple default routes. Under this scenario each packet entering the router will go out a different route. The main drawback to this format is that the paths to the final destination may vary in transit time enough to cause problems with packet reassembly queuing, especially with certain server types. But this is a very simple method to implement.
The route subcommand of the ip utility contains the methods allowing for multiple routers. This is coded using the equalize and nexthop commands. The nexthop command itself defines multiple gateways to send packets to and can take an optional weight command, which allows packets to be differentially balanced. The equalize command tells the route structure to send on a per-packet basis.
For example, if you decide to send each packet independently through each router, you would use the following command:
ip route add equalize default \ nexthop via 1.1.1.30 dev eth1 \ nexthop via 2.2.2.30 dev eth1
This will send each packet out through a different router. The first packet will go to 1.1.1.30, the second to 2.2.2.30, the third to 1.1.1.30, and so on ad nauseaum.
What if the router 1.1.1.30 was two T1s and the router 2.2.2.30 was a 512K fractional T1? Then you would want to weight the routes so as to send 4 packets to 1.1.1.30 for every 1 packet sent to 2.2.2.30. The easy way is to use the packet counts as weights. You would then use the following version of the command:
ip route add equalize default \ nexthop via 1.1.1.30 dev eth1 weight 4 \ nexthop via 2.2.2.30 dev eth1 weight 1
Now another way you might want to load balance is to allow each traffic flow sequence to go by one of the routes. But you do not want to inspect packets or code half the addresses one way and half the other. Instead you simply remove the equalize modifier from your multiple hop default route. Now traffic will be routed to one or the other route on a per-flow basis rather than a per-packet basis. Again you can use weights in this sense to load balance the flows themselves. Note that the per-flow is for tcp sessions while udp is treated per packet.
Example 5.6: Troubleshooting Unbalanced Multiple Loop Routes
You can also use the loopy routing feature to force one of the router connections to be treated as a pure input router and the other router as a pure output router. This method is often used with unbalanced connections to provide for the core site usage.
For example, suppose that you want to start providing a Web site for your corporation. You will contract with two different ISPs to provide connections. One of them will provide a T1 with a subnet of addresses for use. The other will provide 5 T1 lines with 2 IP addresses and they also agree to allow your subnet IPs from the other ISP to be sent through their connection. So you have a configuration as follows ( illustrated in Figure 5.2):
Figure 5.2. Web server load balancing.
ISP #1: Router 1.1.1.30/27 Subnet 1.1.1.0/27 ISP #2: Router 2.2.2.2/30 Your usable IP - 2.2.2.1/30
You set up a network, WebRing, to contain several Web and other Internet servers. They are assigned real IP addresses from the 1.1.1.0/27 network address space. The router from ISP #1 also connects into this network. All of your servers have a single default route pointing at your router's tr0 interface 1.1.1.1. Your other interface is connected by a crossover cable to ISP #2's router. Now the route structure is that all outgoing traffic will be routed to the Internet through ISP #2's router. Since this traffic contains the addresses given by ISP #1, the return requests will come down to your network through ISP #1's router.
Your router is not doing any real work here. The route you use simply allows all traffic from tr0 to flow out through eth0. Now your Web site gets very popular. Your notice that the uplink through ISP #2 is often running at capacity while the downlink through ISP #1 is barely cracking 256K bursts. So you decide to funnel some of the traffic through to use up some of the ISP #1 bandwidth. No problem, you simply use the weights in your router to send some traffic upward through the ISP #1 router.
And whammo, your Web site slows to a crawl. As soon as you remove the weighted routes everything is great. Upon investigation with your Ethereal brand packet sniffer you see that the Web machines are confused by the route redirects and that all the Web traffic now tries to go up through ISP #1's router.
Now you see why the placement of Policy Routing structures becomes important. In this scenario you would want to recode the default routes on the Web systems themselves to have weights. When you recode the route on your router it then informs the Web sites through a redirect to use the router from ISP #1. But since the redirect has no provision for weight, all packets then go through the ISP #1 router. When you code policy routes on the Web servers themselves, the packets are appropriately balanced and the maximum bandwidth is appropriately used.
If you had been assigned the block of IP addresses from ISP #1 and they were independent of the router, you could place the Web servers on a third network behind your router and you could then use the Policy Routing to balance the traffic flows. This type of setup also provides security to the systems as well and will be revisited later.
| Top |
