Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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.

    By default, traffic engineering support is disabled. To enable traffic engineering, include the traffic-engineering statement. You can also configure the following OSPF traffic engineering extensions:

    • advertise-unnumbered-interfaces—(OSPFv2 only) Advertises the link-local identifier in the link-local traffic engineering LSA packet. You do not need to include this statement if RSVP is able 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 IGP shortcuts, which allows OSPF to use an LSP as the next hop as if it were a logical interface from the ingress routing device to the egress routing device. The address specified in the to statement at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level on the ingress routing device must match the router ID of the egress routing device 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. When used in this way, LSPs are no different from Asynchronous Transfer Mode (ATM) and Frame Relay virtual circuits (VCs), except that LSPS carry only IPv4 traffic.

      OSPFv2 installs the prefix for IPv4 routes in the inet.0 routing table, and the LSPs are installed by default in the inet.3 routing table.

      OSPFv3 LSPs used for shortcuts continue to be signaled using IPv4. However, by default, shortcut IPv6 routes calculated through OSPFv3 are added to the inet6.3 routing table. The default behavior is for BGP only to use LSPs in its calculations. If you configure MPLS so that both BGP and IGPs use LSPs for forwarding traffic, IPv6 shortcut routes calculated through OSPFv3 are added to the inet6.0 routing table.

      Note: Whenever possible, use OSPF IGP shortcuts instead of traffic engineering shortcuts.

    • 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.

    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

    Before you begin:

    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 theCLI 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:

    [edit]set routing-options router-id 10.0.0.1set protocols ospf area 0.0.0.0 interface allset protocols ospf area 0.0.0.0 interface fxp0.0 disableset protocols ospf traffic-engineering shortcuts lsp-metric-into-summaryset protocols mpls traffic-engineering bgp-igpset protocols mpls label-switched-path R1-to-R4 to 10.0.0.4

    Configuration on R2:

    [edit]set routing-options router-id 10.0.0.2set protocols ospf area 0.0.0.0 interface allset protocols ospf area 0.0.0.0 interface fxp0.0 disableset protocols ospf traffic-engineering

    Configuration on R3:

    [edit]set routing-options router-id 10.0.0.3set protocols ospf area 0.0.0.0 interface allset protocols ospf area 0.0.0.0 interface fxp0.0 disableset protocols ospf traffic-engineering

    Configuration on R4:

    [edit]set routing-options router-id 10.0.0.4set protocols ospf area 0.0.0.0 interface allset protocols ospf area 0.0.0.0 interface fxp0.0 disableset protocols ospf traffic-engineering

    Step-by-Step Procedure

    To enable OSPF traffic engineering support to advertise LSP metrics in summary LSAs:

    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 protocols 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:

    user@host# show routing-options router-id 10.0.0.1;
    user@host# show protocols ospf traffic-engineering {shortcuts lsp-metric-into-summary;}area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}
    user@host# show protocols mpls traffic-engineering bgp-igp;label-switched-path R1-to-R4 {to 10.0.0.4;}

    Output for R2:

    user@host# show routing-options router-id 10.0.0.2;
    user@host# show protocols ospf traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}

    Output for R3:

    user@host# show routing-options router-id 10.0.0.3;
    user@host# show protocols ospf traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}

    Output for R4:

    user@host# show routing-options router-id 10.0.0.4;
    user@host# show protocols ospf traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}

    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

    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

    Before you begin:

    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 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.

    [edit]set protocols ospf area 0.0.0.0 interface fe-0/1/1 te-metric 10

    Step-by-Step Procedure

    To configure an OSPF traffic engineering metric for a specific interface used only for traffic engineering:

    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.

    user@host# show protocols ospf
    area 0.0.0.0 {interface fe-0/1/1.0 {te-metric 10;}}

    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.

    Modified: 2016-12-21