Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

How to Configure Flexible Algorithms in OSPF for Segment Routing Traffic Engineering

A flexible algorithm allows IGPs alone to compute constraint based paths over the network thereby providing simple traffic engineering without using a network controller. This is a light weight solution for networks that have not implemented a controller with full fledged segment routing but still want to reap the benefits of segment routing in their network.

What's Next

For more information on configuring flexible algorithms, see the OSPF User Guide

Understanding OSPF Flexible Algorithm for Segment Routing

Starting in Junos OS Release 21.1R1, you can thin slice a network by defining flexible algorithms that compute paths using different parameters and link constraints based on your requirements. For example, you can define a flexible algorithm that computes a path to minimize IGP metric and define another flexible algorithm to compute a path based on traffic engineering metric to divide the network into separate planes. This feature allows networks without a controller to configure traffic engineering using segment routing without actually implementing a network controller. You can use the prefix SIDs to steer packets along the constraint-based paths. You can configure the prefix SIDs for flexible algorithm through policy configurations.

IGP protocols use a link metric to calculate a best path. However, the best IGP path might not always be the best path for certain types of traffic. Therefore, the IGP computed best path based on the shortest IGP metric is often replaced with traffic engineered path due to the traffic requirements that are not reflected by the IGP metric. Typically RSVP-TE or SR TE is used for computing the path based on additional metrics and constraints to overcome this limitation. Junos installs such paths in the forwarding tables in addition to or as a replacement for the original path computed by the IGPs.

Benefits of Configuring Flexible Algorithm

  • A lightweight version of segment routing traffic engineering that can be used in the core of the network.

  • Allows you to configure traffic engineering using segment routing even without installing a network controller.

  • Utilize equal-cost multipath (ECMP) and TI-LFA per-slice without configuring BGP-LS or static path.

  • Compute TI-LFA backup path using the same flexible algorithm definition and constraints computation.

  • Take advantage of segment routing traffic engineering using only OSPFv2 without configuring RSVP or LDP.

  • Ability to provision constrained primary path based on a single label.

What is Flexible Algorithm Definition (FAD)?

A flexible algorithm allows IGP to calculate additional best paths based on specified constraints thereby providing simple traffic engineering without using a network controller. This is a lightweight solution for networks that have not implemented a controller with full fledged segment routing but still want to reap the benefits of segment routing in their network. Every operator can define separate constraints or colors depending on their requirements.

To define a flexible algorithm, include flex-algorithm id statement at the [edit routing-options] hierarchy level. The flexible algorithm definition (FAD) is assigned with an identifier ranging from 128 through 255. This flexible algorithm can be defined on one or more routers in a network. A flexible algorithm computes a best path based on the following parameters:

  • Calculation type—SPF or strict SPF are the two available calculation type options. You can specify one of these calculation types in your FAD. Select the SPF calculation type if you want to influence the SPF computation on your device based on a certain local policy such as traffic engineering shortcuts. If you select strict SPF then the local policy cannot influence the SPF path selection.

  • Metric type- IGP metric or TE metric are the available metric type options. You can specify one of these metric types in your FAD depending on your network requirement. If you do not want to use the IGP metric for a specific link you can configure a TE metric that OSPFv2 can use for calculating the route.

  • Priority- You can assign a priority to your FADs as per your requirement and OSPFv2 prioritizes a particular FAD advertisement over another FAD based on your assigned priority.

  • Set of Link constraints- You can configure admin-groups for many protocols at the [edit protocols mpls admin-groups] hierarchy level to color an individual link. These admin-groups can then be defined as include any, include-all or exclude at the [edit routing-options flex-algorithm definition admin-groups] hierarchy level.

We recommend configuring flexible algorithm on only a few routers to provide redundancy and to avoid conflicts. Flexible algorithm definition is advertised in IGP as FAD sub-TLVs. In very large networks, we do not recommend configuring more than 8 flexible algorithm definitions as each flexible algorithm will compute its own path and might cause performance issues beyond that.

The default FAD has the following parameters:

  • calculation type: spf

  • metric type: igp-metric

  • priority: 0

  • Link constraints: none

Note:

Modifying the flexible algorithm definition in a live network or on the fly could cause traffic disruptions until all the nodes converge on the new paths.

Starting in Junos OS 21.4R1, we support flexible Algorithm Definition (FAD)” and “Flexible Algorithm Prefix Metric (FAPM)” in TED and implements two new corresponding TLVs "FAD TLV" and "FAPM TLV" in BGP-LS. The value of FAD TLV contains Flex-Algorithm, Metric-Type, Calculation-Type and Priority, all of which are one byte each. The TLV might have zero or more sub-TLVs included in it. The five sub-tlvs are Flex Algo Exclude Any Affinity, Flex Algo Include Any Affinity, Flex Algo Include All Affinity, Flex Algo Definition Flags and Flex Algo Exclude SRLG.

