MPLS Traffic Engineering --- DiffServ Aware (DS-TE)
Available Languages
Table Of Contents
MPLS Traffic Engineering—DiffServ Aware (DS-TE)
Related Features and Technologies
From Traditional to IETF-Standard Commands
The tunnel mpls traffic-eng bandwidth command
The mpls traffic-eng ds-te commands
Transitioning a Network to the IETF Standard
Level 1: Configuring the Device
Level 2: Configuring the Physical Interface
Level 3: Configuring the Tunnel Interface
Guaranteed Bandwidth Service Configuration
Guaranteed Bandwidth Service Examples
Example with Single Destination Prefix
Tunnel Midpoint Configuration [Mid-1]
Tunnel Midpoint Configuration [Mid-2]
Example with Many Destination Prefixes
Configuration of Tunnel Head-1
Configuration of Tunnel Head-2
Tunnel Midpoint Configuration [Mid-1]
Tunnel Midpoint Configuration [Mid-2]
mpls traffic-eng ds-te bc-model
show mpls traffic-eng topology
tunnel mpls traffic-eng bandwidth
MPLS Traffic Engineering—DiffServ Aware (DS-TE)
This guide presents extensions made to Multiprotocol Label Switching Traffic Engineering (MPLS TE) that make it DiffServ aware. Specifically, the bandwidth reservable on each link for constraint-based routing (CBR) purposes can now be managed through at least two bandwidth pools: a global pool (also called BC0) and a sub-pool (also called BC1). The sub-pool can be limited to a smaller portion of the link bandwidth. Tunnels using the sub-pool bandwidth can then be used in conjunction with MPLS Quality of Service (QoS) mechanisms to deliver guaranteed bandwidth services end-to-end across the network.
Beginning with Cisco IOS Release 12.2(33)SRB, DS-TE has been augmented to conform to IETF standards that were developed after the initial creation of Cisco DS-TE. Now both the traditional and the IETF versions of DS-TE can be run on your network; the new releases are backwards compatible.
Feature History
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
The guide contains the following sections:
Background and Overview
MPLS traffic engineering allows constraint-based routing (CBR) of IP traffic. One of the constraints satisfied by CBR is the availability of required bandwidth over a selected path. DiffServ-aware Traffic Engineering extends MPLS traffic engineering to enable you to perform constraint-based routing of "guaranteed" traffic, which satisfies a more restrictive bandwidth constraint than that satisfied by CBR for regular traffic. The more restrictive bandwidth is termed a sub-pool, while the regular TE tunnel bandwidth is called the global pool. (The sub-pool is a portion of the global pool. In the new IETF-Standard, the global pool is called BC0 and the sub-pool is called BC1. These are two of an eventually available eight Class Types). This ability to satisfy a more restrictive bandwidth constraint translates into an ability to achieve higher Quality of Service performance in terms of delay, jitter, or loss for the guaranteed traffic.
For example, DS-TE can be used to ensure that traffic is routed over the network so that, on every link, there is never more than 40 per cent (or any assigned percentage) of the link capacity of guaranteed traffic (for example, voice), while there can be up to 100 per cent of the link capacity of regular traffic. Assuming that QoS mechanisms are also used on every link to queue guaranteed traffic separately from regular traffic, it then becomes possible to enforce separate "overbooking" ratios for guaranteed and regular traffic. In fact, for the guaranteed traffic it becomes possible to enforce no overbooking at all—or even an underbooking—so that very high QoS can be achieved end-to-end for that traffic, even while for the regular traffic a significant overbooking continues to be enforced.
Also, through the ability to enforce a maximum percentage of guaranteed traffic on any link, the network administrator can directly control the end-to-end QoS performance parameters without having to rely on over-engineering or on expected shortest path routing behavior. This is essential for transport of applications that have very high QoS requirements such as real-time voice, virtual IP leased line, and bandwidth trading, where over-engineering cannot be assumed everywhere in the network.
The new IETF-Standard functionality of DS-TE expands the means for allocating constrained bandwidth into two distinct models, called the "Russian Dolls Model" and the "Maximum Allocation Model". They differ from each other as follows:
Therefore in practice, a Network Administrator might prefer to use:
•
the Maximum Allocation Model when s/he needs to ensure isolation across all Class Types without having to use pre-emption, and s/he can afford to risk some QoS degradation of Class Types other than the Premium Class.
•
DS-TE involves extending OSPF (Open Shortest Path First routing protocol), so that the available sub-pool or class-type bandwidth at each preemption level is advertised in addition to the available global pool bandwidth at each preemption level. And DS-TE modifies constraint-based routing to take this more complex advertised information into account during path computation.
With the addition of IETF-Standard functionality (beginning with Cisco IOS Release 12.2(33)SRB), networks may accomplish DS-TE in three different combinations or "modes", so that they may transition to the IETF-Standard formats in a manner that will not degrade their ongoing traffic service. These three situations or modes are summarized as follows:
1.
2.
3.
Table 2 summarizes these distinctions among the three modes.
1Note that it is not possible for the Traditional mode to be liberal in what it accepts in terms of IGP, since it does not use TE-Class mapping and therefore cannot interpret the "Unreserved Bandwidth" in the IETF-compliant way when the Subpool Sub-TLV is absent.
Benefits
DiffServ-aware Traffic Engineering enables service providers to perform separate admission control and separate route computation for discrete subsets of traffic (for example, voice and data traffic).
Therefore, by combining DS-TE with other IOS features such as QoS, the service provider can:
•
•
•
•
Related Features and Technologies
The DS-TE feature is related to OSPF, IS-IS, RSVP (Resource reSerVation Protocol), QoS, and MPLS traffic engineering. Cisco documentation for all of these features is listed in the next section.
Related Documents
For OSPF:
•
•
For IS-IS:
•
•
For RSVP:
•
•
For QoS:
•
•
For MPLS Traffic Engineering:
•
•
Supported Standards
The traditional (pre-IETF Standard) version of DiffServ-aware MPLS Traffic Engineering conforms to the descriptions given in the following two documents:
•
•
The IETF Standard for DiffServ-aware MPLS Traffic Engineering is described in the following four documents:
•
•
•
•
The new concept of "Class-Type" defined in the IETF Standard corresponds to the prior concept of "bandwidth pool" that was implemented in the original version of DS-TE. Likewise, the two bandwidth pools implemented in the original version of DS-TE (global pool and sub-pool) correspond to two of the IETF Standard's new Class-Types (Class-Type 0 and Class-Type 1, respectively).
Prerequisites
Your network must support the following Cisco IOS features in order to support guaranteed bandwidth services based on DiffServ-aware Traffic Engineering:
•
•
•
•
•
Configuration Tasks
This section presents the minimum set of commands you need to implement the DiffServ-aware Traffic Engineering feature—in other words, to establish a tunnel that reserves bandwidth to a sub-pool (renamed BC1 by the IETF-Standard).
The subsequent "Configuration Examples" section (page 13), presents these same commands in context and shows how, by combining them with QoS commands, you can build guaranteed bandwidth services.
From Traditional to IETF-Standard Commands
DS-TE commands originally were developed from the then-existing command set that had been used to configure MPLS traffic engineering. The only difference introduced at that time to create DS-TE was the expansion of two commands:
•
•
The ip rsvp bandwidth command
The early MPLS command had been
ip rsvp bandwidth x ywhere x = the size of the only possible pool, and y = the size of a single traffic flow (ignored by traffic engineering).
Then, to create the original implementation of DS-TE, the command was made into
ip rsvp bandwidth x y sub-pool zwhere x = the size of the global pool, and z = the size of the sub-pool.
With the addition of the IETF-Standard version of DS-TE, the command has been further extended to become:
ip rsvp bandwidth x y [ [rdm x {subpool z | bc1 z}] | [mam bc0 x bc1 z]]where x = the size of the global pool (now called bc0), and z = the size of the sub-pool (now called also bc1).
Two bandwidth constraint models also have become available, "Russian Dolls" (indicated by the keyword rdm) and "Maximum Allocation" (mam). The former model allows greater sharing of bandwidth across all Class Types (bandwidth pools), while the latter protects especially the premium Class Type. (The IETF Standard makes possible the future implementation of as many as seven sub-pools within one LSP, instead of just one sub-pool per LSP).
The tunnel mpls traffic-eng bandwidth command
The pre-DS-TE traffic engineering command was
tunnel mpls traffic-eng bandwidth bwhere b = the amount of bandwidth this tunnel requires.
So for the original DS-TE, you specified from which pool (global or sub) the tunnel's bandwidth would come. You could enter
tunnel mpls traffic-eng bandwidth sub-pool bto indicate that the tunnel should use bandwidth from the sub-pool. Alternatively, you could enter
tunnel mpls traffic-eng bandwidth bto indicate that the tunnel should use bandwidth from the global pool (which was the default).
With the addition of the IETF-Standard version of DS-TE, the command has been extended to become:
tunnel mpls traffic-eng bandwidth [sub-pool|class-type 1] bwhere both sub-pool and class-type 1 indicate the same, smaller bandwidth pool (now called class-type 1). The two keywords can be used interchangeably.
The mpls traffic-eng ds-te commands
The IETF Standard introduces two new commands, one to indicate the Bandwidth Constraints model
mpls traffic-eng ds-te bc-model [rdm | mam]and one to select the DS-TE mode:
mpls traffic-eng ds-te mode [migration|ietf](The concepts of bc-model and DS-TE mode were explained on page 3).
The first command allows you to select between the Russian Dolls Model (rdm) and the Maximum Allocation Model (mam) of bandwidth constraints.
The second command allows you to transition a network from traditional DS-TE tunnels to the IETF Standard without disrupting any of the tunnels' operation. To accomplish this, you first put the routers into Migration mode (using the migration keyword) and subsequently into the Liberal-IETF mode (using the ietf keyword).
Transitioning a Network to the IETF Standard
Networks already operating DS-TE tunnels by means of the traditional, pre-IETF-Standard software can switch to the IETF-Standard without interrupting their DS-TE service by following this sequence:
1.
2.
3.
Configuring DS-TE Tunnels
To establish a sub-pool (BC1) traffic engineering tunnel, you must enter configurations at three levels:
•
•
•
On the first two levels, you activate traffic engineering; on the third level—the tunnel interface—you establish the sub-pool tunnel. Therefore, it is only at the tunnel headend device that you need to configure all three levels. At the tunnel midpoints and tail, it is sufficient to configure the first two levels.
In the tables below, each command is explained in brief. For a more complete explanation of any command, type it into the Command Lookup Tool at http://www.cisco.com/cgi-bin/Support/Cmdlookup/home.pl. (If prompted to log in there, use your Cisco.com account username and password).
Level 1: Configuring the Device
At this level, you tell the device (router or switch router) to use accelerated packet-forwarding (known as Cisco Express Forwarding or CEF), MultiProtocol Label Switching (MPLS), traffic-engineering tunneling, a bandwidth constraints model, and either the OSPF or IS-IS routing algorithm (Open Shortest Path First or Intermediate System to Intermediate System). This level is called the global configuration mode, because the configuration is applied globally, to the entire device, rather than to a specific interface or routing instance.
You enter the following commands:
Step 1
Enables CEF—which accelerates the flow of packets through the device.
Step 2
Enables MPLS, and specifically its traffic engineering tunnel capability.
Step 3
Router(config)# mpls traffic-eng ds-te bc-model [rdm | mam ]Specifies the bandwidth constraints model (see page 3).
Step 4
Invokes the OSPF routing process for IP and puts the device into router configuration mode. Proceed now to Steps 10 and 11.
Alternatively, you may invoke the IS-IS routing process with this command, and continue with Step 5.
Step 5
Specifies the IS-IS network entity title (NET) for the routing process.
Step 6
Enables the router to generate and accept IS-IS new-style TLVs (type, length, and value objects).
Step 7
Configures the router to learn about destinations inside its own area or "IS-IS level".
Step 8
Specifies the IS-IS level (which must be same level as in the preceding step) to which the router will flood MPLS traffic- engineering link information.
Step 9
Instructs IS-IS to advertise the IP address of the loopback interface without actually running IS-IS on that interface. Continue with Step 10 but don't do Step 11—because Step 11 refers to OSPF.
Step 10
Specifies that the traffic engineering router identifier is the IP address associated with the loopback0 interface.
Step 11
Turns on MPLS traffic engineering for a particular OSPF area.
Level 2: Configuring the Physical Interface
Having configured the device, you now must configure the interface on that device through which the tunnel will run. To do that, you first put the router into interface-configuration mode.
You then enable Resource Reservation Protocol (RSVP). This protocol is used to signal (set up) a traffic engineering tunnel, and to tell devices along the tunnel path to reserve a specific amount of bandwidth for the traffic that will flow through that tunnel. It is with this command that you establish the maximum size of the sub-pool (BC1).
Finally, you enable the MPLS traffic engineering tunnel feature on this physical interface—and if you will be relying on the IS-IS routing protocol, you enable that as well.
To accomplish these tasks, you enter the following commands:
Step 1
Router(config)# interface interface-id
Moves configuration to the interface level, directing subsequent configuration commands to the specific interface identified by the interface-id.
Step 2
Router(config-if)# ip rsvp bandwidth [interface-kbps] [single-flow-kbps][[rdm kbps{[subpool kbps]|[bc1 subpool]}]|[mam max-reservable-bw kbps bc0 kbps bc1 kbps]]
Enables RSVP on this interface, indicates the Bandwidth Constraints Model to be used (explained on page 3), and limits the amount of bandwidth RSVP can reserve on this interface. The sum of bandwidth used by all tunnels on this interface cannot exceed interface-kbps. (For more detail, see page 40).
Step 3
Enables the MPLS traffic engineering tunnel feature on this interface.
Step 4
Router(config-if)# ip router isisEnables the IS-IS routing protocol on this interface. Do not enter this command if you are configuring for OSPF.
Level 3: Configuring the Tunnel Interface
Now you create a set of attributes for the tunnel itself; those attributes are configured on the "tunnel interface" (not to be confused with the physical interface just configured above).
You enter the following commands:
Step 1
Creates a tunnel interface (named in this example tunnel1) and enters interface configuration mode.
Step 2
Specifies the IP address of the tunnel tail device.
Step 3
Sets the tunnel's encapsulation mode to MPLS traffic engineering.
Step 4
Router(config-if)# tunnel mpls traffic-eng bandwidth {sub-pool|class-type1} bandwidthConfigures the tunnel's bandwidth, and assigns it either to the sub-pool (when you use that keyword or the IETF-Standard keyword class-type1) or to the global pool (when you leave out both keywords). For more detail, see page 48.
Step 5
Sets the priority to be used when the system determines which existing tunnels are eligible to be preempted.
Step 6
Configures the paths (hops) a tunnel should use. The user can enter an explicit path (can specify the IP addresses of the hops) or can specify a dynamic path (the router figures out the best set of hops).
Verifying the Configuration
To view the complete configuration you have entered, use the EXEC command show running-config and check its output display for correctness.
To check just one tunnel's configuration, enter show interfaces tunnel followed by the tunnel interface number. And to see that tunnel's RSVP bandwidth and flow, enter show ip rsvp interface followed by the name or number of the physical interface.
Here is an example of the information displayed by these latter two commands. (To see an explanation of each field used in the following displays, enter show interfaces tunnel or show ip rsvp interface into the Command Lookup Tool at http://www.cisco.com/cgi-bin/Support/Cmdlookup/home.pl. If prompted to log in there, use your Cisco.com account username and password.)
Router#show interfaces tunnel 4Tunnel4 is up, line protocol is downHardware is Routing TunnelMTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255Encapsulation TUNNEL, loopback not set, keepalive set (10 sec)Tunnel source 0.0.0.0, destination 0.0.0.0Tunnel protocol/transport GRE/IP, key disabled, sequencing disabledLast input never, output never, output hang neverLast clearing of "show interface" counters neverOutput queue 0/0, 0 drops; input queue 0/75, 0 dropsFive minute input rate 0 bits/sec, 0 packets/secFive minute output rate 0 bits/sec, 0 packets/sec0 packets input, 0 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort0 packets output, 0 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets, 0 restartsRouter#show ip rsvp interface pos4/0interface allocated i/f max flow max sub maxPO4/0 300K 466500K 466500K 0MTo view all tunnels at once on the router you have configured, enter show mpls traffic-eng tunnels brief. The information displayed when tunnels are functioning properly looks like this:
Router#show mpls traffic-eng tunnels briefSignalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 3029 secondsTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTGSR1_t0 192.168.1.13 - SR3/0 up/upGSR1_t1 192.168.1.13 - SR3/0 up/upGSR1_t2 192.168.1.13 - PO4/0 up/upDisplayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tailsWhen one or more tunnels is not functioning properly, the display could instead look like this. (In the following example, tunnels t0 and t1 are down, as indicated in the far right column).
Router#show mpls traffic-eng tunnels briefSignalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 2279 secondsTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTGSR1_t0 192.168.1.13 - SR3/0 up/downGSR1_t1 192.168.1.13 - SR3/0 up/downGSR1_t2 192.168.1.13 - PO4/0 up/upDisplayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tailsTo find out why a tunnel is down, insert its name into this same command, after adding the keyword name and omitting the keyword brief. For example:
Router#show mpls traffic-eng tunnels name GSR1_t0Name:GSR1_t0 (Tunnel0) Destination:192.168.1.13Status:Admin:up Oper:down Path: not valid Signalling:connectedIf, as in this example, the Path is displayed as not valid, use the show mpls traffic-eng topology command to make sure the router has received the needed updates.
Additionally, you can use any of the following show commands to inspect particular aspects of the network, router, or interface concerned:
Network
Advertised bandwidth allocation information
show mpls traffic-eng link-management advertisements
Preemptions along the tunnel path
debug mpls traffic-eng link-management preemption
Available TE link band- width on all head routers
show mpls traffic-eng topology (described on page 49)
Router
Status of all tunnels cur- rently signalled by this router
show mpls traffic-eng link-management admission-control
Tunnels configured on midpoint routers
show mpls traffic-eng link-management summary
Physical interface
Detailed information on current bandwidth pools
show mpls traffic-eng link-management bandwidth-allocation [interface-name]
TE RSVP bookkeeping
show mpls traffic-eng link-management interfaces
Entire configuration of one interface
show run interface
Configuration Examples
Note
First this section presents the DS-TE configurations needed to create the sub-pool tunnel. Then it presents the more comprehensive design for building end-to-end guaranteed bandwidth service, which involves configuring Quality of Service as well.
As shown in Figure 1, the tunnel configuration involves at least three devices—tunnel head, midpoint, and tail. On each of those devices one or two network interfaces must be configured, for traffic ingress and egress.
Figure 1 Sample Tunnel Topology
Tunnel Head
At the device level:
router-1# configure terminalEnter configuration commands, one per line. End with CNTL/Z.router-1(config)# ip cef distributedrouter-1(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-1(config-router)# mpls traffic-eng router-id Loopback0router-1(config-router)# exitrouter-1(config)# interface Loopback0At the virtual interface level:
router-1(config-if)# ip address 22.1.1.1 255.255.255.255router-1(config-if)# no ip directed-broadcastrouter-1(config-if)# exitAt the device level:
router-1(config)# interface POS2/0/0At the physical interface level (egress):
router-1(config-if)# ip address 10.1.1.1 255.255.255.0router-1(config-if)# mpls traffic-eng tunnelsrouter-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000[and if using IS-IS instead of OSPF]:router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitAt the device level:
router-1(config)# interface Tunnel1At the tunnel interface level:
router-1(config-if)# bandwidth 110000router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 24.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamicrouter-1(config-if)# exitrouter-1(config)#Midpoint Devices
At the device level:
router-2# configure terminalrouter-2(config)# ip cef distributedrouter-2(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-2(config-router)# mpls traffic-eng router-id Loopback0router-2(config-router)# exitrouter-2(config)# interface Loopback0At the virtual interface level:
router-2(config-if)# ip address 25.1.1.1 255.255.255.255router-2(config-if)# no ip directed-broadcastrouter-2(config-if)# exitAt the device level: router-1(config)# interface POS4/0router-1(config-if)# ip address 11.1.1.2 255.255.255.0router-1(config-if)# mpls traffic-eng tunnelsrouter-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000[If using IS-IS instead of OSPF]:
router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitAt the device level: router-1(config)# interface POS4/1router-1(config-if)# ip address 12.1.1.2 255.255.255.0router-1(config-if)# mpls traffic-eng tunnelsrouter-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000[If using IS-IS instead of OSPF]:
router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitNote that there is no configuring of tunnel interfaces at the mid-point devices, only network interfaces and the device globally.
Tail-End Device
At the device level:
router-3# configure terminalrouter-3(config)# ip cef distributedrouter-3(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-3(config-router)# mpls traffic-eng router-id Loopback0router-3(config-router)# exitrouter-3(config)# interface Loopback0At the virtual interface level:
router-3(config-if)# ip address 24.1.1.1 255.255.255.255router-3(config-if)# no ip directed-broadcast[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the device level: router-1(config)# interface POS4/0router-1(config-if)# ip address 12.1.1.3 255.255.255.0router-1(config-if)# mpls traffic-eng tunnelsrouter-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000[If using IS-IS instead of OSPF]:
router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exit
Guaranteed Bandwidth Service Configuration
Having configured two bandwidth pools, you now can
•
•
Having a separate pool for traffic requiring strict guarantees allows you to limit the amount of such traffic admitted on any given link. Often, it is possible to achieve strict QoS guarantees only if the amount of guaranteed traffic is limited to a portion of the total link bandwidth.
Having a separate pool for other traffic (best-effort or diffserv traffic) allows you to have a separate limit for the amount of such traffic admitted on any given link. This is useful because it allows you to fill up links with best-effort/diffserv traffic, thereby achieving a greater utilization of those links.
Providing Strict QoS Guarantees Using DS-TE Sub-pool Tunnels
A tunnel using sub-pool bandwidth can satisfy the stricter requirements if you do all of the following:
1.
If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue (EF PHB) is used. On the Cisco 7500(VIP) it is the "priority" queue.You must configure the bandwidth of the queue to be at least equal to the bandwidth of the sub-pool.
If only bandwidth guarantees are sought, the diffserv Assured Forwarding PHB (AF PHB) is used. On the Cisco 7500 (VIP) you use one of the existing Class-Based Weighted Fair Queuing (CBWFQ) queues.
2.
You do this by marking the traffic that enters the tunnel with a unique value in the mpls exp bits field, and steering only traffic with that marking into the GB queue.
3.
You do this by rate-limiting the guaranteed traffic before it enters the sub-pool tunnel. The aggregate rate of all traffic entering the sub-pool tunnel should be less than or equal to the bandwidth capacity of the sub-pool tunnel. Excess traffic can be dropped (in the case of delay/jitter guarantees) or can be marked differently for preferential discard (in the case of bandwidth guarantees).
4.
You do this by setting the sub-pool bandwidth of each outbound link to the appropriate percentage of the total link bandwidth (that is, by adjusting the z parameter of the ip rsvp bandwidth command).
Providing Differentiated Service Using DS-TE Global Pool Tunnels
You can configure a tunnel using global pool bandwidth to carry best-effort as well as several other classes of traffic. Traffic from each class can receive differentiated service if you do all of the following:
1.
2.
3.
To control the amount of diffserv tunnel traffic you intend to support on a given link, adjust the size of the global pool on that link.
Providing Strict Guarantees and Differentiated Service in the Same Network
Because DS-TE allows simultaneous constraint-based routing of sub-pool and global pool tunnels, strict guarantees and diffserv can be supported simultaneously in a given network.
Guaranteed Bandwidth Service Examples
Given the many topologies in which Guaranteed Bandwidth Services can be applied, there is space here only to present two examples. They illustrate opposite ends of the spectrum of possibilities.
In the first example, the guaranteed bandwidth tunnel can be easily specified by its destination. So the forwarding criteria refer to a single destination prefix.
In the second example, there can be many final destinations for the guaranteed bandwidth traffic, including a dynamically changing number of destination prefixes. So the forwarding criteria are specified by Border Gateway Protocol (BGP) policies.
Example with Single Destination Prefix
Figure 2 illustrates a topology for guaranteed bandwidth services whose destination is specified by a single prefix, either Site D (like a voice gateway, here bearing prefix 26.1.1.1) or a subnet (like the location of a web farm, here called "Province" and bearing prefix 26.1.1.0). Three services are offered:
•
•
•
Figure 2 Sample Topology for Guaranteed Bandwidth Services to a Single Destination Prefix
These three services run through two sub-pool tunnels:
•
•
Both tunnels use the same tail router, though they have different heads. (In Figure 2 one midpoint router is shared by both tunnels. In the real world there could of course be many more midpoints.)
All POS interfaces in this example are OC3, whose capacity is 155 Mbps.
Configuring Tunnel Head-1
First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier in this Configuration Examples section). Then we present the QoS commands that guarantee end-to-end service on the subpool tunnel. (With the 7500 router, Modular QoS CLI is used.)
Configuring the Pools and Tunnel
At the device level:
router-1(config)# ip cef distributedrouter-1(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-1(config-router)# mpls traffic-eng router-id Loopback0router-1(config-router)# exitCreate a virtual interface:
router-1(config)# interface Loopback0router-1(config-if)# ip address 23.1.1.1 255.255.255.255router-1(config-if)# no ip directed-broadcastrouter-1(config-if)# exitAt the outgoing physical interface:
router-1(config)# interface pos4/0router-1(config-if)# ip address 10.1.1.1 255.0.0.0router-1(config-if)# mpls traffic-eng tunnelsrouter-1(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-1(config-if)# ip router isis[and in all cases}:router-1(config-if)# exitAt the tunnel interface:
router-1(config)# interface Tunnel1router-1(config-if)# bandwidth 110000router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 27.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamicTo ensure that packets destined to host 26.1.1.1 and subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static route. At the device level:
router-1(config)# ip route 26.1.1.0 255.255.255.0 Tunnel1router-1(config)# exitAnd in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down this tunnel, we disable autoroute announce:
router-1(config)# no tunnel mpls traffic-eng autoroute announceFor Service from Site A to Site D
At the inbound physical interface (FE4/1/0):
1.
class-map match-all sla-1-classmatch access-group 1002.
access-list 100 permit ip any host 26.1.1.13.
a.
- a rate of 8 million bits per second
- a normal burst of 1 million bytes
- a maximum burst of 2 million bytes
b.
c.
d.
policy-map sla-1-input-policyclass sla-1-classpolice 8000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 \ exceed-action dropclass class-defaultset-mpls-exp-transmit 04.
interface FastEthernet4/1/0service-policy input sla-1-input-policyFor Service from Site B to Subnet "Province"
At the inbound physical interface (FE4/1/1):
1.
class-map match-all sla-2-classmatch access-group 1202.
access-list 120 permit ip any 26.1.1.0 0.0.0.2553.
a.
- a rate of 32 million bits per second
- a normal burst of 1 million bytes
- a maximum burst of 2 million bytes
b.
c.
d.
policy-map sla-2-input-policyclass sla-2-classpolice 32000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 \ exceed-action dropclass class-defaultset-mpls-exp-transmit 04.
interface FastEthernet4/1/1service-policy input sla-2-input-policyFor Both Services
The outbound interface (POS4/0) is configured as follows:
1.
class-map match-all exp-5-trafficmatch mpls experimental 52.
policy-map output-interface-policyclass exp-5-trafficpriority 323.
interface POS4/0service-policy output output-interface-policyThe result of the above configuration lines is that packets entering the Head-1 router via interface FE4/1/0 destined to host 26.1.1.1, or entering the router via interface FE4/1/1 destined to subnet 26.1.1.0, will have their MPLS experimental bit set to 5. We assume that no other packets entering the router (on any interface) are using this value. (If this cannot be assumed, an additional configuration must be added to mark all such packets to another experimental value.) Packets marked with experimental bit 5, when exiting the router via interface POS4/0, will be placed into the priority queue.
Note
Configuring Tunnel Head-2
First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier in this Configuration Examples section). Then we present the QoS commands that guarantee end-to-end service on the sub-pool tunnel.
.Configuring the Pools and Tunnel
At the device level:
router-2(config)# ip cef distributedrouter-2(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-2(config-router)# mpls traffic-eng router-id Loopback0router-2(config-router)# exitCreate a virtual interface:
router-2(config)# interface Loopback0router-2(config-if)# ip address 22.1.1.1 255.255.255.255router-2(config-if)# no ip directed broadcastrouter-2(config-if)# exitAt the outgoing physical interface:
router-2(config)# interface pos0/0router-2(config-if)# ip address 11.1.1.1 255.0.0.0router-2(config-if)# mpls traffic-eng tunnelsrouter-2(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-2(config-if)# ip router isis[and in all cases]:router-2(config-if)# exitAt the tunnel interface:
router-2(config)# interface Tunnel2router-2(config-if)# ip unnumbered Loopback0router-2(config-if)# tunnel destination 27.1.1.1router-2(config-if)# tunnel mode mpls traffic-engrouter-2(config-if)# tunnel mpls traffic-eng priority 0 0router-2(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000router-2(config-if)# tunnel mpls traffic-eng path-option 1 dynamicrouter-2(config-if)# exitAnd to ensure that packets destined to subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static route, at the device level:
router-2(config)# ip route 26.1.1.0 255.255.255.0 Tunnel2router-2(config)# exitFinally, in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down this tunnel, we disable autoroute announce:
router-2(config)# no tunnel mpls traffic-eng autoroute announceFor Service from Site C to Subnet "Province"
At the inbound physical interface (FE2/1/0):
1.
class-map match-all sla-3-classmatch access-group 1302.
access-list 130 permit ip any 26.1.1.0 0.0.0.2553.
a.
- a rate of 30 million bits per second
- a normal burst of 1 million bytes
- a maximum burst of 2 million bytes
b.
c.
d.
policy-map sla-3-input-policyclass sla-3-classpolice 30000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 \ exceed-action dropclass class-defaultset-mpls-exp-transmit 04.
interface FastEthernet2/1/0service-policy input sla-3-input-policyThe outbound interface POS0/0 is configured as follows:
1.
class-map match-all exp-5-trafficmatch mpls experimental 52.
policy-map output-interface-policyclass exp-5-trafficpriority 323.
interface POS0/0service-policy output output-interface-policyAs a result of all the above configuration lines, packets entering the Head-2 router via interface FE2/1/0 and destined for subnet 26.1.1.0 have their IP precedence field set to 5. It is assumed that no other packets entering this router (on any interface) are using this precedence. (If this cannot be assumed, an additional configuration must be added to mark all such packets with another precedence value.) When exiting this router via interface POS0/0, packets marked with precedence 5 are placed in the priority queue.
Note
Tunnel Midpoint Configuration [Mid-1]
All four interfaces on the midpoint router are configured identically to the outbound interface of the head router (except, of course, for the IDs of the individual interfaces):
Configuring the Pools and Tunnels
At the device level:
router-3(config)# ip cef distributedrouter-3(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-3(config-router)# mpls traffic-eng router-id Loopback0router-3(config-router)# exitCreate a virtual interface:
router-3(config)# interface Loopback0router-3(config-if)# ip address 24.1.1.1 255.255.255.255router-3(config-if)# exitAt the physical interface level (ingress):
router-3(config)# interface pos2/1router-3(config-if)# ip address 10.1.1.2 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitrouter-3(config)# interface pos1/1router-3(config-if)# ip address 11.1.1.2 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the physical interface level (egress):
router-3(config)# interface pos3/1router-3(config-if)# ip address 12.1.1.1 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitrouter-3(config)# interface pos4/1router-3(config-if)# ip address 13.1.1.1 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitTunnel Midpoint Configuration [Mid-2]
Both interfaces on the midpoint router are configured identically to the outbound interface of the head router (except, of course, for the IDs of the individual interfaces):
Configuring the Pools and Tunnel
At the device level:
router-5(config)# ip cef distributedrouter-5(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-5(config-router)# mpls traffic-eng router-id Loopback0router-5(config-router)# exitCreate a virtual interface:
router-5(config)# interface Loopback0router-5(config-if)# ip address 25.1.1.1 255.255.255.255router-5(config-if)# exitAt the physical interface level (ingress):
router-5(config)# interface pos1/1router-5(config-if)# ip address 13.1.1.2 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitAt the physical interface level (egress):
router-5(config)# interface pos2/1router-5(config-if)# ip address 14.1.1.1 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitTunnel Tail Configuration
The inbound interfaces on the tail router are configured identically to the inbound interfaces of the midpoint routers (except, of course, for the ID of each particular interface):
Configuring the Pools and Tunnels
At the device level:
router-4(config)# ip cef distributedrouter-4(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-4(config-router)# mpls traffic-eng router-id Loopback0router-4(config-router)# exitCreate a virtual interface:
router-4(config)# interface Loopback0router-4(config-if)# ip address 27.1.1.1 255.255.255.255router-4(config-if)# exitAt the physical interface (ingress):
router-4(config)# interface pos2/1router-4(config-if)# ip address 12.1.1.2 255.0.0.0router-4(config-if)# mpls traffic-eng tunnelsrouter-4(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitrouter-4(config)# interface pos2/2router-4(config-if)# ip address 14.1.1.2 255.0.0.0router-4(config-if)# mpls traffic-eng tunnelsrouter-4(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitBecause the tunnel ends on the tail (does not include any outbound interfaces of the tail router), no outbound QoS configuration is used.
Example with Many Destination Prefixes
Figure 3 illustrates a topology for guaranteed bandwidth services whose destinations are a set of prefixes. Those prefixes usually share some common properties such as belonging to the same Autonomous System (AS) or transiting through the same AS. Although the individual prefixes may change dynamically because of route flaps in the downstream autonomous systems, the properties the prefixes share will not change. Policies addressing the destination prefix set are enforced through Border Gateway Protocol (BGP), which is described in the following documents:
•
•
•
•
#xtocid89313)In this example, three guaranteed bandwidth services are offered, each coming through a 7500 or a 12000 edge device:
•
•
•
Figure 3 Sample Topology for Guaranteed Bandwidth Service to Many Destination Prefixes
The applicability of guaranteed bandwidth service is not limited to the three types of multiple destination scenarios described above. There is not room in this document to present all possible scenarios. These three were chosen as representative of the wide range of possible deployments.
The guaranteed bandwidth services run through two sub-pool tunnels:
•
•
In addition, a global pool tunnel has been configured from each head end, to carry best-effort traffic to the same destinations. All four tunnels use the same tail router, even though they have different heads and differ in their passage through the midpoints. (Of course in the real world there would be many more midpoints than just the two shown here.)
All POS interfaces in this example are OC3, whose capacity is 155 Mbps.
Configuring a multi-destination guaranteed bandwidth service involves:
a.
b.
c.
d.
All of these tasks are included in the following example.
Configuration of Tunnel Head-1
First we recapitulate commands that establish a sub-pool tunnel (commands presented earlier on page 13) and now we also configure a global pool tunnel. Additionally, we present QoS and BGP commands that guarantee end-to-end service on the sub-pool tunnel. (With the 7500(VIP) router, Modular QoS CLI is used).
Configuring the Pools and Tunnels
At the device level:
router-1(config)# ip cef distributedrouter-1(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-1(config-router)# mpls traffic-eng router-id Loopback0router-1(config-router)# exitCreate a virtual interface:
router-1(config)# interface Loopback0router-1(config-if)# ip address 23.1.1.1 255.255.255.255router-1(config-if)# exitAt the outgoing physical interface:
router-1(config)# interface pos4/0router-1(config-if)# ip address 10.1.1.1 255.0.0.0router-1(config-if)# mpls traffic-eng tunnelsrouter-1(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitAt one tunnel interface, create a sub-pool tunnel:
router-1(config)# interface Tunnel1router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 27.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path1router-1(config-if)# exitand at a second tunnel interface, create a global pool tunnel:
router-1(config)# interface Tunnel2router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 27.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth 80000router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \ best-effort-path1router-1(config-if)# exitIn this example explicit paths are used instead of dynamic, to ensure that best-effort traffic and guaranteed bandwidth traffic will travel along different paths.
At the device level:
router-1(config)# ip explicit-path name gbs-path1router-1(config-ip-expl-path)# next-address 24.1.1.1router-1(config-ip-expl-path)# next-address 27.1.1.1router-1(config-ip-expl-path)# exitrouter-1(config)# ip explicit-path name best-effort-path1router-1(config-ip-expl-path)# next-address 24.1.1.1router-1(config-ip-expl-path)# next-address 25.1.1.1router-1(config-ip-expl-path)# next-address 27.1.1.1router-1(config-ip-expl-path)# exitNote that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other traffic down these tunnels.
Configuring DiffServ QoS
At the inbound physical interface (in Figure 3 this is FE4/1/0), packets received are rate-limited to:
a.
b.
c.
Packets that are mapped to qos-group 6 and that conform to the rate-limit are marked with experimental value 5 and the BGP destination community string, and are forwarded; packets that do not conform (exceed action) are dropped:
router-1(config)# interface FastEthernet4/1/0router-1(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \ conform-action set-mpls-exp-transmit 5 exceed-action droprouter-1(config-if)# bgp-policy destination ip-qos-maprouter-1(config-if)# exitAt the device level create a class of traffic called "exp5-class" that has MPLS experimental bit set to 5:
router-1(config)# class-map match-all exp5-classrouter-1(config-cmap)# match mpls experimental 5router-1(config-cmap)# exitCreate a policy that creates a priority queue for "exp5-class":
router-1(config)# policy-map core-out-policyrouter-1(config-pmap)# class exp5-classrouter-1(config-pmap-c)# priority 100000router-1(config-pmap-c)# exitrouter-1(config-pmap)# class class-defaultrouter-1(config-pmap-c)# bandwidth 55000router-1(config-pmap-c)# exitrouter-1(config-pmap)# exitThe policy is applied to packets exiting the outbound interface POS4/0.
router-1(config)# interface POS4/0router-1(config-if)# service-policy output core-out-policyConfiguring QoS Policy Propagation via BGP
For All GB Services
Create a table map under BGP to map (tie) the prefixes to a qos-group. At the device level:
router-1(config)# ip bgp-community new-formatrouter-1(config)# router bgp 2router-1(config-router)# no synchronizationrouter-1(config-router)# table-map set-qos-grouprouter-1(config-router)# bgp log-neighbor-changesrouter-1(config-router)# neighbor 27.1.1.1 remote-as 2router-1(config-router)# neighbor 27.1.1.1 update-source Loopback0router-1(config-router)# no auto-summaryrouter-1(config-router)# exitFor GB Service Destined to AS5
Create a distinct route map for this service. This includes setting the next-hop of packets matching 29.1.1.1 so they will be mapped onto Tunnel #1 (the guaranteed bandwidth service tunnel). At the device level:
router-1(config)# route-map set-qos-group permit 10router-1(config-route-map)# match as-path 100router-1(config-route-map)# set ip qos-group 6router-1(config-route-map)# set ip next-hop 29.1.1.1router-1(config-route-map)# exitrouter-1(config)# ip as-path access-list 100 permit ^5$For GB Service Transiting through AS5
Create a distinct route map for this service. (Its traffic will go to AS6 and AS7).
At the device level:
router-1(config)# route-map set-qos-group permit 10router-1(config-route-map)# match as-path 101router-1(config-route-map)# set ip qos-group 6router-1(config-route-map)# set ip next-hop 29.1.1.1router-1(config-route-map)# exitrouter-1(config)# ip as-path access-list 101 permit _5_For GB Service Destined to Community 100:1
Create a distinct route map for all traffic destined to prefixes that have community value 100:1. This traffic will go to AS3, AS5, and AS8.
At the device level:
router-1(config)# route-map set-qos-group permit 10router-1(config-route-map)# match community 20router-1(config-route-map)# set ip qos-group 6router-1(config-route-map)# set ip next-hop 29.1.1.1router-1(config-route-map)# exitrouter-1(config)# ip community-list 20 permit 100:1Mapping Traffic onto the Tunnels
Map all guaranteed bandwidth traffic onto Tunnel #1:
router-1(config)# ip route 29.1.1.1 255.255.255.255 Tunnel1Map all best-effort traffic onto Tunnel #2:
router-1(config)# ip route 30.1.1.1 255.255.255.255 Tunnel2Configuration of Tunnel Head-2
As with the Head-1 device and interfaces, the following Head-2 configuration first presents commands that establish a sub-pool tunnel (commands presented earlier on page 13) and then also configures a global pool tunnel. After that it presents QoS and BGP commands that guarantee end-to-end service on the sub-pool tunnel. (Because this is a 7500 (VIP) router, Modular QoS CLI is used).
Configuring the Pools and Tunnels
At the device level:
router-2(config)# ip cef distributedrouter-2(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-2(config-router)# mpls traffic-eng router-id Loopback0router-2(config-router)# exitCreate a virtual interface:
router-2(config)# interface Loopback0router-2(config-if)# ip address 22.1.1.1 255.255.255.255router-2(config-if)# exitAt the outgoing physical interface:
router-2(config)# interface pos0/0router-2(config-if)# ip address 11.1.1.1 255.0.0.0router-2(config-if)# mpls traffic-eng tunnelsrouter-2(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-2(config-if)# ip router isis[and in all cases]:router-2(config-if)# exitAt one tunnel interface, create a sub-pool tunnel:
router-2(config)# interface Tunnel3router-2(config-if)# ip unnumbered Loopback0router-2(config-if)# tunnel destination 27.1.1.1router-2(config-if)# tunnel mode mpls traffic-engrouter-2(config-if)# tunnel mpls traffic-eng priority 0 0router-2(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path2router-2(config-if)# exitand at a second tunnel interface, create a global pool tunnel:
router-2(config)# interface Tunnel4router-2(config-if)# ip unnumbered Loopback0router-2(config-if)# tunnel destination 27.1.1.1router-2(config-if)# tunnel mode mpls traffic-engrouter-2(config-if)# tunnel mpls traffic-eng priority 0 0router-2(config-if)# tunnel mpls traffic-eng bandwidth 70000router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \ best-effort-path2router-2(config-if)# exitIn this example explicit paths are used instead of dynamic, to ensure that best-effort traffic and guaranteed bandwidth traffic will travel along different paths.
At the device level:
router-2(config)# ip explicit-path name gbs-path2router-2(config-ip-expl-path)# next-address 24.1.1.1router-2(config-ip-expl-path)# next-address 27.1.1.1router-2(config-ip-expl-path)# exitrouter-2(config)# ip explicit-path name best-effort-path2router-2(config-ip-expl-path)# next-address 24.1.1.1router-2(config-ip-expl-path)# next-address 25.1.1.1router-2(config-ip-expl-path)# next-address 27.1.1.1router-2(config-ip-expl-path)# exitNote that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other traffic down these tunnels.
Configuring DiffServ QoS
At the inbound physical interface (in Figure 3 this is FE2/1), packets received are rate-limited to:
a.
b.
c.
Packets that are mapped to qos-group 6 and that conform to the rate-limit are marked with experimental value 5 and the BGP destination community string, and are forwarded; packets that do not conform (exceed action) are dropped:
router-2(config)# interface FastEthernet2/1router-2(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \ conform-action set-mpls-exp-transmit 5 exceed-action droprouter-2(config-if)# bgp-policy destination ip-qos-maprouter-1(config-if)# exitAt the device level create a class of traffic called "exp5-class" that has MPLS experimental bit set to 5:
router-2(config)# class-map match-all exp5-classrouter-2(config-cmap)# match mpls experimental 5router-2(config-cmap)# exitCreate a policy that creates a priority queue for "exp5-class":
router-2(config)# policy-map core-out-policyrouter-2(config-pmap)# class exp5-classrouter-2(config-pmap-c)# priority 100000router-2(config-pmap-c)# exitrouter-2(config-pmap)# class class-defaultrouter-2(config-pmap-c)# bandwidth 55000router-2(config-pmap-c)# exitrouter-2(config-pmap)# exitThe policy is applied to packets exiting interface POS0/0:
interface POS0/0service-policy output core-out-policyAs a result of all the above configuration lines, packets entering the Head-2 router via interface FE2/1 and destined for AS5, BGP community 100:1, or transiting AS5 will have their experimental field set to 5. It is assumed that no other packets entering this router (on any interface) are using this exp bit value. (If this cannot be assumed, an additional configuration must be added to mark all such packets with another experimental value.) When exiting this router via interface POS0/0, packets marked with experimental value 5 are placed into the priority queue.
Note
Configuring QoS Policy Propagation via BGP
For All GB Services
Create a table map under BGP to map (tie) the prefixes to a qos-group. At the device level:
router-2(config)# ip bgp-community new-formatrouter-2(config)# router bgp 2router-2(config-router)# no synchronizationrouter-2(config-router)# table-map set-qos-grouprouter-2(config-router)# bgp log-neighbor-changesrouter-2(config-router)# neighbor 27.1.1.1 remote-as 2router-2(config-router)# neighbor 27.1.1.1 update-source Loopback0router-2(config-router)# no auto-summaryrouter-2(config-router)# exitFor GB Service Destined to AS5
Create a distinct route map for this service. This includes setting the next-hop of packets matching 29.1.1.1 so they will be mapped onto Tunnel #3 (the guaranteed bandwidth service tunnel). At the device level:
router-2(config)# route-map set-qos-group permit 10router-2(config-route-map)# match as-path 100router-2(config-route-map)# set ip qos-group 6router-2(config-route-map)# set ip next-hop 29.1.1.1router-2(config-route-map)# exitrouter-2(config)# ip as-path access-list 100 permit ^5$For GB Service Transiting through AS5
Create a distinct route map for this service. (Its traffic will go to AS6 and AS7).
At the device level:
router-2(config)# route-map set-qos-group permit 10router-2(config-route-map)# match as-path 101router-2(config-route-map)# set ip qos-group 6router-2(config-route-map)# set ip next-hop 29.1.1.1router-2(config-route-map)# exitrouter-2(config)# ip as-path access-list 101 permit _5_For GB Service Destined to Community 100:1
Create a distinct route map for all traffic destined to prefixes that have community value 100:1. This traffic will go to AS3, AS5, and AS8.
At the device level:
router-2(config)# route-map set-qos-group permit 10router-2(config-route-map)# match community 20router-2(config-route-map)# set ip qos-group 6router-2(config-route-map)# set ip next-hop 29.1.1.1router-2(config-route-map)# exitrouter-2(config)# ip community-list 20 permit 100:1Mapping the Traffic onto the Tunnels
Map all guaranteed bandwidth traffic onto Tunnel #3:
router-2(config)# ip route 29.1.1.1 255.255.255.255 Tunnel3Map all best-effort traffic onto Tunnel #4:
router-2(config)# ip route 30.1.1.1 255.255.255.255 Tunnel4Tunnel Midpoint Configuration [Mid-1]
All four interfaces on the midpoint router are configured very much like the outbound interface of the head router. The strategy is to have all mid-point routers in this Autonomous System ready to carry future as well as presently configured sub-pool and global pool tunnels.
Configuring the Pools and Tunnels
At the device level:
router-3(config)# ip cef distributedrouter-3(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-3(config-router)# mpls traffic-eng router-id Loopback0router-3(config-router)# exitCreate a virtual interface:
router-3(config)# interface Loopback0router-3(config-if)# ip address 24.1.1.1 255.255.255.255router-3(config-if)# exitAt the physical interface level (ingress):
router-3(config)# interface pos2/1router-3(config-if)# ip address 10.1.1.2 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitrouter-3(config)# interface pos1/1router-3(config-if)# ip address 11.1.1.2 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the physical interface level (egress), through which two sub-pool tunnels currently exit:
router-3(config)# interface pos3/1router-3(config-if)# ip address 12.1.1.1 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the physical interface level (egress), through which two global pool tunnels currently exit:
router-3(config)# interface pos4/1router-3(config-if)# ip address 13.1.1.1 255.0.0.0router-3(config-if)# mpls traffic-eng tunnelsrouter-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitTunnel Midpoint Configuration [Mid-2]
Both interfaces on this midpoint router are configured like the outbound interfaces of the Mid-1 router.
Configuring the Pools and Tunnels
At the device level:
router-5(config)# ip cef distributedrouter-5(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-5(config-router)# mpls traffic-eng router-id Loopback0router-5(config-router)# exitCreate a virtual interface:
router-5(config)# interface Loopback0router-5(config-if)# ip address 25.1.1.1 255.255.255.255router-5(config-if)# exitAt the physical interface level (ingress):
router-5(config)# interface pos1/1router-5(config-if)# ip address 13.1.1.2 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitAt the physical interface level (egress):
router-5(config)# interface pos2/1router-5(config-if)# ip address 14.1.1.1 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitTunnel Tail Configuration
The inbound interfaces on the tail router are configured much like the outbound interfaces of the midpoint routers:
Configuring the Pools and Tunnels
At the device level:
router-4(config)# ip cef distributedrouter-4(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right. In the case of OSPF, one must advertise two new loopback interfaces—29.1.1.1 and 30.1.1.1 in our example—which are defined in the QoS Policy Propagation section, further along on this page]
:
[now one resumes the common command set, taking care to include the two additional loopback interfaces]:
router-4(config-router)# mpls traffic-eng router-id Loopback0router-4(config-router)# mpls traffic-eng router-id Loopback1router-4(config-router)# mpls traffic-eng router-id Loopback2router-4(config-router)# exitCreate a virtual interface:
router-4(config)# interface Loopback0router-4(config-if)# ip address 27.1.1.1 255.255.255.255router-4(config-if)# exitAt the physical interface (ingress):
router-4(config)# interface pos2/1router-4(config-if)# ip address 12.1.1.2 255.0.0.0router-4(config-if)# mpls traffic-eng tunnelsrouter-4(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitrouter-4(config)# interface pos2/2router-4(config-if)# ip address 14.1.1.2 255.0.0.0router-4(config-if)# mpls traffic-eng tunnelsrouter-4(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitConfiguring QoS Policy Propagation
On the tail device, one must configure a separate virtual loopback IP address for each class-of-service terminating here. The headend routers need these addresses to map traffic into the proper tunnels. In the current example, four tunnels terminate on the same tail device but they represent only two service classes, so only two additional loopback addresses are needed:
Create two virtual interfaces:
router-4(config)# interface Loopback1router-4(config-if)# ip address 29.1.1.1 255.255.255.255[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitrouter-4(config)# interface Loopback2router-4(config-if)# ip address 30.1.1.1 255.255.255.255[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitAt the device level, configure BGP to send the community to each tunnel head:
router-4(config)# ip bgp-community new-formatrouter-4(config)# router bgp 2router-4(config-router)# neighbor 23.1.1.1 send-communityrouter-4(config-router)# neighbor 22.1.1.1 send-communityrouter-4(config-router)# exitCommand Reference
This section documents only commands that are new or modified.
•
•
•
ip rsvp bandwidth
To enable Resource Reservation Protocol (RSVP) for IP on an interface, use the ip rsvp bandwidth command in interface configuration mode. To disable RSVP completely, use the no form of this command. To eliminate only the subpool portion of the bandwidth, use the no form of this command with the sub-pool keyword.
ip rsvp bandwidth [interface-kbps] [single-flow-kbps] [ [rdm kbps {[subpool kbps] | [bc1 subpool]}] | [mam max-reservable-bw kbps bc0 kbps bc1 kbps] ]
no ip rsvp bandwidth [interface-kbps] [single-flow-kbps] [ [rdm kbps {[subpool kbps] | [bc1 subpool]}] | [mam max-reservable-bw kbps bc0 kbps bc1 kbps] ]
Syntax Description
Defaults
RSVP is disabled by default.
If the ip rsvp bandwidth command is entered but no bandwidth values are supplied (for example, ip rsvp bandwidth is entered followed by pressing the Enter key), a default bandwidth value (that is, 75% of the link bandwidth) is assumed for both the interface-kbps and single-flow-kbps arguments.
Command Modes
Interface configuration
Command History
Usage Guidelines
RSVP cannot be configured with distributed Cisco Express Forwarding (dCEF).
RSVP is disabled by default to allow backward compatibility with systems that do not implement RSVP.
Weighted Random Early Detection (WRED) or fair queueing must be enabled first.
When you issue the ip rsvp bandwidth command, the RSVP bandwidth pool adjusts dynamically when the bandwidth of the interface changes.
When using this command for DiffServ-aware traffic engineering (DS-TE) in IETF Standard mode, you must use either rdm and its arguments or mam and its arguments; you cannot use both. For more details about each alternative, see Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering ed. by F. Le Faucheur (RFC 4127) and Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering by F. Le Faucheur & W. Lai (RFC 4125).
Examples
The following example shows a T1 (1536 kbps) link configured to permit RSVP reservation of up to 1158 kbps, but no more than 100 kbps for any given flow on serial interface 0. Fair queueing is configured with 15 reservable queues to support those reserved flows, should they be required.
Router(config)# interface serial 0Router(config-if)# fair-queue 64 256 15Router(config-if)# ip rsvp bandwidth 1158 100Related Commands
mpls traffic-eng ds-te bc-model
To enable a Bandwidth Constraints Model to be used by a router in DiffServ-aware Traffic Engineering, use the mpls traffic-eng ds-te bc-model global configuration command. (Using the no form of this command selects the default model, which is the Russian Dolls Model.)
mpls traffic-eng ds-te bc-model [rdm | mam]
no mpls traffic-eng ds-te bc-model [ rdm | mam ]
Syntax Description
rdm
Russian Dolls Model. (Described in IETF RFC 4127).
mam
Maximum Allocation Model. (Described in IETF RFC 4125).
Defaults
Russian Dolls Model is the default.
Command Modes
Global configuration
Command History
Usage Guidelines
1.
2.
Examples
In the following example,the Maximum Allocation Model is being selected:
Router(config)# mpls traffic-eng ds-te bc-model mammpls traffic-eng ds-te mode
To configure a router to enter DiffServ-aware Traffic Engineering modes which incorporate degrees of the IETF Standard, use the mpls traffic-eng ds-te mode global configuration command. Use the no form of this command to return the router to the pre-IETF-Standard mode.
mpls traffic-eng ds-te mode [migration | ietf]
no mpls traffic-eng ds-te mode [migration | ietf ]
Syntax Description
Defaults
Pre-IETF-Standard mode is the default.
Command Modes
Global configuration
Command History
Usage Guidelines
1.
2.
Examples
In the following example, the router is configured to operate in Migration Mode:
Router(config)# mpls traffic-eng ds-te migrationshow mpls traffic-eng topology
To display the MPLS traffic engineering global topology as currently known at this node, use the show mpls traffic-eng topology command in privileged EXEC mode.
show mpls traffic-eng topology {A.B.C.D | igp-id {isis nsapaddr | ospf A.B.C.D}} [brief] [model-id{mam | rdm}]
Syntax Description
Command Modes
Privileged EXEC
Command History
Examples
The following example shows output from the show mpls traffic-eng topology command:
Router# show mpls traffic-eng topologyMy_System_id: 0000.0000.0001.00 (isis 1 level-2)My_System_id: 10.10.10.10 (ospf 100 area 0)My_BC_Model_Type: MAMSignalling error holddown: 10 sec Global Link Generation 56IGP Id: 0000.0000.0001.00, MPLS TE Id: 10.10.10.10 Router Node (isis 1 level-2)Link[0]:Point-to-Point, Nbr IGP Id:0000.0000.0002.00, Nbr Node Id:6, gen:56Frag Id:0, Intf Address:7.2.2.1, Intf Id:0Nbr Intf Address:7.2.2.2, Nbr Intf Id:0TE Metric:10, IGP Metric:10, Attribute Flags:0x0Switching Capability:, Encoding:BC Model ID:MAMPhysical BW:155520 (kbps), Max Reservable BW:1000 (kbps)BC0:600 (kbps) BC1:400 (kbps)Total Allocated ReservableBW (kbps) BW (kbps)--------------- -----------TE-class[0]: 0 600TE-class[1]: 0 400TE-class[2]: 0 0TE-class[3]: 0 0TE-class[4]: 0 600TE-class[5]: 0 400TE-class[6]: 0 0TE-class[7]: 0 0Link[1]:Point-to-Point, Nbr IGP Id:0000.0000.0002.00, Nbr Node Id:6, gen:56Frag Id:0, Intf Address:7.1.1.1, Intf Id:0Nbr Intf Address:7.1.1.2, Nbr Intf Id:0TE Metric:10, IGP Metric:10, Attribute Flags:0x0Switching Capability:, Encoding:BC Model ID:MAMPhysical BW:155520 (kbps), Max Reservable BW:1000 (kbps)BC0:600 (kbps) BC1:400 (kbps)Total Allocated ReservableBW (kbps) BW (kbps)--------------- -----------TE-class[0]: 10 590TE-class[1]: 0 400TE-class[2]: 0 0TE-class[3]: 0 0TE-class[4]: 0 600TE-class[5]: 0 400TE-class[6]: 0 0TE-class[7]: 0 0Table 3 describes significant fields shown in the display.
Related Commands
tunnel mpls traffic-eng bandwidth
To configure bandwidth required for an MPLS traffic engineering tunnel, use the tunnel mpls traffic-eng bandwidth command in interface configuration mode. To disable this feature, use the no form of this command.
tunnel mpls traffic-eng bandwidth [sub-pool | class-type1] bandwidth
no tunnel mpls traffic-eng bandwidth [sub-pool | class-type1] bandwidth
Syntax Description
Defaults
Default bandwidth is 0.
Default is a global pool tunnel.
Command Modes
Interface configuration
Command History
12.0(5)S
This command was introduced.
12.0(11)ST
Sub-pool option was added.
12.2(33)SRB
Class-type1 keyword was added and global keyword was eliminated.
Usage Guidelines
Enter the bandwidth for either a global pool (BC0) or sub-pool (BC1) tunnel, not both in the same statement. To specify both pools, you need to use this command twice, once with the sub-pool or class-type1 keyword to specify the narrower tunnel, and once without those keywords to specify the larger tunnel.
Related Commands
Glossary
This section defines acronyms and words that may not be readily understood.
AS—Autonomous System. A collection of networks under a common administration, sharing a common routing strategy and identified by a unique 16-bit number (assigned by the Internet Assigned Numbers Authority).
BGP—Border Gateway Protocol. The predominant interdomain routing protocol. It is defined by RFC 1163. Version 4 uses route aggregation mechanisms to reduce the size of routing tables.
CBR—Constraint Based Routing. The computation of traffic paths that simultaneously satisfy label-switched path attributes and current network resource limitations.
CEF—Cisco Express Forwarding. A means for accelerating the forwarding of packets within a router, by storing route lookup information in several data structures instead of in a route cache.
CLI—Command Line Interface. Cisco's interface for configuring and managing its routers.
DS-TE—Diff Serv-aware Traffic Engineering. The capability to configure two bandwidth pools on each link, a global pool and a sub-pool. MPLS traffic engineering tunnels using the sub-pool bandwidth can be configured with Quality of Service mechanisms to deliver guaranteed bandwidth services end-to-end across the network. Simultaneously, tunnels using the global pool can convey DiffServ traffic.
flooding—A traffic passing technique used by switches and bridges in which traffic received on an interface is sent out through all of the interfaces of that device except the interface on which the information was originally received.
GB queue—Guaranteed Bandwidth queue. A per-hop behavior (PHB) used exclusively by the strict guarantee traffic. If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue (EF PHB) is used. If only bandwidth guarantees are sought, the diffserv Assured Forwarding PHB (AF PHB) is used.
Global Pool—The total bandwidth allocated to an MPLS traffic engineering link.
IGP—Interior Gateway Protocol. An internet protocol used to exchange routing information within an autonomous system. Examples of common internet IGPs include IGRP, OSPF, and RIP.
label-switched path (LSP) tunnel—A configured connection between two routers, using label switching to carry the packets.
IS-IS—Intermediate System-to-Intermediate System. A link-state hierarchical routing protocol, based on DECnet Phase V routing, whereby nodes exchange routing information based on a single metric, to determine network topology.
LCAC—Link-level (per-hop) call admission control.
LSP—Label-switched path (see above).
Also Link-state packet—A broadcast packet used by link-state protocols that contains information about neighbors and path costs. LSPs are used by the receiving routers to maintain their routing tables. Also called link-state advertisement (LSA).MPLS—Multi-Protocol Label Switching (formerly known as Tag Switching). A method for directing packets primarily through Layer 2 switching rather than Layer 3 routing, by assigning the packets short fixed-length labels at the ingress to an MPLS cloud, using the concept of forwarding equivalence classes. Within the MPLS domain, the labels are used to make forwarding decisions mostly without recourse to the original packet headers.
MPLS TE—MPLS Traffic Engineering (formerly known as "RRR" or Resource Reservation Routing). The use of label switching to improve traffic performance along with an efficient use of network resources.
OSPF—Open Shortest Path First. A link-state, hierarchical IGP routing algorithm, derived from the IS-IS protocol. OSPF features include least-cost routing, multipath routing, and load balancing.
RSVP—Resource reSerVation Protocol. An IETF protocol used for signaling requests (to set aside internet services) by a customer before that customer is permitted to transmit data over that portion of the network.
Sub-pool—The more restrictive bandwidth in an MPLS traffic engineering link. The sub-pool is a portion of the link's overall global pool bandwidth.
TE—Traffic engineering. The application of scientific principles and technology to measure, model, and control internet traffic in order to simultaneously optimize traffic performance and network resource utilization.
Note
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.
Feedback