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.
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:
user@host> configure dynamic Entering configuration mode [edit dynamic] user@host#
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
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:
[edit policy-options] policy-statement policy-statement-name { dynamic-db; }
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:
[edit policy-options] prefix-list pl2 { dynamic-db; # Reference a prefix list configured in the dynamic database. }
You then configure a routing policy in the standard configuration that includes prefix-list pl2
:
[edit policy-options] policy-statement one { term term1 { from { prefix-list pl2; # Include the prefix list configured in the standard configuration # database, but which references a prefix list configured in the dynamic database. } then accept; } then reject; }
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.
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.
[edit] protocols bgp { export [ policy-names ]; } }
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.
[edit] protocols bgp { import [ policy-names ]; } }
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:
[edit] bgp { protocols { idle-after-switch-over (seconds | never); } }
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.