Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Examples: Configuring OSPF Traffic Engineering

OSPF Support for Traffic Engineering

Traffic engineering allows you to control the path that data packets follow, bypassing the standard routing model, which uses routing tables. Traffic engineering moves flows from congested links to alternate links that would not be selected by the automatically computed destination-based shortest path.

To help provide traffic engineering and MPLS with information about network topology and loading, extensions have been added to the Junos OS implementation of OSPF. When traffic engineering is enabled on the routing device, you can enable OSPF traffic engineering support. When you enable traffic engineering for OSPF, the shortest-path-first (SPF) algorithm takes into account the various label-switched paths (LSPs) configured under MPLS and configures OSPF to generate opaque link-state advertisements (LSAs) that carry traffic engineering parameters. The parameters are used to populate the traffic engineering database. The traffic engineering database is used exclusively for calculating explicit paths for the placement of LSPs across the physical topology. The Constrained Shortest Path First (CSPF) algorithm uses the traffic engineering database to compute the paths that MPLS LSPs take. RSVP uses this path information to set up LSPs and to reserve bandwidth for them.

• advertise-unnumbered-interfaces—(OSPFv2 only) Advertises the link-local identifier in the link-local traffic engineering LSA packet. This statement must be included on both ends of an unnumbered link to allow an ingress LER to update the link in its traffic engineering database and use it for CSPF calculations. The link-local identifier is then used by RSVP to signal unnumbered interfaces as defined in RFC 3477, Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE).
• credibility-protocol-preference—(OSPFv2 only) Assigns a credibility value to OSPF routes in the traffic engineering database. By default, Junos OS prefers IS-IS routes in the traffic engineering database over other interior gateway protocol (IGP) routes even if the routes of another IGP are configured with a lower, that is, more preferred, preference value. The traffic engineering database assigns a credibility value to each IGP and prefers the routes of the IGP with the highest credibility value. In Junos OS Release 9.4 and later, you can configure OSPF to take protocol preference into account to determine the traffic engineering database credibility value. When protocol preference is used to determine the credibility value, IS-IS routes are not automatically preferred by the traffic engineering database, depending on your configuration.
• ignore-lsp-metrics—Ignores RSVP LSP metrics in OSPF traffic engineering shortcut calculations or when you configure LDP over RSVP LSPs. This option avoids mutual dependency between OSPF and RSVP, eliminating the time period when the RSVP metric used for tunneling traffic is not up to date. In addition, If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established by RSVP. LDP effectively treats the traffic-engineered LSPs as single hops.
• multicast-rpf-routes—(OSPFv2 only) Installs unicast IPv4 routes (not LSPs) in the multicast routing table (inet.2) for multicast reverse-path forwarding (RPF) checks. The inet.2 routing table consists of unicast routes used for multicast RPF lookup. RPF is an antispoofing mechanism used to check if the packet is coming in on an interface that is also sending data back to the packet source.
• no-topology—(OSPFv2 only) To disable the dissemination of link-state topology information. If disabled, traffic engineering topology information is no longer distributed within the OSPF area.
• shortcuts—Configures OSPF to use MPLS LSPs as shortcut next hops. By default, shortcut routes calculated through OSPFv2 are installed in the inet.3 routing table, and shortcut routes calculated through OSPFv3 are installed in the inet6.3 routing table.

  Note: Whenever possible, use OSPF IGP shortcuts configured at the [edit protocols mpls traffic-engineering bgp-igp] hierarchy level instead of traffic engineering shortcuts configured at the [edit protocols (ospf | ospf3) traffic-engineering shortcuts] hierarchy level. If you configure OSPF IGP shortcuts, inet.3 routes are moved into the inet.0 routing table. In addition, you can verify the data path using ping or traceroute commands since the ping and traceroute packets get tunneled into the LSP. In case of a VPN enabled device, we recommend using [edit protocols mpls traffic-engineering bgp-igp-both-ribs] because BGP next-hop resolution for VPN prefixes relies on entries in the inet.3 table. If you configure traffic engineering shortcuts, OSPF treats the MPLS LSP as a candidate next hop and installs the routes in the inet.3 (for OSPFv2) and inet6.3 (for OSPFv3) routing tables. The only use for these tables is to allow BGP to perform next-hop resolution. In addition, you cannot verify the data path of these routes using ping or traceroute commands because the ping and traceroute packets get tunneled into the LSP.

• lsp-metric-info-summary—Advertises the LSP metric in summary LSAs to treat the LSP as a link. This configuration allows other routing devices in the network to use this LSP. To accomplish this, you need to configure MPLS and OSPF traffic engineering to advertise the LSP metric in summary LSAs.

When you enable traffic engineering on the routing device, you can also configure an OSPF metric that is used exclusively for traffic engineering. The traffic engineering metric is used for information injected into the traffic engineering database. Its value does not affect normal OSPF forwarding.

Caution: When the OSPF traffic engineering configuration is considerably modified, the routing table entries are deleted and the routing table is recreated. Changes to configuration that can cause this behavior include enabling or disabling: Traffic engineering shortcuts IGP shortcuts LDP tunneling Multiprotocol LSP Advertise summary metrics Multicast RPF routes

Example: Enabling OSPF Traffic Engineering Support

This example shows how to enable OSPF traffic engineering support to advertise the label-switched path (LSP) metric in summary link-state advertisements (LSAs).

• Requirements
• Overview
• Configuration
• Verification

Requirements

• Configure the device interfaces. See the Junos® OS Network Interfaces.
• Configure BGP per your network requirements. See the Junos OS Routing Protocols Configuration Guide
• Configure MPLS per your network requirements. See the Junos OS MPLS Applications Configuration Guide.

