Routing Policies

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

In order to get a better understanding, the lab setup is shown in the picture below.

In general, a router uses various routing protocols (e.g., static routing, OSPF, BGP, …​) to learn about possible destinations. Depending on the routing protocols in use, it chooses the best (shortest) path based on protocol specific algorithms and stores it in its routing table. If multiple routing protocols are used in parallel, the router prefers routes from protocols with numerical lower route preference. Finally, the router than installs the active path into the forwarding table which is used to forward packets out the proper interface. In addition, those active paths will be sent to the corresponding protocol neighbors to help other routers building an end-to-end path.

Routing policies are control plane mechanisms that can modify the routers default route selection behavior. The goal of using routing policies is to optimize the traffic flow based on parameters other than shortest path, e.g., network utilization or business advantages like financial costs. Key aspects of routing policies are

In RBFS, a routing policy is defined by a policy statement which is composed of one or more blocks called ordinals that are daisy-chained and evaluated step-by-step. Each ordinal consists of a set of match rules and a set of actions rules.

A route is evaluated in each ordinal until a match is found. In case of a match, the corresponding actions will be executed. If there is no match, the action block will not be executed, and the next ordinal will be processed.

The action block can contain one or more action rules. An action rule can be either a modifying action, i.e., changing certain parameters associated with the route, or a terminating action, i.e., allowing or rejecting the route.

Action rules are evaluated step-by-step. Modifying action rules must be in front of the terminating action in order to get executed. If no ordinal exists and if the policy is used, then all routes or objects will be denied.

The policy framework is generic and can serve multiple purposes and applications. Because the most common use case is control of routing updates in BGP, we will focus on BGP in this module. As BGP policies can get very complex, it is the best way to understand the concept of routing policies through some examples. Therefore, we will go through the process of creating a very simple BGP import policy step-by-step.

BGP routing policies have two main attachment points: as import policies and as export policies. The following figure provides a short summary of the BGP route evaluation process for instance default and IPv4 unicast address-family:

The routing table has two equally good paths to certain prefixes. In this section we will pick two specific prefixes for demonstration: 172.16.104.0/27 and 172.16.104.32/29.

We already know that the most significant BGP attribute in the route selection process is the BGP Local Preference attribute. The BGP FIB reveals the Local Preference value for the considered prefixes:

Note, that for both prefixes under consideration no local preference value is set and two different nexthops (R2 and R3) exist.

We will now implement a simple policy statement consisting of one ordinal. The match rule is only executed for prefix 172.16.104.0/27. The value-type discrete refers to a single value instead of a list of prefixes. The match-type exact indicates that we want to exactly match the given prefix. It is also possible to build more complex matches with regular expressions or prefix-lengths which we will cover later.

The action block consists of two rules. The first rule will set the local preference value to 200. The second rule will accept the prefix. Remember, the implicit default action is deny.

A routing policy by itself does nothing. You can configure as many routing policy statements as you like without changing the behavior of the system. In order to get it working, we need to apply the policy statement to an attachment point, i.e., we need to specify which protocol, address-family, neighbor, etc. should be controlled by this policy statement. In our example, we want to execute it on all IPv4 routes that are learned from BGP peer R2, so we modify the peer-group:

Now, let’s have look at the result:

From the output of prefix 172.16.24.0/27 we can see, that two things have changed after applying the policy statement: The local preference value is now set to 200 and the nexthop is updated to R2 only, because now R2 has a better local preference than R3 and the paths are no longer considered equally good for multipath. Great!

What about your second test prefix. As it is not part of our policy, it should be unchanged:

Oops! There is still no local preference set, but the list of nexthops only contains R3. The path to R2 has been removed. The reason is that there is no rule in our policy matching 172.16.104.32/29 and the default behavior is to reject everything that is not explicitly allowed. In order to fix this problem, we need to add another ordinal:

Now that we have seen a very simple policy example, let’s explorer some more details on the policy actions. The general syntax of an action rule is given by the syntax

There are three well-known attributes possible:

The type and value attribute depend on the routing protocol in use. For IGP protocols (like OSPF and IS-IS) the igp-metric type is the most common one. For BGP, the types local-preference, med, community, large-community and extended-community are regularly used. For a full list of attribute types and supported operation types, please have look at the Policy Configuration.

The operation can be either a terminating or flow control operation or an operation that modifies a route attribute or metric. There are two terminating operations and one flow control operation:

In addition, there are a couple of modifying operations, e.g.

If you want to steer incoming traffic into your autonomous system, you need to adjust BGP path attributes on the routes that you advertise to your neighboring peers. Looking at the BGP route selection process and bearing in mind, that local preference is an attribute only advertised to internal peers, the most common attributes to steer incoming traffic are the AS_PATH and the multi-exit discriminator (MED). As the MED can easily be overwritten easily by subsequent routers, prolonging the AS_PATH is a very popular mechanism.

The general syntax of a match rule is given by the syntax

There are four attribute/value pairs that are all mandatory:

For a full list of attribute types and supported match types please refer to the Policy User Guide.

If you define complex BGP peering policies and will notice that some rules occur over and over again in multiple policies, e.g., certain prefixes that are handled the same way. In order to simplify the configuration and make it easier to read and easier to keep it up-to-date, RBFS supports policy lists for

A policy list represents a set of entries. With IP prefixes it’s obvious that the implicit match-logic is or as two prefixes can hardly be matching at the same time. The policy list is defined using the set policy list <NAME> <TYPE> ordinal <number> value <value> syntax.

Policies can get fairly complex and therefore it is desirable to test a policy without applying it to operational traffic. RBFS provides a way to test a policy before attaching it to a protocol with the test policy run command. For policy tests we need three information:

Consider we want to test the operation of the ISP3_IN policy prior to attaching it to peer R3. As this is a BGP peering, the bgp.appd.1 is the daemon responsible for evaluating the policy. All routes which are learned from R3 are stored in the RIB-IN for this peer. Thus, we can execute the test.

The policy test feature will create two result tables. The result table with the name <bds_table>.policy.permit will show all objects permitted by the policy, the one named <bds_table>.policy.deny will show all objects denied by the policy.

This module outlined the building blocks of the RBFS routing policy framework. You should be able to understand and configure policies using different match and action rules.

If you have completed the exercise, you can check the results by executing