Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Routing Policy Prefix Lists

In Junos OS, prefix lists provide one method of defining a set of routes. Junos OS provides other methods of accomplishing the same task, such as route filters. A prefix list is a listing of IP prefixes that represent a set of routes that are used as match criteria in an applied policy. Such a list might be useful for representing a list of customer routes in your autonomous system (AS). A prefix list is given a name and is configured within the [edit policy-options] configuration hierarchy.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

Prefix lists are similar to a list of route filters. The functional difference between route filters and prefix lists is that you cannot specify a range using a prefix list. You can simulate a range using a prefix list by including additional prefixes in the list, or by using two prefix lists, one shorter and one longer, setting one to accept and the other to reject. You can also filter a prefix list using the prefix-list-filter match condition. Your choices are exact, longer, and orlonger.

The benefit of a prefix list over a list of route filters is seen when the prefixes are referenced in several different locations. For instance, a prefix list can be referenced in a BGP import policy, an export policy, an RPF policy, in firewall filters, in loopback filters, in setting a multicast scope, and so on.

When your list of prefixes changes, rather than trying to remember the many different locations prefixes are configured, you can instead update the prefix list, changing the prefix one time instead of multiple times. This helps to reduce the likelihood of configuration errors, such as mistyping the address in a location or forgetting to update one or more locations.

Prefix lists also help when managing a large number of devices. You can write the various filters and policies as generically as possible, referencing prefix lists instead of specific IP addresses. The more complex logic in the filters and policies has to be written only one time, with minimal per-device and per-site customizations.

As shown in Figure 1, each router in AS 64510 has customer routes. Device R1 assigns customer routes within the 172.16.1.0/24 subnet. Device R2 and Device R3 assign customer routes within the 172.16.2.0/24 and 172.16.3.0/24 subnets, respectively. Device R1 has been designated the central point in AS 64510 to maintain a complete list of customer routes. Device R1 has a prefix list called customers, as follows:

As you can see, the prefix list does not contain a match type for each route (as you would see with a route filter). This is an important point when using a prefix list in a policy. Routes match only if they exactly match one of the prefixes in the list. In other words, each route in the list must appear in the routing table exactly as it is configured in the prefix list.

You reference the prefix list as a match criterion within a policy like this:

In this example, all the routes in the customers prefix list appear in the routing table on Device R1. Device R2 and Device R3 export to Device R1 static routes to their customers.

As previously mentioned, you can use the prefix-list-filter match condition with the exact, longer, or orlonger match type. This provides a way to avoid the prefix list exact-match limitation of prefix lists. For example:

The example demonstrates the effects of both the prefix-list match condition and the prefix-list-filter match condition.

Topology

Figure 1 shows the sample network.

Figure 1: BGP Topology for Policy Prefix ListsBGP Topology for Policy Prefix Lists

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

The section #configuration449__policy-prefix-list-st describes the steps on Device R1.

Configuration

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 necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R1

Device R2

Device R3

Device R4

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1:

  1. Configure the device interfaces.

  2. Configure the internal BGP (IBGP) connections to Device R2 and Device R3.

  3. Configure the EBGP connection to Device R4.

  4. Configure OSPF connections to Device R2 and Device R3.

  5. Configure the prefix list.

  6. Configure the routing policy that references the prefix list as a match criterion.

  7. Configure the static route to the 172.16.5.0/24 network.

  8. Configure the autonomous system (AS) number and router ID.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-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.

Verification

Confirm that the configuration is working properly.

Verifying the Routes on Device R1

Purpose

On Device R1, check the routes in the routing table.

Action

Meaning

Device R1 has learned its own static routes (S) and the BGP routes from Devices R2 and R3 (B).

Verifying the Route Advertisement to Device R4

Purpose

On Device R1, make sure that the customer routes are advertised to Device R4.

Action

Meaning

As expected, only the routes from the customer prefix list are advertised to Device R4.

Experimenting with the prefix-list-filter Statement

Purpose

See what can happen when you use prefix-list-filter instead of prefix-list.

Action

  1. On Device R2, add a static route that is longer than one of the existing static routes.

  2. On Device R1, deactivate the prefix list and configure a prefix list filter with the orlonger match type.

  3. On Device R1, check which routes are advertised to Device R4.

Meaning

As expected, Device R1 is now advertising the 172.16.2.65/32 route to Device R4, even though 172.16.2.65/32 is not in the prefix list.