ON THIS PAGE
Topology-Independent Loop-Free Alternate with Segment Routing for OSPF
Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol
Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF
Example: Configuring an OSPF Export Policy for Network Summaries
Example: Configuring an OSPF Import Policy for Network Summaries
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.
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.
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 ] .
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:
- Configure per-packet load balancing.[edit policy-options]user@host# set policy-statement ecmp term 1 then load-balance per-packet
- Enable RSVP on all the interfaces.[edit protocols]user@host# set rsvp interface all
- Configure administrative groups.[edit protocols mpls]user@host# set admin-groups group-name
- Configure srlg values.[edit routing-options]user@host# set srlg srlg-name srlg-value srlg-value
- Enable MPLS on all the interfaces.[edit protocols mpls]user@host# set interface all
- Apply MPLS to an interface configured with an administrative
group.[edit protocols mpls]user@host# set interface interface-name admin-group group-name
- Configure the ID of the router.[edit routing-options]user@host# set router-id router-id
- Apply the routing policy to all equal cost multipaths
exported from the routing table to the forwarding table.[edit routing-options]user@host# set forwarding-table export ecmp
- Enable link protection and configure metric values on
all the interfaces for an area.[edit protocols ospf]user@host# set area area-id interface interface-name link-protectionuser@host# set area area-id interface interface-name metric metric
- 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name admin-groupSpecify the administrative group to be excluded.
[edit routing-options backup-selection destination ip-address interface interface-name admin-group]user@host# set exclude group-nameThe 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:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]user@host# set exclude c1Configure all the administrative groups if each link in the backup path requires all the listed administrative groups in order to accept the path.
[edit routing-options backup-selection destination ip-address interface interface-name admin-group]user@host# set include-all group-nameFor example, to set all the administrative groups if each link requires all the listed administrative groups in order to accept the path:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]user@host# set include-all c2Configure 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.
[edit routing-options backup-selection destination ip-address interface interface-name admin-group]user@host# set include-any group-nameFor 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:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]user@host# set include-any c3Define 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.
[edit routing-options backup-selection destination ip-address interface interface-name admin-group]user@host# set preference group-nameFor example, to set an ordered set of an administrative group that specifies the preference of the backup path:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]user@host# set preference c4
- 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.[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name bandwidth-greater-equal-primary
- 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name dest-metric highest
Configure the backup path that has the lowest destination metric.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name dest-metric lowest
- Configure the backup path that is a downstream path to
the destination.[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name downstream-paths-only
- 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name metric-order destuser@host# set backup-selection destination ip-address interface interface-name metric-order root - 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name nodeConfigure the list of neighbors to be excluded.
[edit routing-options backup-selection destination ip-address interface interface-name node]user@host# set exclude node-addressThe 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.
[edit routing-options backup-selection destination ip-address interface interface-name node]user@host# set preference node-addressThe backup path having the leftmost neighbor is selected.
- 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name protection-type linkSelect the backup path that provides node protection.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name protection-type nodeSelect the backup path that allows either node or link protection LFA where node-protection LFA is preferred over link-protection LFA.
[edit routing-options]user@host# set backup-selection destination ip-address interface interface-name protection-type node-link
- 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface all root-metric highestSelect the path with lowest root metric.
[edit routing-options]user@host# set backup-selection destination ip-address interface all root-metric lowest
- 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface all srlg looseA 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface all srlg strict
- 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.
[edit routing-options]user@host# set backup-selection destination ip-address interface all evaluation-order admin-groupuser@host# set backup-selection destination ip-address interface all evaluation-order srlguser@host# set backup-selection destination ip-address interface all evaluation-order bandwidth
Topology-Independent Loop-Free Alternate with Segment Routing for OSPF
Understanding Topology-Independent Loop-Free Alternate with Segment Routing for OSPF
Configuring 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:
- Enable TI-LFA for OSPF protocol.[edit protocols ospf backup-spf-options]user@R1# set use-post-convergence-lfa
- (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.[edit protocols ospf backup-spf-options use-post-convergence-lfa]user@R1# set maximum-backup-paths maximum-backup-pathsuser@R1# set maximum-labels maximum-labels
- Configure the computation and installation of a backup
path that follows the post-convergence path on the given area and
interfacefor the OSPF protocol.[edit protocols ospf area area-id interface interface-nameuser@R1# set post-convergence-lfa
- (Optional) Enable node protection for a given area and
interface.[edit protocols ospf area area-id interfaceinterface-name post-convergence-lfa]user@R1# set node-protection
- (Optional) Enable fate-sharing protection for a given
area and interface.[edit protocols ospf area area-id interfaceinterface-name post-convergence-lfa]user@R1# set fate-sharing-protection
- (Optional) Enable SRLG protection for a given area and
interface.[edit protocols ospf area area-id interfaceinterface-name post-convergence-lfa]user@R1# set srlg-protection
Related Documentation
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:
Configure the device interfaces.
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.
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:
- Configure the interfaces.[edit interfaces]user@R3# set ge-0/0/5 unit 0 family inet address 172.16.50.2/30user@R3# set ge-0/0/5 unit 0 family inet6 address 2001:db8:50:1:1::2/64user@R3# set ge-0/0/5 unit 0 family mplsuser@R3# set xe-0/3/1 unit 0 family inet address 172.16.75.1/30user@R3# set xe-0/3/1 unit 0 family inet6 address 2001:db8:75:1:1::1/64user@R3# set xe-0/3/1 unit 0 family mplsuser@R3# set ge-1/0/0 unit 0 family inet address 172.16.80.1/30user@R3# set ge-1/0/0 unit 0 family inet6 address 2001:db8:80:1:1::1/64user@R3# set ge-1/0/0 unit 0 family mplsuser@R3# set ge-1/0/5 unit 0 family inet address 172.16.200.1/24user@R3# set ge-1/0/5 unit 0 family inet6 address 2001:db8:200:1:1::1/64user@R3# set ge-1/0/6 unit 0 family inet address 172.16.85.1/30user@R3# set ge-1/0/6 unit 0 family inet6 address 2001:db8:85:1:1::1/64user@R3# set ge-1/0/6 unit 0 family mplsuser@R3# set xe-1/3/0 unit 0 family inet address 172.16.90.1/30user@R3# set xe-1/3/0 unit 0 family inet6 address 2001:db8:90:1:1::1/64user@R3# set xe-1/3/0 unit 0 family mplsuser@R3# set lo0 unit 0 family inet address 172.16.3.3/32 primaryuser@R3# set lo0 unit 0 family inet6 address 2001:db8::3:3:3:3/128 primaryuser@R3# set lo0 unit 0 family mpls
- Configure srlg values.[edit routing-options]user@R3# set srlg srlg1 srlg-value 1001user@R3# set srlg srlg2 srlg-value 1002user@R3# set srlg srlg3 srlg-value 1003user@R3# set srlg srlg4 srlg-value 1004user@R3# set srlg srlg5 srlg-value 1005user@R3# set srlg srlg6 srlg-value 1006user@R3# set srlg srlg7 srlg-value 1007user@R3# set srlg srlg8 srlg-value 1008user@R3# set srlg srlg9 srlg-value 1009user@R3# set srlg srlg10 srlg-value 10010user@R3# set srlg srlg11 srlg-value 10011user@R3# set srlg srlg12 srlg-value 10012
- Configure the ID of the router.[edit routing-options]user@R3# set router-id 172.16.3.3
- Apply the routing policy to all equal-cost multipaths
exported from the routing table to the forwarding table.[edit routing-options]user@R3# set forwarding-table export ecmp
- Configure attributes of the backup selection policy.[edit routing-options backup-selection]user@R3# set destination 10.1.1.0/30 interface xe-1/3/0.0 admin-group include-all c2user@R3# set destination 10.1.1.0/30 interface all admin-group exclude c3user@R3# set destination 10.1.1.0/30 interface all srlg strictuser@R3# set destination 10.1.1.0/30 interface all protection-type nodeuser@R3# set destination 10.1.1.0/30 interface all bandwidth-greater-equal-primaryuser@R3# set destination 10.1.1.0/30 interface all neighbor preference 172.16.7.7user@R3# set destination 10.1.1.0/30 interface all root-metric lowestuser@R3# set destination 10.1.1.0/30 interface all metric-order rootuser@R3# set destination 172.16.30.0/30 interface all admin-group exclude c5user@R3# set destination 172.16.30.0/30 interface all srlg strictuser@R3# set destination 172.16.30.0/30 interface all protection-type nodeuser@R3# set destination 172.16.30.0/30 interface all bandwidth-greater-equal-primaryuser@R3# set destination 172.16.30.0/30 interface all neighbor preference 172.16.7.7user@R3# set destination 172.16.30.0/30 interface all root-metric lowestuser@R3# set destination 172.16.30.0/30 interface all metric-order rootuser@R3# set destination 192.168.45.0/30 interface all admin-group exclude c5user@R3# set destination 192.168.45.0/30 interface all srlg strictuser@R3# set destination 192.168.45.0/30 interface all protection-type nodeuser@R3# set destination 192.168.45.0/30 interface all bandwidth-greater-equal-primaryuser@R3# set destination 192.168.45.0/30 interface all neighbor preference 172.16.7.7user@R3# set destination 192.168.45.0/30 interface all root-metric lowestuser@R3# set destination 192.168.45.0/30 interface all metric-order root
- Enable RSVP on all the interfaces.[edit protocols]user@R3# set rsvp interface all
- Configure administrative groups.[edit protocols mpls]user@R3# set admin-groups c0 0user@R3# set admin-groups c1 1user@R3# set admin-groups c2 2user@R3# set admin-groups c3 3user@R3# set admin-groups c4 4user@R3# set admin-groups c5 5user@R3# set admin-groups c6 6user@R3# set admin-groups c7 7user@R3# set admin-groups c8 8user@R3# set admin-groups c9 9user@R3# set admin-groups c10 10user@R3# set admin-groups c11 11user@R3# set admin-groups c12 12user@R3# set admin-groups c13 13user@R3# set admin-groups c14 14user@R3# set admin-groups c15 15user@R3# set admin-groups c16 16user@R3# set admin-groups c17 17user@R3# set admin-groups c18 18user@R3# set admin-groups c19 19user@R3# set admin-groups c20 20user@R3# set admin-groups c21 21user@R3# set admin-groups c22 22user@R3# set admin-groups c23 23user@R3# set admin-groups c24 24user@R3# set admin-groups c25 25user@R3# set admin-groups c26 26user@R3# set admin-groups c27 27user@R3# set admin-groups c28 28user@R3# set admin-groups c29 29user@R3# set admin-groups c30 30user@R3# set admin-groups c31 31
- Enable MPLS on all the interfaces and configure administrative
group for an interface.[edit protocols mpls]user@R3# set interface alluser@R3# set interface ge-0/0/5.0 admin-group c0
- Enable link protection and configure metric values on
all the interfaces for an OSPF area.[edit protocols ospf]user@R3# set area 0.0.0.0 interface ge-0/0/5.0 link-protectionuser@R3# set area 0.0.0.0 interface ge-0/0/5.0 metric 10user@R3# set area 0.0.0.0 interface xe-0/3/1.0 metric 21user@R3# set area 0.0.0.0 interface ge-1/0/0.0 metric 13user@R3# set area 0.0.0.0 interface ge-1/0/6.0 metric 15user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protectionuser@R3# set area 0.0.0.0 interface xe-1/3/0.0 metric 22
- Enable link protection and configure metric values on
all the interfaces for an OSPF3 area.[edit protocols ospf3]user@R3# set area 0.0.0.0 interface ge-0/0/5.0 link-protectionuser@R3# set area 0.0.0.0 interface ge-0/0/5.0 metric 10user@R3# set area 0.0.0.0 interface xe-0/3/1.0 metric 21user@R3# set area 0.0.0.0 interface ge-1/0/0.0 metric 13user@R3# set area 0.0.0.0 interface ge-1/0/6.0 metric 15user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protectionuser@R3# set area 0.0.0.0 interface xe-1/3/0.0 metric 22
- Configure the routing policy.[edit policy-options]user@R3# set policy-statement ecmp term 1 then load-balance per-packet
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.
user@R3> show routeinet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.3.3/32 *[Direct/0] 02:22:27
> via lo0.0
10.4.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.5.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.6.128.0/17 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.9.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.10.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.13.4.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.13.10.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.82.0.0/15 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.84.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.85.12.0/22 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.92.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.92.16.0/20 *[Direct/0] 02:22:57
> via fxp0.0
10.92.24.195/32 *[Local/0] 02:22:57
Local via fxp0.0
10.94.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.99.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.102.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.150.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.155.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.157.64.0/19 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.160.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.204.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.205.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.206.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.207.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.209.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.212.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.213.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.214.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.215.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.216.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.13.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.14.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.16.0/20 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.32.0/20 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.227.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
172.16.50.0/30 *[Direct/0] 02:19:55
> via ge-0/0/5.0
172.16.50.2/32 *[Local/0] 02:19:58
Local via ge-0/0/5.0
172.16.75.0/30 *[Direct/0] 02:19:55
> via xe-0/3/1.0
172.16.75.1/32 *[Local/0] 02:19:57
Local via xe-0/3/1.0
172.16.24.195/32 *[Direct/0] 02:22:57
> via lo0.0
172.16.0.0/12 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.102.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.136.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.136.192/32 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.137.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.233.5/32 *[OSPF/10] 00:16:55, metric 1
MultiRecv
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
47.0005.80ff.f800.0000.0108.0001.1280.9202.4195/152
*[Direct/0] 02:22:57
> via lo0.0
mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 00:16:55, metric 1
Receive
1 *[MPLS/0] 00:16:55, metric 1
Receive
2 *[MPLS/0] 00:16:55, metric 1
Receive
13 *[MPLS/0] 00:16:55, metric 1
Receive
inet6.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8:50:1:1::/64 *[Direct/0] 02:19:44
> via ge-0/0/5.0
2001:db8:50:1:1::2/128 *[Local/0] 02:19:58
Local via ge-0/0/5.0
2001:db8:75:1:1::/64 *[Direct/0] 02:19:44
> via xe-0/3/1.0
2001:db8:75:1:1::1/128 *[Local/0] 02:19:57
Local via xe-0/3/1.0
2001:db8::3:3:3:3/128 *[Direct/0] 02:22:27
> via lo0.0
2001:db8::128:92:24:195/128
*[Direct/0] 02:22:57
> via lo0.0
fe80::/64 *[Direct/0] 02:19:44
> via ge-0/0/5.0
[Direct/0] 02:19:43
> via xe-0/3/1.0
fe80::205:86ff:fe00:ed05/128
*[Local/0] 02:19:58
Local via ge-0/0/5.0
fe80::205:86ff:fe00:ed3d/128
*[Local/0] 02:19:57
Local via xe-0/3/1.0
fe80::5668:a50f:fcc1:3ca2/128
*[Direct/0] 02:22:57
> via lo0.0Meaning
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.
user@R3> show ospf route detailTopology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop
Type Type Type Interface Address/LSP
172.16.50.0/30 Intra Network IP 10 ge-0/0/5.0
area 0.0.0.0, origin 172.16.3.3, priority low
172.16.75.0/30 Intra Network IP 21 xe-0/3/1.0
area 0.0.0.0, origin 172.16.3.3, priority lowMeaning
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.
user@R3> show ospf3 route detail
Prefix Path Route NH Metric
Type Type Type
2001:db8:50:1:1::/64 Intra Network IP 10
NH-interface ge-0/0/5.0
Area 0.0.0.0, Origin 172.16.3.3, Priority low
2001:db8:75:1:1::/64 Intra Network IP 21
NH-interface xe-0/3/1.0
Area 0.0.0.0, Origin 172.16.3.3, Priority lowMeaning
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.
user@R3> show backup-selectionPrefix: 10.1.1.0/30
Interface: all
Admin-group exclude: c3
Neighbor preference: 172.16.7.7
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= Primary: Enabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Root-metric, Dest-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric
Interface: xe-1/3/0.0
Admin-group include-all: c2
Protection Type: Link, Downstream Paths Only: Disabled, SRLG: Loose, B/w >= Primary: Disabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Dest-metric, Root-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric Prefix: 172.16.30.0/30
Interface: all
Admin-group exclude: c5
Neighbor preference: 172.16.7.7
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= Primary: Enabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Root-metric, Dest-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric
Prefix: 172.16.45.0/30
Interface: all
Admin-group exclude: c5
Neighbor preference: 172.16.7.7
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= Primary: Enabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Root-metric, Dest-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric 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:
Configure network interfaces.
Configure external peer sessions. See Example: Configuring External BGP Point-to-Point Peer Sessions.
Configure interior gateway protocol (IGP) sessions between peers.
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.
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:
Create the policy term.
[edit policy-options policy-statement injectpolicy1]user@host# set term injectterm1Specify OSPF as a match condition.
[edit policy-options policy-statement injectpolicy1 term injectterm1]user@host# set from protocol ospfSpecify the routes from an OSPF area as a match condition.
[edit policy-options policy-statement injectpolicy1 term injectterm1]user@host# set from area 0.0.0.1Specify that the route is to be accepted if the previous conditions are matched.
[edit policy-options policy-statement injectpolicy1 term injectterm1]user@host# set then acceptApply the routing policy to BGP.
[edit]user@host# set protocols bgp export injectpolicy1
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.
Include a trace action in the policy.
[edit policy-options policy-statement injectpolicy1 term injectterm1]user@host# then traceConfigure the tracing file for the output.
[edit routing-options traceoptions]user@host# set file ospf-bgp-policy-loguser@host# set file size 5muser@host# set file files 5user@host# set flag policy
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:
Configure the device interfaces. See the Interfaces User Guide for Security Devices.
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.
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.
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:
- Create the routing policy.[edit]user@host# edit policy-options policy-statement exportstatic1
- Create the policy term. [edit policy-options policy-statement exportstatic1]user@host# set term exportstatic1
- Specify static as a match condition.[edit policy-options policy-statement exportstatic1 term exportstatic1]user@host# set from protocol static
- Specify that the route is to be accepted if the previous
condition is matched. [edit policy-options policy-statement exportstatic1 term exportstatic1]user@host# set then accept
- Apply the routing policy to OSPF.
Note For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]user@host# set protocols ospf export exportstatic1 - If you are done configuring the device, commit the configuration.[edit]user@host# commit
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:
Configure the router identifiers for the devices in your OSPF network. See Example: Configuring an OSPF Router Identifier.
Control OSPF designated router election. See Example: Controlling OSPF Designated Router Election.
Configure a single-area OSPF network. See Example: Configuring a Single-Area OSPF Network .
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:
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:
- Configure the interfaces.[edit]user@R1# set interfaces so-0/2/0 unit 0 family inet address 10.0.2.1/30[edit]user@R2# set interfaces so-0/2/0 unit 0 family inet address 10.0.2.2/30
- Enable OSPF on the interfaces.
Note For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]user@R1# set protocols ospf area 0.0.0.0 interface so-0/2/0[edit]user@R2# set protocols ospf area 0.0.0.0 interface so-0/2/0 - On R1, redistribute the static route into OSPF.[edit]user@R1# set protocols ospf export export_staticuser@R1# set policy-options policy-statement export_static from protocol staticuser@R1# set policy-options policy-statement export_static then accept
- On R2, configure the OSPF import policy.[edit]user@R2# set protocols ospf import filter_routesuser@R2# set policy-options policy-statement filter_routes from route-filter 10.0.16.0/30 exactuser@R2# set policy-options policy-statement filter_routes then reject
- If you are done configuring the devices, commit the configuration.[edit]user@host# commit
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:
Configure the device interfaces. See the Interfaces User Guide for Security Devices.
Configure the router identifiers for the devices in your OSPF network. See Example: Configuring an OSPF Router Identifier.
Control OSPF designated router election See Example: Controlling OSPF Designated Router Election
Configure a single-area OSPF network. See Example: Configuring a Single-Area OSPF Network .
Configure a multiarea OSPF network. See Example: Configuring a Multiarea OSPF Network.
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.
The priority value takes effect when a new route is installed, or when there is a change to an existing route.
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.
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:
- Configure the interfaces.[edit]user@host# set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30user@host# set interfaces fe-0/2/0 unit 0 family inet address 192.168.8.5/30
- Enable OSPF on the interfaces.
Note For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]user@host# set protocols ospf area 0.0.0.0 interface fe-0/1/0user@host# set protocols ospf area 0.0.0.0 interface fe-0/2/0 - Configure the policy to specify the priority for prefixes
learned through OSPF.[edit ]user@host# set policy-options policy-statement ospf-import term t1 from route-filter 203.0.113.0/24 orlongeruser@host# set policy-options policy-statement ospf-import term t1 then priority lowuser@host# set policy-options policy-statement ospf-import term t1 then acceptuser@host# set policy-options policy-statement ospf-import term t2 from route-filter 198.51.100.0/24 orlongeruser@host# set policy-options policy-statement ospf-import term t2 then priority mediumuser@host# set policy-options policy-statement ospf-import term t2 then acceptuser@host# set policy-options policy-statement ospf-import term t3 from route-filter 192.0.2.0/24 orlongeruser@host# set policy-options policy-statement ospf-import term t3 then priority highuser@host# set policy-options policy-statement ospf-import term t3 then accept
- Apply the policy to OSPF.[edit]user@host# set protocols ospf import ospf-import
- If you are done configuring the device, commit the configuration.[edit]user@host# commit
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:
Configure the router identifiers for the devices in your OSPF network. See Example: Configuring an OSPF Router Identifier.
Control OSPF designated router election. See Example: Controlling OSPF Designated Router Election
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.
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.
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:
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:
- Configure the interfaces.
Note For OSPFv3, use IPv6 addresses.
[edit]user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30user@R1# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30[edit]user@R2# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30user@R2# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.1/30[edit]user@R3# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30[edit]user@R4# set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30user@R4# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.6/30user@R4# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.9/30[edit]user@R5# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30[edit]user@R6# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.10/30 - Enable OSPF on the interfaces.
Note For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1[edit]user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0[edit]user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1[edit]user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1user@R4# set protocols ospf area 0.0.0.4 interface fe-1/1/0user@R4# set protocols ospf area 0.0.0.4 interface fe-1/0/0[edit]user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0[edit]user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0 - On R4, configure the export network summary policy.[edit ]user@R4# set policy-options policy-statement export-policy term term1 from route-filter 10.0.4.4/30 prefix-length-range /30-/30user@R4# set policy-options policy-statement export-policy term term1 then accept
- 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.
[edit]user@R4# set protocols ospf area 0.0.0.4 network-summary-export export-policy - If you are done configuring the devices, commit the configuration.[edit]user@host# commit
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:
Configure the router identifiers for the devices in your OSPF network. See Example: Configuring an OSPF Router Identifier.
Control OSPF designated router election. See Example: Controlling OSPF Designated Router Election.
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.
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.
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
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:
- Configure the interfaces.
Note For OSPFv3, use IPv6 addresses.
[edit]user@R1# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.13/30user@R1# set interfaces fe-0/0/1 unit 0 family inet address 10.0.4.5/30[edit]user@R2# set interfaces fe-0/1/0 unit 0 family inet address 10.0.4.6/30user@R2# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.1/30[edit]user@R3# set interfaces fe-1/0/0 unit 0 family inet address 10.0.4.2/30user@R3# set interfaces fe-1/1/0 unit 0 family inet address 10.0.4.14/30user@R3#set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30[edit]user@R4# set interfaces fe-0/0/1 unit 0 family inet address 10.0.2.1/30user@R4# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.6/30user@R4# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.9/30[edit]user@R5# set interfaces fe-1/1/0 unit 0 family inet address 10.0.8.5/30[edit]user@R6# set interfaces fe-1/0/0 unit 0 family inet address 10.0.8.10/30 - Enable OSPF on the interfaces.
Note For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]user@R1# set protocols ospf area 0.0.0.3 interface fe-0/1/0user@R1# set protocols ospf area 0.0.0.3 interface fe-0/0/1[edit]user@R2# set protocols ospf area 0.0.0.3 interface fe-0/1/0user@R2# set protocols ospf area 0.0.0.3 interface fe-1/0/0[edit]user@R3# set protocols ospf area 0.0.0.3 interface fe-1/0/0user@R3# set protocols ospf area 0.0.0.3 interface fe-1/1/0user@R3# set protocols ospf area 0.0.0.0 interface fe-0/0/1[edit]user@R4# set protocols ospf area 0.0.0.0 interface fe-0/0/1user@R4# set protocols ospf area 0.0.0.4 interface fe-1/1/0user@R4# set protocols ospf area 0.0.0.4 interface fe-1/0/0[edit]user@R5# set protocols ospf area 0.0.0.4 interface fe-1/1/0[edit]user@R6# set protocols ospf area 0.0.0.4 interface fe-1/0/0 - On R3, configure the import network summary policy.[edit ]user@R3# set policy-options policy-statement import-policy term term1 from route-filter 10.0.4.12/30 prefix-length-range /30-/30user@R3# set policy-options policy-statement import-policy term term1 then accept
- 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.
[edit]user@R3# set protocols ospf area 0.0.0.3 network-summary-import import-policy - If you are done configuring the devices, commit the configuration.[edit]user@host# commit
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.
CLI Quick Configuration shows the configuration for all of the devices in Figure 5. The section Step-by-Step Procedure describes the steps on Device R2. Step-by-Step Procedure describes the steps on Device R3.
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, 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:
- Configure the network interfaces.[edit interfaces]user@R2# set fe-1/2/1 unit 0 description to-R5user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.37/30user@R2# set fe-1/2/1 unit 0 family isouser@R2# set fe-1/2/0 unit 0 description to-OSPF-networkuser@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.45/30user@R2# set lo0 unit 0 family inet address 172.16.9.7/32user@R2# set lo0 unit 0 family iso address 49.0002.0172.0016.0907.00
- Configure IS-IS on the interface facing Device R1 and
the loopback interface.[edit protocols isis]user@R2# set interface fe-1/2/1.0user@R2# set interface lo0.0
- Configure the policy that enables Device R1 to reach the
10.0.0.44/30 network.[edit policy-options policy-statement send-direct-to-isis-neighbors]user@R2# set from protocol directuser@R2# set from route-filter 10.0.0.44/30 exactuser@R2# set then accept
- Apply the policy that enables Device R1 to reach the 10.0.0.44/30
network.[edit protocols isis]user@R2# set export send-direct-to-isis-neighbors
- Configure OSPF on the interfaces.[edit protocols ospf]user@R2# set area 0.0.0.1 interface fe-1/2/0.0user@R2# set area 0.0.0.1 interface lo0.0 passive
- Configure the OSPF route redistribution policy.[edit policy-options policy-statement ospf-isis term 1]user@R2# set from protocol ospfuser@R2# set from route-filter 192.168.0.0/22 longeruser@R2# set then accept
- Apply the OSPF route redistribution policy to the IS-IS
instance.[edit protocols isis]user@R2# set export ospf-isis
- Configure the policy that enables Device R3 to reach the
10.0.0.36/30 network.[edit policy-options policy-statement send-direct-to-ospf-neighbors]user@R2# set from protocol directuser@R2# set from route-filter 10.0.0.36/30 exactuser@R2# set then accept
- Apply the policy that enables Device R3 to reach the 10.0.0.36/30
network.[edit protocols ospf]user@R2# set export send-direct-to-ospf-neighbors
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:
- Configure the network interfaces.
Multiple addresses are configured on the loopback interface to simulate multiple route destinations.
[edit interfaces]user@R3# set fe-1/2/0 unit 0 family inet address 10.0.0.46/30user@R3# set lo0 unit 0 family inet address 192.168.1.1/32user@R3# set lo0 unit 0 family inet address 192.168.2.1/32user@R3# set lo0 unit 0 family inet address 192.168.3.1/32user@R3# set lo0 unit 0 family inet address 192.168.0.1/32 - Configure static routes to the loopback interface addresses.
These are the routes that are redistributed into IS-IS.
[edit routing-options static]user@R3# set route 192.168.0.0/24 discarduser@R3# set route 192.168.1.0/24 discarduser@R3# set route 192.168.3.0/24 discarduser@R3# set route 192.168.2.0/24 discard - Configure OSPF on the interfaces.[edit protocols ospf area 0.0.0.1]user@R3# set interface fe-1/2/0.0user@R3# set interface lo0.0 passive
- Configure the OSPF policy to export the static routes. [edit policy-options policy-statement ospf term 1]user@R3# set from protocol staticuser@R3# set then accept
- Apply the OSPF export policy. [edit protocols ospf]user@R3# set export ospf
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.
user@R2> show route protocol ospf
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0
> to 10.0.0.46 via fe-1/2/0.0
192.168.0.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
192.168.1.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0
> to 10.0.0.46 via fe-1/2/0.0
192.168.1.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
192.168.2.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0
> to 10.0.0.46 via fe-1/2/0.0
192.168.2.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
192.168.3.0/24 *[OSPF/150] 03:54:21, metric 0, tag 0
> to 10.0.0.46 via fe-1/2/0.0
192.168.3.1/32 *[OSPF/10] 03:54:21, metric 1
> to 10.0.0.46 via fe-1/2/0.0
224.0.0.5/32 *[OSPF/10] 03:56:03, metric 1
MultiRecv
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)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.
user@R1> show route protocol isis
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.44/30 *[IS-IS/160] 03:45:24, metric 20
> to 10.0.0.37 via fe-1/2/0.0
172.16.9.7/32 *[IS-IS/15] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.0.0/24 *[IS-IS/160] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.0.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
192.168.1.0/24 *[IS-IS/160] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.1.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
192.168.2.0/24 *[IS-IS/160] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.2.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
192.168.3.0/24 *[IS-IS/160] 03:49:46, metric 10
> to 10.0.0.37 via fe-1/2/0.0
192.168.3.1/32 *[IS-IS/160] 03:49:46, metric 11, tag2 1
> to 10.0.0.37 via fe-1/2/0.0
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)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.
user@R1> ping 192.168.1.1PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=63 time=2.089 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=1.270 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=2.135 ms
Meaning
These results confirm that Device R1 can reach the destinations in the OSPF network.