Configuring Traffic Engineering

This section details the setup and configuration of MPLS tunnels for traffic engineering on the Avici router. Traffic engineering has become an important issue within network service providers, because existing internal gateway protocols (IGPs) can only route traffic based on a limited number of constraints such as shortest path or lower cost. Traffic engineering provides new criteria for making routing decisions, providing the means to more efficiently and dynamically utilize the capacity made available by a given network topology.

Traffic engineering can significantly enhance the operation and performance of the network by providing efficient use of available aggregate bandwidth. This is achieved by utilizing traffic engineering's capability to create label switched paths in the network, such that subsets of the network do not become overutilized, while other subsets of the network along potential alternate paths are underutilized.

A router which supports MPLS is referred to as a label switched router (LSR). A path through a set of label switched routers is referred to as a label switched path (LSP). The ingress label switched router computes the path for a given label switched path. The egress router is the point of output from the label switched path. The midpoint routers are any routers in the path between the ingress and the egress.

To permit the computation of a label switched path, information about bandwidth reservations is flooded through IGP protocols. You refer to this information as the link state database (TE-LSDB). The link state database permits the ingress Avici router of a label switched path to compute an appropriate path, based on bandwidth and policy constraints. Traffic engineering is designed to compute and setup paths in a distributed manner. Using IGP and RSVP protocols, extensions to the RSVP protocol are used to signal paths.

For a given label switched path, an ingress label switched router determines and signals the path. Zero or more midpoint label switched routers set up labels used to switch traffic and pass the setup signaling toward the egress label switched router. The egress label switched router sets up state to remove the MPLS label on traffic forwarded on the label switched path. The ingress router, while setting up the label switched path, will get the label value from the egress router, using the RSVP signaling protocol. When a label switched path has been setup, the ingress begins forwarding traffic into the label switched path by pushing a label onto the front of the packet. The midpoints will swap labels and forward the packet. The egress router pops the label and forwards the packet using that routers internet gateway address.

The Avici traffic engineering component allows the Avici router to operate as an ingress label switched router, a midpoint label switched router, and an egress label switched router.

Traffic Engineering Command Line Modes

Command line interface (CLI) commands provide the means for traffic engineering setup, configuration, and the display of system information and statistics. You must be in the appropriate command mode to enter a command.

Should you need an introduction or brush up on the IPriori CLI modes, see the IPriori Software Configuration Guide that accompanied this release for general CLI mode information.

The following is a brief commented example of how you move from one mode to another for those modes relevant to traffic engineering:

After you log on to the router start out in executive mode. The prompt display as follows:

router>

Example 1: You access router configuration mode from the privileged mode. The following example gets you to configuration mode from executive mode:

router>enable password: avici router#configure terminal router(config)#

Example 2: The following example places you in interface mode for the pos interface 1/1/1, returns you to privileged mode and then places you in traffic engineering configuration mode for IS-IS:

router>enable router#configure terminal router(config)#interface pos 1/1/1 router(config-if)#end router#configure router(config)#mpls traffic-engineering isis router(config-te)#

What follows is a brief overview of the four categories of command modes you will use to configure traffic engineering followed by a discussion of the four modes specific to traffic engineering mode.

There are four general categories of commands discussed in this document:

Global	The effect of the command applies to the entire Avici router. Affected command modes are: configuration, mpls te, and Router ISIS and OSPF.
Interface	The effect of the command applies to a specific interface. All commands are in interface mode.
RSVP	Command relates to configuration of RSVP. All commands are in configuration mode
Traffic Engineering	Command relates to the creation, modification or deletion of a MPLS tunnel. Commands are in mpls te or one of its three sub modes: path-list, parameter-set, or tunnel-name.

There are four CLI command modes that directly relate to traffic engineering. The mpls te mode is a high level mode that allows entry into three traffic engineering submodes: path-list, tunnel-name, and tunnel parameter-set. Together they provide for the creation, configuration, modification or deletion of traffic engineering tunnels and associated attributes.

Many traffic engineering commands can be entered in multiple modes. For example, commands used to configure tunnel parameters can be entered in either traffic engineering tunnel name or parameter set command modes. In parameter set mode the entered command configures a parameter of the named parameter set when you entered the mode. In tunnel name mode, the configured parameter is assigned to the tunnel named when you entered the mode.

In most cases, from the submode you are currently in, you can reenter a submode to configure a different tunnel, path list, or parameter set or enter one or more of the other submodes. Reentering the same submode, or entering a new one, automatically saves the configuration changes for the submode you are exiting.

Example 3: For example, the following set of commands enters the tunnel-name command mode and changes the bandwidth of the BosChi tunnel to 500 mega-bits per second, and then reenters the tunnel-name command mode and changes the bandwidth of the BosLa tunnel to 700 mega-bits per second. Because you can enter the tunnel parameter-set mode from tunnel-name mode, this example then enters the tunnel parameter-set mode and modifies the bandwidth for the GovFundedResearch parameter set to OC12. The example then exits:

router>enable router#configure terminal router(config)#mpls traffic-engineering isis router(config-te)#tunnel BosChi router(config-te-tunnel)#bandwidth 500m router(config-te-tunnel)#tunnel BosLa router(config-te-tunnel)#bandwidth 700m router(config-te-tunnel)#tunnel parameter-set GovFundedReserach router(config-te-tunnel-param)#bandwidth oc12 router(config-te-tunnel-param)#exit router(config-te)#

Refer to Figure 1-1 for a presentation of the traffic engineering CLI hierarchy.

You can exit any submode to the traffic engineering mode with changes saved using the exit command. Prior to exiting a mode, you can only cancel entered commands in traffic engineering path list and tunnel name modes. Cancel path list and tunnel name configuration changes using the cancel command. In the other submodes you must reconfigure options that were incorrectly entered. IPriori automatically saves submode modifications after sixty seconds of idle keyboard time.

Traffic engineering Commands that are interface specific form a subset of the interface configuration commands.