The FAD TLV can only be added to the BGP-LS Attribute of the Node NLRI if the corresponding node originates in the underlying IGP TLV or sub-TLV. The BGP-LS Attribute associated with a Node NLRI might include one or more FAD TLVs corresponding to the Flexible Algorithm Definition for each algorithm that the node is advertising.

The value of FAPM TLV contains Flex-Algorithm (1 byte), Reserved (3 bytes) and Metric (4 bytes). The FAPM TLV can be added to the BGP-LS Attribute of the Prefix NLRI originated by a node, only if the corresponding node originates from the Prefix.

Starting in Junos OS Release 22.4R1, we've defined the Flexible Algorithm Prefix Metric (FAPM) to allow optimal end-to-end path for an interarea prefix. The area border router (ABR) must include the FAPM when advertising the prefix between areas that is reachable in that given Flexible Algorithm (flex algo). When a prefix is unreachable, the ABR must not include that prefix in that flex algo when advertising between areas. The defined FAPM provides inter-area support.

Participation in a Flexible Algorithm

You can configure specific routers to participate in a particular flexible algorithm as per your requirement. Paths computed based on a flexible algorithm definition is used by various applications each potentially using its own specific data plane for forwarding the data over such paths. The participating device must explicitly advertise its participation in a particular flexible algorithm to every application in the segment routing flexible algorithm sub TLV for OSPFv2. You can configure a node to participate in a certain flexible algorithm provided it can support the constraints specified in that FAD.

To configure participation in a flexible algorithm include the flex-algorithm statement at the [edit protocols isis source-packet- routing] hierarchy level. The same device can advertise a FAD and also participate in a flexible algorithm.

Network Topology Configured with Flexible Algorithm Definitions

Figure 1 shows the sample topology, there are 8 routers R0, R1, R2, R3, R4, R5, R6, and R7. Four flexible algorithms, 128, 129, 130, and 135 are defined and configured with admin-groups as listed in the following table:

Flex Algorithm Definition (FAD)

Color

128

Include any Red

129

Include any Green

130

Include any Green and Blue

135

Exclude Red

Figure 1: Flexible Algorithm TopologyFlexible Algorithm Topology

Figure 2 shows how FAD 128 routes traffic on any interface that is configured with admin group red.

Figure 2: Traffic Flow for Flexible Algorithm Definition 128Traffic Flow for Flexible Algorithm Definition 128

Figure 3 shows how FAD 129 routes traffic on any interface that is configured with admin group green.

Figure 3: Traffic Flow for Flexible Algorithm Definition 129Traffic Flow for Flexible Algorithm Definition 129

Figure 4 shows how FAD 130 routes traffic on any interface that is configured with admin group green and blue.

Figure 4: Traffic flow for Flexible Algorithm Definition 130Traffic flow for Flexible Algorithm Definition 130

Figure 5 shows how FAD 135 routes traffic on any interface that is not configured with admin group red.

Figure 5: Traffic Flow for Flexible Algorithm Definition 135Traffic Flow for Flexible Algorithm Definition 135

Flexible Algorithm RIBs

For every flexible algorithm that a router participates in the corresponding flexible algorithm routes are installed in the corresponding flexible algorithm RIB groups also known as routing tables. By default, labeled OSPFv2 flexible algorithm routes are installed in the inet.color, inet(6)color.0 and mpls.0 RIBs.

BGP Community and Flexible Algorithms

A flexible algorithm can have an associated BGP color community to resolve routes of other services such as VPN service. By default, the associated BGP color community is the same as the flexible algorithm ID. The flexible algorithm ingress routes that are installed in the inet(6)color.0 tables will have this color community in the route. However, you can configure a different BGP color community at the [edit routing-options flex-algorithm id color desired color community value] hierarchy level.

Note:

Changing the BGP color community for a flexible algorithm might result in traffic disruption. If you modify a BGP color community for a flexible algorithm then all routes pertaining to that flexible algorithm are removed from the RIB and added again with new colors.

Supported and Unsupported Features

Junos OS supports flexible algorithms in the following scenarios:

  • Support for configuring and advertising prefix SIDs for different flexible algorithms.

  • Partially supports Internet Draft draft-ietf-lsr-flex-algo-05.txt IGP Flexible Algorithm

  • The current implementation for flexible algorithms is supported for only OSPFv2 only as only OSPFv2 supports segment routing.

