Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring OSPF Routing Policy

Understanding Routing Policies

For some routing platform vendors, the flow of routes occurs between various protocols. If, for example, you want to configure redistribution from RIP to OSPF, the RIP process tells the OSPF process that it has routes that might be included for redistribution. In Junos OS, there is not much direct interaction between the routing protocols. Instead, there are central gathering points where all protocols install their routing information. These are the main unicast routing tables inet.0 and inet6.0.

From these tables, the routing protocols calculate the best route to each destination and place these routes in a forwarding table. These routes are then used to forward routing protocol traffic toward a destination, and they can be advertised to neighbors.

Importing and Exporting Routes

Two terms—import and export—explain how routes move between the routing protocols and the routing table.

  • When the Routing Engine places the routes of a routing protocol into the routing table, it is importing routes into the routing table.

  • When the Routing Engine uses active routes from the routing table to send a protocol advertisement, it is exporting routes from the routing table.

    Note:

    The process of moving routes between a routing protocol and the routing table is described always from the point of view of the routing table. That is, routes are imported into a routing table from a routing protocol and they are exported from a routing table to a routing protocol. Remember this distinction when working with routing policies.

As shown in Figure 1, you use import routing policies to control which routes are placed in the routing table, and export routing policies to control which routes are advertised from the routing table to neighbors.

Figure 1: Importing and Exporting RoutesImporting and Exporting Routes

In general, the routing protocols place all their routes in the routing table and advertise a limited set of routes from the routing table. The general rules for handling the routing information between the routing protocols and the routing table are known as the routing policy framework.

The routing policy framework is composed of default rules for each routing protocol that determine which routes the protocol places in the routing table and advertises from the routing table. The default rules for each routing protocol are known as default routing policies.

You can create routing policies to preempt the default policies, which are always present. A routing policy allows you to modify the routing policy framework to suit your needs. You can create and implement your own routing policies to do the following:

  • Control which routes a routing protocol places in the routing table.

  • Control which active routes a routing protocol advertises from the routing table. An active route is a route that is chosen from all routes in the routing table to reach a destination.

  • Manipulate the route characteristics as a routing protocol places the route in the routing table or advertises the route from the routing table.

You can manipulate the route characteristics to control which route is selected as the active route to reach a destination. The active route is placed in the forwarding table and is used to forward traffic toward the route’s destination. In general, the active route is also advertised to a router’s neighbors.

Active and Inactive Routes

When multiple routes for a destination exist in the routing table, the protocol selects an active route and that route is placed in the appropriate routing table. For equal-cost routes, the Junos OS places multiple next hops in the appropriate routing table.

When a protocol is exporting routes from the routing table, it exports active routes only. This applies to actions specified by both default and user-defined export policies.

When evaluating routes for export, the Routing Engine uses only active routes from the routing table. For example, if a routing table contains multiple routes to the same destination and one route has a preferable metric, only that route is evaluated. In other words, an export policy does not evaluate all routes; it evaluates only those routes that a routing protocol is allowed to advertise to a neighbor.

Note:

By default, BGP advertises active routes. However, you can configure BGP to advertise inactive routes, which go to the same destination as other routes but have less preferable metrics.

Explicitly Configured Routes

An explicitly configured route is a route that you have configured. Direct routes are not explicitly configured. They are created as a result of IP addresses being configured on an interface. Explicitly configured routes include aggregate, generated, local, and static routes. (An aggregate route is a route that distills groups of routes with common addresses into one route. A generated route is a route used when the routing table has no information about how to reach a particular destination. A local route is an IP address assigned to a router interface. A static route is an unchanging route to a destination.)

The policy framework software treats direct and explicitly configured routes as if they are learned through routing protocols; therefore, they can be imported into the routing table. Routes cannot be exported from the routing table to the pseudoprotocol, because this protocol is not a real routing protocol. However, aggregate, direct, generated, and static routes can be exported from the routing table to routing protocols, whereas local routes cannot.

Dynamic Database

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 by the standard configuration database. As a result, you can quickly commit these routing policies and policy objects, which can be referenced and applied in the standard configuration as needed. BGP is the only protocol to which you can apply routing policies that reference policies configured in the dynamic database. After a routing policy based on the dynamic database is configured and committed in the standard configuration, you can quickly make changes to existing routing policies by modifying policy objects in the dynamic database. 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.

Understanding OSPF Routing Policy

Each routing policy is identified by a policy name. The name can contain letters, numbers, and hyphens (-) and can be up to 255 characters long. To include spaces in the name, enclose the entire name in double quotation marks. Each routing policy name must be unique within a configuration. Once a policy is created and named, it must be applied before it is active.

In the import statement, you list the name of the routing policy used to filter OSPF external routes from being installed into the routing tables of OSPF neighbors. You can filter the routes, but not link-state address (LSA) flooding. An external route is a route that is outside the OSPF Autonomous System (AS). The import policy does not impact the OSPF database. This means that the import policy has no impact on the link-state advertisements.

In the export statement, you list the name of the routing policy to be evaluated when routes are being exported from the routing table into OSPF.

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 specify more than one policy and create a policy chain, you list the policies using a space as a separator. If multiple policies are specified, the policies are evaluated in the order in which they are specified. As soon as an accept or reject action is executed, the policy chain evaluation ends.

This topic describes the following information:

Routing Policy Terms

Routing policies are made up of one or more terms. A term is a named structure in which match conditions and actions are defined. You can define one or more terms. The name can contain letters, numbers, and hyphens ( - ) and can be up to 255 characters long. To include spaces in the name, enclose the entire name in double quotation marks.

Each term contains a set of match conditions and a set of actions:

  • Match conditions are criteria that a route must match before the actions can be applied. If a route matches all criteria, one or more actions are applied to the route.

  • Actions specify whether to accept or reject the route, control how a series of policies are evaluated, and manipulate the characteristics associated with a route.

Routing Policy Match Conditions

A match condition defines the criteria that a route must match for an action to take place. You can define one or more match conditions for each term. If a route matches all of the match conditions for a particular term, the actions defined for that term are processed.