Figure 1-1 shows a graphic presentation of the traffic engineering portion of the Avici router command line interface. The command modes affected by traffic engineering are mpls te, leading to path-list, tunnel-name and tunnel parameter-set, as well as interface and router configuration.

Figure 1-1. Navigating Through the Avici router Command Line Interface

Understanding Tunnel Parameter Precedence

Because tunnel options can be explicitly set, set in a named parameter set, set in a default parameter set, and exist as a factory default, the following rules are used to determine which of these possible simultaneous settings has precedence.

For all parameters and any given tunnel:

1. If you explicitly configure a parameter in a tunnel command, that parameter value overrides everything else. The tunnel command is described in "Using Tunnel Name Mode".
   
   
2. If you don't explicitly configure a parameter in a tunnel command, but you do explicitly configure a parameter in a parameter-set command, for a set that is referenced by the tunnel, that parameter value overrides everything else. The parameter-set command is described in "Using Tunnel Parameter Set Mode".
   
   
3. If you don't explicitly configure a parameter in either the tunnel or a parameter-set command specified in the tunnel, but you do configure the parameter in the tunnel default parameter-set, then the tunnel defaults parameter value is used. The tunnel defaults command is described in "Setting Tunnel Defaults".
   
   
4. If none of the above applies for a given parameter, the factory default option value is used.
   
   

When a tunnel parameter-set or tunnel default is changed, traffic engineering updates all affected tunnels. This can force tunnels to be rerouted.

Tunnel Parameter Precedence Example

What follows is a configuration example that steps you through these four levels of tunnel precedence. The tunnel is a Washington, D. C. to San Francisco label switched path named DCtoSF. This is a new configuration. There are no tunnel defaults configured prior to the example, therefore any parameter not specifically configured has a value of factory default. The following steps are required for this example:

1. Configure several tunnel defaults that override the factory defaults.
   
   
2. Configure a tunnel parameter-set named hiPri.
   
   
3. Assign the hiPri parameter-set to the DCtoSF tunnel. Once assigned to the tunnel, the parameter values configured in the hiPri parameter-set override both the factory default and configured tunnel default parameter values.
   
   
4. Configure several values directly to the DCtoSF tunnel in tunnel name mode. These directly assigned parameter values override any parameter values configured in the hiPri parameter-set, tunnel defaults, or factory defaults.
   
   

Note that even though the following example user input sections are separated by headers and explanation, all command lines should be entered in as though there were no delineating material separating them, until you are told that the example is complete.

Configuring Example Tunnel defaults

Example: We are going to configure three tunnel default parameters for this example:

• A tunnel metric of 1
  
  
• A holding priority of 4
  
  
• And a reserving priority of 4.
  
  

router>enable router#configure terminal router(config)#mpls traffic-engineering isis router(config-te)#tunnel default router(config-te-tunnel-param)#metric absolute 1 router(config-te-tunnel-param)#holding-priority 4 router(config-te-tunnel-param)#reserving-priority 4 router(config-te-tunnel-param)#exit router(config-te)#

The three values we configured here will override the factory defaults for any tunnel created with this router as ingress. The metric value will not be overriden by either the hiPri parameter set or directly in tunnel name mode for the DCtoSF tunnel. The metric value configured for tunnel defaults is the highest level of precedence and therefore used by this tunnel.

The holding-priority and reserving-priority will be overriden when we configure the hiPri parameter-set and therefore will not be used by this tunnel. Should these two parameters be either deleted from the hiPri parameter-set or the parameter-set is removed from the tunnel, the tunnel defaults configured here for holding-priority and reserving-priority would become the highest level of precedence and therefore used by the DCtoSF tunnel.

Configuring Example Parameter-set hiPri

We are now going to create a parameter set named hiPri and assign the following parameters to it:

• A holding priority of 2
  
  
• A reserving priority 2
  
  
• A bandwidth of 10g
  
  

router(config-te)#tunnel parameter-set hiPri router(config-te-tunnel-param)#holding-priority 2 router(config-te-tunnel-param)#reserving-priority 2 router(config-te-tunnel-param)#bandwidth 10g router(config-te-tunnel-param)#

This parameter set will be assigned to the DCtoSF tunnel. Once that is done, the parameter-set holding-priority and reserving-priority override the values set in tunnel defaults. The bandwidth value configured for this parameter set overrides the factory default value (no value has been configured for tunnel defaults). When we configure the tunnel, a new bandwidth parameter will be configured in tunnel name mode. The bandwidth value configured in tunnel name mode overrides both the hiPri parameter set value and the factory default for the DCtoSF tunnel.

Configuring Example Tunnel DCtoSF

We are now going to create the DCtoSF tunnel and assign the following parameters to it:

• An egress address of 10.5.6.7
  
  
• A bandwidth of 160g
  
  
• The parameter-set hiPri
  
  

The egress command will inform traffic engineering to construct a tunnel from the ingress to the specified egress with however many mid-point routers the restraint based calculation requires. There are no precedence ramifications for this command.

router(config-te)#tunnel oc48BosToChi router(config-te-tunnel)# egress 10.5.6.7 router(config-te-tunnel)# bandwidth 160g router(config-te-tunnel)# parameter-set hiPri router(config-te-tunnel)# exit router(config-te)#

The bandwidth configured here overrides both the parameter-set and factory default bandwidth values. Refer to "Configuring Example Parameter-set hiPri" for parameter-set hiPri related precedence information.

Example Conclusion

With the tunnel configured the following parameter values are in affect based upon tunnel parameter precedence:

• The bandwidth of 160g configured in tunnel name mode overrides both the hiPri parameter-set and factory default bandwidth values.
  
  
• The holding priority and reserving priority configured for the hiPri parameter set and associated with the tunnel, override the parameter values configured in tunnel defaults as well as the factory defaults.
  
  
• The tunnel metric value configured in tunnel defaults overrides the factory default for this parameter.
  
  
• All other parameters associated with the DCtoSF tunnel are the factory default values.
  
  

The tunnel parameter precedence example is complete.

Understanding Interface Parameter Precedence

