Scalable Policy Routing

If “policy routing” reminds you of nightmarish spaghetti solutions of hop-by-hop route-maps, read my latest IP Corner article, Scalable Policy Routing. It describes how you can use a distance vector routing protocol (BGP is used in the article, but you could do the same with EIGRP or even RIP) to solve common policy routing problems in a highly scalable way.

3 comments:

  1. While your article on the use of BGP weights, communities/attributes, and MEDs was quite instructive, I would like to point out that your comments about asymmetric routing being undesirable (with the big 'Warning!' box) are incorrect. Asymmetric routing is a fact of life on the Internet and in endpoint networks of any size; it is at worst neutral, and often has beneficial properties. I would strongly suggest removing this assertion from your otherwise-informative tutorial.

    Keep up the good work!

    ReplyDelete
  2. Roland,

    In my opinion, the warning (which was no bigger or styled differently than any other note) is absolutely correct in the scope of the article.

    If, for example, you want to push delay-sensitive traffic on lightly loaded backup links, you don't want the return traffic to flow over the Internet. In this context, asymmetrical routing would increase jitter and thus application performance (or users' perception if the application would be VoIP).

    Please not that the article was focused on policy-based routing, using BGP just as a convenient tool due to the breadth of its attributes and features. I know that the asymmetric routing is a reality in some other environments (for example, the Internet at large) and that it could prove beneficial if the line speeds and delays of uplink/downlink are significantly different, but that was not the scenario discussed in the article.

    Thanks for the comment!
    Ivan

    ReplyDelete
  3. Of course, I wasn't speaking in terms of routing one half of a 'conversation' on an internal network, and the other half across the best-effort Internet, heh. It's hard for me to conceive of a realistic network topology which would even render such a thing possible, much less desirable, except through deliberate sabotage or almost willful incompetence.

    In terms of VoIP, or anything else, asymmetrical traffic flows through the topology (a private network or the Internet) are not a problem at all, other things being equal. Artificial enforcement of topological symmetry, even if it were possible, is no guarantee of bidirectional performance.

    The main design considerations are to avoid congestion or other performance-related issues, to ensure resiliency, to maximize economy, to avoid fate-sharing, to avoid unnecessary complexity, and to avoid unnecessary backhaul, which of course induces delay. This of course has nothing to do with attempting to enforce artificial traffic flow symmetry.

    Asymmetry simply isn't the problem you believe it to be, and your concerns about it and advice regarding it aren't borne out in the real world, IMHO. With the exception of stateful devices/services in the network which require traffic flow symmetry (you give the excellent examples of a stateful firewall and a NAT in your subsequent post), trying to artificially engineer this symmetry into the network makes things unnecessarily complicated, more brittle, and can actually lead to performance degradation.

    No one who designs and operates networks of any size designs the network with the enforcement of traffic symmetry in mind; it isn't practical, and isn't desirable or necessary, even if it were practical. Yes, you can do this on small LANs if you work hard enough at it, but it's effort which brings no real returns in terms of performance, and can be actively harmful both in terms of the added complexity and inherent performance/resiliency side-effects of artificially engineering it into the network.

    Talk to anyone clueful who operates a medium-sized enterprise network, much less an SP. They'll confirm to you that enforcing artificial symmetry simply isn't a valid design consideration, except in the circumstances described via the abovementioned caveats.

    Your tutorial is good and very useful, and you're doing a great job with the site - again, keep up the good work!

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.