Policy-based routing is evil? Discuss.

Eugeniu Patrascu eugen at imacandi.net
Mon Nov 25 06:36:16 UTC 2013

On Fri, Oct 11, 2013 at 8:27 PM, William Waites <wwaites at tardis.ed.ac.uk>wrote:

> I'm having a discussion with a small network in a part of the world
> where bandwidth is scarce and multiple DSL lines are often used for
> upstream links. The topic is policy-based routing, which is being
> described as "load balancing" where end-user traffic is assigned to a
> line according to source address.
> In my opinion the main problems with this are:
>   - It's brittle, when a line fails, traffic doesn't re-route

You can always know what IPs are on the other end of the link, add static
routes for them to make sure they're reachable and based on ping results
use the link or not. It works fairly well if 1-2 minutes of downtime is not
an issue. I've done this using Linux and a bash script and it worked to
balance traffic across two links with up/down detection. iproute2 does

>   - None of the usual debugging tools work properly

As long as you don't have asymmetric routing in place, debugging will be
the same. Even so, you can (at least on Linux) do a "tcpdump -i any" and
see what goes in/out of your box :)

>   - Adding a new user is complicated because it has to be done in (at
>     least) two places
I agree it's not scaleable, but for when all you have are DSL lines or low
capacity lines over which you cannot run an IGP, you'll have make it work
with what you have :)

> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
I would go for the "right tools for the right job" idea and say that PBR in
the case you're mentioning of a valid use and probably the most effective
way of doing business for them.

Also take into consideration that in many parts of the world, the effort of
configuring and maintaining a setup like this fall in the the day to day
job of one or several network admins. Also, most of the time is cheaper to
hire more people than go and buy let's say professional networking


More information about the NANOG mailing list