A few parameters such as maximum reservable bandwidth, MPLS reflood timers, and administrative color can be configured both globally and per interface. In these cases, global values apply if you do not explicitly assign the value to an interface; explicitly assigning the value to an interface overrides global configuration. Global defaults, factory or configured, apply if neither global nor interface values are explicitly assigned.

For interface parameters:

1. If you explicitly specify a parameter within the interface command mode, that parameter value overrides everything else. Interface parameters that can be configured as global defaults are described in "Configuring Traffic Engineering Interface Parameters". Parameters only configurable on a per interface basis are described in "Setting Traffic Engineering Parameters Per Interface".
   
   
2. If you do not explicitly specify a parameter within the interface command mode, and it both can be specified and you do specify it as a global default, that parameter value overrides the factory default. Interface parameters that can be configured as global defaults are described in "Configuring Traffic Engineering Interface Parameters".
   
   
3. If you neither explicitly specify an interface parameter within the interface command mode, nor configure an interface global default, the factory default value for that parameter is used.
   
   

Interface Parameter Precedence Example

What follows is an interface configuration that:

• Configures two global interface default parameters: default maximum reservable bandwidth and MPLS reflood timer. The global MPLS reflood timer will be overriden at the interface command mode.
  
  
• Explicitly configures two interface parameters: maximum reservable bandwidth and the traffic engineering interface metric for this interface.
  
  
• All other interface parameter values remain at factory default for this interface.
  
  

Example: Note that even though the following example user input sections are separated by headers and explanation, all command lines should be entered in as though there were no delineating material separating them, until you are told that the example is complete.

Configuring Example Global Interface Defaults

For this router, we are going to configure two global interface defaults as follows:

• Default maximum reservable bandwidth of 250%.
  
  
• MPLS reflood timer linear of 90% 3s 60% 25s 30% 150s jitter 15%
  
  

router>enable router#configure terminal router(config)#mpls traffic-engineering isis router(config-te)#default-max-reservable-bandwidth 250% router(config-te)#mpls-reflood-timer linear 90% 3s 60% 25s 30% 150s jitter 15% router(config-te)#exit router(config)#

Of the two values configured here, only the default maximum reservable bandwidth will apply to this interface. The MPLS reflood timer value will be overridden at the interface level.

Configuring Example Interface Specific Parameters

For the OC48 interface POS 1/1/1, we are going to override one of the configured global interface defaults and configure an interface specific parameter as follows:

• MPLS reflood timer linear of 90% 1s 60% 20s 30% 100s jitter 20%
  
  
• Set the metric parameter used to calculate the cost of this interface at tunnel creation time to 20
  
  

router(config)#interface pos 1/1/1 router(config-if)#mpls-reflood-timer linear 90% 1s 60% 20s 30% 100s jitter 20% router(config-if)#mpls te metric 20 router(config-if)#end

As stated above, the MPLS reflood timer configured here overrides the global configuration for this parameter. The MPLS TE Metric value configured here overrides the factory default for this parameter.

Example Conclusion

With the interface configured the following parameter values are in affect based upon interface parameter precedence:

• The maximum reservable bandwidth is set to the global default of 250%.
  
  
• The MPLS reflood timer is set to the interface specific configuration of 90% 1s 60% 20s 30% 100s jitter 20%.
  
  
• The interface metric used at tunnel creation time is set to the interface specific value of 20.
  
  
• All other parameters are set to factory default for this interface.
  
  

The interface parameter precedence example is complete.

Using Traffic Engineering Configuration Mode

Traffic engineering configuration mode is accessed from the configuration mode. You configure the default maximum reservable bandwidth and gain access to the three traffic engineering submodes in traffic engineering mode. The three traffic engineering submodes are tunnel name, path list, and parameter set.

Access the traffic engineering tunnel name submode from traffic engineering configuration mode to create and name a tunnel, as well as associate path configuration and parameter set values with that tunnel. Refer to section "Using Tunnel Name Mode" for further information concerning this submode.

Access the traffic engineering path list submode from traffic engineering configuration mode to create, name, and assign hops to a path list. Refer to section "Using Tunnel Path List Mode" for further information concerning this submode. Path lists are assigned to a tunnel in the tunnel name submode.

Access the traffic engineering parameter set submode from traffic engineering configuration mode to create and name a parameter set, configure parameter set values, and configure tunnel default values. Refer to section "Using Tunnel Parameter Set Mode" for further information concerning this submode. Configured parameter sets are assigned to a tunnel in the tunnel name submode.

To access traffic engineering mode use the mpls te command in configuration mode. You must specify the IGP used by this router. Traffic engineering is supported for an IS-IS router or an OSPF router. The IGP you choose determines the source for the generation of the TE-LSDB. You can not use both IS-IS and OSPF for creating the TE-LSDB. Refer to sections "Enabling Traffic Engineering on an IS-IS Router" and "Enabling Traffic Engineering on an OSPF Router" for further information about this command.

Besides enabling traffic engineering for the appropriate internal gateway protocol in configuration mode, you must also enable MPLS for each interface you wish to enable for traffic engineering functionality. Refer to section "Enabling MPLS on an Interface" for further information.

Enabling Traffic Engineering on an IS-IS Router

The mpls traffic-engineering isis command in configuration mode enables and disables traffic engineering and specifies IS-IS as the IGP traffic engineering will use to generate the TE-LSDB for the computation of MPLS-TE tunnel paths. Enabling traffic engineering causes IS-IS to flood traffic engineering extensions to this router's IS-IS neighbors.

You must be in configuration mode to use the mpls traffic-engineering isis command. The command is disabled by default.

On an IS-IS router, you must further configure the router for level. Level determines which IS-IS level to flood traffic engineering extensions on. A level 1 router handles traffic within an area; use the level-1 keyword to configure the level for this IS-IS router type. A level 2 router handles traffic between areas; use the level-2 keyword for this IS-IS router type. Level defaults to level-1.

Example: The following example enables traffic engineering for an IS-IS level 2 router:

