How to Configure Routing Policy Match Actions in Junos

Routing policies have terms that include match conditions and match actions. The match conditions are the IF, the match actions are the THEN. When a particular match condition is met, the action associated with that term is executed. While there are many match conditions, there are a limited number of match actions you can choose from.

Action	Description
accept	Accept or advertise the route.
reject	Reject or suppress the route.
next-term	Stop evaluating the current term in the policy and immediately go to the next term. In this case, no terminating action is executed, but all other actions are executed (meaning a route can be modified before passing to the next term).
next-policy	Stop evaluating the current term in the policy and immediately move to the next policy. In this case, no terminating action is executed, but all other actions are executed (exactly as the previous action).
modify	Several modifying actions manipulate values in the route, such as as-path, class="code">metric, preference, and so on. These actions are not terminating actions. The specified route attribute is modified as configured, and then any other match actions are executed (if more than one is configured for that particular term). If there are no terminating actions, the next term is evaluated (if one exists).
trace	Log the match to a trace file. This is useful for debugging routing policy.

About 95 percent of the time (if not more), you’ll be able to do what you want using only accept and reject. These actions are called terminating actions, because when they’re executed, the routing policy evaluation stops, and the decision about the route is made. You don’t need to continue evaluating other terms in the policy or other policies in the chain.

Actions such as next-term and next-policy provide some sophisticated flow control capabilities, but you probably will not need them right away. (In fact, in many cases they just complicate figuring out exactly what the policy will do when you turn the policy loose.)

Additionally, unless you’re a service provider, modifying route attributes is probably not something you want to deal with. Although you can do some interesting things by modifying route attributes, such constructs are more widely used in carrier networks.

If match actions form the THEN part of the IF-THEN statement, it probably makes sense to configure them using the then statement within a policy:

[edit policy-options]
policy-statement my-sample-policy {
  term my-first-term {
   from protocol ospf;
   then accept;
  term my-second-term {
   from neighbor 10.22.32.1;
   then reject;
  }
}

Notice that, just like with the match conditions, the configuration is collapsed when you have a single match action. In this example, the first term is evaluated. If the route is an OSPF route, the route is accepted. If the route isn’t an OSPF route, the second term is evaluated. If the route has been learned from the neighbor 10.22.32.1, the route is rejected.

Note that this latest my-sample-policy does not reject OSPF routes learned from 10.22.32.1. The first term accepts all OSPF routes and the second one rejects everything learned from 10.22.32.1.

Match conditions in the same term are evaluated as a logical AND, but policy terms are evaluated more like a logical OR in the order encountered. If you want something special to happen to OSPF routes learned from 10.22.32.1, this is not the way to do it. If you’re now confused, at least you understand how delicate routing policy formulation can be.

As with match conditions, you can specify more than one match action. For example, you may want to modify a route metric so that it becomes the preferred route, and then you want to accept that route. In this case, you need both a modifying action and the accept terminating action. This configuration is as follows:

[edit policy-options]
policy-statement my-sample-policy {
  term my-first-term {
   from protocol ospf;
   then {
     metric 5;
     accept;
   }
  }
}

In this example, you match on all OSPF routes. Before accepting the route, you set the route metric to 5 (why it isn’t “modify metric 5” is a mystery). Both match actions are executed in this case.

dummies

Source:http://www.dummies.com/how-to/content/how-to-configure-routing-policy-match-actions-in-j.html