Enabling OSPF Traffic Engineering Support

When traffic engineering is enabled on the routing device, you can enable OSPF traffic engineering support, which allows OSPF to generate LSAs that carry traffic engineering parameters. These parameters are used to create the traffic engineering database, which is used by Constrained Shortest Path First (CSPF) to compute MPLS LSPs.

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

By default, traffic engineering support is disabled. To enable it, include the traffic-engineering statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

To disable the dissemination of the link-state topology information, include the no-topology statement. To use LSPs as next hops, specify the shortcuts statement.

When traffic engineering is enabled for OSPF, the SPF algorithm takes into account the various LSPs configured under MPLS. These routes are installed into the primary routing table, inet.0. To advertise the LSP metric for a prefix in a summary LSA, specify the lsp-metric-into-summary statement. To ignore RSVP LSP metrics in OSPF traffic engineering shortcut calculations, specify the ignore-lsp-metrics statement.

You can configure OSPF to install routes with regular IP next hops (no LSPs as next hops) into the inet.2 routing table for a reverse-path-forwarding (RPF) check. 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. To install routes for multicast RPF checks into the inet.2 routing table, include the multicast-rpf-routes statement.

Note: You must enable OSPF traffic engineering shortcuts to use the multicast-rpf-routes statement. You must not allow LSP advertisement into OSPF when configuring the multicast-rpf-routes statement.

In some scenarios, you might want to advertise the link-local identifier in the link-local TE link-state advertisement packets. To advertise unnumbered interfaces in a traffic-engineering environment, include the advertise-unnumbered-interfaces statement.

Note: The advertise-unnumbered-interfaces statement has no effect on your configuration if RSVP can signal unnumbered interfaces, as defined in RFC 3477, Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE). You do not need to configure this statement in this situation.

By default, the Junos OS prefers IS-IS routes in the traffic engineering database over other 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. For example, OSPF routes have a default preference value of 10, while IS-IS Level 1 routes have a default preference value of 15. When protocol preference is enabled, the credibility value is determined by deducting the protocol preference value from a base value of 512. Using default protocol preference values, OSPF has a credibility value of 502, while IS-IS has a credibility value of 497. Because the traffic engineering database prefers IGP routes with the highest credibility value, OSPF routes are now preferred.

This feature is also supported for IS-IS. For more information see, Configuring IS-IS Traffic Engineering Attributes.

To configure OSPF to take protocol preference into account to determine the traffic engineering database credibility value, include the credibility-protocol-preference statement:

Note: The credibility protocol-preference statement is supported only for OSPFv2.

For more information about configuring LSPs and MPLS, see the Junos MPLS Applications Configuration Guide.

Example: Enabling OSPF Traffic Engineering Support

Enable OSPF traffic engineering support by configuring a virtual link on the local router. This router must be an area border router that is physically connected to the backbone.