router>enable router#configure terminal router(config)#mpls traffic-engineering isis level-2 router(config-te)#end router#show mpls traffic-engineering Traffic engineering is enabled IGP: isis Administrative color(s): Default administrative color(s): Default maximum reservable bandwidth: 100

NOTE Be sure to enable traffic engineering on the appropriate interfaces using the mpls te tunnel command in interface command mode.

Enabling Traffic Engineering on an OSPF Router

The mpls traffic-engineering ospf command in configuration mode enables and disables traffic engineering and specifies OSPF as the IGP traffic engineering will use to generate the TE-LSDB for the computation of MPLS-TE tunnel paths. Enabling traffic engineering causes OSPF to flood traffic engineering extensions to this router's OSPF neighbors.

You must be in configuration mode to use the mpls traffic-engineering ospf command. The command is disabled by default.

Example: The following example enables traffic engineering for OSPF:

router>enable router#configure terminal router(config)#mpls traffic-engineering ospf router(config-te)#end router#show mpls traffic-engineering Traffic engineering is enabled IGP: ospf Administrative color(s): Default administrative color(s): Default maximum reservable bandwidth: 100

NOTE Be sure to enable traffic engineering on the appropriate interfaces using the mpls te tunnel command in interface command mode.

Configuring a Avici router Containing non-MPLS Capable Modules

The default configuration assumes that all the modules loaded in the Avici router support MPLS. IPriori performs the MPLS label and IP header examination and forwarding decision on the incoming interface. An Avici router MPLS tunnel egress node must remove the label from the packet before forwarding it as a standard IP packet. An Avici router containing a single non-MPLS capable module will not perform this critical task when that module contains the outbound interface for a packet received over an MPLS tunnel.

An egress-capable Avici router contains only MPLS capable modules. A non-egress-capable Avici router contains one or more non-MPLS capable modules. You use the mpls egress-capable command in configuration mode to enable an egress-capable Avici router. IPriori enables the egress-capable function by default. If you have a non-egress-capable Avici router, use the no mpls egress-capable command in configuration mode to disable the egress-capable function for this Avici router.

When you disable the egress-capable function on a Avici router, IPriori requests a mechanism called pentultimate hop popping (PHP) from its neighbors. The penultimate hop of an MPLS tunnel removes the label of tunnel packets and sends them on to the tunnel egress as standard IP packets. This action relieves the egress of any responsibility for removing the label from the packet and the packet continues to act as a standard IP packet. Penultimate hop popping allows MPLS and non-MPLS capable modules to coexist in a single Avici router. The primary drawback to penultimate hop popping is the inability to gather tunnel statistics for any tunnel terminating at a non-egress-capable Avici router.

When enabling traffic engineering on a Avici router, IPriori checks whether there are any non-MPLS capable modules installed and automatically changes the system configuration to no mpls egress-capable if that is the case.

Configuring Traffic Engineering Interface Parameters

Once you have enabled traffic engineering for this Avici router, set the parameters that are global to the Avici router. These global interface parameters are configured in configuration mode. The values apply to all interfaces for the configured parameter. The following configuration traffic engineering parameter types are detailed in this section:

• Administrative color bit-position mapping, default color, and color list creation
  
  
• Maximum reservable bandwidth default
  
  
• Reflood timers
  
  
• Metric style for IS-IS routers
  
  

Using Administrative-color

Administrative-colors provide for the grouping of interfaces by common resource classes for inclusion or exclusion from consideration at tunnel path computation time. In the context of administrative colors, a resource class is any logical defining of interfaces for the purpose of inclusion or exclusion from a tunnel. Organizational type, delivery priority, link bandwidth, and geographical location are examples of common resource classes.

There are three aspects to administrative color usage. Administrative colors are: defined, associated with an interface, and assigned to a tunnel parameter-set or directly to a tunnel for inclusion or exclusion policy.

You define an administrative color by giving it a name and assigning it to one of 32 bit positions. You will associate this administrative color with an interface, so the name you give it should in some way identify an aspect of an organization, a physical or logical network, priority, or data type that you wish to associate with one or more of the interfaces in your network. You define an administrative color using the administrative-color command in configuration mode. See "Defining an Administrative Color" for further information.

Next you assign the defined administrative colors to the interfaces you wish to associate with the colors. For instance, if the color name is state_government you will want to assign the name to interfaces that will carry state government related data. If you wanted to further discriminate between regions of the country, you could first define and then assign regional names such as north_east and mid_west to relevant interfaces. You could further discriminate between interfaces by assigning high_priority and low_priority color names to interfaces you wish to associate with those priority levels. You associate an administrative-color with an interface using the mpls te administrative-color command in interface configuration mode. See "Associating an Administrative Color with an Interface" for further information.

You can group administrative colors into lists for ease of use. These list names can be used in place of administrative color names in any non-interface specific command that calls for the specifying of administrative colors. In the case where a command is specific to a single interface or in the case of initially defining a color and associating it with a bit position, administrative color lists are not allowed. See "Defining an Administrative Color List" for further information.

Figure 1-2 shows a simple network of six routers labeled Ra - Rf. Darkened circles attached to each router represent interfaces. Traffic engineering created two tunnels: one named brokenline, the other named solidline. The following procedure steps you through the assigning of administrative colors to these two tunnels:

1. There are four administrative colors used in the figure: green (G), blue (B), red (R), and orange (O). You must create the colors and assign them the bit positions before they can be assigned to an interface that will be part of a tunnel. Create the colors and assign them to bit positions using the administrative-color command in configuration mode.
   
   
2. Once created, you must assign them to the appropriate interfaces using the mpls te administrative-color command in interface configuration mode.
   
   
3. Next you must assign the appropriate colors to unique parameter sets that will be associated with the tunnels. For each parameter set you must first be in the tunnel parameter-set mode. You do this using the tunnel parameter-set command in the mpls traffic-engineering command mode. You are now in the tunnel parameter-set command mode for the parameter-set you specified with the tunnel parameter-set command. Include the appropriate colors for this parameter set using the include-administrative-color command. Use the exit command to return to the mpls traffic-engineering command mode. Repeat the step for the second parameter set.
   
   
4. Next you must assign the appropriate tunnel parameter values to the two tunnels used in our example. You can specify parameters directly or assign a parameter set to the tunnels. In this example we assign parameter sets to the two tunnels used in our example: brokenline and solidline. From the mpls traffic-engineering command mode enter the tunnel-name command mode for the brokenline tunnel by entering the command tunnel brokenline where brokenline is the name of the tunnel. Assign the parameter set containing the colors green and blue to the brokenline tunnel using the parameter-set command. Return to the mpls traffic-engineering command mode using the exit command. Now repeat the process for the solidline tunnel by entering the tunnel solidline command to enter the tunnel-name command mode for the tunnel solidline and assign the parameter set containing the colors red and orange to the solidline tunnel using the parameter-set command. Save the changes and exit the mode using the exit command.
   
   