Each term can include two statements, from and to, that define the match conditions:

  • In the from statement, you define the criteria that an incoming route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur.

    The from statement is optional. If you omit the from and the to statements, all routes are considered to match.

    Note:

    In export policies, omitting the from statement from a routing policy term might lead to unexpected results.

  • In the to statement, you define the criteria that an outgoing route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur.

The order of the match conditions in a term is not important because a route must match all match conditions in a term for an action to be taken.

For a complete list of match conditions, see Configuring Match Conditions in Routing Policy Terms.

Routing Policy Actions

An action defines what the routing device does with the route when the route matches all the match conditions in the from and to statements for a particular term. If a term does not have from and to statements, all routes are considered to match and the actions apply to all routes.

Each term can have one or more of the following types of actions. The actions are configured under the then statement.

  • Flow control actions, which affect whether to accept or reject the route and whether to evaluate the next term or routing policy.

  • Actions that manipulate route characteristics.

  • Trace action, which logs route matches.

The then statement is optional. If you omit it, one of the following occurs:

  • The next term in the routing policy, if one exists, is evaluated.

  • If the routing policy has no more terms, the next routing policy, if one exists, is evaluated.

  • If there are no more terms or routing policies, the accept or reject action specified by the default policy is executed.

For a complete list of routing policy actions, see Configuring Actions in Routing Policy Terms.

Understanding Backup Selection Policy for OSPF Protocol

Support for OSPF loop-free alternate (LFA) routes essentially adds IP fast-reroute capability for OSPF. Junos OS precomputes multiple loop-free backup routes for all OSPF routes. These backup routes are pre-installed in the Packet Forwarding Engine, which performs a local repair and implements the backup path when the link for a primary next hop for a particular route is no longer available. The selection of LFA is done randomly by selecting any matching LFA to progress to the given destination. This does not ensure best backup coverage available for the network. In order to choose the best LFA, Junos OS allows you to configure network-wide backup selection policies for each destination (IPv4 and IPv6) and a primary next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth, protection-type, metric, and node information.

During backup shortest-path-first (SPF) computation, each node and link attribute of the backup path is accumulated by IGP and is associated with every node (router) in the topology. The next hop in the best backup path is selected as the backup next hop in the routing table. In general, backup evaluation policy rules are categorized into the following types:

  • Pruning — Rules configured to select the eligible backup path.

  • Ordering — Rules configured to select the best among the eligible backup paths.

The backup selection policies can be configured with both pruning and ordering rules. While evaluating the backup policies, each backup path is assigned a score, an integer value that signifies the total weight of the evaluated criteria. The backup path with the highest score is selected.

To enforce LFA selection, configure various rules for the following attributes:

  • admin-group– Administrative groups, also known as link coloring or resource class, are manually assigned attributes that describe the “color” of links, such that links with the same color conceptually belong to the same class. These configured administrative groups are defined under protocol MPLS. You can use administrative groups to implement a variety of backup selection policies using exclude, include-all, include-any, or preference.

  • srlg— A shared risk link group (SRLG) is a set of links sharing a common resource, which affects all links in the set if the common resource fails. These links share the same risk of failure and are therefore considered to belong to the same SRLG. For example, links sharing a common fiber are said to be in the same SRLG because a fault with the fiber might cause all links in the group to fail. An SRLG is represented by a 32-bit number unique within an IGP (OSPF) domain. A link might belong to multiple SRLGs. You can define the backup selection to either allow or reject the common SRLGs between the primary and the backup path. This rejection of common SRLGs are based on the non-existence of link having common SRLGs in the primary next-hop and the backup SPF.

    Note:

    Administrative groups and SRLGs can be created only for default topologies.

  • bandwidth—The bandwidth specifies the bandwidth constraints between the primary and the backup path. The backup next-hop link can be used only if the bandwidth of the backup next-hop interface is greater than or equal to the bandwidth of the primary next hop.

  • protection-type— The protection-type protects the destination from node failure of the primary node or link failure of the primary link. You can configure node, link, or node-link to protect the destination. If link-node is configured , then the node-protecting LFA is preferred over link-protection LFA.

  • node- The node is per-node policy information. Here, node can be a directly connected router, remote router like RSVP backup LSP tail-end, or any other router in the backup SPF path. The nodes are identified through the route-id advertised by a node in the LSP. You can list the nodes to either prefer or exclude them in the backup path.

  • metric— Metric decides how the LFAs should be preferred. In backup selection path, root metric and dest-metric are the two types of metrics. root-metric indicates the metric to the one-hop neighbor or a remote router such as an RSVP backup LSP tail-end router. The dest-metric indicates the metric from a one-hop neighbor or remote router such as an RSVP backup LSP tail-end router to the final destination. The metric evaluation is done either in ascending or descending order. By default, the first preference is given to backup paths with lowest destination evaluation and then to backup paths with lowest root metrics.

The evaluation-order allows you to control the order and criteria of evaluating these attributes in the backup path. You can explicitly configure the evaluation order. Only the configured attributes influence the backup path selection. The default order of evaluation of these attributes for the LFA is [ admin-group srlg bandwidth protection-type node metric ] .

Note:

TE attributes are not supported in OSPFv3 and cannot be used for backup selection policy evaluation for IPv6 prefixes.

Configuring Backup Selection Policy for the OSPF Protocol

Support for OSPF loop-free alternate (LFA) routes essentially adds IP fast-reroute capability for OSPF. Junos OS precomputes multiple loop-free backup routes for all OSPF routes. These backup routes are pre-installed in the Packet Forwarding Engine, which performs a local repair and implements the backup path when the link for a primary next hop for a particular route is no longer available. The selection of LFA is done randomly by selecting any matching LFA to progress to the given destination. This does not ensure best backup coverage available for the network. In order to choose the best LFA, Junos OS allows you to configure network-wide backup selection policies for each destination (IPv4 and IPv6) and a primary next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth, protection-type, metric, and node information.

Before you begin to configure the backup selection policy for the OSPF protocol:

  • Configure the router interfaces. See the Junos OS Network Management Administration Guide for Routing Devices.

  • Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library for Routing Devices.

