Routing

Experts,

I'm new to playing with policies on Junos.  While configuring some vrf-leaking policies today, I found that the funcationality of prefix -lists is also duplicated by route-filters (as far as matching routes is concerned in my small test topology).  

Are there any specific scenarios (or limitations) where one would want to use prefix-lists over route-filters and vice-versa?

Please let me know.

Cheers

Prefix list is a named group of prefixes, with the following format prefix/netmask

Route filters has more options and are especially useful when you need to define ranges of prefixes...

If you think that's cumbersome to define each time the route-filters in policies, then you could use nested policies where inner policy is used to aggregate route-filters while the outer to perform specific actions:

For example:

policy-statement import_S5-S8 {

    term 1 {

        from {

            protocol bgp;

            community S5-S8;

        }

        then accept;

    }

    term 10 {

        from {

            community Gn;

            policy Gn-DT_to_S5;

        }

        then accept;

    }

}

inner policy:

dpa@JCore503# show policy-options policy-statement Gn-DT_to_S5

term 1 {

    from {

        route-filter………………………..;

        route-filter ……………………….;

    }

    then accept;

}

Honestly, I rarely use route-filters.

             route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;
            prefix-list-filter bgp-networks-ASN orlonger;

Except for my prefix-length-range rule, I use prefix-lists. I also use them extensively in my firewall rulesets. My theory on it is that it's easier to get into the prefixlist and make a change and you're less likely to make a mistake compared to changing a route-filter in the middle of a policy.

Same here, very rarely use route-filters.  

Only difference that I've seen is you can't specify a range using a prefix-list.  Your choices  are exact, longer, orlonger.  Of course, you can create the same sort of behavior using a prefix-list, it just requires listing additional prefixes in the list. Or using a couple of prefix-lists, one shorter and one longer, setting one to accept and the other to reject.

In a lot of cases, the prefix(es) will be used in several different locations.  For instance, BGP import and/or export policy, RPF policy, firewall filters, loopback filters, multicast scope, etc.  Rather than trying to remember the many different locations a prefix may live, it goes in a prefix-list.  Change the prefix one time, far fewer chances of mistyping the address in a location or forgetting one or more spots.

It also helps when managing a large number of devices.  You can write the various filters and policies as generically as possible, referencing prefix-lists instead of specific IPs / prefixes.  The more complex logic in the filters and policies only has to be written once, with minimal per device / per site customizations needed.  The bulk of the customization for the site / device is handled by putting the various IPs / prefixes into the correct prefix-lists.  One spot to update, and you're having to effectively recreate all of the policies from scratch for every device deployment.  Name your prefix-lists something that makes sense and the configuration becomes easier to understand and maintain as well.

-Chad