Figure 1-2. Tunnel creation with administrative colors

Defining an Administrative Color

You define an administrative color by specifying the color name and associating it with one of 32 bits using the administrative-color command in configuration mode. Each definition has its own command line. You can assign as many colors to a single bit as you wish, but any given color can only be assigned to one bit. The name must begin with an alpha character and can be up to 128 alpha-numeric characters including underlines and hyphens. The bit-position has a value of 0 - 31. Names are arbitrary strings. A name can be used to represent such entities or concepts as organization type, link type, delivery priority, geographical region etc.

You can delete a single color using the no option. You must enter a command line for each color you wish to delete, specifying only the color name.

Example: The following example assigns administrative color names oc48_northEast, oc48_midWest, high_priority, and stateGovernment to unique bit positions:

router>enable router#configure terminal router(config)#administrative-color oc48_northEast 3 router(config)#administrative-color oc48_midWest 4 router(config)#administrative-color highPriority 5 router(config)#administrative-color stateGovernment 6 router(config)#end

The above commands assure that only those interfaces you associated with the color names oc48_nortEast, oc48_midWest, high_priority, and stateGovernment will be available to a tunnel that includes these administrative color names in its parameter-set. It also assures that interfaces with these names will not be available to a tunnel if these names are excluded from the tunnel parameter-set.

Assigning Configuration Default Administrative Colors

Use the default-administrative-color color-name command to define the default administrative color(s). This default color(s) is applied to an interface if no administrative color is explicitly defined for that interface using the administrative-color command in interface configuration mode. You can specify as many default colors as will fit on a single command line.

You can delete the current definition of the default administrative color using the no option without specifying a color name(s); The no option deletes the entire default colors definition. If you delete a configured set of default administrative colors, factory defaults of include all and exclude none are used if include and exclude administrative colors are not explicitly configured or included in a parameter set at tunnel configuration time.

Example: The following example sets the administrative color defaults to green, red, orange and blue:

router>enable router#configure terminal router(config)#default-administrative-color green red orange blue router (config)# end

Defining an Administrative Color List

Administrative color lists are a short hand method for grouping administrative colors for including in or excluding from constraint based routing computation. Colors assigned to a list must already have been defined using the administrative-color command in configuration mode. You can not use the color list for interface context only tunnel commands. The administrative-color-list command, in the configuration command mode, enables you to assemble administrative colors into useful groups. For example, you may want to group together all colors relating to OC48 links in the northeast and refer to them with a single list name instead of identifying the colors individually.

There is no limit to the number of administrative-color-lists you can create. An administrative color can be a member of multiple administrative-color-lists.

Example 1: The following example defines a list oc48north_east and applies the administrative colors green, orange, and blue to it:

router>enable router#configure terminal router(config)#administrative-color-list oc48north_east green orange blue

Referring back to Figure 1-2, instead of listing the colors individually when assigning them to a tunnel's parameter-set, you could create one color list that includes the colors green and blue and another color list that includes the colors red and orange and assign the color list name to the appropriate tunnel's parameter-set or tunnel name.

You can delete administrative color-lists, one list at a time, using the no option and specifying the list you wish to delete. The entire list is deleted. This command only deletes the list; the individual colors remain unchanged.

Example 2: The following example deletes the oc48north_east color list:

router>enable router#configure terminal router(config)#no administrative-color-list oc48north_east

Setting the Default Maximum Reservable Bandwidth

The maximum reservable bandwidth specifies the percentage of the total available bandwidth that can be reserved for an interface.

To protect unreserved traffic, the maximum reservable bandwidth can be set lower than the value defined by the mpls te max-link-bandwidth interface command. Conversely, bandwidth can be set higher than the value set by the mpls te max-link-bandwidth command to permit multiplexing of traffic through multiple label switched paths or give label switched paths better setup by overallocating. Such adjustments are made in maximum reservable bandwidth, not maximum link bandwidth. Maximum link bandwidth adjustment is reserved for the administrative change of nominal bandwidth as in the case of ethernet, where bandwidth is shared. In practice, most links will be overallocated with a maximum reservable bandwidth of 4 times the actual bandwidth of the link. Overallocation permits the link to be reserved by more label switched paths, with the caveat that not all label switched paths can be active at the same time, without seriously degrading performance.

Figure 1-3 shows two OC48 and two OC12 tunnels converging on a single OC48 interface with its maximum reservable bandwidth set to 250 percent. The tunnels continue by splitting off to different interfaces.

Figure 1-3. Over allocation of an interface bandwidth

Use the default-max-reservable-bandwidth command in traffic engineering mode to set the maximum reservable bandwidth when this value is not explicitly configured for the interface.

The command defaults to 100 percent and must be used in traffic engineering configuration mode.

Use the no option with this command to reset the value to the default of 100 percent.

Example: The following command line sets the default maximum reservable bandwidth to 400%:

router>enable router#configure terminal router(config)#mpls traffic-engineering isis router(config-te)#default-max-reservable-bandwidth 400%

Configuring MPLS Reflood Timers Per Router