To configure the backup selection policy for the OSPF protocol:

  1. Configure per-packet load balancing.
  2. Enable RSVP on all the interfaces.
  3. Configure administrative groups.
  4. Configure srlg values.
  5. Enable MPLS on all the interfaces.
  6. Apply MPLS to an interface configured with an administrative group.
  7. Configure the ID of the router.
  8. Apply the routing policy to all equal cost multipaths exported from the routing table to the forwarding table.
  9. Enable link protection and configure metric values on all the interfaces for an area.
  10. Configure the administrative group of the backup selection policy for an IP address.

    You can choose to exclude, include all, include any, or prefer the administrative groups from the backup path.

    • Specify the administrative group to be excluded.

      The backup path is not selected as the loop-free alternate (LFA) or backup nexthop if any of the links in the path have any one of the listed administrative groups.

      For example, to exclude the group c1 from the administrative group:

    • Configure all the administrative groups if each link in the backup path requires all the listed administrative groups in order to accept the path.

      For example, to set all the administrative groups if each link requires all the listed administrative groups in order to accept the path:

    • Configure any administrative group if each link in the backup path requires at least one of the listed administrative groups in order to select the path.

      For example, to set any administrative group if each link in the backup path requires at least one of the listed administrative groups in order to select the path:

    • Define an ordered set of an administrative group that specifies the preference of the backup path.

      The leftmost element in the set is given the highest preference.

      For example, to set an ordered set of an administrative group that specifies the preference of the backup path:

  11. Configure the backup path to allow the selection of the backup next hop only if the bandwidth is greater than or equal to the bandwidth of the primary next hop.
  12. Configure the backup path to specify the metric from the one-hop neighbor or from the remote router such as an RSVP backup label-switched-path (LSP) tail-end router to the final destination.

    The destination metric can be either highest or lowest.

    • Configure the backup path that has the highest destination metric.

    • Configure the backup path that has the lowest destination metric.

  13. Configure the backup path that is a downstream path to the destination.
  14. Set the order of preference of the root and the destination metric during backup path selection.

    The preference order can be :

    • [root dest] — Backup path selection or preference is first based on the root-metric criteria. If the criteria of all the root-metric is the same, then the selection or preference is based on the dest-metric.

    • [dest root] — Backup path selection or preference is first based on the dest-metric criteria. If the criteria of all the dest-metric is the same, then the selection is based on the root-metric.

  15. Configure the backup path to define a list of loop-back IP addresses of the adjacent neighbors to either exclude or prefer in the backup path selection.

    The neighbor can be a local (adjacent router) neighbor, remote neighbor, or any other router in the backup path.

    • Configure the list of neighbors to be excluded.

      The backup path that has a router from the list is not selected as the loop-free alternative or backup next hop.

    • Configure an ordered set of neighbors to be preferred.

      The backup path having the leftmost neighbor is selected.

  16. Configure the backup path to specify the required protection type of the backup path to be link, node, or node-link.
    • Select the backup path that provides link protection.

    • Select the backup path that provides node protection.

    • Select the backup path that allows either node or link protection LFA where node-protection LFA is preferred over link-protection LFA.

  17. Specify the metric to the one-hop neighbor or to the remote router such as an RSVP backup label-switched-path (LSP) tail-end router.
    • Select the path with highest root metric.

    • Select the path with lowest root metric.

  18. Configure the backup selection path to either allow or reject the common shared risk link groups (SRLGs) between the primary link and each link in the backup path.
    • Configure the backup path to allow common srlgs between the primary link and each link in the backup path.

      A backup path with a fewer number of srlg collisions is preferred.

    • Configure the backup path to reject the backup path that has common srlgs between the primary next-hop link and each link in the backup path.

  19. Configure the backup path to control the order and the criteria of evaluating the backup path based on the administrative group, srlg, bandwidth, protection type, node, and metric.

    The default order of evaluation is admin-group, srlg, bandwidth, protection-type, node, and metric.

Topology-Independent Loop-Free Alternate with Segment Routing for OSPF

Understanding Topology-Independent Loop-Free Alternate with Segment Routing for OSPF

Segment routing enables a router to send a packet along a specific path in the network by imposing a label stack that describes the path. The forwarding actions described by a segment routing label stack do not need to be established on a per-path basis. Therefore, an ingress router can instantiate an arbitrary path using a segment routing label stack and use it immediately without any signaling.

In segment routing, each node advertises mappings between incoming labels and forwarding actions. A specific forwarding action is referred to as a segment and the label that identifies that segment is referred to as a segment identifier (SID). The backup paths created by TI-LFA use the following types of segments:

  • Node segment—A node segment forwards packets along the shortest path or paths to a destination node. The label representing the node segment (the node SID) is swapped until the destination node is reached.

  • Adjacency segment—An adjacency segment forwards packets across a specific interface on the node that advertised the adjacency segment. The label representing an adjacency segment (the adjacency SID) is popped by the node that advertised it.

A router can send a packet along a specific path by creating a label stack that uses a combination of node SIDs and adjacency SIDs. Typically, node SIDs are used to represent parts of the path that correspond to the shortest path between two nodes. An adjacency SID is used wherever a node SID cannot be used to accurately represent the desired path.

When used with OSPF, TI-LFA provides protection against link failure, node failure., fate-sharing failures, and shared risk link group failures. In link failure mode, the destination is protected if the link fails. In node protection mode, the destination is protected if the neighbor connected to the primary link fails. To determine the node-protecting post-convergence path, the cost of all the links leaving the neighbor is assumed to increase by a configurable amount.

Starting in Junos OS Release 20.3R1, you can configure fate-sharing protection in TI-LFA networks for segment routing to choose a fast reroute path that does not include fate-sharing groups in the topology-independent loop-free alternate (TI-LFA) backup paths to avoid fate-sharing failures. With fate-sharing protection, a list of fate-sharing groups are configured on each PLR with the links in each fate-sharing group identified by their respective IP addresses. The PLR associates a cost with each fate-sharing group. The fate-sharing-aware post-convergence path is computed by assuming that the cost of each link in the same fate-sharing group as the failed link has increased the cost associated with that group.

