Routing

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  Question on 'next policy' and 'next term' policy actions

     
    Posted 09-10-2021 05:36

    Hi all.

     

    I know how the 'next policy' and 'next term' policy actions work, but can somebody please provide real world examples of their use?

     

    Thanks,

    Deepak


    Juniper Business Use Only



  • 2.  RE: Question on 'next policy' and 'next term' policy actions

    Posted 16 days ago
    Hi Deepak,

    There are so many use cases for that... :-)

    Here are two examples: 

    - You may use 'next term' to set common attributes to all routes (communities, next-hop, LP, etc) then the other terms to accept/reject prefixes.
    - You may use 'next policy' to chain policies. Let's say you have multiple peers you want to filter routes not respecting your security policy (RFC 1918, Bogons, too many communities, you own routes, or what ever) then you want to apply peer specific policy. In that case, the last term of the first policy should be 'then next policy'. 

    HTH, 
    C

    ------------------------------
    Christophe Lemaire
    ------------------------------



  • 3.  RE: Question on 'next policy' and 'next term' policy actions

     
    Posted 16 days ago
    I would add to Christophe good description that the next policy options gives you the opportunity to have reusable modular policies that are a single place to update all your bgp peerings at once.

    For example you have a policy for the items he mentions like bogon, community operations or the final reject.  This is one and only one policy each.  But they get used in all of the peerings.  

    Should you need to change a community action, you change it in one place, that policy, and it automatically is updated everywhere.


    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 4.  RE: Question on 'next policy' and 'next term' policy actions

     
    Posted 15 days ago

    Some other purposes of these are to use at least the "next policy" one is to use it as a form of inverted match, since Juniper policies don't have an inverted match condition (to my knowledge).

    So for example let's say you want to filter out anything that is not 10.0.0.0/8 (hypothetical example) you can set it up like:

    policy-options {
        policy-statement reject-non-10 {
            term bypass {
                from {
                    route-filter 10.0.0.0/8 orlonger;
                }
                then next policy;
            }
            term reject-rest {
                then reject;
            }
        }
    }

    This will drop anything that's not 10/8 from further processing, and you can then chain additional policies behind it to have the remaining routes be processed as you want your routes to be processed. Of course, you can also do such things at the tail of your policy chain. In most cases I would recommend doing that, explicitly accepting the prefixes you want, and rejecting anything at the end that doesn't match your standards, rather than filtering at the head and letting things flow through for the rest of the process, but I can imagine that there are certainly scenarios that you'd want to utilize this.

    Another purpose however is when you have a policy that can do multiple non-terminating actions, and you want it to basically only apply the first "matching" one, rather than all of them. For example, maybe you want to tag on a community, or set a local preference based on some criteria, then you might have a policy set up with terms for the different matching criteria, but if a prefix matches more than 1 of those criteria you could choose for it to "break" out of the policy once it matches one.
    Hypothetical example:

    policy-options {
       policy-statement set-localpref {
          term customer-locpref-100 {
             from {
                route-filter 10.0.0.0/16 orlonger;
             }
             then {
                local-preference 100;
                next policy;
             }
          }
          term customer-locpref-200 {
             from {
                route-filter 10.0.0.0/8 orlonger;
             }
             then {
                local-preference 200;
                next policy;
             }
          }
          term default-locpref-300 {
             then {
                local-preference 300;
             }
          }
       }
    }

    In this example if the next-policy was not there, a prefix like 10.0.0.0/24 would hit the first term, get marked at localpref 100, then continue flowing through the policy, it will ALSO match the second less specific term, get re-marked with localpref 200, and then flow on and ALSO hit the catch-all at the bottom and get marked 300 (overwriting all previous changes), while you probably (in this completely fictional example) actually want it to hit the most-specific one and get localpref 100. So adding "then next policy" makes it "break" out of the policy chain once it hits the first match at localpref 100, and proceed to the next one in the chain rather than getting set with a localpref of 300 like everything.

    These are of course just a small sample of potential usecases, there are many as Christophe said indeed. One quick sidenote about what Christophe mentioned though: If you chain policies together, then adding "next policy" at the end is mainly a "best practice" for visibility (similar to how it's strongly recommended to explicitly define your accept and reject actions, even if that is the default behavior) but the default will already make it proceed to the next policy unless it has explicitly hit a terminating action, so that is not a hard requirement (similar to how next-term is not necessarily required). So the purpose is mainly to allow a match to break the processing chain inside of a policy, rather than going through the full list of terms in a policy.

    As for the next-term, to be fair in most cases that is the default already, so as long as a term doesn't have a so-called "terminating" action (like accept and reject) it will automatically continue to the next term anyway, so I'm not entirely sure on when you'd want to use this other than to have a clearly visible documented behavior (instead of relying on invisible defaults). So adding "next term" makes it nicely visible when troubleshooting that the intended behavior is that it continues on to the next term after it matched and did whatever the term instructed it to do. I might be missing a usecase for next-term, but other than to make the default behavior explicitly visible, I'm not entirely sure what the purpose of it would functionally be.