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.

Configuring LSPs for DiffServ-Aware Traffic Engineering

You must configure the Differentiated Services domain (see Configuring Routers for DiffServ-Aware Traffic Engineering) before you can enable DiffServ-aware traffic engineering for LSPs. The Differentiated Services domain provides the underlying class types and corresponding traffic engineering classes that you reference in the LSP configuration. The traffic engineering classes must be configured consistently on each router participating in the Differentiated Services domain for the LSP to function properly.

Note: You must configure either MAM or RDM as the bandwidth model when you configure DiffServ-aware traffic engineering for LSPs. See Configuring Routers for DiffServ-Aware Traffic Engineering.

The actual data transmitted over this Differentiated Services domain is carried by an LSP. Each LSP relies on the EXP bits of the MPLS packets to enable DiffServ-aware traffic engineering. Each LSP can carry traffic for a single class type.

All the routers participating in the LSP must be Juniper Networks routers running Junos OS Release 6.3 or later. The network can include routers from other vendors and Juniper Networks routers running earlier versions of the Junos OS. However, the DiffServ-aware traffic engineering LSP cannot traverse these routers.

Note: You cannot simultaneously configure multiclass LSPs and DiffServ-aware traffic engineering LSPs on the same router.

To enable DiffServ-aware traffic engineering for LSPs, you need to configure the following:

Configuring Class of Service for the Interfaces

The existing class-of-service (CoS) infrastructure ensures that traffic that is consistently marked receives the scheduling guarantees for its class. The classification, marking, and scheduling necessary to accomplish this are configured using the existing Junos OS CoS features.

Note: The Junos OS does not support CoS on ATM interfaces.

For information about how to configure CoS, see the Junos OS Class of Service Configuration Guide.

Configuring IGP

You can configure either IS-IS or OSPF as the IGP. The IS-IS and OSPF configurations for routers supporting LSPs are standard. For information about how to configure these protocols, see the Junos OS Routing Protocols Configuration Guide.

Configuring Traffic-Engineered LSPs

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

If you do not specify a bandwidth for a class type, ct0 is automatically specified as the queue for the LSP. You can configure only one class type for each LSP, unlike multiclass LSPs.

• ct0—Bandwidth reserved for class 0
• ct1—Bandwidth reserved for class 1
• ct2—Bandwidth reserved for class 2
• ct3—Bandwidth reserved for class 3

• The combination of class and priority must be one of the configured traffic engineering classes. The default setup priority is 7 and the default holding priority is 0.
• Configuring an invalid combination of class type and priority causes the commit operation to fail.
• Automatic bandwidth allocation is not supported. If you configure automatic bandwidth allocation, the commit operation fails.
• LSPs configured with the bandwidth statement but without specifying a class type use the default class type ct0.
• For migration issues, see Internet draft draft-ietf-tewg-diff-te-proto-07.txt.

Configuring Policing for LSPs

Policing allows you to control the amount of traffic forwarded through a particular LSP. Policing helps to ensure that the amount of traffic forwarded through an LSP never exceeds the requested bandwidth allocation. You can configure multiple policers for each LSP.

For information about how to configure a policer for an LSP, see Configuring MPLS Firewall Filters and Policers.

Configuring Fast Reroute for Traffic-Engineered LSPs

You can configure fast reroute for traffic engineered LSPs (LSPs carrying a single class of traffic). It is also possible to reserve bandwidth on the detour path for the class of traffic when fast reroute is enabled. The same class type number is used for both the traffic engineered LSP and its detour.

If you configure the router to reserve bandwidth for the detour path, a check is made to ensure that the link is capable of handling DiffServ-aware traffic engineering and for CoS capability before accepting it as a potential detour path. Unsupported links are not used.

You can configure the amount of bandwidth to reserve for detours using either the bandwidth statement or the bandwidth-percent statement. You can only configure one these statements at a time. If you do not configure either the bandwidth statement or the bandwidth-percent statement, the default setting is to not reserve bandwidth for the detour path (the bandwidth guarantee will be lost if traffic is switched to the detour).

When you configure the bandwidth statement, you can specify the specific amount of bandwidth (in bits per second [bps]) you want to reserve for the detour path. For information, see Configuring Fast Reroute.

The bandwidth-percent statement allows you to specify the bandwidth of the detour path as a percentage of the bandwidth configured for the protected path. For example, if you configure 100 millions bps of bandwidth for the protected path and configure 20 for the bandwidth-percent statement, the detour path will have 20 million bps of bandwidth reserved for its use.

• [edit protocols mpls label-switched-path lsp-name fast-reroute]
• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name fast-reroute]