Starting in Junos OS Release 20.3R1, you can configure Shared Risk Link Group (SRLG) protection in TI-LFA networks for segment routing to choose a fast reroute path that does not include SRLG links in the topology-independent loop-free alternate (TI-LFA) backup paths. SRLGs share a common fibre and they also share the risks of a broken link. When one link in an SRLG fails, other links in the group might also fail. Therefore, you need to avoid links that share the same risk as the protected link in the backup path. Configuring SRLG protection prevents TI-LFA from selecting backup paths that include a shared risk link. If you have configured SRLG protection then OSPFv2 computes the fast reroute path that is aligned with the post convergence path and excludes the links that belong to the SRLG of the protected link. All local and remote links that are from the same SRLG as the protected link are excluded from the TI-LFA back up path. The point of local repair (PLR) sets up the label stack for the fast reroute path with a different outgoing interface. Currently you cannot enable SRLG protection in IPv6 networks and in networks with multitopology.

In order to construct a backup path that follows the post-convergence path, TI-LFA can use several labels in the label stack that define the backup path. If the number of labels required to construct a particular post-convergence backup path exceeds a certain amount, it is useful in some circumstances to not install that backup path. You can configure the maximum number of labels that a backup path can have in order to be installed. The default value is 3, with a range of 2 through 5.

It is often the case that the post-convergence path for a given failure is actually a set of equal-cost paths. TI-LFA attempts to construct the backup paths to a given destination using multiple equal-cost paths in the post-failure topology. Depending on the topology, TI-LFA might need to use different label stacks to accurately construct those equal-cost backup paths. By default, TI-LFA only installs one backup path for a given destination. However, you can configure the value in the range from 1 through 8.

Benefits of Using Topology-Independent Loop-Free Alternate with Segment Routing

  • Loop-free alternate (LFA) and remote LFA (RLFA) have been used to provide fast-reroute protection for several years. With LFA, a point of local repair (PLR) determines whether or not a packet sent to one of its direct neighbors reaches its destination without looping back through the PLR. In a typical network topology, approximately 40 to 60 percent of the destinations can be protected by LFA. Remote LFA expands on the concept of LFA by allowing the PLR to impose a single label to tunnel the packet to a repair tunnel endpoint from which the packet can reach its destination without looping back through the PLR. Using remote LFA, more destinations can be protected by the PLR compared to LFA. However, depending on the network topology, the percentage of destinations protected by remote LFA is usually less than 100 percent.

  • Topology-independent LFA (TI-LFA) extends the concept of LFA and remote LFA by allowing the PLR to use deeper label stacks to construct backup paths. In addition, TI-LFA imposes the constraint that the backup path used by the PLR be the same path that a packet takes once the interior gateway protocol (IGP) has converged for a given failure scenario. This path is referred to as the post-convergence path.

  • Using the post-convergence path as the backup path has some desirable characteristics. For some topologies, a network operator only needs to make sure that the network has enough capacity to carry the traffic along the post-convergence path after a failure. In these cases, a network operator does not need to allocate additional capacity to deal with the traffic pattern immediately after the failure while the backup path is active, because the backup path follows the post-convergence path.

  • When used with OSPF, TI-LFA provides protection against link failure and node failure.

Configuring Topology-Independent Loop-Free Alternate with Segment Routing for OSPF

Before you configure TI-LFA for OSPF, be sure you configure SPRING or segment routing.

Starting in Junos OS Release 19.3R1, Junos supports creation of OSPF topology-independent TI-LFA backup paths where the prefix SID is learned from a segment routing mapping server advertisement when the PLR and mapping server are both in the same OSPF area.

To configure TI-LFA using SPRING for OSPF, you must do the following:

  1. Enable TI-LFA for OSPF protocol.
  2. (Optional) Configure backup shortest path first (SPF) attributes such as maximum equal-cost multipath (ECMP) backup paths and maximum labels for TI-LFA for the OSPF protocol.
  3. Configure the computation and installation of a backup path that follows the post-convergence path on the given area and interfacefor the OSPF protocol.
  4. (Optional) Enable node protection for a given area and interface.
  5. (Optional) Enable fate-sharing protection for a given area and interface.
  6. (Optional) Enable SRLG protection for a given area and interface.

Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol

This example shows how to configure the backup selection policy for the OSPF or OSPF3 protocol, which enables you to select a loop-free alternate (LFA) in the network.

When you enable backup selection policies, Junos OS allows selection of LFA based on the policy rules and attributes of the links and nodes in the network. These attributes are admin-group, srlg, bandwidth, protection-type, metric, and node.

Requirements

This example uses the following hardware and software components:

  • Eight routers that can be a combination of M Series Multiservice Edge Routers, MX Series 5G Universal Routing Platforms, PTX Series Packet Transport Routers, and T Series Core Routers

  • Junos OS Release 15.1 or later running on all devices

Before you begin:

  1. Configure the device interfaces.

  2. Configure OSPF.

Overview

In Junos OS, the default loop-free alternative (LFA) selection algorithm or criteria can be overridden with an LFA policy. These policies are configured for each destination (IPv4 and IPv6) and a primary next-hop interface . These backup policies enforce LFA selection based on admin-group, srlg, bandwidth, protection-type, metric, and node attributes of the backup path. During backup shortest-path-first (SPF) computation, each attribute (both node and link) of the backup path, stored per backup next-hop, is accumulated by IGP. For the routes created internally by IGP, the attribute set of every backup path is evaluated against the policy configured for each destination (IPv4 and IPv6) and a primary next-hop interface. The first or the best backup path is selected and installed as the backup next hop in the routing table. To configure the backup selection policy, include the backup-selection configuration statement at the [edit routing-options] hierarchy level. The show backup-selection command displays the configured policies for a given interface and destination. The display can be filtered against a particular destination, prefix, interface, or logical systems.

Topology

In this topology shown in Figure 2, the backup selection policy is configured on Device R3.

Figure 2: Example Backup Selection Policy for OSPF or OPSF3Example Backup Selection Policy for OSPF or OPSF3

Configuration

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

R0

R1

R2

R3

R4

R5

