Common IPv4 Routing Problems and Solutions
Common IPv4 Routing Problems and Solutions
As I implied earlier in the chapter, Policy Routing grew out of several different needs within IPv4 networks. One of the more recent and prominent discussions was the entire topic of QoS. But there have been many problems with the destination-based routing structures. Some of you may remember that it was only recently, in the early '90s, that the Internet was allowed to carry any commercial traffic. Indeed there existed for some time parallel networks where one carried commercial traffic and the other carried Internet traffic. While this was a somewhat extreme and short-lived situation, there was call for and discussions about methods of differentially treating the routing based on the source of the packet as well as the destination. Consider, for example, an educational institution that carried on correspondence with both a commercial entity and a governmental entity on the same project. Under the parallel networks the educational institution would have to send out two copies of all work and provide two different connections to the internal networks. They would need to use two completely different sets of internal routing tables to allow data from perhaps one experimental computer to be sent through a "commercial" connection and through a "research" connection. If the connections were indeed physically separate, then destination routing could still be used. But if the connections were intermingled (as was usually the case), at some point in time it would be necessary to artificially separate the data streams and route one of them through a defined path and the other through an alternate path . These decisions would be based on the source address as well as the destination address of the packet. This is Policy Routing.
Aside from this extreme example, you can see that even in the networks that were being developed internally by many corporations and other large entities there was a need to route packets based on the properties of the packet besides just the destination. An actual case I was involved in illustrates the vagaries of the routing needed under destination-based systems.
In this instance there was an accounting network that contained the user desktops for the auditing staff. All of the work these auditors did was on servers that resided on the main accounting network located in a different building on the corporate campus. Getting the traffic through to the accounting network from the auditor network required connecting to the main corporate campus backbone.
The problem resided in the fact that some other employees of the company had been recently reprimanded for attempting to access the accounting systems. These actions were caught by the auditing staff. After these incidents the accounting network itself was locked down physically and through other various network security measures. However, there remained the problem that any and all traffic from the auditing division could be seen and potentially used to access the accounting network. The corporate campus backbone was connected to many other buildings and in some cases all of the traffic on the backbone actually traversed several corporate campus buildings .
The company brought in my team to find a way to route the auditor traffic so that it passed through the backbone in such a path as to not allow any of the traffic to traverse these other buildings. For security reasons since the network is still operational I will not go into detail as to the exact setup of the network involved. Generally speaking, the backbone network consisted of several multiply-connected network segments bridged together. The majority of the routing tables were set up to route all traffic through the backbone even if there was more than one connection. Due to the bridging structure you could not access the backbone router connections directly. We ended up defining new IP networks for many of the routers and setting up a ring of static routes, which would force traffic within those address scopes only through a different network path.
Suffice it to say that what would have been a simple Policy Routing decision within the auditing and backbone routers ended up requiring us to set up multiple IP network scopes with different destination route tables. If we could have specified routing based on IP source address we would not have had any problem setting up the route structure. While we did try using a strict source routing packet header structure, the only method that worked was to use a completely different set of IP network addresses and set them up statically to force the route flow. And with such a static forced route structure there were problems when machines were added to or removed from the secured networks.
This was one of the scenarios that started me down the path to Policy Routing. It was obvious even then that if we could have specified the source IP address or network as a routing factor, we could have solved the problem quickly and easily. The need for redundancy, which drove the original destination-based routing, was rapidly coming into conflict with the security and structure of the network. Ideally, we should be able to have our redundancy and security too.
The Quality of Service Explosion
Fast forward to the mid '90s to the explosion of the other, and considered by many the primary, driving force for Policy Routing structures, QoS. The commercialization of the Internet has driven the entire assumption base for the IPv4 protocol family into intense scrutiny. The traditional packet delivery basis for IPv4 has been described as "best-effort." This summarizes the entire process quite aptly. The underlying reason for the split between UDP (User Datagram Protocol) and TCP (Transmission Control Protocol) is related to the fact that IP (Internet Protocol) is a best-effort delivery service. In this split UDP packets get there if they can, when they can, and that is fine. TCP packets are checked on through all sorts of mechanisms to ensure that the packets get there at all. In either case, the routing is left to the routers and is decided based on where the packet is going.
Now as a corporate or other entity, what if I am willing to pay for better, faster, or available packet delivery? Enter the entire rationale for QoS. QoS, as a basic premise , means that I as a service provider of networking connectivity will guarantee you some level of service that you pay a premium for using. Under IPv4 networks, this mechanism depends on the routing and queueing of network packets depending on the TOS (Type of Service) tag associated with the QoS service provided.
There are a few standards for TOS tags and many of the actual drawbacks of the system are related to the definition of what is provided for a particular TOS tag. But that also is the bulk of the discussion and work relating to the various QoS systems today. For example, you can look at the various specifications and definitions for Differentiated Service (DiffServ) which specify the TOS values related to various types of queueing disciplines. The assumption of course is that the queueing structure, by providing mediated preferential access to the existing finite bandwidth connection, allows for better service of your packet stream. This begs the question of what additional structures are possible with QoS.
Routing structures that take advantage of the tagging of QoS are the natural extension. By providing a route that depends on the TOS tag in the packet, it is possible to now provide certain guarantees of packet delivery. Under queueing alone, about all you can guarantee is that the tagged data stream will get a defined percentage of the available bandwidth. With Policy Routing, based on the TOS tag you can add in methods of congestion avoidance and preferential packet paths.
Consider a setup as illustrated in Figure 2.1 where you have two potential data paths. Each data path is a private connection to a different network. Each of these networks is then connected to a final destination. As a peer to these external networks your router is knowledgeable about the availability, load, and capacity of these networks. My agreement with you is to provide a certain bandwidth to my packets with a clause specifying an additional payment for low latency connections. You would like to maximize your income from my contract so you will set up the policy in your routers to always send my packets by whatever path offers the lowest latency. Since your router knows the latency at points TRN1, TRN2, RET1, and RET2, you can calculate the latency of First Path versus Second Path. Thus you can provide both a queueing guarantee to me and you can then route my packets for lowest current latency. This would work by having your router make a per packet or per queue decision based on the current calculations of Latency(TRN1 + RET1) versus Latency(TRN2 + RET2) and then routing the packet based on that decision. This packet selection can use the same TOS tag you use to queue on for the bandwidth guarantee.
Figure 2.1. Dual path cost structure.
| Top |
