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. It can control route import into a routing instance, route redistribution into protocols such as BGP, OSPF, or IS-IS, as well as the route updates sent to and received from BGP neighbors. Since the most common use case is the control of routing updates in BGP, we will focus on BGP in this module.

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:

As BGP policies can become very complex, we will start with a simple policy example. In our pre-configured lab environment, R1 sends three prefixes to its neighbor that originate within AS 64501:

As we can see, the advertised prefixes are the links to R2 and R3, as well as the loopback address. These prefixes are direct routes and are redistributed into BGP. We’ll configure a policy named LOOP_ONLY that only allows the redistribution of the loopback address into BGP. A policy is created using the command set policy statement <name>.

This policy will have a single ordinal that matches the IPv4 prefix corresponding to the loopback address. The match-type exact ensures that the prefix must exactly match the defined prefix, while the value-type discrete indicates that a single value is used.

After defining the policy, we need to attach it. In this example, we want to control the routes that are redistributed into BGP. To do so, we use the command set instance <name> protocol bgp address-family <afi> <safi> redistribute <protocol> policy <policy-name>. Then, commit the configuration changes.

We can confirm that only the loopback prefix is advertised to peers.

After we had a first look on the updates that R1 sends to it’s peers, we can also inspect what R1 receives from it’s BGP neighbors, for example R2:

RFC 1918 defines ranges of IPv4 addresses that should not be used on the public Internet. These ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. In our lab environment, the last two blocks are used for demonstration purposes, but the 10.0.0.0/8 range is not. However, both R2 and R3 advertise prefixes from this block.

After evaluating the policy, we find the result is not as expected:

The good news is that the 10.0.0.0/8 prefix is no longer accepted. The bad news is that no other prefixes are accepted either.

This happens because the default behavior of a policy is to reject all prefixes that are not explicitly accepted. In our first example, LOOP_ONLY, this behavior was exactly what we wanted, i.e., only one prefix was meant to be accepted. However, in the NET10 policy, there are no terms that explicitly accept other prefixes. As a result, everything is rejected. To fix this, you must add an ordinal that explicitly accepts all other prefixes, which is placed after the reject rule for 10.0.0.0/8.

Especially when used at a BGP peering router, the complexity of policy configurations for these routes can become significant. Individual policies can easily span hundreds of lines of code, making both operation and troubleshooting more challenging. Additionally, some policy rules (e.g., filtering RFC 1918 private addresses) are frequently used, and keeping them up to date can require additional effort.

To address these challenges, RBFS offers the option to implement policy chaining. Policy chaining allows you to break down a large, complex policy into smaller, modular policies that are executed in a predefined order, making them easier to maintain. This modular approach not only simplifies operation, as the policies become more readable and understandable, but also makes implementing changes easier by providing a single touchpoint, thus reducing the risk of inconsistencies.

In RBFS, configuring a policy chain is straightforward: you simply add multiple import or export policies to the corresponding attachment point, creating a list of policies rather than an atomic entry. The policy chain is then evaluated in the same manner as a single policy — ordinal by ordinal — just as if it were one large policy.

It’s important to remember that policy execution stops if a return-permit or return-deny action is encountered. To ensure that all policies are properly evaluated, make sure there are no actions for unmatched prefixes at the end of a policy. Otherwise, the next policy in the chain may not be evaluated.

We can now verify that all the subnets from the 10.0.0.0/8 are discarded by the NET10 policy, while all remaining prefixes are accepted:

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.

Now that we’ve covered the most important match rules supported in RBFS, let’s take a closer look at the action rules. We’ve already used return-permit and return-deny, but when working with BGP, it’s often useful to modify route attributes. 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 two flow control operation:

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

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 IMPORT_ISP2 policy prior to attaching it to peer R2. As this is a BGP peering, the bgp.appd.1 is the daemon responsible for evaluating the policy. All routes which are learned from R2 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