R6

R7

Configuring Device R3

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device R3:

  1. Configure the interfaces.

  2. Configure srlg values.

  3. Configure the ID of the router.

  4. Apply the routing policy to all equal-cost multipaths exported from the routing table to the forwarding table.

  5. Configure attributes of the backup selection policy.

  6. Enable RSVP on all the interfaces.

  7. Configure administrative groups.

  8. Enable MPLS on all the interfaces and configure administrative group for an interface.

  9. Enable link protection and configure metric values on all the interfaces for an OSPF area.

  10. Enable link protection and configure metric values on all the interfaces for an OSPF3 area.

  11. Configure the routing policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

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

Verification

Confirm that the configuration is working properly.

Verifying the Routes

Purpose

Verify that the expected routes are learned.

Action

From operational mode, run the show route command for the routing table.

Meaning

The output shows all Device R3 routes.

Verifying the OSPF Route

Purpose

Verify the routing table of OSPF.

Action

From operational mode, run the show ospf route detail command for Device R3.

Meaning

The output displays the routing table of OSPF routers.

Verifying the OSPF3 Route

Purpose

Verify the routing table of OSPF3.

Action

From operational mode, run the show ospf3 route detail command for Device R3.

Meaning

The output displays the routing table of OSPF3 routers.

Verifying the Backup Selection Policy for Device R3

Purpose

Verify the backup selection policy for Device R3.

Action

From operational mode, run the show backup-selection command for Device R3.

Meaning

The output displays the configured policies per prefix per primary next-hop interface.

Example: Injecting OSPF Routes into the BGP Routing Table

This example shows how to create a policy that injects OSPF routes into the BGP routing table.

Requirements

Before you begin:

Overview

In this example, you create a routing policy called injectpolicy1 and a routing term called injectterm1. The policy injects OSPF routes into the BGP routing table.

Topology

Configuration

Configuring the Routing Policy

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To inject OSPF routes into a BGP routing table:

  1. Create the policy term.

  2. Specify OSPF as a match condition.

  3. Specify the routes from an OSPF area as a match condition.

  4. Specify that the route is to be accepted if the previous conditions are matched.

  5. Apply the routing policy to BGP.

Results

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

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

Configuring Tracing for the Routing Policy

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Include a trace action in the policy.

  2. Configure the tracing file for the output.

Results

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

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

Verification

Confirm that the configuration is working properly.

Verifying That the Expected BGP Routes Are Present

Purpose

Verify the effect of the export policy.

Action

From operational mode, enter the show route command.

Troubleshooting

Using the show log Command to Examine the Actions of the Routing Policy

Problem

The routing table contains unexpected routes, or routes are missing from the routing table.

Solution

If you configure policy tracing as shown in this example, you can run the show log ospf-bgp-policy-log command to diagnose problems with the routing policy. The show log ospf-bgp-policy-log command displays information about the routes that the injectpolicy1 policy term analyzes and acts upon.

Example: Redistributing Static Routes into OSPF

This example shows how to create a policy that redistributes static routes into OSPF.

Requirements

Before you begin:

Overview

In this example, you create a routing policy called exportstatic1 and a routing term called exportstatic1. The policy injects static routes into OSPF. This example includes the following settings:

  • policy-statement—Defines the routing policy. You specify the name of the policy and further define the elements of the policy. The policy name must be unique and can contain letters, numbers, and hyphens ( - ) and be up to 255 characters long.

  • term—Defines the match condition and applicable actions for the routing policy. The term name can contain letters, numbers, and hyphens ( - ) and be up to 255 characters long. You specify the name of the term and define the criteria that an incoming route must match by including the from statement and the action to take if the route matches the conditions by including the then statement. In this example you specify the static protocol match condition and the accept action.

  • export—Applies the export policy you created to be evaluated when routes are being exported from the routing table into OSPF.

Topology

Configuration

CLI Quick Configuration

To quickly create a policy that injects static routes into OSPF, copy the following commands and paste them into the CLI.

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide.

To inject static routes into OSPF:

  1. Create the routing policy.

  2. Create the policy term.

  3. Specify static as a match condition.

  4. Specify that the route is to be accepted if the previous condition is matched.

  5. Apply the routing policy to OSPF.

    Note:

    For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  6. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by entering the show policy-options and show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

To confirm your OSPFv3 configuration, enter the show policy-options and the show protocols ospf3 commands.

Verification

Confirm that the configuration is working properly.

Verifying That the Expected Static Routes Are Present

Purpose

Verify the effect of the export policy.

Action

From operational mode, enter the show route command.

Verifying That AS External LSAs Are Added to the Routing Table

Purpose

On the routing device where you configured the export policy, verify that the routing device originates an AS external LSA for the static routes that are added to the routing table.

Action

From operational mode, enter the show ospf database command for OSPFv2, and enter the show ospf3 database command for OSPFv3.

Example: Configuring an OSPF Import Policy

This example shows how to create an OSPF import policy. OSPF import policies apply to external routes only. An external route is a route that is outside the OSPF autonomous system (AS).

Requirements

Before you begin:

Overview

External routes are learned by AS boundary routers. External routes can be advertised throughout the OSPF domain if you configure the AS boundary router to redistribute the route into OSPF. An external route might be learned by the AS boundary router from a routing protocol other than OSPF, or the external route might be a static route that you configure on the AS boundary router.

For OSPFv3, the link-state advertisement (LSA) is referred to as the interarea prefix LSA and performs the same function as a network-summary LSA performs for OSPFv2. An area border router (ABR) originates an interarea prefix LSA for each IPv6 prefix that must be advertised into an area.

OSPF import policy allows you to prevent external routes from being added to the routing tables of OSPF neighbors. The import policy does not impact the OSPF database. This means that the import policy has no impact on the link-state advertisements. The filtering is done only on external routes in OSPF. The intra-area and interarea routes are not considered for filtering. The default action is to accept the route when the route does not match the policy.

