Applying Policies to OSPF Routes

All routing protocols store the routes that they learn in the routing table. The routing table uses this collected route information to determine the active routes to destinations. The routing table then installs the active routes into its forwarding table and also exports them back into the routing protocols. It is these exported routes that the protocols advertise.

For each protocol, you control which routes the protocol stores in the routing table and which routes the routing table exports into the protocol by defining a routing policy for that protocol. For information about defining a routing policy, see the Junos Policy Framework Configuration Guide.

By default, if a routing device has multiple OSPF areas, learned routes from other areas are automatically installed into area 0 of the routing table.

To apply routing policies that affect how the routing table exports routes into OSPF, include the export statement:

export [ policy-names ];

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

OSPF import policy allows users to define policy to prevent adding OSPF routes to the routing table. This filtering happens when OSPF installs the route in the routing table. You can filter the routes, but not LSA flooding. The import policy can filter on any attribute of the OSPF route.

To filter OSPF routes from being added to the routing table, include the import statement:

import [ policy-names ];

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Configuring Import and Export Policies for Network Summaries

By default, OSPF uses network-summary link-state advertisements (LSAs) to transmit route information across area boundaries. Each area border router (ABR) floods network-summary LSAs to other routing devices in the same area. In Junos OS Release 9.1 and later, you can configure export and import policies for OSPFv2 and OSPFv3 that enable you to control how network-summary LSAs, which contain information about interarea OSPF prefixes, are distributed and generated. For OSPFv3, the LSA is referred to as the interarea prefix LSA and performs the same function as a network-summary LSA performs for OSPFv2. An ABR originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an area.

The export policy enables you to specify which summary LSAs are flooded into an area. The import policy enables you to control which routes learned from an area are used to generate summary LSAs into other areas. You define a routing policy at the [edit policy-options policy-statement policy--name] hierarchy level. As with all OSPF export policies, the default for network-summary LSA export policies is to reject everything. Similarly, as with all OSPF import policies, the default for network-summary LSA import policies is to accept all OSPF routes. For more information about configuring policies, see the Junos Policy Framework Configuration Guide.

To apply an export routing policy for OSPFv2 that affects which network-summary LSAs are flooded into an area, include the network-summary-export [ policy-names ] statement:

area area-id {network-summary-export [ policy-names ];}

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

To apply an import routing policy for OSPFv2 that affects which routes learned from an area are used to generate network-summary LSAs, include the network-summary-import [ policy-names] statement:

area area-id {network-summary-import [ policy-names ];}

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

To apply an export routing policy for OSPFv3 that affects which interarea prefix LSAs are flooded into an area, include the inter-area-prefix-export [ policy-names ] statement:

area area-id {inter-area-prefix-export [ policy-names ];}

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

To apply an import routing policy for OSPFv3 that affects which routes learned from an area are used to generate interarea prefix LSAs, include the inter-area-prefix-import [ policy-names ] statement:

area area-id {inter-area-prefix-import [ policy-names ];}

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Configuring Priority for Prefixes in Import Policy

In a network with a large number of OSPF routes, it can be useful to control the order in which routes are updated in response to a network topology change. In Junos OS Release 9.3 and later, you can specify a priority of high, medium, or low for prefixes included in an OSPF import policy. In the event of an OSPF topology change, high priority prefixes are updated in the routing table first, followed by medium and then low priority prefixes.

OSPF import policy can only be used to set priority or to filter OSPF external routes. If an OSPF import policy is applied that results in a reject terminating action for a nonexternal route, then the reject action is ignored and the route is accepted anyway. By default, such a route is now installed in the routing table with a priority of low. This behavior prevents traffic black holes, that is, silently discarded traffic, by ensuring consistent routing within the OSPF domain.

In general, OSPF routes that are not explicitly assigned a priority are treated as priority medium, except for the following:

To specify a priority for prefixes included in an import policy, include the priority (high | medium | low) statement at the [edit policy-options policy statement policy-statement-name term term-name then] or [edit policy-options policy-statement policy-statement-name then] hierarchy level.

Any available match criteria applicable to OSPF routes can be used to determine the priority. Two of the most commonly used match criteria for OSPF are the route-filter and tag statements. For more information about configuring routing policy and match conditions, see the Junos Policy Framework Configuration Guide.

Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF

Configure an import routing policy, ospf-import, that enables you to specify a priority for specific prefixes learned through OSPF. Routes associated with these prefixes are installed in the routing table in the order of the prefixes’ specified priority. Routes matching 200.3.0.0/16 orlonger are installed first because they have a priority of high. Routes matching 200.2.0.0/16 orlonger are installed next because they have a priority of medium. Routes matching 200.1.0.0/16 orlonger are installed last because they have a priority of low. To apply the import policy to OSPF, include the import ospf-import statement at the [edit protocols (ospf | ospf3)] hierarchy level. For a complete list of hierarchy levels at which the import statement can be configured, see the configuration statement summary for that statement.

policy-options {policy-statement ospf-import {term t1 {from {route-filter 200.1.0.0/16 orlonger;}then {priority low;accept;}}term t2 {from {route-filter 200.2.0.0/16 orlonger;}then {priority medium {accept;}}tern t3 {from {route-filter 200.3.0.0/16 orlonger;}then {priority high;accept;}}}}