Limits must be placed on how often traffic engineering link state database readvertisments should be flooded to prevent router overloading and network instability. Readvertisements occur when there is a change in a links reservation bandwidth, configured bandwidth or administrative color. IPriori provides three methods for configuring MPLS reflood timers: immediate, paced, and piecewise linear. MPLS reflood timers can be set globally in configuration mode, but can also be set per interface in interface configuration mode. MPLS reflood timers default to the piecewise linear setting.

The no mpls-reflood-timer command removes any user defined reflood timer value, restoring the piecewise linear method factory default.

The immediate method refloods MPLS link state database advertisements without any delay. This is generally viewed as a less than ideal approach, because reflooding takes place when the first of a series of label switched paths makes its reservation. The remaining label switched paths are not reflected in IGP advertisements until the IGP readvertisement timer expires, which is typically a few seconds in length. The reflood immediate method can be satisfactory for some small networks and for a network under test; its usage is otherwise discouraged.

Example 1: The following command line sets the MPLS reflood timer method to immediate for this router:

router>enable router#configure terminal router(config)#mpls-reflood-timer immediate

The paced method refloods MPLS link state database advertisements at a set pacing interval without any regard for the current link bandwidth reservation. This method provides a set interval and an associated jitter value. Jitter is added to the interval value. This method provides some protection against synchronization that causes traffic distribution to contain peaks that can overload an individual system or link. The jitter value defaults to 20 percent of the specified set interval; i.e. if the specified interval is 5 seconds and the jitter is the default of 20 percent, the actual timing of the readvertisement will be somewhere between 5 and 6 seconds.

Example 2: The following command line sets the MPLS reflood timer method to paced with a pacing interval of 5 seconds and a default jitter of 20% of the pacing interval for this router:

router>enable router#configure terminal router(config)#mpls-reflood-timer pacing 5s

The piecewise linear method provides for the associating of a bandwidth reservation value with the interval setting and jitter. There is an inverse relationship between the amount of link bandwidth reservation and the desirable reflood interval; the larger the bandwidth reservation, the more critical it is that other interfaces be informed of the change.

The piecewise linear method requires at least two bandwidth reservation and reflood interval sets be configured. The first set starts with the largest bandwidth reservation and lowest reflood interval. With each additional set, the bandwidth reservation value decreases and the reflood interval value increases.

Bandwidth reservation is expressed as a percentage. If the bandwidth reservation for a link is overallocated, the piecewise linear method bandwidth reservation value represents a percentage of that overallocation. For instance, if the bandwidth reservation of a 10 gigabit link is set to 200 percent, the maximum reservable bandwidth is 20 gigabits. If the piecewise linear bandwidth reservation value is set to 90 percent, that value represents 18 gigabits of the actual 20 gigabits of link bandwidth reservation.

The bandwidth value always descends while the interval value always ascends for each additional bandwidth and interval combination.

Example 3: The following command line sets the MPLS reflood timer method to piecewise linear, sets three linear value sets and a jitter value of 30 percent for this router:

router>enable router#configure terminal router(config)#mpls-reflood-timer linear 90% 4s 60% 30s 30% 200s jitter 30%

Refer to section "Configuring MPLS Reflood Timers Per Interface" for information concerning configuring reflood timers for an interface.

Configuring a Preference for MPLS Routes at Tunnel Egress

As an MPLS-TE Ingress LER, by default IPriori will always forward packets over an MPLS Tunnel for prefixes reachable via the Egress of the tunnel, even if a lower cost IGP path exists to reach the prefixes. The no tunnel-preference command adds the ability to disable that behavior, and instead decide whether to use the MPLS-TE Tunnel or the IGP path based on their cost. If an IGP route's lowest cost is via an attached MPLS-TE tunnel and all links along the way are TE enabled, IPriori converts the route to MPLS.

Use the no tunnel-preference command to disable the default behavior of preferring the tunnel at this ingress node, and instead use the MPLS vs. IGP cost as the basis for the decision.

Use the tunnel-preference command at the ingress, in global TE configuration mode, to force the ingress router to use the MPLS tunnel for prefixes on the egress, regardless of IGP costs.

Example 1: The following example places you in global TE mode for IS-IS and enables tunnel preference:

router>enable router#configure terminal router(config)#mpls traffic-engineering isis router(config-te)#tunnel-preference router(config-te)#end router#

Example 2: The following example places you in global TE mode for IS-IS and disables tunnel preference:

router>enable router#configure terminal router(config)#mpls traffic-engineering isis router(config-te)#no tunnel-preference router(config-te)#end router#

Setting Traffic Engineering Parameters Per Interface

This section describes traffic engineering functionality that you configure for each interface. The following interface related traffic engineering functionality is detailed:

• Enabling MPLS on an interface
  
  
• Associating an administrative color with an interface
  
  
• Setting maximum link bandwidth
  
  
• Setting maximum reservable bandwidth
  
  
• Setting the default metric used during the creation of an MPLS tunnel
  
  

Enabling MPLS on an Interface

MPLS-CP is a control protocol of PPP which enables use of MPLS on an interface on which MPLS is intended to be used. It must be enabled on each interface for MPLS to function properly. You enable MPLS-CP using the mpls te tunnels command in interface configuration mode.

To disable MPLS on an interface use the no option with this command.

Associating an Administrative Color with an Interface

Administrative colors provide the user with a means of assigning meaningful resource class related labels to an interface. A color might be assigned for the type of organization, subgroups within that organization, link value, priority, and the geographical region the link is associated with. When traffic engineering attempts to establish a label switched path, one of the criteria it takes into consideration is whether a given administrative color can be included or excluded from the tunnel. By associating an administrative color with an interface you are informing traffic engineering that any tunnel that includes the assigned administrative color in its parameter-set or tunnel name can use this interface. If a tunnel specifically excludes an administrative color, interfaces associated with that administrative color will be excluded when computing traffic engineering path for that tunnel.

Use the administrative-color command, in interface configuration mode, to specify administrative colors for this interface. You can specify as many names as can fit on a single command line. You can not use an administrative color list in place of a color name. Color-names specify the name of the administrative color; they must begin with an alpha character and can be up to 128 alpha-numeric characters including underlines and hyphens.

