How would you like to configure Policy-Based Routing (PBR)

Adam Sweeney, VP of EOS Engineering @ Arista Networks posed me a challenging question after my I-so-hate-PBR-CLI rant: “Is there something in particular that makes the IOS PBR CLI so painful? Is there a PBR CLI provided by any of the other systems out there that you like a lot better?

My Twitter friends helped me find the answer to the second question: PBR in Junos is even more convoluted than it is in Cisco IOS... but what would be a better CLI?

Here’s my attempt at answering the question:

I understand one needs a route map (or something similar) to configure PBR. The major grudge I have with route maps is that they were designed for something completely different (after all, they’re called route maps for a reason) and then someone hammered a square peg into a round hole.

The other pretty obvious alternative (from Cisco IOS CLI perspective) would be the MQC, but that one is even more verbose than the route maps.

My biggest peeve is (probably) the need to create a separate ACL for every line in route-map (or a separate class-map for each class in a policy-map). It would be nice to have both existing syntax (for ACL reusability) and in-line options (for ease-of-understanding and brevity): refer to an ACL or have an ACL-like syntax within a route map, or refer to a class-map or have an inline class definition in a policy map.

Do you have a better answer? What would you like to see in a PBR CLI? Here’s your chance to nudge Adam and his team in the right direction.

6 comments:

  1. IMO the easiest CLI is in Linux. Create an iptables rule to match the packet and set a mark, and then create a separate routing table for that mark and add you entries there. So, if we limit ourselves to dedicated routers only, I'd say the easiest is Mikrotik with RouterOS, since it also follows similar approach.

    P.S. I find JunOS CLI more convoluted than IOS in general. Too verbose, too much typing ...

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. JunOS can be alot of typing, but if you do it right the templates and groups can make your work a lot easier. Staying on topic... PBR is a pain in JunOS too. Last I recall you had to at the minimum create another forwarding instance and import the connected routes, then setup a new default route for that instance and use a firewall filter to kick traffic into it.

    ReplyDelete
  4. or perhaps CLI is totally the wrong abstraction for any of this.

    ReplyDelete
  5. Its not very original and its off the cuff but how does the following sound;

    On the basis of very familiar # ip route {src} {mask} {dst}.

    # pbr route mac 0000.1111.2222 int fa0/1 ip 10.1.1.1
    # pbr route int fa0/0 tcp dst port 80 int fa0/2 ip 10.2.2.2
    # pbr route ipx all int fa0/2

    While this approach is one-line configuration and lacks sophisticated if-then/flow options, I believe PBR shouldn't be used for general purpose as it doesn't scale. Rules would need to be definined, ie more specific TCP beats least specific MAC.

    This seems like a logical approach, for a scaleable CLI driven solution.

    SDN style centralised (GUI as mentioned) be an approach for complexity. But if the world wide phone system and the internet have worked with least/most specific routing (as the default underlying rules) without GUI's then PBR CLI interfaces should be able to work.

    ReplyDelete
  6. In 12.2 juniper add new option for PBR with next-hop or next-interface directly in the firewall filter.

    The juniper approach of routing instance give you more options for example verify next-hop with BFD etc ...

    And to the topic I think that PBR can be done with openflow so may be it should be used with static flows CLI

    http://www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/release-notes/12.2/index.html?topic-66800.html

    Nitzan

    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.