The beauty of dynamic routing protocols is that, once you've configured them properly, you can more or less leave your routers to find the best path between any two networks. If a link fails, it doesn't matter, since they'll rebuild their tables and find another path - that's the theory, anyway.

That's the danger too. Don’t let's forget that routers are machines. They can't think, don’t have opinions, and aren't able to use common sense. Yes, you can configure them (depending on which routing protocol you're running) to take into account metrics such as bandwidth, speed and even cost of a link but any decisions based on those parameters will be for all traffic, and sometimes that's not good.

Take voice, for instance. Everyone should know by now that what kills voice quality is delay, especially variable delay (jitter). So if you have two links, a stable, reliable, leased line and a satellite link, it would seem obvious to send the voice traffic down the former, while it makes no difference to your email, FTP, etc, which they use, since a few seconds either way isn't going to make any difference.

Not to a router. Unless you tell it so. Which is where policy routing comes in. Policy routing allows you to tell a router that traffic which matches certain parameters should not be sent the way the router would expect to forward them, based on its routing tables, but instead take a route that you specify.

Matching traffic
This is what policies are all about. You configure a set of rules (policies) governing which traffic is sent where. First you have to identify this special case traffic. You do this by matching packets to filters or access-lists, depending how your router vendor of choice implements things. So, for instance, any traffic that is sourced from, or destined for, a specific subnet or host. Or traffic arriving on a certain interface or of a certain length. Or traffic that has certain QoS characteristics - this is where it starts to get more interesting, since depending on how you've set up your QoS configuration, the QoS settings on certain packets may change as the packets travel through the network, based on traffic levels etc. This means you can create set of rules that will dynamically change what happens to your data based on changing network conditions.

Routing traffic
Once you have picked out the traffic you want, you need to specify how it's to be handled. For example, regardless of the best route to a destination, you can insist that this traffic is only to be sent out a specific interface, or to a particular next hop address. Any traffic that matches your criteria will bypass the normal routing tables, and any traffic that doesn't match will be forwarded as usual.

Typically you'd expect most of your traffic to fail to match your criteria - in general policy routing is for special case traffic. If you find that nearly all of your data does match the filters you've set, you probably need to take another look at your network design, as it may be that over time a sub-optimal routing topology has evolved.

Implementation
We've already mentioned voice traffic. A couple of the other most common uses of this type of tuning are for security and billing purposes.

Say you work for a government agency, finance house or R&D lab. Some of your network links have heavy-duty external hardware encryption for maximum security. It's too expensive to have this on all links, and a lot of your network traffic doesn't justify it anyway. You don't want to build two separate networks, so setting policies will let you classify your sensitive traffic, probably by IP address, and ensure it's sent only on these encrypted links. If they fail, it's better that the traffic stops than travels over non-protected circuits. The same could apply where you have backup links. You may have traffic that you would rather was blocked than used these backup circuits, either because the backup couldn't guarantee the service levels some of your traffic required, or just because you didn’t want to use expensive backup circuits for non-critical traffic.

Or you may have departments that insist on having 'their own' dedicated links. If that's the case, then their traffic should be set to use their - and only their - circuits. Again, matching their traffic by IP address and then setting a policy to force matched traffic to use specific interfaces is a fairly simple procedure.

You may have an application that for some reason won't allow data fragmentation to occur. If you have serial links that can't support large packet sizes, maybe for historical reasons, you can tune this traffic away from these links, since it would get dumped if the packet size exceeded the MTU.

Policy routing lets you override the decisions your routers make regarding the 'best' path for your traffic. In many cases, routers can make decisions quicker and more accurately than we can hope to do. But if you have extra intelligence that your routers are unaware of, then this gives you the option to take control and make sure the network serves you the way you want it to.