Creating a Simple Routing Policy

Problem

You want to advertise configured static routes to adjacent OSPF neighbors, going beyond the OSPF default of advertising only the routes learned from an OSPF neighbor.

Solution

To modify the route advertisement behavior, create and apply a routing policy. First, create the policy:

	[edit]
	aviva@router1# set policy-options policy-statement send-statics term 1 from protocol
	static
	aviva@router1# set policy-options policy-statement send-statics term 1 then accept

Then, apply it to OSPF:

	[edit]
	aviva@router1# set protocols ospf export send-statics

Here's what the policy looks like in the configuration:

	[edit]
	aviva@router1# show
	policy-options {
	 policy-statement send-statics {
	 term 1 {
	 from protocol static;
	 then accept;
	 }
	 }
	}
	protocols {
	 
ospf {
	 export send-statics;
	 }
	}

 

Discussion

From a structural point of view, this routing policy is very straightforward and illustrates the basic components of how to configure a policy. The JUNOS policy language is similar to standard programming languages or pseudocode, so you can read through the show output in this recipe to get the gist of the policy. If you are not a programmer, you can read the policy language as if it were a paragraph written in an outline format. Looking through the show output in this recipe, you see it creates a policy named send-statics that looks for static routes and accepts them. OSPF applies the policy to routes it advertises to its OSPF neighbors. Rephrased, this recipe allows OSPF to advertise static routes in addition to the default OSPF behavior, which is to advertise routes learned from OSPF.

Before looking at the policy configuration, one question you might ask is why you need to create routing policies at all. What happens if you don't configure any? By default, all routing protocols accept any routes they learn from their protocol neighbors or peers and place them into one of the routing tables (see Table 9-1). This means that without a routing policy, BGP accepts all routes from all its BGP neighbors, IS-IS accepts all routes from all its IS-IS neighbors, OSPF from all its OSPF neighbors, and so on. Routing policy is how you modify this behavior. In most cases, you use routing policy with BGP to enforce peering agreements and your company's administrative policies because they provide explicit control over which routes are installed in the routing table. These routes are eligible to become active routes, which are used for forwarding traffic. Routing policy also provides explicit control over which routes are advertised to the router's neighbors.

Table 9-1. Default routing-policy actions

Protocol	Routing table	Default import action	Default export action
BGP	inet.0	Accept all BGP routes. Do not modify BGP route properties.	Accept and export active BGP routes. Do not modify BGP route properties.
DVMRP	inet.1	Accept all DVMRP routes.	Accept and export active DVMRP routes.
IS-IS	inet.0 and inet6.0	Accept all IS-IS routes. Policy cannot be modified because IS-IS requires that all routers in an area have the same linkstate database to maintain a stable, loop-free network.	Reject everything (IS-IS uses LSPs to advertise its routes).
LDP	inet.3	Accept all LDP routes.	Accept and export active LDP routes.
MPLS	inet.3	Accept all MPLS routes.	Accept and export active MPLS routes.
OSPF	inet.0	Accept all OSPF routes. Policy cannot be modified because OSPF requires that all routers in an area have the same linkstate database to maintain a stable, loop-free network.	Reject everything (OSPF uses LSAs to advertise its routes).
PIM dense mode	inet.1	Accept all PIM DM routes.	Accept and export active PIM DM routes.
PIM sparse mode	inet.1	Accept all PIM SM routes.	Accept and export active PIM SM routes.
RIP	inet.0	Accept all RIP routes learned from RIP neighbors.	Reject everything.
RIPng	inet6.0	Accept all RIPng routes learned from RIPng neighbors.	Reject everything.
Direct and static routes	inet.0	Accept all routes.	Do not export.

What are some reasons to modify the default routing-policy behavior? This recipe illustrates one reason, which is to redistribute routes learned from one protocol (here, static routes) to another protocol (here, OSPF). This type of policy affects which routes the protocol advertises (or exports) from the routing table, so you configure it with a set export command. Another reason is to keep a route out of the routing table so that it can never become the active route. Active routes are placed in the forwarding table and are used to forward traffic. For these types of policy, you use a set import command to control the routes placed into (imported into) the routing table. Another reason specific to BGP is to change the BGP properties associated with a route, such as the AS path and community, and to configure route flap damping. Depending on your purposes, you use the set import or set export commands to apply policies.

For the link-state IGPs (IS-IS and OSPF), you should never modify the default policy behavior for incoming routes (with a set import command). These protocols use link-state databases to keep track of their routes, and the databases on all routers in an area must be identical for the protocol to work properly.

Now let's look at this recipe to understand how the policy is configured. The policy, being a simple one, has only one term, called 1. While you could name the term with a text string that describes what the term does, it is common practice to use a number to name the term, especially in simple policies. The term name is not referenced by other parts of the configuration. It is, however, used in logfiles created when tracing routing-policy operation (see Recipe 9.7), so, for more complex networks and policies, identify each term with a meaningful name so you can identify them in the logfiles.

The first command in the recipe defines the policy match condition. The from clause, from protocol static, looks for routes from the static protocolin other words, static routes that are configured on the local router. Routing policies can match various routing information (see Table 9-2).

Table 9-2. Routing-information match conditions used in routing policies