Junos OS does not support the following features in conjunction with flexible algorithms:

  • Link delay metric is not supported.

  • Flexible algorithm is applicable only for default unicast topology, OSPFv2 multi-topology is not supported.

  • OSPFv2 shortcuts and other OSPFv2 traffic engineering configuration options are not applicable for flexible algorithm computation. .
  • The current implementation for flexible algorithms is not supported for OSPFv3.
  • Inter-area (OSPFv2) leaking of flexible algorithm prefix SIDs is not supported.

  • Prefix and SID conflict resolution is not supported.

  • Remote loop free alternate functionality is not supported because TI-LFA is the preferred FRR computation.

  • Advertising flexible algorithm definition in the absence of flexible algorithm participation is not supported.

  • Advertisement of link attributes for flex algorithm using the application-specific link attribute advertisements is not supported.

  • Transport class RIB is not supported.

Application-specific Link Attribute based flexible algorithm

Starting in Junos OS and Junos OS Evolved Release 22.2R1, you can advertise different te-attributes such as te-metric, delay-metric, or admin-groups for RSVP and flexible algorithms on the same link. This is done using flexible algorithm specific application-specific link attribute as defined in RFC 8920.

The advantage of having a flexible algorithm application-specific link attribute advertise te-metric, delay-metric, or admin-groups is that a single link can advertise different te-link-attributes for legacy applications such as RSVP and different te-link-attributes for flexible algorithms.

To configure flexible algorithm application-specific te-attribute, include the application-specific statement at the [edit protocols ospf area interface] hierarchy level and the strict-asla-based-flex-algorithm statement at the [edit protocols ospf source-packet-routing] hierarchy level. With this implementation, it is no longer mandatory for the link to have RSVP enabled and [edit protocols ospf traffic-engineering advertisement always] to be configured which is the case with the existing behavior of advertising traffic engineering attributes.

Note:

The Junos OS and Junos OS Evolved implementation of application-specific link attribute supports flexible algorithm applications only.

Strict Application-Specific Link Attribute based flexible algorithm

The default behavior of application-specific flexible algorithm is to use the flexible algorithm application-specific te-attributes for a link if available, and if not, then fall back to the common application-specific te-attributes, and if neither are available, use the legacy te-attributes.

The configuration statement strict-asla-based-flex-algorithm at the [edit protocols ospf source-packet-routing] has to be applied to all the flexible algorithms running on the devices in the network to avoid routing loops.

If strict-asla-based-flex-algorithm is configured on all the devices, either a common application-specific te-attribute or flexible algorithm application-specific te-attribute must be advertised for each flexible algorithm link. In the absence of application-specific te-attributes, the device does not fall back to the legacy te-attributes and simply ignores the link.

The Operating System supports the following features in conjunction with application-specific link attribute based flexible algorithm:

  • The application-specific te-attribute subTLV to comply with RFC 8920. The application-specific te-attributes sub-TLV is a sub-TLV of the OSPFv2 extended link TLV as defined in RFC 7684.

  • Partially supports standard application identifier bit mask to advertise X-bit for flexible algorithms. Only the te-metric, delay-metric, or admin-groups are advertised as part of the application-specific link attribute sub-TLV.

The Operating System does not support the following features in conjunction with application-specific link attribute based flexible algorithm:

  • Advertising user-defined application identifier bit masks is not supported.
  • Readvertising flexible algorithm application-specific link attribute or rather any application-specific link attributes with BGP-LS is not supported because Traffic Engineering Database (TED) does not support application-specific link attribute.
  • Advertising a common application-specific link attribute with standard application identifier bit mask and user-defined application identifier bit masks length set to zero is not supported.

  • Advertising SRLG link constraint in flexible algorithm is not supported.

  • Supporting traffic engineering for multiple applications is not supported, except for flexible algorithms.

  • Defining admin-groups independent of MPLS is not supported.

Example: OSPF Flexible Algorithm

Overview

This example shows how to configure flexible algorithm in an OSPFv2 network. The flexible algorithm allows networks without a controller to configure traffic engineering using segment routing without actually implementing a network controller.

Starting in Junos OS Release 21.1R1, you can thin-slice a network by defining flexible algorithms that compute paths using different parameters and link constraints based on your requirements. The set consisting of calculation-type, metric-type, and a set of constraints is referred to as a flexible algorithm definition (FAD). You can define FADs and advertise the same in an OSPFv2 network. A device can also be configured to participate in a certain flexible algorithm provided it supports the constraints for that specific FAD.

Topology

