Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understanding Dynamic Routing Policies

The verification process required to commit configuration changes can entail a significant amount of overhead and time. For example, changing a prefix in one line of a routing policy that is 20,000 lines long can take up to 20 seconds to commit. It can be useful to be able to commit routing policy changes much more quickly.

In Junos OS Release 9.5 and later, you can configure routing policies and certain routing policy objects in a dynamic database that is not subject to the same verification required in the standard configuration database. As a result, the time it takes to commit changes to the dynamic database is much shorter than for the standard configuration database. You can then 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 the 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.

Configuring Routing Policies and Policy Objects in the Dynamic Database

Junos OS Release 9.5 and later support a configuration database, the dynamic database, which can be edited in a similar way to the standard configuration database but which is not subject to the same verification process to commit configuration changes. As a result, the time it takes to commit a configuration change is much faster. The policies and policy objects defined in the dynamic database can then be referenced in routing policies configured in the standard configuration. The dynamic database is stored in the /var/run/db/juniper.dyn directory.

To configure the dynamic database, enter the configure dynamic command to enter the configuration mode for the dynamic database:

In this dynamic configuration database, you can configure the following statements at the [edit policy-options] hierarchy level:

  • as-path name

  • as-path-group group-name

  • community community-name

  • condition condition-name

  • prefix-list prefix-list-name

  • policy-statement policy-statement-name

Note:

No other configuration is supported at the [edit dynamic] hierarchy level.

Use the policy-statement policy-statement-name statement to configure routing policies as you would in the standard configuration database.

To exit configuration mode for the dynamic database, issue the exit configuration-mode command from any level within the [edit dynamic] hierarchy, or use the exit command from the top level.

Configuring Routing Policies Based on Dynamic Database Configuration

In the standard configuration mode, you can configure routing policies that reference policies and policy objects configured at the [edit dynamic] hierarchy level in the dynamic database. To define a routing policy that references the dynamic database configuration, include the dynamic-db statement at the [edit policy-options policy-statement policy-statement-name] hierarchy level:

You can also define specific policy objects based on the configuration of these objects in the dynamic database. To define a policy object based on the dynamic database, include the dynamic-db statement with the following statements at the [edit policy-options] hierarchy level:

  • as-path name

  • as-path-group group-name

  • community community-name

  • condition condition-name

  • prefix-list prefix-list-name

In the standard configuration, you can also define a routing policy that references any policy object you have configured in the standard configuration that references an object configured in the dynamic database.

For example, in standard configuration mode, you configure a prefix list prefix-list pl2 that references a prefix list, also named prefix-list pl2, that has been configured in the dynamic database:

You then configure a routing policy in the standard configuration that includes prefix-list pl2:

If you need to update the configuration of prefix-list pl2, you do so in the dynamic database configuration using the [edit dynamic] hierarchy level. This enables you to make commit configuration changes to the prefix list more quickly than you can in the standard configuration database.

Note:

If you are downgrading the Junos OS to Junos OS Release 9.4 or earlier, you must first delete any routing policies that reference the dynamic database. That is, you must delete any routing policies or policy objects configured with the dynamic-db statement.

Applying Dynamic Routing Policies to BGP

BGP is the only routing protocol to which you can apply routing policies that reference the dynamic database configuration. You must apply these policies in the standard configuration. Dynamic policies can be applied to BGP export or import policy. They can also be applied at the global, group, or neighbor hierarchy level.

To apply a BGP export policy, include the export [ policy-names ] statement at the [edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp group group-name neighbor address] hierarchy level.

To apply a BGP import policy, include the import [ policy-names ] statement at the [edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp group group-name neighbor address] hierarchy level.

Include one or more policy names configured in that standard configuration at the [edit policy-options policy-statement] hierarchy level that reference policies configured in the dynamic database.

Preventing Reestablishment of BGP Peering Sessions After NSR Routing Engine Switchover

If you have active nonstop routing (NSR) enabled, the dynamic database is not synchronized with the backup Routing Engine. 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.

You can configure the router not to reestablish a BGP peering session after an active nonstop routing switchover either for a specified period or until you manually reestablish the session. Include the idle-after-switch-over (seconds | forever) statement at the [edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp group group-name neighbor address] hierarchy level:

For seconds, specify a value from 1 through 4,294,967,295 (232 – 1). The BGP peering session is not reestablished until after the specified period. If you specify the forever option, the BGP peering session is not established until you issue the clear bgp neighbor command.