Understanding Policy Subroutines in Routing Policy Match Conditions
You can use a routing policy called from another routing policy as a match condition. This process makes the called policy a subroutine.
In some ways, the Junos OS policy framework is similar to a programming language. This similarity includes the concept of nesting policies into a policy subroutine. A subroutine in a software program is a section of code that you reference on a regular basis. A policy subroutine works in the same fashion—you reference an existing policy as a match criterion in another policy. The routing device first evaluates the subroutine and then evaluates the main policy. The evaluation of the subroutine returns a true or false Boolean result to the main policy. Because you are referencing the subroutine as a match criterion, a true result means that the main policy has a match and can perform any configured actions. A false result from the subroutine, however, means that the main policy does not have a match.
Configuring Subroutines
To configure a subroutine in a routing policy to be called from
another routing policy, create the subroutine and specify its name
using the policy match condition in the from or to statement of another routing policy.
Do not evaluate a routing policy within itself. The result is that no prefixes ever match the routing policy.
The action specified in a subroutine is used to provide a match condition to the calling policy. If the subroutine specifies an action of accept, the calling policy considers the route to be a match. If the subroutine specifies an action of reject, the calling policy considers the route not to match. If the subroutine specifies an action that is meant to manipulate the route characteristics, the changes are made.
Possible Consequences of Termination Actions in Subroutines
A subroutine with particular statements can behave differently from a routing policy that contains the same statements. With a subroutine, you must remember that the possible termination actions of accept or reject specified by the subroutine or the default policy can greatly affect the expected results.
In particular, you must consider what happens if a match does not occur with routes specified in a subroutine and if the default policy action that is taken is the action that you expect and want.
For example, imagine that you are a network administrator at an Internet service provider (ISP) that provides service to Customer A. You have configured several routing policies for the different classes of neighbors that Customer A presents on various links. To save time maintaining the routing policies for Customer A, you have configured a subroutine that identifies their routes and various routing policies that call the subroutine, as shown below:
[edit]
policy-options {
policy-statement customer-a-subroutine {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
then accept;
}
}
policy-options {
policy-statement send-customer-a-default {
from {
policy customer-a-subroutine;
}
then {
set metric 500;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-primary {
from {
policy customer-a-subroutine;
}
then {
set metric 100;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-secondary {
from {
policy customer-a-subroutine;
}
then {
set metric 200;
accept;
}
}
}
protocols {
bgp {
group customer-a {
export send-customer-a-default;
neighbor 10.1.1.1;
neighbor 10.1.2.1;
neighbor 10.1.3.1 {
export send-customer-a-primary;
}
neighbor 10.1.4.1 {
export send-customer-a-secondary;
}
}
}
}
The following results occur with this configuration:
The group-level
exportstatement resets the metric to 500 when advertising all BGP routes to neighbors 10.1.1.1 and 10.1.2.1 rather than just the routes that match the subroutine route filters.The neighbor-level
exportstatements reset the metric to 100 and 200 when advertising all BGP routes to neighbors 10.1.3.1 and 10.1.4.1, respectively, rather than just the BGP routes that match the subroutine route filters.
These unexpected results occur because the subroutine policy does not specify a termination action for routes that do not match the route filter and therefore, the default BGP export policy of accepting all BGP routes is taken.
If the statements included in this particular subroutine had been contained within the calling policies themselves, only the desired routes would have their metrics reset.
This example illustrates the differences between routing policies and subroutines and the importance of the termination action in a subroutine. Here, the default BGP export policy action for the subroutine was not carefully considered. A solution to this particular example is to add one more term to the subroutine that rejects all other routes that do not match the route filters:
[edit]
policy-options {
policy-statement customer-a-subroutine {
term accept-exact {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
then accept;
}
term reject-others {
then reject;
}
}
}
Termination action strategies for subroutines in general include the following:
Depend upon the default policy action to handle all other routes.
Add a term that accepts all other routes.
Add a term that rejects all other routes.
The option that you choose depends upon what you want to achieve with your subroutine. Plan your subroutines carefully.