This example includes the following OSPF policy settings:

  • policy-statement—Defines the routing policy. You specify the name of the policy and further define the elements of the policy. The policy name must be unique and can contain letters, numbers, and hyphens ( - ) and be up to 255 characters long.

  • export—Applies the export policy you created to be evaluated when network summary LSAs are flooded into an area. In this example, the export policy is named export_static.

  • import—Applies the import policy you created to prevent external routes from being added to the routing table. In this example, the import policy is named filter_routes.

The devices you configure in this example represent the following functions:

  • R1—Device R1 is in area 0.0.0.0 and has a direct connection to device R2. R1 has an OSPF export policy configured. The export policy redistributes static routes from R1’s routing table into R1’s OSPF database. Because the static route is in R1’s OSPF database, the route is advertised in an LSA to R1’s OSPF neighbor. R1’s OSPF neighbor is device R2.

  • R2—Device R2 is in area 0.0.0.0 and has a direct connection to device R1. R2 has an OSPF import policy configured that matches the static route to the 10.0.16.0/30 network and prevents the static route from being installed in R2’s routing table. R2’s OSPF neighbor is device R1.

Configuration

CLI Quick Configuration

To quickly configure an OSPF import policy, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Configuration on Device R1:

Configuration on Device R2:

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in theCLI User Guide.

To configure an OSPF import policy:

  1. Configure the interfaces.

  2. Enable OSPF on the interfaces.

    Note:

    For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  3. On R1, redistribute the static route into OSPF.

  4. On R2, configure the OSPF import policy.

  5. If you are done configuring the devices, commit the configuration.

Results

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols ospf commands on the appropriate device. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Output for R1:

Output for R2:

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, show routing-options, and show protocols ospf3 commands on the appropriate device.

Verification

Confirm that the configuration is working properly.

Verifying the OSPF Database

Purpose

Verify that OSPF is advertising the static route in the OSPF database.

Action

From operational mode, enter the show ospf database for OSPFv2, and enter the show ospf3 database command for OSPFv3.

Verifying the Routing Table

Purpose

Verify the entries in the routing table.

Action

From operational mode, enter the show route command.

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

This example shows how to create an OSPF import policy that prioritizes specific prefixes learned through OSPF.

Requirements

Before you begin:

Overview

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:

  • Summary discard routes have a default priority of low.

  • Local routes that are not added to the routing table are assigned a priority of low.

  • External routes that are rejected by import policy and thus not added to the routing table are assigned a priority of low.

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.

In this example, the routing device is in area 0.0.0.0, with interfaces fe-0/1/0 and fe-1/1/0 connecting to neighboring devices. You configure an import routing policy named ospf-import to specify a priority for 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 192.0.2.0/24 orlonger are installed first because they have a priority of high. Routes matching 198.51.100.0/24 orlonger are installed next because they have a priority of medium. Routes matching 203.0.113.0/24 orlonger are installed last because they have a priority of low. You then apply the import policy to OSPF.

Note:

The priority value takes effect when a new route is installed, or when there is a change to an existing route.

Topology

Configuration

CLI Quick Configuration

To quickly configure an OSPF import policy that prioritizes specific prefixes learned through OSPF, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in theCLI User Guide.

To configure an OSPF import policy that prioritizes specific prefixes:

  1. Configure the interfaces.

  2. Enable OSPF on the interfaces.

    Note:

    For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  3. Configure the policy to specify the priority for prefixes learned through OSPF.

  4. Apply the policy to OSPF.

  5. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by entering the show interfaces, show policy-options, and the show protocols ospf commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols ospf3 commands.

Verification

Confirm that the configuration is working properly.

Verifying the Prefix Priority in the OSPF Routing Table

Purpose

Verify the priority assigned to the prefix in the OSPF routing table.

Action

From operational mode, enter the show ospf route detail for OSPFv2, and enter the show ospf3 route detail command for OSPFv3.

Import and Export Policies for Network Summaries Overview

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. The ABR also controls which routes from the area are used to generate network-summary LSAs into other areas. Each ABR maintains a separate topological database for each area to which they are connected. 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.

Example: Configuring an OSPF Export Policy for Network Summaries

This example shows how to create an OSPF export policy to control the network-summary (Type 3) LSAs that the ABR floods into an OSPF area.

Requirements

Before you begin:

Overview

OSPF uses network-summary LSAs to transmit route information across area boundaries. Depending on your network environment, you might want to further filter the network-summary LSAs between OSPF areas. For example, if you create OSPF areas to define administrative boundaries, you might not want to advertise internal route information between those areas. To further improve the control of route distribution between multiple OSPF areas, you can configure network summary policies on the ABR for the area that you want to filter the advertisement of network-summary LSAs.

Note:

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. In this topic, the terms network summary policy and network-summary policy are used to describe both OSPFv2 and OSPFv3 functionality.

The following guidelines apply to export network summary policies:

  • You should have a thorough understanding of your network before configuring these policies. Incorrect network summary policy configuration might result in an unintended result such as suboptimal routing or dropped traffic.

  • We recommend that you use the route-filter policy match condition for these types of policies.

  • We recommend that you use the accept and reject routing policy terms for these types of policies.

Figure 3 shows a sample topology with three OSPF areas. R4 generates network summaries for the routes in area 4 and sends them out of area 4 to area 0. R3 generates network summaries for the routes in area 3 and sends them out of area 3 to area 0.

Figure 3: Sample Topology Used for an OSPF Export Network Summary PolicySample Topology Used for an OSPF Export Network Summary Policy

In this example, you configure R4 with an export network summary policy named export-policy that only allows routes that match the 10.0.4.4 prefix from area 3 into area 4. The export policy controls the network-summary LSAs that R4 floods into area 4. This results in only the allowed interarea route to enter area 4, and all other interarea routes to be purged from the OSPF database and the routing table of the devices in area 4. You first define the policy and then apply it to the ABR by including the network-summary-export statement for OSPFv2 or the inter-area-prefix-export statement for OSPFv3.