Figure 6 shows a flexible algorithm topology in which there are 6 devices R0, R1, R2, R3, R4, and R5. Two flexible algorithms 128 and 129 are defined on each of these devices. The admin-groups red, blue, and green are configured on the devices. The FADs with different parameters such as metric-types, calculation-types, and link constraints are defined on each of the devices.

Figure 6: Flexible Algorithm TopologyFlexible Algorithm Topology

Requirements

This example uses the following hardware and software components:

  • Six MX Series routers.
  • Junos OS Release 21.1R1 or later running on all devices.

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 R0

Device R1

Device R2

Device R3

Device R4

Device R5

Configuring Device R0

To configure flexible algorithm for OSPFv2, perform the following steps on the device R0:

  1. Configure the device interfaces to enable IP transport.

  2. Configure the loopback interface (lo0) address that is used as router ID for OSPF sessions.

  3. Configure the router ID and autonomous system (AS) number to propagate routing information within a set of routing devices that belong to the same AS.

  4. Define a policy to load balance packets and apply the per-packet policy to enable load balancing of traffic.

  5. Configure the route filter for the routing policy term that enables the Device R0 to reach the 192.168.255.10/32 network.

  6. Configure MPLS on all interfaces excluding the management interface.
  7. Configure the MPLS label range to assign static labels for the links.

  8. Configure TI-LFA to enable protection against link and node failures. SR using TI-LFA provides faster restoration of network connectivity by routing the traffic instantly to a backup or an alternate path if the primary path fails or becomes unavailable.

  9. Configure the maximum number of labels for segment routing routed paths for protection of backup shortest-path-first attributes.

  10. Configure prefix segment attributes, the start label and the index range for segment routing global blocks (SRGBs) in SPRING for the OSPF protocol.

  11. Enable node-link protection on the OSPF interfaces that follow post-convergence path.

  12. Configure the loopback interface as passive to ensure the protocols do not run over the loopback interface and that the loopback interface is advertised correctly throughout the network.

  13. Define flexible algorithms on the device R0. Assign a name for each of the FADs ranging from 128 through 255.

    Specify the parameters of the definition. OSPFv2 calculates the path based on these specified parameters of the FAD.

    1. Specify the calculation type based on which the OSPFv2 protocol calculates the path.

    2. Specify the metric type based on which OSPFv2 calculates the path.

    3. If you have enabled RSVP traffic engineering, you can configure admin-groups for many protocols to color an individual link.

    4. Assign the configured admin-groups policies to the device R0 interfaces.

    5. Define the admin-groups as per your requirement.

      Note:

      For FADs with link-constraints to work, all relevant links should advertise the admin-colors in OSPFv2. You must either enable RSVP on the interfaces or if you have not configured RSVP for traffic engineering, make sure you configure set traffic-engineering advertise always at the [edit protocols ospf] hierarchy level.

  14. Configure the flexible algorithm participation on the device R0. The same device can advertise a FAD and also participate in a flexible algorithm.
  15. Advertise prefix segments through policy configuration.

Results

Check the results of the configuration:

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

Verification

To confirm that the configuration is working properly, perform the following tasks:

Verifying the OSPF Database

Purpose

Verifying that the flexible algorithm signaling is displayed in the OSPF database.

Action

From operational mode, run the show ospf database opaque-area extensive command.

On R0

Meaning

This output on R0 illustrates that:

Three segment-routing algorithms (including two flexible algorithms) are advertised by this device.

Two FADs are advertised by this device.

Verifying the Flexible Algorithm Details

Purpose

Verifying that the flexible algorithm details are displayed.

Action

From operational mode, run the show ospf spring flex-algorithm <flex-algorithm-id> command.

On R0

Meaning

The flexible algorithm details that are configured on R0 are displayed.

Verifying Flexible Algorithm Specific OSPF Internal Routes

Purpose

Verifying that the fexible algorithm specific OSPF internal routes are displayed.

Action

From operational mode, run the show ospf route flex-algorithm <flex-algorithm-id> command.

On R0

Meaning

The show ospf route command is extended with flex-algorithm option to show flexible algorithm specific OSPF internal routes. Each route is prefixed with the flex-algo-id:

Verifying Flex Colored routes

Purpose

Verifying that the fexible algorithm specific OSPF internal routes are displayed.

Action

From operational mode, run the show route protocol ospf command.

On R0

Meaning

The output displays all the colored flex routes programmed in inetcolor.0 table in the following format: prefix_address-flex-algo-id<c>/64

Verifying OSPF Logs

Purpose

Verifying that the OSPF logs displays the flexible algorithm keyword.

Action

From operational mode, run the show ospf log command.

On R0

Meaning

The output displays the FlexAlgo keyword added for the SPF logs.