Online Test Banks
Score higher
See Online Test Banks
eLearning
Learning anything is easy
Browse Online Courses
Mobile Apps
Learning on the go
Explore Mobile Apps
Dummies Store
Shop for books and more
Start Shopping

How to Configure Routing Policy Terms in Junos

The building blocks that make up routing policies are called terms. Each term contains match conditions, a series of “if” statements that are compared to the routes under consideration. The match conditions are checked against the routing information. Based on the outcome of those checks, the router will take one or more actions. Terms can be strung together to form a routing policy.

Terms and actions needed to create a policy.
Terms and actions needed to create a policy.

Assume that you apply a routing policy to filter incoming routing protocol information. The routing policy is made up of several terms. As the route comes in, the policy is invoked.

The first term in the policy is evaluated. If the route matches the conditions specified, some kind of action is taken. If the route doesn’t match, the second term in the policy is evaluated. That second term’s conditions are checked, and if they match, an action is taken. If they don’t match, the third term in the policy is evaluated, and so on until all terms have been examined.

If none of the terms of the policy are a match for the route in question, the next policy is evaluated, and so on until the default policy action is taken. It’s important to realize that some default action is always taken unless an earlier match condition applies.

To configure a routing policy, you must configure one or more terms within that policy. You handle configuration for policies within the policy-options configuration hierarchy:

[edit policy-options]
policy-statement my-sample-policy {
  term my-first-term {
   from {
     match-conditions;
   }
   then {
     action;
   }
  term my-second-term {
   from {
     match-conditions;
   }
   then {
     action;
   }
}

In this configuration skeleton, you configure a single routing policy called my-sample-policy. That policy has two terms, each of which has a match condition and a match action. If a route is evaluated against this policy and neither term matches, the default action is executed.

Once an action is taken, the policy is no longer evaluated. So, if you have an action triggered in the first term, the second term never evaluates the second term.

Because the policy chain evaluation stops with any applied action, the ordering of terms is crucial to proper policy operation.

Terms within a policy are evaluated in a top-down manner, so the order of the terms within your configuration counts. The challenge here is that whenever you add a new term to an existing policy, by default, these terms are appended to the terms that are already configured. More recently added terms are always evaluated after the terms initially configured. For example, examine the following policy configuration:

 [edit policy-options]
policy-statement advertise-ospf-routes {
  term find-ospf {
   from {
     protocol ospf;
   }
   then {
     accept;
   }
  }
}

When applied as an input policy, this policy simply accepts all OSPF routes. To fine-tune this policy a little bit and accept all OSPF routes except those that originate from a particular area in your OSPF network, you need to add a term. Because terms are, by default, appended to existing terms, your configuration will be as follows:

[edit policy-options]
policy-statement advertise-ospf-routes {
  term find-ospf {
   from {
     protocol ospf;
   }
   then {
     accept;
   }
  }
  term reject-area-10 {
   from {
     protocol ospf;
     area 10;
   }
   then {
     reject;
   }
  }
}

Here, you want all OSPF routes to be accepted unless they come from area 10. However, when a route comes in, the first term is evaluated. If the route is an OSPF route, it’s accepted, regardless of its area of origin. No routes from area 10 are ever rejected, because the first term accepts all OSPF routes.

To add the reject-area-10 term before the find-ospf term, you use the insert command. You configure the two terms exactly as you did in the preceding code, but when you’re done, you insert the term where you want it:

user@host# insert policy-statement advertise-ospf-routes term reject-area-10
    before term find-ospf

The insert command moves the configuration for the reject-area-10 term before the configuration to find all OSPF routes. The resulting configuration does what you want:

[edit policy-options]
policy-statement advertise-ospf-routes {
  term reject-area-10 {
   from {
     protocol ospf;
     area 10;
   }
   then {
     reject;
   }
  }
  term find-ospf {
   from {
     protocol ospf;
   }
   then {
     accept;
   }
  }
}
blog comments powered by Disqus
Advertisement

Inside Dummies.com

Dummies.com Sweepstakes

Win $500. Easy.