Example: Configuring Walkup for Route Filters Locally to Improve Operational Efficiency
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.
This example shows how to configure the route filter walkup feature locally for policy statements with route filters. When configured at the local level, the route filter walkup option applies only to the policy statement in which it is configured. This example does not change the default behavior of policy terms with route filters globally. This example establishes route filter walkup locally.
This example uses the following hardware and software components:
A Juniper Networks router
A Junos operating system from 13.3 or above
Before you configure route filter walkup globally, be sure you have:
A properly configured routing policy or set of routing policies
A need to consolidate multiple route filter terms into fewer routing policy terms
Routing protocols exchange information with other routers running the same routing protocols. In many cases, route filters are used in routing policy statements to filter prefixes for import or export. In some cases, when route filters are split into many separate terms, performance is impacted. The route filter walkup feature allows consolidation of policy statement terms for operational efficiency.
This example uses BGP, but the same walkup feature applies to any routing protocol that supports route filtering of input or output.
You can configure a Juniper Networks router to change the default operation of a term in a policy statement with route filters. By default, only a single longest match attempt is made for all route filters in a term. The walkup feature allows the router to “walk up” the route filters in a term from longest match to less specific in search of a true condition. This allows consolidation of multiple terms in a policy statement and corresponding operational efficiency.
This example changes the default behavior locally in a single policy statement. It does not affect the behavior of other policy statements.
In the sample network in Figure 1, the router CE1 is a router from another vendor. The rest are Juniper Networks routers. The walkup feature can be configured on any router in the figure, except for router CE1. The vendor of router CE1 might or not might support a similar feature.
In the example, the following addresses are used:
Although the 10.0.0.0/8 address space is 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.
Configuring Route Filter Walkup Locally
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details such as addresses and interfaces to match your network configuration, and then copy and paste the commands into the CLI at the  hierarchy level.
The following example requires that you navigate to various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide
To configure router PE1 to perform walkup locally for multiple route filters in one term:
- Configure the walkup feature locally in a policy named routeset1-import.[edit policy-options policy-statement routeset1-import defaults]user@PE1# set route-filter walkup
- Configure the policy statements for an import policy named routeset1-import.[edit policy-options ]user@PE1# set policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/16 prefix-length-range /22-/24user@PE1# set policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/8 orlongeruser@PE1# set policy-statement routeset1-import term prefixes1 then acceptuser@PE1# set policy-statement routeset1-import term reject-the-rest then reject
- Configure the policy options for the import and export policy statements.[edit policy-options]user@PE1# set policy-statement import-route-filter-a term import-routes from protocol bgpuser@PE1# set policy-statement import-route-filter-a term import-routes from policy routeset1-importuser@PE1# set policy-statement import-route-filter-a term import-routes then next policyuser@PE1# set policy-statement route-filter-a-export term all-others then reject
- Apply the import and export policies to a BGP neighbor.[edit protocols bgp]user@PE1# set group routeset1 type externaluser@PE1# set group routeset1 neighbor 10.0.10.13 import import-route-filter-auser@PE1# set group routeset1 neighbor 10.0.10.13 family inet unicastuser@PE1# set group routeset1 neighbor 10.0.10.13 export route-filter-a-exportuser@PE1# set group routeset1 neighbor 10.0.10.13 peer-as 64506
From configuration mode, confirm your configuration by entering the show protocols and show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
If you are done configuring the device, enter commit from configuration mode.
Verifying Route Filter Operation
Display expected information about the routes to confirm the route filters are working as expected.
Notice 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. Without the walkup feature enabled in the policy example given, a route such as 10.0.0.0/16 would be rejected and become a hidden route. If the walkup feature is working as expected, then a route such as 10.0.0.0/16 would be accepted by the policy.
From operational mode, enter the show route protocolbgp 10.0.0.0/16 command. Make sure that 10.0.0.0/16 is not a hidden route.
user@PE1>show route protocol bgp 10.0.0.0/16
inet.0: 520762 destinations, 520764 routes (520760 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/16 *[BGP/170] 01:07:37, localpref 100 AS path: 64506, I, validation-state: unverified > to 10.0.100.13 via xe-0/2/0.0
As a further check, make sure that no routes that should be accepted are hidden routes. From operational mode, enter the show route protocol bgp ip-address-prefix hidden command to verify this.
The presence of routes that are not the longest match in the configured policy route filter term shows that the walkup feature is functioning locally.
To troubleshoot route filter walkup locally:
BGP is not functioning as expected.
See the BGP Configuration Overview topic, examples, and troubleshooting.
Troubleshooting Policy Statements
The policy statements are not functioning as expected.
See the Verify That a Particular BGP Route Is Received on Your Router and Example: Configuring BGP Route Advertisement topics, related examples, and troubleshooting.
Troubleshooting Route Filters
The route filters are not functioning as expected.
See the Route Filter Match Conditions topic, examples, and troubleshooting.