The devices operate as follows:

  • R1—Device R1 is an internal router in area 3. Interface fe-0/1/0 has an IP address of 10.0.4.13/30 and connects to R3. Interface fe-0/0/1 has an IP address of 10.0.4.5/30 and connects to R2.

  • R2—Device R2 is an internal router in area 3. Interface fe-0/0/1 has an IP address of 10.0.4.6/30 and connects to R1. Interface fe-1/0/0 has an IP address of 10.0.4.1 and connects to R3.

  • R3—Device R3 participates in area 3 and area 0. R3 is the ABR between area 3 and area 0, and passes network-summary LSAs between the areas. Interface fe-1/0/0 has an IP address of 10.0.4.2/30 and connects to R2. Interface fe-1/1/0 has an IP address of 10.0.4.14/30 and connects to R1. Interface fe-0/0/1 has an IP address of 10.0.2.1/30 and connects to R4.

  • R4—Device R4 participates in area 0 and area 4. R4 is the ABR between area 0 and area 4, and passes network-summary LSAs between the areas. Interface fe-0/0/1 has an IP address of 10.0.2.4/30 and connects to R3. Interface fe-1/1/0 has an IP address of 10.0.8.6/30 and connects to R5. Interface fe-1/0/0 has an IP address of 10.0.8.9/30 and connects to R6.

  • R5—Device R5 is an internal router in area 4. Interface fe-1/1/0 has an IP address of 10.0.8.5/30 and connects to R4.

  • R6—Device R6 is an internal router in area 4. Interface fe-1/0/0 has an IP address of 10.0.8.10/30 and connects to R4.

Configuration

CLI Quick Configuration

To quickly configure an OSPF export policy for network summaries, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Configuration on Device R1:

Configuration on Device R2:

Configuration on Device R3:

Configuration on Device R4:

Configuration on Device R5:

Configuration on Device R6:

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide.

To configure an configure an OSPF export policy for network summaries:

  1. Configure the interfaces.

    Note:

    For OSPFv3, use IPv6 addresses.

  2. Enable OSPF on the interfaces.

    Note:

    For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  3. On R4, configure the export network summary policy.

  4. On R4, apply the export network summary policy to OSPF.

    Note:

    For OSPFv3, include the inter-area-prefix-export statement at the [edit protocols ospf3 area area-id] hierarchy level.

  5. If you are done configuring the devices, commit the configuration.

Results

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols ospf commands on the appropriate device. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Output for R1:

Output for R2:

Output for R3:

Output for R4:

Output for R5:

Output for R6:

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols ospf3 commands on the appropriate device.

Verification

Confirm that the configuration is working properly.

Verifying the OSPF Database

Purpose

Verify that the OSPF database for the devices in area 4 includes the interarea route that we permitted on the ABR R4. The other interarea routes that are not specified should age out or no longer be present in the OSPF database.

Action

From operational mode, enter the show ospf database netsummary area 0.0.0.4 command for OSPFv2, and enter the show ospf3 database inter-area-prefix area 0.0.0.4 command for OSPFv3.

Verifying the Routing Table

Purpose

Verify that the routes corresponding to the rejected network summaries are no longer present in R4’s, R5’s, or R6’s routing table.

Action

From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3.

Example: Configuring an OSPF Import Policy for Network Summaries

This example shows how to create an OSPF import policy to control the network-summary (Type 3) LSAs that the ABR advertises out of an OSPF area.

Requirements

Before you begin:

Overview

OSPF uses network-summary LSAs to transmit route information across area boundaries. Depending on your network environment, you might want to further filter the network-summary LSAs between OSPF areas. For example, if you create OSPF areas to define administrative boundaries, you might not want to advertise internal route information between those areas. To further improve the control of route distribution between multiple OSPF areas, you can configure network summary policies on the ABR for the area that you want to filter the advertisement of network-summary LSAs.

Note:

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. In this topic, the terms network summary policy and network-summary policy are used to describe both OSPFv2 and OSPFv3 functionality.

The following guidelines apply to import network summary policies:

  • You should have a thorough understanding of your network before configuring these policies. Incorrect network summary policy configuration might result in an unintended result such as suboptimal routing or dropped traffic.

  • We recommend that you use the route-filter policy match condition for these types of policies.

  • We recommend that you use the accept and reject routing policy terms for these types of policies.

Figure 4 shows a sample topology with three OSPF areas. R4 generates network summaries for the routes in area 4 and sends them out of area 4 to area 0. R3 generates network summaries for the routes in area 3 and sends them out of area 3 to area 0.

Figure 4: Sample Topology Used for an OSPF Import Network Summary PolicySample Topology Used for an OSPF Import Network Summary Policy

In this example, you configure R3 with an import network summary policy named import-policy so R3 only generates network summaries for the route 10.0.4.12/30. The import policy controls the routes and therefore the network summaries that R3 advertises out of area 3, so applying this policy means that R3 only advertises route 10.0.4.12/30 out of area 3. This results in existing network summaries from other interarea routes getting purged from the OSPF database in area 0 and area 4, as well as the routing tables of the devices in areas 0 and area 4. You first define the policy and then apply it to the ABR by including the network-summary-import statement for OSPFv2 or the inter-area-prefix-import statement for OSPFv3.

The devices operate as follows:

  • R1—Device R1 is an internal router in area 3. Interface fe-0/1/0 has an IP address of 10.0.4.13/30 and connects to R3. Interface fe-0/0/1 has an IP address of 10.0.4.5/30 and connects to R2.

  • R2—Device R2 is an internal router in area 3. Interface fe-0/0/1 has an IP address of 10.0.4.6/30 and connects to R1. Interface fe-1/0/0 has an IP address of 10.0.4.1/30 and connects to R3.

  • R3—Device R3 participates in area 3 and area 0. R3 is the ABR between area 3 and area 0, and passes network-summary LSAs between the areas. Interface fe-1/0/0 has an IP address of 10.0.4.2/30 and connects to R2. Interface fe-1/1/0 has an IP address of 10.0.4.14/30 and connects to R1. Interface fe-0/0/1 has an IP address of 10.0.2.1/30 and connects to R4.

  • R4—Device R4 participates in area 0 and area 4. R4 is the ABR between area 0 and area 4, and passes network-summary LSAs between the areas. Interface fe-0/0/1 has an IP address of 10.0.2.1/30 and connects to R3. Interface fe-1/1/0 has an IP address of 10.0.8.6/30 and connects to R5. Interface fe-1/0/0 has an IP address of 10.0.8.9/30 and connects to R6.

  • R5—Device R5 is an internal router in area 4. Interface fe-1/1/0 has an IP address of 10.0.8.5/30 and connects to R4.

  • R6—Device R6 is an internal router in area 4. Interface fe-1/0/0 has an IP address of 10.0.8.10/30 and connects to R4.