You can delete all defined administrative colors for the interface using the no option.

By default, no administrative colors are enabled for the interface.

Example 1: The following example applies the colors green, orange, and blue to the pos 1/1/1 interface:

router(config)#interface pos 1/1/1 router(config-if)#mpls te administrative-color green orange blue router(config-if)#end

Example 2: The following command deletes all administrative colors currently configured for the pos 1/1/1 interface:

router(config)#interface pos 1/1/1 router(config-if)#no mpls te administrative-color router(config-if)#end

Setting Bandwidth

There are two types of bandwidth settings:

Maximum Link	The maximum usable bandwidth for this link.
Maximum Reservable	The portion of the total bandwidth that can be reserved by this interface.

Setting Maximum Link Bandwidth

Use the mpls te max-link-bandwidth command to specify the maximum bandwidth of the physical link. If no maximum bandwidth value for the link is explicitly specified, the inherent bandwidth of the underlying interface is used. For example, if you have installed an OC48c module, the default maximum bandwidth for the link is 2404 megabits/second.

Use the no mpls te max-link-bandwidth command to set the maximum bandwidth for the link to the default value.

You must be in interface configuration mode to use this command.

Example: The following example sets the maximum link bandwidth for this OC12 link to its full value of 622 megabits per second:

router(config)#interface pos 1/1/1 router(config-if)#mpls te max-link-bandwidth 622 router(config-if)#end

Setting Maximum Reservable Bandwidth

The maximum reservable bandwidth specifies the portion of the total available bandwidth that can be reserved on this interface Bandwidth can be set lower than the value set by the mpls te max-link-bandwidth command to provide room for hop-by-hop routed traffic. Conversely, bandwidth can be set higher than the value set by the mpls te max-link-bandwidth command to permit statistical multiplexing of MPLS traffic. A maximum reservable bandwidth default value can be set in traffic engineering configuration mode using the default-max-reservable-bandwidth command for any interfaces you do not explicitly set using the mpls te max-reservable-bandwidth command.

The default for the maximum reservable bandwidth is the value specified by the mpls te max-link-bandwidth command. The default maximum reservable bandwidth for each priority is the value specified by the maximum reservable bandwidth for the interface.

You must be in the interface configuration mode to use this command.

Example: The following example sets the maximum reservable bandwidth for the pos 1/1/1 interface to 80 percent:

router(config)#interface pos 1/1/1 router(config-if)#mpls te max-reservable-bandwidth 80% router(config-if)#end

Use the default-max-reservable-bandwidth command, in traffic engineering configuration mode, to set a default maximum reservable bandwidth to apply to any interfaces that are not explicitly set with the mpls te max-reservable-bandwidth command.

If the priority of a given maximum reservable bandwidth is greater than the priority of another maximum reservable bandwidth, the value of that maximum reservable bandwidth should also be greater.

Setting Interface Metrics for Traffic Engineering

A metric is a cost you assign to an interface that is used during path computation to indicate the relative preference of one interface over another in the creation of an MPLS tunnel. You use the traffic engineering metric to identify the relative preference between interfaces during tunnel creation, when there are multiple alternative interfaces. If an IGP route's lowest cost is via an attached MPLS-TE tunnel and all links along the way are TE enabled, IPriori converts the route to MPLS.

Configuring an MPLS TE metric should not be confused with configuring metrics that cause traffic to prefer one already existing tunnel over another. This traffic engineering metric type is set as a tunnel default or tunnel parameter-set option. Refer to "Tunnel Metric" in the "Setting Tunnel Defaults" section for further information.

Figure 1-4 shows a simple network of six routers with the interface metric assignment displayed for each link. The total cost of a tunnel between router A and router F is determined by adding the costs of the links. Assuming all other considerations are equal, traffic engineering will assign a preference for path Ra - Rc - Rd - Re - Rf, with a total cost of 30, over path Ra - Rb - Re - Rf, which has a total cost of 40.

Figure 1-4. Default metric for tunnel creation

Use the mpls te metric command in interface configuration mode to set the interface metric for this interface with a range of 1 - 16777215, if metric style for this router is wide, and a range of 1 - 63, if metric style for this router is narrow. The limitation of narrow routing only applies to IS-IS.

You must be in the interface configuration mode to use this command.

Example: The following command sets the metric for the pos 1/1/1 interface, for a router with a global metric style configured as wide, at a cost of 100:

router(config)#interface pos 1/1/1 router(config-if)#mpls te metric 100 router(config-if)#end

Configuring a Default TE Metric

IPriori provides for the configuring of a default traffic-engineering metric for interfaces that are not explicitly configured for TE metric using the mpls te metric command. A metric is a cost you assign to an interface that is used during path computation to indicate the relative preference of one interface over another. The MPLS traffic engineering metric identifies the relative preference between interfaces during tunnel creation, when there are multiple alternative interfaces. If an MPLS traffic engineering metric is not explicitly set, the interface metric defaults to the IGP metric set by the ip ospf cost command for an OSPF interface or the isis metric command for an IS-IS interface. IPriori provides for specifying a specific MPLS TE default metric value or specifying that the IGP metric will be the default value.

Use the default-te-metric command to specify how the default MPLS TE interface metric should be handled, i.e. a specified TE metric default or the IGP configured value.

Use the default-te-metric teValue command to configure a specific default MPLS TE metric for interfaces not explicitly configured using the mpls te metric command.

Use the default-te-metric igp command to specify that the configured IGP metric value should be used when creating tunnels for any interface not explicitly configured using the mpls te metric command.

Use the no default-te-metric command to reset the default MPLS TE metric to the configured IGP metric.

Example: The following example:

• The default for MPLS TE metric is set to the IGP metric value for all interfaces not explicitly set for MPLS TE metric.
  
  
• The MPLS TE metric is set to 200 for POS interface 1/1/1.
  
  
• The IGP IS-IS L2 metric is set to 100 for POS interface 1/1/2.
  
  

