I heard that network engineers tend to avoid policy routing. I am thinking to source-address dependent routing for example. Is policy routing bad practice? If so, why?


Normally, a router forwards packets based on destination address alone. This is obviously very simple and efficient.

Policy-based routing means the router is now looking at other factors to determine how to forward each packet. Those other factors might include source address, protocol, or something else that can be gleaned from the header or payload.

The most obvious drawback to routing traffic based on policies like this is that the router must now inspect all packets to find matches. This places a load on the CPU and possibly TCAM that wasn't there before. To add a small handful of policy routes should be fine on most hardware but the more that are added, the more loaded the CPU will become at all times.

The second reason I would avoid policy routing if I had the option is that it makes management a bit tricky. In my experience it's easy to break something and somewhat difficult to think of all possible scenarios to test when implementing something like this. When it comes time to troubleshoot a connectivity issue you'll now have these granular policy routes to consider as opposed to traditional destination address routing.


Policy routing (based on source address, protocol, ...) is a method that is required for certain scenarios. As with many other techniques, it's better to avoid but sometimes you can't do without. PBR can severely complicate your network and land on your feet if you forget about it. Whether it's good or bad depends on its specific use.

Note that source routing usually means something different: the largely obsolete IP option to let the source host determine the routing path (instead of the routers in the path).

  • I guess OP meant "source-specific" routing (SADR), i.e. regular routes which additionally match on the source address. (It's sometimes implemented via policy routing.) – user1686 Nov 8 '19 at 14:01
  • yes, that's it. (now edited) – exeral Nov 8 '19 at 16:19

The original premise of IP and packet switching is that routing is dynamic, meaning the path can change based on changing conditions. Each end does not need to know or care about how traffic reaches the other end. For example, if you have a connection with another machine in another city, and some disaster (fiber cut, hurricane, tornado, fire, bomb, etc.) happens, the way IP and routing is designed will automatically reroute the traffic with little to no interruption or packet loss.

If you specifically configure routing, either PBR or source routing, you completely defeat the dynamic nature of IP routing and packet switching. For example, if you define a class of traffic (IP address, transport protocol, etc.), and you set it up to only send that traffic in a particular direction, if there is a problem in that path, it cannot dynamically reroute to a different path, and you will then lose that traffic.

There are cases where you must use PBR, but it needs to be well understood prior to configuring that because you lose the flexibility. Also, source routing has really been deprecated because letting the sender determine the path almost always fails, and as a network engineer, you would need to troubleshoot something over which you have little information or control.

The point is that letting traffic flow naturally over the best path and automatically fail over to the next best path is how IP routing was designed, and any change to that paradigm can introduce hard to discover problems, suboptimal routing, etc.

  • Your argument against (static) PBR or source routing applies identically to (static) destination based routing – Hagen von Eitzen Nov 10 '19 at 3:06
  • Yes, and PBR is really a form of static routing. It doesn't scale, is hard to maintain and troubleshoot, etc. Sometimes, though, it is necessary, but you really need to understand it and the implications before implementing it. – Ron Maupin Nov 10 '19 at 3:43
  • @RonMaupin plent of what to handle dynamic policy routing – Matt Douhan Dec 7 '19 at 9:37

All the previous answers are correct, but since this is a site for network engineering, let me give one more from an engineering perspective:

The majority of the effort you will spend on a network will be operating and maintaining it: improving, expanding, troubleshooting, repairing, etc. Over the life of the network, this effort is much larger than the time spent designing or building it.

Given this fact, it makes sense to design your network so that maintenance and troubleshooting are as easy as possible. To that end, you use the simplest techniques in order to get the job done. Complex or "clever" designs are hard to maintain. When there's a failure, it takes a long time to figure out how it's "supposed to work," and changes can break things in unexpected ways. This idea can be summed up as: "simple is better than complex."

PBR is more complex than simple routing (it is highly customized with access-lists, route-maps, etc) and harder to understand or modify. For that reason, you would prefer not to use it if you don't have to.

The bottom line is, there is no such thing as a "good" or "bad" technology. If you need PBR to get the job done, then it is the right thing to use. Knowing when to use it, or when to find a simpler way of solving the problem is what engineering is all about.


PBR (Policy Base Routing) is the one off solution that you can solve you Design when you need to send part of lan's data to specific ISP or direction and so on. thing that avoid architecture engineer when design Solution is "NAT" because troubleshooting is hard when you using it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.