Creating a Chain of Routing Policies

Problem

You need to perform a series of actions on routes.

Solution

The JUNOS routing-policy language has several different ways of chaining policies together. One way is to list more than one policy in the import or export command:

	[edit protocols bgp group external-group ]
	aviva@router1# set export [ block-private remove-communities send-statics ] 

A second way is to configure policy evaluation so that it explicitly jumps to the next policy when a match occurs:

	[edit policy-options policy-statement from-my-customers  term 1 ]
	aviva@router1# set then local-preference 300 
	aviva@router1# set then community set 65500:12345 
	aviva@router1# set then next policy 

 

Discussion

Larger networks typically require a number of routing policies to handle an ISP's peer and customer relationship or to handle different organizations within a large enterprise network. You have to make the design decision about whether to create longer policies with many terms or whether to create a number of smaller policies and chain them together. Because policy language is so critical to the operation of your network and your business, and because policy language can get complex quickly and might have unexpected results, it is good practice to design policies to be as straightforward as possible.

This recipe illustrates two ways of creating a number of smaller policies and chaining them together. The first command, set export, chains together three policies that have been configured in the [edit policy-options] hierarchy when configuring a BGP group. The JUNOS policy language evaluates the three policies in order. If a route does not match the conditions in block-private, evaluation continues with the remove-communities policy. If a route does not match the conditions in remove-communities, the policy language looks at the send-statics policy. When a route does match the conditions in one of the policies, the action is taken immediately. If a route matches none of the policies, no action is taken.

Let's take a look at the three routing policies to see how they are evaluated when chained together:

	[edit]
	aviva@router1> show configuration policy-options
	policy-statement block-private {
	 term 1 {
	 from {
	 route-filter 0.0.0.0/0 upto /7;
	 route-filter 0.0.0.0/0 prefix-length-range /25-/32;
	 route-filter 10.0.0.0/8 orlonger;
	 route-filter 127.0.0.0/8 orlonger;
	 route-filter 172.16.0.0/12 orlonger;
	 route-filter 192.168.0.0/16 orlonger;
	 route-filter 224.0.0.0/4 orlonger;
	 }
	 then reject;
	 }
	 }
	}
	policy-statement remove-communities {
	 term 1 {
	 then {
	 community delete all-communities;
	 }
	 }
	}
	policy-statement send-statics {
	 term 1 {
	 from protocol [ static direct ];
	 then accept;
	 }
	}
	community all-communities members *:*;

For routes being exported by the BGP group external-group, the policy evaluation first checks against the prefix ranges listed in the block-private policy, which keeps private addresses from being advertised to external ASs. Routes matching any one of the prefixes are rejected, and policy evaluation stops. Otherwise, routes are checked against the remove-communities policy. This policy has no match conditions, so all routes match and all community strings are removed from the route. Because this policy has no action that terminates policy evaluation (accept or reject), the evaluation continues with the next policy in the chain, send-statics, which redistributes static and direct routes to the BGP peers. At this point, if a route does not match any of the three routing policies, the default BGP export action is taken, which is to export only those routes learned from BGP and reject everything else.

You can also design routing policies that are implicitly chained together. If a policy has no flow control action (then accept, then reject, then next term, or then next policy) and has no more terms, policy evaluation automatically continues with the next policy if one is configured. The second two policies, remove-communities and send-statics, illustrate how this works. After the remove-communities policy removes the community string from the route, no action is taken and evaluation automatically continues with the send-statics policy, which has an accept action to terminate policy evaluation.

When chaining policies together in this way, make sure that the last policy in the chain has a terminating action (either then accept or then reject). One trick for ensuring that there's always a terminating action is to create a policy that is nothing more than the action itself and place it at the end of the chain:

	[edit policy-options policy-statement final-accept ]
	aviva@router1# set then accept 
	[edit protocols bgp group external-group ]
	aviva@router1# set export [ block-private remove-communities send-statics final-accept ] 

You would no longer need the set then accept command at the end of the send-statics policy, so the configured policies would look like this:

	edit]
	aviva@router1> show configuration policy-options
	policy-statement remove-communities {
	 term 1 {
	 then {
	 community delete all-communities;
	 }
	 }
	}
	policy-statement send-statics {
	 term 1 {
	 from protocol [ static direct ];
	 }
	}
	policy-statement final-accept {
	 term 1 {
	 then accept;
	 }
	}
	community all-communities members *:*;

The second configuration in this recipe chains policies using the next policy action in a then clause. This forces policy evaluation to continue with the next policy after a match occurs. The next policy action is optional because it is the default action that the policy evaluation takes when a match occurs; when you do not include an accept, reject, or next term action; and when there are no more terms in the routing policy. However, using it can speed up policy evaluation when a policy contains several terms and the import or export command references a number of policies.

It is also possible to explicitly jump to the next term in a policy when a match occurs:

	[edit policy-options policy-statement from-my-customers]
	aviva@router1# set term 1 from protocol direct
	aviva@router1# set term 1 then local-preference 300
	aviva@router1# set term 1 then community set 65500:12345
	aviva@router1# set term 1 then 
next term
	aviva@router1# set term 2 from protocol static
	aviva@router1# set term 2 then local-preference 300
	aviva@router1# set term 2 then community set 65500:10300
	aviva@router1# set term 2 then next term
	aviva@router1# set final-term then reject

Once again, explicitly configuring this action is optional because it is the default when a match occurs and you haven't specified an accept, reject, or next term action.