router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#default-te-metric igp router(config)#interface pos 1/1/1 router(config-if)#mpls te metric 200 router(config-if)#exit router(config)#interface pos 1/1/2 router(config-if)#isis metric 100 level-2 router(config-if)#end router#show running-config ! ! server-id 5 upper ! server-location 1/11 ! ! . . . default-te-metric igp ! mpls ldp ! ! ! . . . end router#

The MPLS TE metric values for the above example are as follows:

• Interface POS 1/1/1: 200. This value was explicitly set for this interface using the mpls te metric command.
  
  
• Interface POS 1/1/2: 100. The MPLS TE metric value was not explicitly set and the default TE metric value is the configured IGP value, therefore the configured IS-IS metric value is used for the MPLS TE metric.
  
  

Example: The following example:

• The default for MPLS TE metric is set to 50 for all interfaces not explicitly set for MPLS TE metric.
  
  
• The MPLS TE metric is set to 200 for POS interface 1/1/1.
  
  
• The IGP IS-IS L2 metric is set to 100 for POS interface 1/1/2.
  
  

router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#default-te-metric 50 router(config)#interface pos 1/1/1 router(config-if)#mpls te metric 200 router(config-if)#exit router(config)#interface pos 1/1/2 router(config-if)#isis metric 100 level-2 router(config-if)#end router#show running-config ! ! server-id 5 upper ! server-location 1/11 . . .default-te-metric 50 ! mpls ldp ! ! ! . . . end router#

The MPLS TE metric values for the above example are as follows:

• Interface POS 1/1/1: 200. This value was explicitly set for this interface using the mpls te metric command.
  
  
• Interface POS 1/1/2: 50. The MPLS TE metric value was not explicitly set and the default TE metric value is the configured 50, therefore the configured IS-IS metric value is not used for the MPLS TE metric.
  
  

Configuring MPLS Reflood Timers Per Interface

MPLS reflood timers can be configured globally for the router by entering the appropriate command for the desired reflood timer method in configuration mode. You can override a router configuration for a given interface by entering the appropriate command in interface mode. To remove this per interface override use the reflood timers command no option.

For details concerning the three MPLS reflood timers methods available refer to section "Configuring MPLS Reflood Timers Per Router".

Example 1: The following command line overrides the router setting and configures the MPLS reflood timer method to immediate for interface pos 1/1/1:

router>enable router#configure terminal router(config)#interface pos 1/1/1 router(config-if)#mpls-reflood-timer immediate router(config-if)#end

Example 2: The following command line overrides the router setting and configures the MPLS reflood timer method to paced with a pacing interval of 5 seconds and a default jitter of 20% of the pacing interval for interface pos 1/1/1:

router>enable router#configure terminal router(config)#interface pos 1/1/1 router(config-if)#mpls-reflood-timer pacing 5s router(config-if)#end

Example 3: The following command line overrides the router setting and configures the MPLS reflood timer method to piecewise linear, sets three linear value sets and a jitter value of 30 percent for interface pos 1/1/1:

router>enable router#configure terminal router(config)#interface pos 1/1/1 router(config-if)#mpls-reflood-timer linear 90% 4s 60% 30s 30% 200s jitter 30% router(config-if)#end

Using RSVP Extensions for Traffic Engineering

The functions described in this section are RSVP extensions to provide traffic engineering capabilities over MPLS. RSVP is the signaling protocol used to set up label switched paths. Configuration is required so only authorized messages are accepted and acted upon. RSVP must be informed of all neighbors it expects to receive messages from and send messages to. This section discusses the setup of RSVP neighbors and associated parameters, as well as refresh timers.

Setting Up RSVP Neighbors

RSVP can be configured to require explicit knowledge of neighboring routers to prevent denial of service attacks. The rsvp neighbor enable-label-requests command identifies the specified router as a neighbor. Use the rsvp neighbor enable-label-requests command to identify individual neighbors and enable MPLS label requests.

Example: The following command identifies router 10.1.1.1 as a RSVP neighbor and enables MPLS label requests for that router:

router>enable router#configure terminal router(config)#rsvp neighbor 10.1.1.1 enable-label-requests

You can turn off message authentication of all incoming RSVP messages using the rsvp promiscuous command. A router that is not in promiscuous mode checks where an RSVP message comes from and compares that check with the router's list of configured neighbors. If the incoming message is from a router that is not a configured neighbor, the message is ignored. In promiscuous mode this check is not done, and the router accepts requests from any address. When promiscuous mode is disabled, this router only accepts requests from valid neighbors configured using the rsvp neighbor command. To disable RSVP promiscuous mode use the no option with this command. Only use promiscuous mode if you feel you have sufficient control of your network that you will not be receiving illegal RSVP requests.

Configuring Reservation and Path Refresh Timers

There are two types of RSVP refresh messages: reservation and path. End systems send path and reservation messages to set up RSVP connections. These messages set up state along the path that needs to be periodically refreshed. You can set the refresh time on a global basis for both of these message types.

NOTE Changing the refresh time values affects existing RSVP sessions. When you increase the refresh interval, the change does not immediately go into affect for increases greater than 30 percent. Refresh time values are increased by 30 percent per current refresh interval until the new refresh interval is reached.

The reservation refresh time is the amount of time between refresh messages that revalidate reservation state along a path. The global default value is 30 seconds, unless changed using the rsvp default-resv-refresh command. Supported values range between 1 - 300 seconds. Shorter refresh times cause the generation of more refresh messages, along with an increase in computational overhead that could have a negative affect on performance. Longer refresh times resolve the performance issue at the expense of a slower response to errors caused by message loss.

Example 1: The following command sets the global reservation refresh time to 50:

router>enable router#configure terminal router(config)#rsvp default-resv-refresh 50

Path Refresh is used to periodically revalidate an existing path. A path refresh message is sent out periodically; the frequency is determined by the value set for refresh time.

The path refresh timer is configurable globally. Use the rsvp default-path-refresh command to set the path refresh time. The system default for refresh time is 30 seconds.

The path refresh timeout timer is non-configurable and is fixed at a multiple of 5.25 times the refresh time.

Example 2: The following command sets the path refresh time to 50: