[Contents] [Prev] [Next] [Index] [Report an Error]

Defining 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 (described in Table 14) in the from or to statement of another routing policy:



[edit]

policy-options {



policy-statement subroutine-policy-name {


term term-name {


from {

match-conditions;
route-filter destination-prefix match-type <actions>;
source-address-filter destination-prefix match-type <actions>;
prefix-list name;

}




to {

match-conditions;
}


then actions;
}


}


}

policy-options {



policy-statement policy-name {


term term-name {


from {
policy subroutine-policy-name; 
}




to {
policy subroutine-policy-name;
}


then actions;
}


}


}

Note: Do not evaluate a routing policy within itself. If you attempt to do so, no prefixes will 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. For more details about the subroutine evaluation, see How a Routing Policy Subroutine Is Evaluated.

Termination Actions

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. (For more information about default routing policies, see Default Routing Policies and Actions.)

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 export statement 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 export statements 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. (Also see Side Effects of Omitting the "from" Statement from an Export Policy.)
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.

[Contents] [Prev] [Next] [Index] [Report an Error]