Configuration

Procedure

CLI Quick Configuration

To quickly configure an OSPF import policy for network summaries, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Configuration on Device R1:

Configuration on Device R2:

Configuration on Device R3:

Configuration on Device R4:

Configuration on Device R5:

Configuration on Device R6:

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in the CLI User Guide.

To configure an configure an OSPF import policy for network summaries:

  1. Configure the interfaces.

    Note:

    For OSPFv3, use IPv6 addresses.

  2. Enable OSPF on the interfaces.

    Note:

    For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  3. On R3, configure the import network summary policy.

  4. On R3, apply the import network summary policy to OSPF.

    Note:

    For OSPFv3, include the inter-area-prefix-export statement at the [edit protocols ospf3 area area-id] hierarchy level.

  5. If you are done configuring the devices, commit the configuration.

Results

Confirm your configuration by entering the show interfaces, show policy-options, and show protocols ospf commands on the appropriate device. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Output for R1:

Output for R2:

Output for R3:

Output for R4:

Output for R5:

Output for R6:

To confirm your OSPFv3 configuration, enter the show interfaces, show policy-options, and show protocols ospf3 commands on the appropriate device.

Verification

Confirm that the configuration is working properly.

Verifying the OSPF Database

Purpose

Verify that the OSPF database for the devices in area 4 includes the interarea route that we are advertising from R3. Any other routes from area 3 should not be advertised into area 4, so those entries should age out or no longer be present in the OSPF database.

Action

From operational mode, enter the show ospf database netsummary area 0.0.0.4 command for OSPFv2, and enter the show ospf3 database inter-area-prefix area 0.0.0.4 command for OSPFv3.

Verifying the Routing Table

Purpose

Verify that the specified route is included in R4’s, R5’s, or R6’s routing table. Any other routes from area 3 should not be advertised into area 4.

Action

From operational mode, enter the show route protocol ospf command for both OSPFv2 and OSPFv3.

Example: Redistributing OSPF Routes into IS-IS

This example shows how to redistribute OSPF routes into an IS-IS network.

Requirements

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

Overview

Export policy can be applied to IS-IS to facilitate route redistribution.

Junos OS does not support the application of import policy for link-state routing protocols like IS-IS because such policies can lead to inconsistent link-state database (LSDB) entries, which in turn can result in routing inconstancies.

In this example, OSPF routes 192.168.0/24 through 192.168.3/24 are redistributed into IS-IS area 49.0002 from Device R2.

In addition, policies are configured to ensure that Device R1 can reach destinations on the 10.0.0.44/30 network, and that Device R3 can reach destinations on the 10.0.0.36/30 network. This enables end-to-end reachability.

Figure 5 shows the topology used in this example.

Figure 5: IS-IS Route Redistribution TopologyIS-IS Route Redistribution Topology

CLI Quick Configuration shows the configuration for all of the devices in Figure 5. The section #d175e62__d175e232 describes the steps on Device R2. #d175e62__d175e361 describes the steps on Device R3.

Topology

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 R1

Device R2

Device R3

Step-by-Step Procedure

To configure Device R2:

  1. Configure the network interfaces.

  2. Configure IS-IS on the interface facing Device R1 and the loopback interface.

  3. Configure the policy that enables Device R1 to reach the 10.0.0.44/30 network.

  4. Apply the policy that enables Device R1 to reach the 10.0.0.44/30 network.

  5. Configure OSPF on the interfaces.

  6. Configure the OSPF route redistribution policy.

  7. Apply the OSPF route redistribution policy to the IS-IS instance.

  8. Configure the policy that enables Device R3 to reach the 10.0.0.36/30 network.

  9. Apply the policy that enables Device R3 to reach the 10.0.0.36/30 network.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure multi-level IS-IS:

  1. Configure the network interfaces.

    Multiple addresses are configured on the loopback interface to simulate multiple route destinations.

  2. Configure static routes to the loopback interface addresses.

    These are the routes that are redistributed into IS-IS.

  3. Configure OSPF on the interfaces.

  4. Configure the OSPF policy to export the static routes.

  5. Apply the OSPF export policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device R2

Device R3

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

Verification

Confirm that the configuration is working properly.

Verifying OSPF Route Advertisement

Purpose

Make sure that the expected routes are advertised by OSPF.

Action

From operational mode on Device R2, enter the show route protocol ospf command.

Meaning

The 192.168/16 routes are advertised by OSPF.

Verifying Route Redistribution

Purpose

Make sure that the expected routes are redistributed from OSPF into IS-IS.

Action

From operational mode on Device R1, enter the show route protocol isis command.

Meaning

The 192.168/16 routes are redistributed into IS-IS.

Verifying Connectivity

Purpose

Check that Device R1 can reach the destinations on Device R3.

Action

From operational mode, enter the ping command.

Meaning

These results confirm that Device R1 can reach the destinations in the OSPF network.

Release History Table
Release
Description
20.3R1
Starting in Junos OS Release 20.3R1, you can configure fate-sharing protection in TI-LFA networks for segment routing to choose a fast reroute path that does not include fate-sharing groups in the topology-independent loop-free alternate (TI-LFA) backup paths to avoid fate-sharing failures.
20.3R1
Starting in Junos OS Release 20.3R1, you can configure Shared Risk Link Group (SRLG) protection in TI-LFA networks for segment routing to choose a fast reroute path that does not include SRLG links in the topology-independent loop-free alternate (TI-LFA) backup paths.
19.3R1
Starting in Junos OS Release 19.3R1, Junos supports creation of OSPF topology-independent TI-LFA backup paths where the prefix SID is learned from a segment routing mapping server advertisement when the PLR and mapping server are both in the same OSPF area.