Policy Routing Structure

   

Policy Routing Structure

This brings up the notion of the structure of a policy routed network. As you can surmise from this chapter, such networks comprise not only the actual routing structure itself but also the intelligence of the devices participating in the network. This is the reason that Policy Routing was often and still is often referred to as "intelligent routing." I prefer the Policy Routing term because " intelligent routing" could refer to anything better than simple single static default routes.

The structure of a Policy Routing network encompasses participatory elements of the network. This ranges from the core routers through to the user endstations. Any device that participates in the infrastructure of the network may also participate in the policy. Conversely, just because a device participates in the network infrastructure does not mean it participates in the network policy.

The primary source of the policy for the routing structure is usually found in the core routers. As the source for the majority of the routing decisions it is natural to expect them to provide the majority of the policy structure. As you will see later in this chapter, this is not always the case, especially in high security networks where the routing devices tend to be very limited in their capabilities.

A core router is usually designated as such because of the functions it provides to the network. Often this is the central router in a hub-and-spoke routed network. However, the core router with regard to policy is often the router or other security device that provides the main interconnectivity between the internal corporate network and external allied networks. A central router in a hub-and-spoke system historically needed only to perform traditional routing to service the corporate network needs.

The recent trends within corporate networks have been to incorporate more advanced services for use. As services such as streaming audio and video are introduced to corporate networks, there is a greater need to allocate and economize the resources within the network. As these services are added the central routers become strained trying to handle all of the traffic being generated. The standard solution is to throw more money at the problem and purchase larger routers and higher-speed networks. The reality in almost every case is that redesigning and optimizing the network traffic using Policy Routing often returns a far higher cost savings through greater efficiency. But it is not glamorous to management and not highly profitable for VARs (Value Added Resellers).

As in network security, policy and the resultant structures promulgated from implementing the policy must be balanced between the need to provide a specific set of functions and the need to reduce the cost associated with providing such structures. These costs are not only material but also highly intangible with respect to the human factors. If it is easier to bypass the policy when using the network or the policy in place renders usage of the network difficult, the policy hinders rather than helps. The analogy to network security policy structures is very precise and deeply intertwined.

A carefully crafted and implemented Policy Routing structure can assist on many fronts. As a concrete example, consider a Policy Routing structure that defines that all Internet traffic from the outbound call center be administratively denied . This serves to implement a security policy for Internet access, a network policy reducing extraneous traffic, and a business policy for divisional workflow. This multiplicity of usage points out the fundamental shift in today's corporate networks: The network defines and drives fundamental productivity in much the same way as the telephone before it. And as business grew from single telephones to PBX systems and call centers, so too has computing grown to networks and NOCs (Network Operation Centers). As with the telephone usage policies earlier, network and security policies now concern themselves with the usage of the corporate network resources. And these policies are implemented through a Policy Routing structure.

Implementation Considerations for Policy Routing

Implementing a Policy Routing structure requires that all extant policies for network usage be considered along with the actual logical/physical configuration of the network. In many cases, the logical and physical configuration of the network may be changed to facilitate the implementation. The best place to start when considering a Policy Routing structure is to map the logical structure of the network. This logical map will show the network intermesh. The logical intermesh is important as most networks today still incorporate the single connection philosophy. The single connection philosophy defines that any two networks should be connected only at a single point.

In traditional routing, especially under RIP dynamics, you should not have two routes to any network. If you did, then only one of the routes would be used. This style of network design led to the two popular network topologies, the hub and spoke and the backbone. In a backbone system there is a central network with many routers attached to this backbone network. These attached routers connect the leaf or branch networks to the backbone network. Any conversations between leaf networks require traversing the backbone. A backbone system works well for distributed computing where the majority of each leaf network's traffic is within the leaf network. A hub-and-spoke system usually has a single large router that is connected to all of the leaf networks directly. Thus a hub and spoke is often referred to as a collapsed backbone system.

In either of these types of network, the implementation of a Policy Routing structure requires a careful analysis of the objectives and a clear understanding of the actual logical structure. Implementing Policy Routing on a leaf router when the traffic does not pass through that router not only wastes resources but can actively deteriorate network traffic flow. Worse still, implementing a Policy Routing structure without understanding the packet traversal paths and the oddities of the desktop operating systems connected to the networks can crash your network.

To illustrate , consider a backbone network where several of the stub networks contain traffic destined for the Internet as illustrated in Figure 2.2. The connection to the Internet is through a router, Inter1, connected to the backbone and to an external network. Originally all the stub networks sent their traffic to Inter1 as the default gateway. Then Inter1 would send on all the traffic to the Internet. A firewall placed between Inter1 and the Internet connection was responsible for blocking the traffic from those stub networks not allowed to the Internet.

Figure 2.2. Multinetwork policy structures.

graphics/02fig02.gif

The backbone network was upgraded twice to faster speeds due to the increasing level of traffic, and there were attempts to use static routes to contain the internal traffic. With the backbone now saturated again, the decision was made to try to tune the network. The first attempt implemented Policy Routing on Inter1. The Policy Routing structure on Inter1 mediated access to the Internet based on source IP address. The backbone network collapsed on the first full business day after the implementation.

A packet dump of the backbone showed that the packets destined for the Internet from the stub networks arrived at Inter1 and that Inter1 then sent back an administratively denied response packet. The desktop OS in use ignored these packets and resent the request. Thus the traffic on the backbone due to these requests at least tripled in volume. Under the old method, the firewall between Inter1 and the Internet had simply dropped the packets so there was no further response and the original request timed out. Under this first attempt the original goal ”reduction of the backbone traffic ”was reversed .

The successful second attempt implemented a Policy Routing structure on the leaf routers as well as Inter1. The leaf routers were instructed to simply drop, or "blackhole," the packets that were denied access to the Internet based on the source address incoming from the Stub network. Packets from addresses that were allowed out onto the Internet were additionally tagged with a TOS field id that defined the Stub that the packet came from and additionally the protocol used such as http. Then Inter1 was configured to queue these packets according to the network policy allowed rates for those services. Later on the leaf routers were configured to TOS tag and differentially route various internal network data flows, thus maximizing the available backbone bandwidth and making the network seem much faster than ever before to the end users.


   
Top


Policy Routing Using Linux
Policy Routing Using Linux
ISBN: B000C4SRVI
EAN: N/A
Year: 2000
Pages: 105

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net