Overview

You can configure OSPF to treat an LSP as a link and have other routing devices in the network use this LSP. To accomplish this, you configure MPLS and OSPF traffic engineering to advertise the LSP metric in summary LSAs.

In this example, there are four routing devices in area 0.0.0.0, and you want OSPF to treat the LSP named R1-to-R4 that goes from the ingress Device R1 to the egress Device R4 as a link.

For OSPF, you enable traffic engineering on all four routing devices in the area by including the traffic-engineering statement. This configuration ensures that the shortest-path-first (SPF) algorithm takes into account the LSPs configured under MPLS and configures OSPF to generate LSAs that carry traffic engineering parameters. You further ensure that OSPF uses the MPLS LSP as the next hop and advertises the LSP metric in summary LSAs, by including the optional shortcuts lsp-metric-into-summary statement on the ingress Device R1.

For MPLS, you enable traffic engineering so that MPLS performs traffic engineering on both BGP and IGP destinations by including the traffic-engineering bgp-igp statement, and you include the LSP named R1-to-R4 by including the label-switched-path lsp-path-name to address statement on the ingress Device R1. The address specified in the to statement on the ingress Device R1 must match the router ID of the egress Device R4 for the LSP to function as a direct link to the egress routing device and to be used as input to the OSPF SPF calculations. In this example, the router ID of the egress Device R4 is 10.0.0.4.

Configuration

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 CLI User Guide.

CLI Quick Configuration

To quickly enable OSPF traffic engineering support to advertise the LSP metric in summary LSAs, copy the following commands and paste them into the CLI.

Configuration on R1:

Configuration on R2:

Configuration on R3:

Configuration on R4:

Step-by-Step Procedure

1. Configure the router ID.
   [edit]user@R1# set routing-options router-id 10.0.0.1
   [edit]user@R2# set routing-options router-id 10.0.0.2
   [edit]user@R3# set routing-options router-id 10.0.0.3
   [edit]user@R4# set routing-options router-id 10.0.0.4
2. Configure the OSPF area and add the interfaces.

   Note: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

   [edit]user@R1# set protocols ospf area 0.0.0.0 interface alluser@R1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
   [edit]user@R2# set protocols ospf area 0.0.0.0 interface alluser@R2# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
   [edit]user@R3# set protocols ospf area 0.0.0.0 interface alluser@R3# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
   [edit]user@R4# set protocols ospf area 0.0.0.0 interface alluser@R4# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
3. Enable OSPF traffic engineering.
   [edit]user@R1 set protocols ospf traffic-engineering shortcuts lsp-metric-into-summary
   [edit]user@R2 set protocols ospf traffic-engineering
   [edit]user@R3 set protocols ospf traffic-engineering
   [edit]user@R4 set protocols ospf traffic-engineering
4. On Device R1, configure MPLS traffic engineering.
   [edit ]user@R1 set protocol mpls traffic-engineering bgp-igpuser@R1 set protocols mpls label-switched-path R1-to-R4 to 10.0.0.4
5. If you are done configuring the devices, commit the configuration.
   [edit]user@host# commit

Results

Confirm your configuration by entering the show routing-options, show protocols ospf, and show protocols mpls commands. 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:

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

Verification

Confirm that the configuration is working properly.

• Verifying the Traffic Engineering Capability for OSPF
• Verifying OSPF Entries in the Traffic Engineering Database
• Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF

Verifying the Traffic Engineering Capability for OSPF

Purpose

Verify that traffic engineering has been enabled for OSPF. By default, traffic engineering is disabled.

Action

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

Verifying OSPF Entries in the Traffic Engineering Database

Purpose

Verify the OSPF information in the traffic engineering database. The Protocol field displays OSPF and the area from which the information was learned.

Action

From operational mode, enter the show ted database command.

Verifying That the Traffic Engineering Database Is Learning Node Information from OSPF

Purpose

Verify that OSPF is reporting node information. The Protocol name field displays OSPF and the area from which the information was learned.

Action

From operational mode, enter the show ted protocol command.

Example: Configuring the Traffic Engineering Metric for a Specific OSPF Interface

This example shows how to configure the OSPF metric value used for traffic engineering.

• Requirements
• Overview
• Configuration
• Verification

Requirements

• Configure the device interfaces. See the Junos® OS Network Interfaces.
• Configure OSPF for traffic engineering. See Example: Enabling OSPF Traffic Engineering Support

Overview

You can configure an OSPF metric that is used exclusively for traffic engineering. To modify the default value of the traffic engineering metric, include the te-metric statement. The OSPF traffic engineering metric does not affect normal OSPF forwarding. By default, the traffic engineering metric is the same value as the OSPF metric. The range is 1 through 65,535.

In this example, you configure the OSPF traffic engineering metric on OSPF interface fe-0/1/1 in area 0.0.0.0.

Configuration

CLI Quick Configuration

To quickly configure the OSPF traffic engineering metric for a specific interface, copy the following command and paste it into the CLI.

Step-by-Step Procedure

1. Create an OSPF area.

   Note: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

   [edit]user@host# edit protocols ospf area 0.0.0.0
2. Configure the traffic engineering metric of the OSPF network segments.
   [edit protocols ospf area 0.0.0.0]user@host set interface fe-0/1/1 te-metric 10
3. If you are done configuring the device, commit the configuration.
   [edit protocols ospf area 0.0.0.0]user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. 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 protocols ospf3 command.

Verification

Confirm that the configuration is working properly.

Verifying the Configured Traffic Engineering Metric

Purpose

Verify the traffic engineering metric value. Confirm that Metric field displays the configured traffic engineering metric.

Action

From operational mode, enter the show ted database extensive command.