The Triad ElementsAddress, Route, Rule
The Triad Elements ”Address, Route, Rule
The core of Policy Routing rests on the use of three elements. These are the traditional elements of Address and Route as extended by Policy Routing, and the additional Policy Routing element: Rule. The address refers to the assigned network address under the protocol in use. The route is the corresponding directional element for the address. And the rule implements the additional information provisions demanded by Policy Routing.
These three elements comprise the structure around which the implementation of Policy Routing is built. All three play unique roles that can act singularly, but they are most effective when combined. The interactions between these elements provide the flexibility, and the complexity, seen in Policy Routing.
The order in which you look at these elements determines the output you derive from the system. Because each element is totally independent of the others, you can consider the effects of each on the system. The interactions then add the extra dimension to complete the scope. In Chapter 5, "Simple Network Examples," and Chapter 6, "Complex Network Examples," you will actually implement some real examples using these elements individually and then in concert. To understand the implementation details you need to understand first the background of each element.
Address
The first element of the triad is address. This element refers to the actual identification of a set of services. The address specifies the object that is acting or is acted upon. This sounds very general, but you must step back and consider how any service is provided on a network.
For example, consider how you access a Web server on the current IPv4 Internet. The first step is usually to try to connect to the system. You type the protocol and address into your browser, such as http://www.policyrouting.org. Then your browser asks your DNS server to resolve the name. Resolving the name means that the browser is asking for the IP address associated with that name ; that is, you are requesting the http service from that IP address.
Now that IP address may not have anything to do with any physical machine. In Chapter 5 you will actually run through examples of this type of behavior. But for the moment consider what use you are making of this address. To your browser it serves as a marker that defines where the browser should go to look for the information it is seeking. It defines to your browser the location of that service.
Up to this point you have looked at the destination address. This is one of two core parts of the traditional routing. As you saw in Chapter 1, "Basic IPv4 Routing," traditional routing is destination based. And in traditional routing, the destination implicitly and explicitly referred to is the destination IP address within the packet header.
To see the depth of this statement, suppose that you have decided to implement a new packet header for your new "SuperTrad" traditional IPv4 router. This header will be added as a wrapper when the packet traverses a "SuperTrad"-only network. Don't laugh unless you too remember systems such as ProNet, the fight between NetBEUI and NetBIOS, or have tried to import an EIGRP-only network into a gated environment. In your new header you decide that all you need is the destination IP address and checksum of the whole packet. After all, nothing else matters to the routing. This packet would function fine in almost all of the routing cases in IPv4 for the last twenty years .
Now you come to Policy Routing. In Policy Routing, as it should have been in traditional routing, both of the addresses within the IPv4 packet header are important. Indeed, the entire packet header can be used to define a route. This elevates the source IP address to the same intense scrutiny as the destination. If you think about it, if the source address had been as important in traditional routing as the destination address you would not see any spoofed addresses. After all, when a router is paying attention to the source address and it is looking for a specific set of source addresses, using a faked source address (spoofing) is limited to a small set of internal source addresses. That legal set could be shrunk to one address, which makes spoofing impossible .
Both of the addresses provided in an IPv4 and IPv6 packet are important in Policy Routing. And the importance is not limited to the actual single address itself. There is a whole method for specifying groups of addresses similar to the way you specify networks. The notation used is the same ”CIDR (Classless InterDomain Routing).
The result of applying a CIDR scope to an address is used to associate the address with the network as it needs to be defined for the purpose of implementing the Policy Routing structure. It should not be confused with the definition of the network by a CIDR mask. In Chapter 5 there is a set of examples you can work through to see exactly how this works.
In brief, consider that the address CIDR mask has nothing to do with the network CIDR mask. If I have a network that is 192.168.1.0/24 and I decide to use the address 192.168.1.1/25, I can. I can even use the address 192.168.1.1/16. The network does not and should not care what my address scope is so long as I obey the routing rules of the network and provide the machine with the correct local network broadcast address which may differ from the address scope. For the moment, you should just remember that the scope of an address does not necessarily have anything to do with the definition of the network.
The scope of both addresses within the packet header is either explicitly stated when dealing with the address or it defaults to the network scope. In both cases, once the scope is given it associates the address with some grouping, which then defines the relevant route used. This brings you to the second core element of the Policy Routing triad ”routes.
Route
Essentially , routes are little changed from the traditional variety. They code the forward method for getting to the destination address. And when you consider the larger viewpoint this makes sense. Most of the routing that is done is straightforward. You have a destination in mind and you want to get there by the best means possible.
All of the discussion in Chapter 2 merely adds to this point. When you look into Policy Routing, what you notice is that it helps you make a decision on where to route a packet based on alternate criteria. The method of actually selecting a route is changed, but the method of using the route once obtained is the same.
What is different when contrasting the Policy Routing route element with the traditional method is more versatility and flexibility in specification and destination options. The traditional route command allows you to specify a gateway and some options on the path to that gateway for a network or host destination address. Additionally, most route command implementations allow you to specify a "reject" or " denied " route option. This is essentially the same as a route lookup failure and returns an ICMP Type 3 Code 0 "network unreachable" error.
Besides the standard gateway object, in the Policy Routing schema a route may provide reference to an outgoing source address, interface, or specify an error destination. The errors returned may exist in the ICMP codes or the packet may be simply dropped or changed. When the packet is changed, the action becomes a NAT (Network Address Translation) function, which you will see in Chapter 8, "NAT Functions." The additional destinations are not required but are specified on an implementation basis. Within Linux you will see that the Policy Routing subcommand has a range of additional targets for the route object. Some of these targets refer to types of network structure such as broadcast or multicast. Others provide alternate destination targets for control such as prohibit or blackhole. You will use these features in Chapters 5 and 6 when you start to see how to implement Policy Routing structures.
For now you want to consider the route element of the Policy Routing triad as an advanced version of the traditional route structure. Indeed, for simple networks where you are providing standard routing functions the Policy Routing implementation reduces to the traditional specification. But the greater functionality is always there for use.
Rule
So if the route element is not all that different, how do you select a route using all of the advanced methods discussed in Chapter 2? Where are the route by source address, route by packet header data, and other selection mechanisms?
This is where the rule element comes into play. Think of the rule as a method for implementing ACLs (Access Control Lists) for routes. The rule allows you to specify the filters that match packets, and which route structure to select when the filter does match. Because the filter is part of the rule selection mechanism, you can also use rules to specify other advanced options such as destination targets and NAT functions.
Using a rule you can perform the most common Policy Routing function, route by source address. The rule can specify to select a packet based on whether or not the source address of the packet falls into a designated address scope. If it does match, the rule states which route structure to use or other destination to choose. But if you stop to think about this for a moment, you realize that on a system where you only have one routing table a rule set is usable only under limited conditions.
Multiple Routing Tables
In a single routing table system, such as current network router devices, or most operating systems, all of the routes specified are in a single group called a table. This table is then read through (in network speak the route is "looked up") sequentially and the longest match of the packet destination is made. This longest match then returns the gateway to which to forward the packet.
Suppose you have three routers to the same network. Each router has a different speed connection to your network core. Which one should you use in your routing table? Even under OSPF this type of routing structure still results in a single "best" route for the condition of use.
Consider this conundrum in a different light. Most of your network clients only need limited access to a particular network. They would be fine on a slow link. A select group of your network clients needs a higher rate access to this network. If you have only one routing table, you can only put in one route to this destination network. Which one do you use? In this case even if you use rules to select the traffic, where are you going to end up sending them? To the routing table.
Thus the implementation of the rule in Policy Routing implies that for true global structure you must also implement multiple routing tables. A complete Policy Routing structure is found in the Linux kernel, version 2.1 and higher. It provides full use of Address, Multiple Independent Route Tables, and a Rule selection mechanism that can interact bidirectionally with the route tables. Additionally, there are the policy actions that are contained within Cisco IOS 11.2 and above. If you are curious about this check out the Cisco documentation on the Web (http://www.cisco.com/warp/public/732/jump.shtml).
| Top |
