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.

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).

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.

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