Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Dynamic Routing Policies

This example shows how to configure routing policy objects in a dynamic database that is not subject to the same verification required in the standard configuration database.

Requirements

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

Overview

The verification process required to commit configuration changes can entail a significant amount of overhead and time.

The time it takes to commit changes to the dynamic database is much shorter than for the standard configuration database. You can reference these policies and policy objects in routing policies you configure in the standard database. BGP is the only protocol to which you can apply routing policies that reference policies and policy objects configured in the dynamic database. After you configure and commit a routing policy based on the objects configured in the dynamic database, you can quickly update any existing routing policy by making changes to the dynamic database configuration.

CAUTION:

Because Junos OS does not validate configuration changes to the dynamic database, when you use this feature, you should test and verify all configuration changes before committing them.

Figure 1 shows the sample network.

Figure 1: Dynamic Routing Policy Sample NetworkDynamic Routing Policy Sample Network

The example includes three routers with external BGP (EBGP) sessions established. Only Device R1 makes use of the dynamic database.

On Device R0’s fe-1/2/1 interface, multiple IPv4 interfaces are configured, and a routing policy injects these prefixes into BGP, using the from interface fe-1/2/1.0 policy condition as a shorthand method for specifying all of the IP addresses configured on Device R0’s fe-1/2/1 interface.

Likewise, on Device R2’s fe-1/2/3 interface, multiple IPv4 addresses are configured, and a routing policy injects these prefixes into BGP. Device R2’s configuration is slightly different from Device R0’s in that Device R2’s configuration demonstrates the use of a prefix list.

On Device R1, in the dynamic database, two prefix lists are defined, one for the interface addresses learned from Device R0 and another for the interface addresses learned from Device R2. Device R1’s standard database contains routing policies with prefix lists that are similar to those defined in the dynamic database.

In its peer session with Device R0, Device R1 has the static-database policies applied. In contrast, in its peer session with Device R2, Device R1’s configuration references the dynamic database.

The results of these different configurations are analyzed in the Verification section.

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

The section #configuration776__policy-dynamic-st describes the steps on Device R1’s dynamic database.

The section #configuration776__policy-standard-st describes the steps on Device R1’s standard database.

Configuration

Procedure

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 R0

Device R1 Dynamic Database

Device R1 Standard Database

Device R2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1’s dynamic database:

  1. Enter configuration mode for the dynamic database.

  2. Create a prefix list for the interface addresses learned from Device R0.

  3. Create a prefix list for the interface addresses learned from Device R2.

  4. Configure the routing policies.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1’s standard database:

  1. Create the router interfaces.

  2. Create routing policies that reference the policies in the dynamic database.

  3. Configure BGP peering with Device R0.

  4. Apply the dynamic database policies to the BGP peering with Device R0.

  5. Configure a prefix list for prefixes learned from Device R0.

  6. Configure a prefix list for prefixes learned from Device R2.

  7. Configure the static database policies.

  8. Configure BGP peering with Device R2.

  9. Apply the static database policies to the BGP peering with Device R2.

  10. (Optional) Configure the router not to reestablish the BGP peering sessions after an active nonstop routing switchover either for a specified period or until you manually reestablish the session.

    This statement is particularly useful with dynamic routing policies because the dynamic database is not synchronized with the backup Routing Engine when nonstop active routing (NSR) is enabled. As a result, if a switchover to a backup Routing Engine occurs, import and export policies running on the primary Routing Engine at the time of the switchover might no longer be available. Therefore, you might want to prevent a BGP peering session from automatically being reestablished as soon as a switchover occurs.

  11. Configure the autonomous system (AS) number.

Results

Confirm your configuration by entering the show command from configuration mode in the dynamic database, and the show interfaces, show protocols, show policy-options and show routing-options commands from configuration mode in the standard database. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device R1 Dynamic

Device R1 Standard

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking the Configured Policies on Device R1

Purpose

Verify that Device R1 has the dynamic and static policies in effect.

Action

From Device R1, enter the show policy command.

Meaning

The dynamic policies are listed two times because they are configured two times, the first and central configuration in the dynamic database. The secondary configuration is in the static database, where the dynamic database is referenced, as shown here:

Configured in the Dynamic Database

Referenced from the Static Database

Checking the Routes Advertised from Device R0 to Device R1

Purpose

Verify that Device R0’s routing policy is working.

Action

From Device R0, enter the show route advertising-protocol bgp command, using the neighbor address for Device R1.

Meaning

Device R0 is sending the expected routes to Device R1.

Checking the Routes That Device R1 Is Receiving from Device R0

Purpose

Verify that Device R1’s import routing policy is working.

Action

From Device R1, enter the show route receive-protocol bgp command, using the neighbor address for Device R0.

Meaning

Some of the routes that are sent by Device R0 are not received by Device R1. The routes 172.16.9.0/24, 172.16.10.0/24, and 10.0.0.0/30 are missing. This is because Device R1’s import policy, applied to the BGP peering session with Device R0 using the import dyn_policy1 statement, specifically defines a prefix list limited to the following routes:

Checking the Routes Advertised from Device R2 to Device R1

Purpose

Verify that Device R2’s routing policy is working.

Action

From Device R2, enter the show route advertising-protocol bgp command, using the neighbor address for Device R1.

Meaning

Device R2 is sending the expected routes to Device R1.

Checking the Routes That Device R1 Is Receiving from Device R2

Purpose

Verify that Device R1’s import routing policy is working.

Action

From Device R1, enter the show route receive-protocol bgp command, using the neighbor address for Device R0.

Meaning

One of the routes that is sent by Device R2 is not received by Device R1. The route 172.16.6.0/24 is missing. This is because Device R1’s import policy, applied to the BGP peering session with Device R2 using the import static_policy1 statement, specifically defines a prefix list limited to the following routes:

Checking the Routes That Device R1 Is Advertising to Device R0

Purpose

Verify that Device R1’s export routing policy is working.

Action

From Device R1, enter the show route advertising-protocol bgp command, using the neighbor address for Device R0.

Meaning

Perhaps unexpectedly, the route that Device R1 did not receive through BGP from Device R2 (172.16.6.0/24) is nonetheless being advertised by Device R1 through BGP to Device R0. This is happening for two reasons. The first reason is that route 172.16.6.0/24 is in Device R1’s routing table, albeit as a direct route, as shown here:

The second reason is that Device R1’s export policy, applied to the BGP peering session with Device R0 using the export dyn_policy2 statement, specifically defines a prefix list limited to the following routes:

Note the inclusion of 172.16.6.0/24.

Checking the Routes That Device R1 Is Advertising to Device R2

Purpose

Verify that Device R1’s export routing policy is working.

Action

From Device R1, enter the show route advertising-protocol bgp command, using the neighbor address for Device R2.

Meaning

Device R1 is sending the expected routes to Device R2. Device R1’s export policy, applied to the BGP peering session with Device R2 using the export static_policy2 statement, specifically defines a prefix list limited to the following routes: