Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Walkup for Route Filters Overview

Use the walkup feature if you have concerns about policy performance because of split route filters across multiple policy terms. The walkup feature enables the consolidation of route filters under one policy term.

By default, Junos evaluates multiple route filters in a policy statement term by first finding the longest match prefix and then evaluating the conditions attached to the route filter, such as prefix range. If the route filter condition is false (for example, the prefix is not in the specified range), then the whole term is false, even if there are potentially true shorter route filter prefixes. Due to this behavior, there can be performance issues if route filters are split into individual policy statement terms. The walkup feature changes the default route filter behavior.

Some automated policy tools — for example, those used for autonomous system border routers in the Border Gateway Protocol (BGP) — break up route filters into multiple terms because of the default route filter behavior. Route filters are also used in routing protocols other than BGP; the walkup feature is not limited to BGP route filters.

Note:

Technically, BGP does not deal with routes in the same way as OSPF or IS-IS. BGP “routes” are more properly called network layer reachability information (NLRI) updates. However, the term “route” is used in most documentation and is used here.

Route filters consist of three major parts:

  1. A prefix and prefix length (for example, 10.0.0.0/8)

  2. A match condition (for example, exact)

  3. An action that is carried out if both previous parts — the prefix and match condition — both evaluate to true (for example, accept)

So the 10.0.0.0/8 exact accept route filter succeeds if and only if the prefix considered is 10.0.0.0/8 exactly. This route filter rejects routes with all other longer prefixes, such as 10.0.0.0/10, although there might be other route filter terms in the policy chain that accept the 10.0.0.0/10 route.

Note:

Although the 10.0.0.0/8 route and variations are not specifically reserved for documentation, the private RFC 1918 10.0.0.0/8 address space is used in this topic because of the flexibility and realistic scenarios that this address spaces provides.

Route filters can be combined in a single policy statement term. In that case, evaluation becomes more complex. Consider the following routing policy:

Note that the 10.0.0.0/8 orlonger filter includes the 10.0.0.0/16 prefix-length-range /22-/24 filter in its scope. That is, any 10.0.0.0 route with a prefix of 8 bits or longer could also be a route with a prefix in the range between 22 and 24 bits.

By default, evaluation of a policy statement term with multiple route filters is a two-step process:

  1. The policy framework software performs a longest-match lookup on the list based on prefix and prefix-length values.

  2. The software considers the route filter condition (orlonger, exact, and so on). The route either fulfills the route filter condition (success) or does not match the route filter condition (failure).

Based on the results of these two steps, the action determined by the match or failure is applied to the route. In Route-Filter-A, this means that any route that is “true” is accepted and any route that is “false” in the RouteFilter-1 term is rejected. This route becomes a hidden (filtered) route.

For example, consider what happens when the route 10.0.0.0/18 is evaluated by the policy statement RouteFilter-A:

First, the 10.0.0.0/18 route is evaluated by the RouteFilter-1 term. Because 10.0.0.0/16 is longer than 10.0.0.0/8, the 10.0.0.0/18 route matches the longer and more specific route prefix. Next, the match fails because the 10.0.0.0/18 route does not match the prefix-length-range /22-/24 condition. So the route match fails in the RouteFilter-1 term, and the policy examines the next term, the default term. The 10.0.0.0/18 route is rejected by the default term.

As a result, the 10.0.0.0/18 route is hidden (filtered). (The 10.0.0.0/18 route can still be found with the show route hidden command.)

The issue is that the user might actually want the 10.0.0.0/18 route to be accepted, not rejected. Naturally, a route filter with a 10.0.0.0/18 exact configuration could be added. But in a backbone routing table with 100,000 or more entries, it is not possible to configure a route filter tuned to every possible route or every possible new route added to the network.

The default workaround to achieve the proper behavior from the example routing policy is to configure a separate term for each route filter. This is frequently done, as follows:

Now the 10.0.0.0/18 route is accepted because, although it still fails the RouteFilter-1 match condition, it matches the new RouteFilter-2 term (10.0.0.0/8 is the longest match, and the orlonger condition is true). The problem with this approach is that the complete routing policy now takes more time to evaluate than when multiple route filters are grouped. This method also makes maintenance more complex.

The issues with the one-term-per-route-filters approach are solved with the walkup statement and feature. Walkup alters the default behavior of route filter evaluation globally or on a per-policy basis.

The walkup feature allows terms with multiple route filters to “walk-up” the evaluation process to include less-specific routes as well as the longest match. In other words, the walkup knob changes the default behavior from “if one fails, then the term fails” to if “one matches, then the term matches.”

Consider the application of the walkup feature to the example policy statement (you can also apply walk-up globally to all policies configured):

This is what happens when the route prefix 10.0.0.0/18 is evaluated by the policy statement RouteFilter-A:

The default behavior is altered by the walkup knob. As before, the 10.0.0.0/18 route matches the longer and more specific route prefix because 10.0.0.0/16 is longer than 10.0.0.0/8. As before, this match fails because the 10.0.0.0/18 route does not match the prefix-length-range /22-/24 condition. However, this time the process continues by a “walk up” and examines the less specific 10.0.0.0/8 route filter. The route condition of orlonger matches this filter and therefore the route is accepted by the RouteFilter-1 term.

This can be verified (for a BGP route) by the show route protocol bgp 10.0.0.0/18 command. This time, the route is not hidden.

If you enable the walkup feature globally, you can override it locally on a per-policy basis with the [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] statement.

Related Documentation