Match term	Match description
area area-id	Routes learned from an OSPF area.
as-path as-path-string	Routes containing the BGP AS path, which you specify as a regular expression.
community [ names ]	One or more BGP communities.
external [ type metric]	OSPF external routes.
interface name interface address	In a from clause, routes received on an interface or address. In a to clause, routes advertised out of an interface or to an address. Do not use with BGP.
level level	In a from clause, routes from an IS-IS level. In a to clause, routes advertised to an IS-IS level.
local-preference value	BGP LOCAL_PREF attribute.
metric value meTRic2 value	Routes with the metric value. For BGP, metric is the MED and metric2 is the IGP metric of the BGP next hop.
neighbor address	In a from clause, routes from a neighbor. In a to clause, routes advertised to a neighbor.
origin value	BGP ORIGIN attribute.
preference value	Preference value.
protocol name	Sending protocol (aggregate, bgp, direct, dvmrp, isis, local, ospf, pim-dense, pim-sparse, rip, ripng, or static).
tag value tag2 value	Tag and tag2 values in OSPF external LSAs.

A single term can match one or several conditions. Here's an example of a term with two conditions:

	[edit policy-options policy-statement ospf-policy  term 1 ]
	aviva@router1# set from area 0.0.0.1 
	aviva@router1# set from metric 1 

For a route to match this term, it must match both conditions. OSPF must have learned it from area 0.0.0.1, and it must have a metric value of 1. This operation is similar to a logical AND operation.

The second command in the recipe specifies the action to take when a match occurs. Here, the action is to accept the packet ( set then accept). Table 9-3 lists possible policy actions.

Table 9-3. General actions to take on matching routes

Action term	Description	Additional action taken
accept	Accept the route and propagate it.	Evaluation of the policy statement ends. If the policy has more terms, they are ignored. If the policy is part of a chain of policies, any subsequent policies are ignored.
reject	Reject the route and do not propagate it.	Evaluation of the policy statement ends. If the policy has more terms, they are ignored. If the policy is part of a chain of policies, any subsequent policies are ignored.
next term	Take any actions in the then clause that modify the route properties.	Any accept or reject action is ignored, and evaluation of the policy statement jumps to the next term in the policy.
next policy	Take any actions in the then clause that modify the route properties.	Any accept or reject action is ignored, any subsequent terms in the policy are ignored, and evaluation of the policy statement jumps to the next policy in the chain.

Because the policy in this recipe has one term, if the packet matches all the conditions (similar to a logical AND action), the action is taken. If there are no actions or if a route does not match all the conditions, the default accept or reject action is taken, which for OSPF is to reject the route and not advertise it. If a routing policy has multiple terms, they are evaluated sequentially. As soon as the route matches a term, the action in that term is taken and policy evaluation completes. If the route does not match any of the terms, the default action for that protocol is taken.

The then clause can include additional actions that modify the route properties. These are discussed in Recipe 9.2.

The third command in the recipe, set export send-statics, applies the policy to OSPF, referencing it by name. The set export command affects routes that OSPF advertises to its peers. By default, OSPF advertises only routes learned from other OSPF routers. This policy configures OSPF to also advertise any static routes configured on the local router.

Use the show policy command to see which policies are configured:

	aviva@router1> show policy
	Configured policies:
	send-statics

For just one policy, the output is not very interesting. However, if the configuration contains a number of routing policies, this command is a good way to get a quick list of the policies.

Because all routing policies are in a common place in the configuration (in the [edit policy-options] hierarchy), you can refer to them more than once when configuring a routing protocol. For example, you can use the policy in this recipe to redistribute static routes into an EBGP group. Because the policy is already defined, you need to just reference the EBGP group:

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

It's worthwhile to take a moment to comment on the style you use to type configuration statements for routing policies (and also for firewall filters). In this recipe, you are at the [edit] configuration hierarchy level, which is the very top level of the hierarchy, so you have to type the full hierarchy to the statement as well as the statement itself. This recipe has a fairly deep hierarchy level, as do most policy and firewall configurations, so the method shown here involves a lot of typing:

	[edit]
	aviva@router1# set policy-options policy-statement send-statics term 1 from protocol
	static
	aviva@router1# set policy-options policy-statement send-statics term 1 then accept

You may find it a better practice to move to that hierarchy level, both so you have less typing to do and so you have a better sense of where you are in the configuration. For this recipe, you could type most of the configuration commands from the [edit policy-options policy-statement send-statics term 1] hierarchy level:

	[edit]
	aviva@router1# edit policy-options policy-statement send-statics term 1 
	[edit policy-options policy-statement send-statics  term 1 ]
	aviva@router1# set from protocol static 
	aviva@router1# set then accept 

Another configuration shortcut to minimize typing is to use the keystroke sequences listed in Table 1-1. Ctrl-p (or sometimes the up arrow on the keyboard) displays the previous CLI command:

	[edit]
	aviva@router1# set policy-options policy-statement send-statics term 1 from protocol
	static
	aviva@router1# Ctrl-p
	[edit]
	aviva@router1# set policy-options policy-statement send-statics term 1 from protocol
	static

Then delete from protocol static and type then accept. To delete the previous statements, use the Backspace key or the sequence Ctrl-b to move back one character or Esc-b to move back one word, along with Ctrl-k to delete all characters from the cursor to the end of the line:

	[edit]
	aviva@router1# set policy-options policy-statement send-statics term 1 backspace to here 
	aviva@router1# set policy-options policy-statement send-statics term 1 then accept 

 

See Also

Recipes 9.2 and 9.7