Understanding Dynamic Routing Policies

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

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.

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 (2³² – 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.