Table Of Contents
Diff-Serv-aware Traffic Engineering (DS-TE)
Related Features and Technologies
Platforms and Interfaces Supported
The tunnel mpls traffic-eng bandwidth command
Level 1: Configuring the Device
Level 2: Configuring the Physical Interface
Level 3: Configuring the Tunnel Interface
Guaranteed Bandwidth Service Configuration
Guaranteed Bandwidth Service Example
Tunnel Head Configuration (Head-1)
Tunnel Head Configuration (Head-2)
Tunnel Midpoint Configuration [Mid-1]
Tunnel Midpoint Configuration [Mid-2]
mpls traffic-eng administrative-weight
mpls traffic-eng attribute-flags
mpls traffic-eng backup-path tunnel
mpls traffic-eng flooding thresholds
mpls traffic-eng link timers bandwidth-hold
mpls traffic-eng link timers periodic-flooding
mpls traffic-eng reoptimize timers frequency
show mpls traffic-eng autoroute
show mpls traffic-eng fast-reroute database
show mpls traffic-eng fast-reroute log reroutes
show mpls traffic-eng link-management admission-control
show mpls traffic-eng link-management advertisements
show mpls traffic-eng link-management bandwidth-allocation
show mpls traffic-eng link-management igp-neighbors
show mpls traffic-eng link-management interfaces
show mpls traffic-eng link-management summary
show mpls traffic-eng topology
tunnel mpls traffic-eng affinity
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric
tunnel mpls traffic-eng bandwidth
tunnel mpls traffic-eng fast-reroute
tunnel mpls traffic-eng path-option
tunnel mpls traffic-eng priority
debug mpls traffic-eng link-management preemption
Diff-Serv-aware Traffic Engineering (DS-TE)
This guide presents extensions made recently to Multiprotocol Label Switching Traffic Engineering (MPLS TE) that make it Diff-Serv aware. Specifically, the bandwidth reservable on each link for constraint-based routing (CBR) purposes can now be managed through two bandwidth pools: a global pool and a sub-pool. 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.
The guide contains the following sections:
•
Background and Overview, page 1
•
Platforms and Interfaces Supported, page 3
•
Configuration Examples, page 12
Note
References made to specific page numbers are meant to help readers of the printed (Acrobat™ .PDF) form of this guide. On-line readers may simply click on the page number (or the underlined, colored, or bolded text) to go to the referenced page.
Background and Overview
MPLS traffic engineering allows constraint-based routing of IP traffic. One of the constraints satisfied by CBR is the availability of required bandwidth over a selected path. Diff-Serv-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.) 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 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.
DS-TE involves extending OSPF (Open Shortest Path First routing protocol), so that the available sub-pool 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.
Benefits
Diff-Serv-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:
•
Develop QoS services for end customers based on signaled rather than provisioned QoS
•
Build the higher-revenue generating "strict-commitment" QoS services, without over-provisioning
•
Offer virtual IP leased-line, Layer 2 service emulation, and point-to-point guaranteed bandwidth services including voice-trunking
•
Enjoy the scalability properties offered by MPLS
Related Features and Technologies
The DS-TE feature is related to OSPF, 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:
•
"Configuring OSPF" in Cisco IOS Release 12.1 IP and IP Routing Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1cdospf.htm•
"OSPF Commands" in Cisco IOS Release 12.1 IP and IP Routing Command Reference, http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdospf.htm
For RSVP:
•
"Configuring RSVP" in Cisco IOS Release 12.1 Quality of Service Solutions Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt5/qcdrsvp.htm•
IP RSVP commands section in Cisco IOS Release 12.1 Quality of Service Solutions Command Reference, http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/qrdcmd2.htm
For QoS:
•
Cisco IOS Release 12.1 Quality of Service Solutions Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/index.htm•
Cisco IOS Release 12.1 Quality of Service Solutions Command Reference,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/index.htmFor MPLS Traffic Engineering:
•
Cisco IOS Release 12.1(3)T MPLS Traffic Engineering and Enhancements,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/traffeng.htm•
"Multiprotocol Label Switching" in Cisco IOS Release 12.1 Switching Services Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/switch_c/xcprt4•
Section containing MPLS commands in Cisco IOS Release 12.1 Switching Services Command Reference,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/switch_r/xrdscmd3.htmPlatforms and Interfaces Supported
This release supports DS-TE together with QoS on POS (Packet over Sonet) interfaces on the Cisco 12000 Series Gigabit Switch Router (GSR), with Engine 0 on edge (access) interfaces and Engine 2 on core (backbone) interfaces.
Supported Standards
Standardization of Diff-Serv-aware MPLS Traffic Engineering is still in progress in the IETF (Internet Engineering Task Force). At the time of publication of this feature guide, DS-TE has been documented in the following IETF drafts:
•
Requirements for Support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki & M. Tatham
http://search.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-reqts-00.txt•
Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki & M. Tatham
http://search.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-ext-00.txt•
Extensions to OSPF for Support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend & D. Skalecki
http://search.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ospf-00.txtAs the IETF work is still in progress, details are still under definition and subject to change, so DS-TE should be considered as a pre-standard implementation of IETF Diff-Serv-aware MPLS Traffic Engineering. However, it is in line with the requirements described in the first document above. The concept of "Class-Type" defined in that IETF draft corresponds to the concept of bandwidth pool implemented by DS-TE. And because DS-TE supports two bandwidth pools (global pool and sub-pool), DS-TE should be seen as supporting two Class-Types (Class-Type 0 and Class-Type 1).
Prerequisites
Your network must support the following Cisco IOS features in order to support guaranteed bandwidth services based on Diff-Serv-aware Traffic Engineering:
•
MPLS
•
IP Cisco Express Forwarding (CEF)
•
OSPF
•
RSVP
•
QoS
Configuration Tasks
This section lists the minimum set of commands you need to implement the Diff-Serv-aware Traffic Engineering feature—in other words, to establish a tunnel that reserves bandwidth from the sub-pool.
The subsequent "Configuration Examples" section (page 10), presents these same commands in context and shows how, by combining them with QoS commands, you can build guaranteed bandwidth services.
New Commands
DS-TE commands were developed from the existing command set that configures MPLS traffic engineering. The only difference introduced to create DS-TE was the expansion of two commands:
•
ip rsvp bandwidth was expanded to configure the size of the sub-pool on every link.
•
tunnel mpls traffic-eng bandwidth was expanded to enable a TE tunnel to reserve bandwidth from the sub-pool.
The ip rsvp bandwidth command
The old command was
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)
Now the extended command is
ip rsvp bandwidth x y sub-pool zwhere x = the size of the global pool, and z = the size of the sub-pool.
(Remember, the sub-pool's bandwidth is less than—because it is part of—the global pool's bandwidth.)
The tunnel mpls traffic-eng bandwidth command
The old command was
tunnel mpls traffic-eng bandwidth bwhere b = the amount of bandwidth this tunnel requires.
Now you specify from which pool (global or sub) the tunnel's bandwidth is to come. You can enter
tunnel mpls traffic-eng bandwidth sub-pool bThis indicates that the tunnel should use bandwidth from the sub-pool. Alternatively, you can enter
tunnel mpls traffic-eng bandwidth bThis indicates that the tunnel should use bandwidth from the global pool (the default).
The Configuration Procedure
To establish a sub-pool TE tunnel, you must enter configurations at three levels:
•
the device (router or switch router)
•
the physical interface
•
the tunnel interface
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, refer to the page given in the right-hand column.
Level 1: Configuring the Device
At this level, you tell the device (switch router) to use accelerated packet-forwarding (known as Cisco Express Forwarding or CEF), MultiProtocol Label Switching (MPLS), traffic-engineering tunneling, and the Open Shortest Path First (OSPF) routing algorithm. This level is often called global configuration mode because the configuration is applied globally, to the entire device, rather than to a specific interface or routing instance. (These commands have not been modified from earlier releases of Cisco IOS.)
You enter the following commands:
Command PurposeStep 1
Router(config)# ip cefEnables CEF—which accelerates the flow of packets through the device. (More on page 30.)
Step 2
Router(config)# mpls traffic-eng tunnelsEnables MPLS, and specifically its traffic engineering tunnel capability. (More on page 44.)
Step 3
Router(config)# router ospfInvokes the OSPF routing process for IP and puts the device into router configuration mode. (More on page 46.)
Step 4
Router(config-router)# mpls traffic-eng area numTurns on MPLS traffic engineering for a particular OSPF area. (More on page 35.)
Step 5
Router(config-router)# mpls traffic-eng router-id loopback0Specifies that the traffic engineering router identifier is the IP address associated with the loopback0 interface. (More on page 43.)
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 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.
Finally, you enable the MPLS traffic engineering tunnel feature on this physical interface.
To accomplish these tasks, you enter the following commands:
Command PurposeStep 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. (More on page 26.)
Step 2
Router(config-if)# ip rsvp bandwidth interface-kbps sub-pool kbps
Enables RSVP on this interface 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, and the sum of bandwidth used by all sub-pool tunnels cannot exceed sub-pool kbps. (More on page 32.)
Step 3
Router(config-if)# mpls traffic-eng tunnelsEnables the MPLS traffic engineering tunnel feature on this interface. (More on page 45.)
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).
The only command which was modified at this level for DS-TE is tunnel mpls traffic-eng bandwidth (described in detail on page 96).
You enter the following commands:
Command PurposeStep 1
Router(config)# interface tunnel1Creates a tunnel interface (named in this example tunnel1) and enters interface configuration mode. (More on page 26.)
Step 2
Router(config-if)# tunnel destination A.B.C.DSpecifies the IP address of the tunnel tail device. (More on page 90.)
Step 3
Router(config-if)# tunnel mode mpls traffic-engSets the tunnel's encapsulation mode to MPLS traffic engineering. (More on page 92.)
Step 4
Router(config-if)# tunnel mpls traffic-eng bandwidth {sub-pool | [global]} bandwidthConfigures the tunnel's bandwidth and assigns it either to the sub-pool or the global pool. (More on page 96).
Step 5
Router(config-if)# tunnel mpls traffic-eng prioritySets the priority to be used when system determines which existing tunnels are eligible to be preempted. (More on page 100).
Step 6
Router(config-if)# tunnel mpls traffic-eng path-optionConfigures 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). (More on page 98).
Verifying the Configurations
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 two commands. To see an explanation of each field used in the following displays turn to page 47 for show interfaces tunnel and page 61 for show ip rsvp interface.
GSR1#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 restartsGSR1#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 (a table explaining the display fields begins on page 88):
GSR1#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).
GSR1#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:
GSR1#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. (That command is described on page 85.)
Additionally, you can use any of the following show commands to inspect particular aspects of the network, router, or interface concerned:
To see information about... Use this command this level and this item...Network
Advertised bandwidth allocation information
show mpls traffic-eng link-management advertisements (described on page 72)
Preemptions along the tunnel path
debug mpls traffic-eng link-management preemption (described on 103)
Available TE link band- width on all head routers
show mpls traffic-eng topology (described on page 85)
Router
Status of all tunnels cur- rently signalled by this router
show mpls traffic-eng link-management admission-control (described on page 70)
Tunnels configured on midpoint routers
show mpls traffic-eng link-management summary
(described on page 83)Physical interface
Detailed information on current bandwidth pools
show mpls traffic-eng link-management bandwidth-allocation [interface-name]
(described on page 75)TE RSVP bookkeeping
show mpls traffic-eng link-management interfaces
(described on page 81)Entire configuration of one interface
show run interface
Configuration Examples
This section first presents the DS-TE configuration 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.
DS-TE Configuration
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 physical interfaces must be configured, for traffic ingress and egress.
Figure 1 Sample Tunnel Topology
Tunnel Head
At the device level:
gsr-68-1# configure terminalgsr-68-1(config)# ip cefgsr-68-1(config)# mpls traffic-eng tunnelsgsr-68-1(config)# router ospf 100gsr-68-1(config-router)# redistribute connectedgsr-68-1(config-router)# network 11.1.1.0 0.0.0.255 area 0gsr-68-1(config-router)# network 23.1.1.1 0.0.0.0 area 0gsr-68-1(config-router)# mpls traffic-eng router-id Loopback0gsr-68-1(config-router)# mpls traffic-eng area 0gsr-68-1(config-router)# exitgsr-68-1(config)# interface Loopback0At the physical interface level (internal):
gsr-68-1(config-if)# ip address 23.1.1.1 255.255.255.255gsr-68-1(config-if)# no ip directed-broadcastgsr-68-1(config-if)# exitAt the device level:
gsr-68-1(config)# interface POS3/0At the physical interface level (egress):
gsr-68-1(config-if)# ip address 11.1.1.1 255.255.255.0gsr-68-1(config-if)# mpls traffic-eng tunnelsgsr-68-1(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000gsr-68-1(config-if)# exitAt the device level:
gsr-68-1(config)# interface Tunnel1At the tunnel interface level:
gsr-68-1(config-if)# ip unnumbered Loopback0gsr-68-1(config-if)# tunnel destination 24.1.1.1gsr-68-1(config-if)# tunnel mode mpls traffic-enggsr-68-1(config-if)# tunnel mpls traffic-eng priority 0 0gsr-68-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000gsr-68-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamicgsr-68-1(config-if)# exitgsr-68-1(config)#Midpoint Devices
At the device level:
gsr-68-2# configure terminalgsr-68-2(config)# ip cefgsr-68-2(config)# mpls traffic-eng tunnelsgsr-68-2(config)# router ospf 100gsr-68-2(config-router)# network 10.1.1.0 0.0.0.255 area 0gsr-68-2(config-router)# network 11.1.1.0 0.0.0.255 area 0gsr-68-2(config-router)# network 12.1.1.0 0.0.0.255 area 0gsr-68-2(config-router)# network 25.1.1.1 0.0.0.0 area 0gsr-68-2(config-router)# mpls traffic-eng router-id Loopback0gsr-68-2(config-router)# mpls traffic-eng area 0gsr-68-2(config-router)# exitgsr-68-2(config)# interface Loopback0At the physical interface level (internal):
gsr-68-2(config-if)# ip address 25.1.1.1 255.255.255.255gsr-68-2(config-if)# no ip directed-broadcastgsr-68-2(config-if)# exitAt the device level:
gsr-68-2(config)# interface POS4/0At the physical interface level (ingress):
gsr-68-2(config-if)# ip address 11.1.1.2 255.255.255.0gsr-68-2(config-if)# mpls traffic-eng tunnelsgsr-68-2(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000gsr-68-2(config-if)# exitAt the device level:
gsr-68-2(config)# interface POS4/1At the physical interface level (egress):
gsr-68-2(config-if)# ip address 12.1.1.2 255.255.255.0gsr-68-2(config-if)# mpls traffic-eng tunnelsgsr-68-2(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000gsr-68-2(config-if)# exitNote that there is no configuring of tunnel interfaces at the mid-point devices, only physical interfaces and the device globally.
Tail-End Device
At the device level:
gsr-69-1# configure terminalgsr-69-1(config)# ip cefgsr-69-1(config)# mpls traffic-eng tunnelsgsr-69-1(config)# router ospf 100gsr-69-1(config-router)# redistribute connectedgsr-69-1(config-router)# network 12.1.1.0 0.0.0.255 area 0gsr-69-1(config-router)# network 24.1.1.1 0.0.0.0 area 0gsr-69-1(config-router)# mpls traffic-eng router-id Loopback0gsr-69-1(config-router)# mpls traffic-eng area 0gsr-69-1(config-router)# exitgsr-69-1(config)# interface Loopback0At the physical interface level (internal):
gsr-69-1(config-if)# ip address 24.1.1.1 255.255.255.255gsr-69-1(config-if)# no ip directed-broadcastgsr-69-1(config-if)# exitAt the device level:
gsr-69-1(config)# interface POS2/0At the physical interface level (ingress):
gsr-69-1(config-if)# ip address 12.1.1.3 255.255.255.0gsr-69-1(config-if)# mpls traffic-eng tunnelsgsr-69-1(config-if)# exitGuaranteed Bandwidth Service Configuration
Having configured two bandwith pools, you now can
•
Use one pool, the sub-pool, for tunnels that carry traffic requiring strict bandwidth guarantees or delay guarantees
•
Use the other pool, the global pool, for tunnels that carry traffic requiring only Differentiated Service.
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.
Select a queue—or in diffserv terminology, select a PHB (per-hop behavior)—to be used exclusively by the strict guarantee traffic. This shall be called the "GB queue."
If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue (EF PHB) is used. On the Cisco Series 12000 that is the "low-latency" 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 12000 you use one of the existing Modified Deficit Round Robin (MDRR) queues.
2.
Ensure that the guaranteed traffic sent through the sub-pool tunnel is placed in the GB queue at the outbound interface of every tunnel hop, and that no other traffic is placed in this queue.
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.
Ensure that this GB queue is never oversubscribed; that is, see that no more traffic is sent into the sub-pool tunnel than the GB queue can handle.
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.
Ensure that the amount of traffic entering the GB queue is limited to an appropriate percentage of the total bandwidth of the corresponding outbound link. The exact percentage to use depends on several factors that can contribute to accumulated delay in your network: your QoS performance objective, the total number of tunnel hops, the amount of link fan-in along the tunnel path, burstiness of the input traffic, and so on.
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.
Select a separate queue (a distinct diffserv PHB) for each traffic class. For example, if there are three classes (gold, silver, and bronze) there must be three queues (diffserv AF2, AF3, and AF4).
2.
Mark each class of traffic using a unique value in the MPLS experimental bits field (for example gold = 4, silver = 5, bronze = 6).
3.
Ensure that packets marked as Gold are placed in the gold queue, Silver in the silver queue, and so on. The tunnel bandwidth is set based on the expected aggregate traffic across all classes of service.
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 Example
Figure 2 illustrates a topology for guaranteed bandwidth services whose destination is specified by a single prefix, either Site D (prefix 26.1.1.1) or subnet Province (prefix 26.1.1.0). Three services are offered:
•
From Site A (defined as all traffic arriving at interface FE4/1/0): to host 26.1.1.1, 8 Mbps of guaranteed bandwidth with low loss, low delay and low jitter
•
From Site B (defined as all traffic arriving at interface FE4/1/1): towards subnet 26.1.1.0, 32 Mbps of guaranteed bandwidth with low loss
•
From Site C (defined as all traffic arriving at interface FE2/1/0): 30 Mbps of guaranteed bandwidth with low loss
Figure 2 Sample Guaranteed Bandwidth Services Topology
These three services run through two sub-pool tunnels:
•
From the router-1 head-1, 23.1.1.1, to the router-4 tail
•
From the router-2 head-2, 22.1.1.1, to the router-4 tail
Thus both tunnels use the same tail router, though they have different heads. (In this picture the two tunnels also share one of the midpoint routers. In the real world there would of course be many more midpoints than just the two shown here.)
All POS interfaces in this example are OC3, whose capacity is 155 Mgps.
Tunnel Head Configuration (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.
Configuring the Pools and Tunnel
At the device level:
router-1(config)# ip cefrouter-1(config)# mpls traffic-eng tunnelsrouter-1(config)# router ospf 100router-1(config-router)# redistribute connectedrouter-1(config-router)# network 10.1.1.0 0.0.0.255 area 0router-1(config-router)# network 23.1.1.1 0.0.0.0 area 0router-1(config-router)# mpls traffic-eng router-id Loopback0router-1(config-router)# mpls traffic-eng area 0router-1(config-router)# 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 60000router-1(config-if)# exitAt the (internal) physical 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 tunnel interface:
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 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.
In global configuration mode, create an ACL 100 to refer to all packets destined to 26.1.1.1:
access-list 100 permit ip any host 26.1.1.12.
Packets received on the inbound interface FE4/1/0 that match ACL 100 are rate-limited to:
a.
a rate of 8 Mgps
b.
a normal burst of 1 MB
c.
a maximum burst of 2 MB
d.
Packets which conform to this rate are marked prec 5 and are forwarded
e.
Packets which exceed the rate are dropped
interface FastEthernet4/1/0rate-limit input access-group 100 8000000 1000000 2000000 conform-action \ set-mpls-exp-transmit 5 exceed-action drop3.
Packets which do not match ACL 100 are rate-limited and, regardless of whether they conform or not, their precedence is set to zero and they are forwarded. Note that we do not really care to rate-limit these packets. The intention is simply to ensure that all these packets are marked with precedence zero. The values used for rate-limiting are irrelevant.
rate-limit input 2000000000 512000000 1024000000 conform-action \ set-mpls-exp-transmit 0 exceed-action set-mpls-exp-transmit 0For Service from Site B to Subnet "Province"
At the inbound physical interface (FE4/1/1):
1.
In global configuration mode, create an ACL 120 to refer to all packets destined to subnet 26.1.1.0:
access-list 120 permit ip any 26.1.1.0 255.255.255.2552.
Packets received on the inbound interface FE4/1/1 that match ACL 120 are rate-limited to:
a.
a rate of 32 Mgps
b.
a normal burst of 1 MB
c.
a maximum burst of 2 MB
d.
Packets which conform to this rate are marked prec 5 and are forwarded
e.
Packets which exceed the rate are dropped
interface FastEthernet4/1/1rate-limit input access-group 120 32000000 1000000 2000000 conform-action \ set-mpls-exp-transmit 5 exceed-action drop3.
Packets which do not match ACL 120 are rate-limited and, regardless of whether they conform or not, their precedence is set to zero and they are forwarded. Note that we do not really care to rate-limit these packets. The intention is simply to ensure that all these packets are marked with precedence zero. The values used for rate-limiting are irrelevant.
rate-limit input 2000000000 512000000 1024000000 conform-action \ set-mpls-exp-transmit 0 exceed-action set-mpls-exp-transmit 0For Both Services
The outbound interface (POS4/0) is configured as follows. At the device level, you create a profile of QoS queuing:
router-1(config)# cos-queue-group class0+5router-1(config-cos-queue)# precedence 0 random-detect-label 0router-1(config-cos-queue)# precedence 5 queue low-latencyrouter-1(config-cos-queue)# precedence 5 random-detect-label 5router-1(config-cos-queue)# random-detect-label 0 100 200 1router-1(config-cos-queue)# random-detect-label 5 2000 3000 1router-1(config-cos-queue)# queue low-latency strict-priorityAt the physical interface level:
router-1(config)# interface pos4/0router-1(config-if)# tx-cos class0+5As a result of all the above configuration lines, packets entering the Head-1 router via interface FE4/1/0 and destined for host 26.1.1.1, or entering that router via interface FE4/1/1 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 POS4/0, packets marked with IP precedence 5 are placed in the low latency queue.
Note
Packets entering the router via FE4/1/0 or FE4/1/1 and exiting POS4/0 enter as IP packets and exit as MPLS packets.
Tunnel Head Configuration (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.
Configuring the Pools and Tunnel
At the device level:
router-2(config)# ip cefrouter-2(config)# mpls traffic-eng tunnelsrouter-2(config)# router ospf 100router-2(config-router)# redistribute connectedrouter-2(config-router)# network 11.1.1.0 0.0.0.255 area 0router-2(config-router)# network 22.1.1.1 0.0.0.0 area 0router-2(config-router)# mpls traffic-eng router-id Loopback0router-2(config-router)# mpls traffic-eng area 0router-2(config-router)# 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 60000router-2(config-if)# exitAt the (internal) physical 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 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/0):
1.
In global configuration mode, create an ACL 130 to refer to all packets destined to 26.1.1.0:
access-list 130 permit ip any 26.1.1.0 255.255.255.2552.
Packets received on the inbound interface FE2/0 that match ACL 130 are rate-limited to:
a.
a rate of 30 Mgps
b.
a normal burst of 1 MB
c.
a maximum burst of 2 MB
d.
Packets which conform to this rate are marked prec 5 and are forwarded
e.
Packets which exceed the rate are dropped
interface FastEthernet2/0rate-limit input access-group 130 32000000 1000000 2000000 conform-action \ set-mpls-exp-transmit 5 exceed-action drop3.
Packets which do not match ACL 130 are rate-limited and, regardless of whether they conform or not, their precedence is set to zero and they are forwarded. Note that we do not really care to rate-limit these packets. The intention is simply to ensure that all these packets are marked with precedence zero. The values used for rate-limiting are irrelevant.
rate-limit input 2000000000 512000000 1024000000 conform-action \ set-mpls-exp-transmit 0 exceed-action set-mpls-exp-transmit 0For the outbound physical interface (POS0/0), you create, at the device level, a profile of QoS queuing:
router-1(config)# cos-queue-group class0+5router-1(config-cos-queue)# precedence 0 random-detect-label 0router-1(config-cos-queue)# precedence 5 queue low-latencyrouter-1(config-cos-queue)# precedence 5 random-detect-label 5router-1(config-cos-queue)# random-detect-label 0 100 200 1router-1(config-cos-queue)# random-detect-label 5 2000 3000 1router-1(config-cos-queue)# queue low-latency strict-priorityAnd at the physical interface level:
router-1(config)# interface pos0/0router-1(config-if)# tx-cos class0+5As 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 IP precedence 5 are placed in the low latency queue.
Note
Packets entering the router via FE2/1/0 and exiting through POS0/0 enter as IP packets and exit as MPLS packets.
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 cefrouter-3(config)# mpls traffic-eng tunnelsrouter-3(config)# router ospf 100router-3(config-router)# redistribute connectedrouter-3(config-router)# network 10.1.1.0 0.0.0.255 area 0router-3(config-router)# network 11.1.1.0 0.0.0.255 area 0router-3(config-router)# network 24.1.1.1 0.0.0.0 area 0router-3(config-router)# network 12.1.1.0 0.0.0.255 area 0router-3(config-router)# network 13.1.1.0 0.0.0.255 area 0router-3(config-router)# mpls traffic-eng router-id Loopback0router-3(config-router)# mpls traffic-eng area 0router-3(config-router)# exitAt the (internal) physical interface:
router-3(config)# interface Loopback0router-3(config-if)# ip address 24.1.1.1 255.255.255.255router-3(config-if)# no ip directed-broadcastrouter-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 60000router-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 60000router-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 60000router-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 60000router-3(config-if)# exitFor All GB Services
At the device level, create a profile of QoS queuing:
router-3(config)# cos-queue-group class0+5router-3(config-cos-queue)# precedence 0 random-detect-label 0router-3(config-cos-queue)# precedence 5 queue low-latencyrouter-3(config-cos-queue)# precedence 5 random-detect-label 5router-3(config-cos-queue)# random-detect-label 0 100 200 1router-3(config-cos-queue)# random-detect-label 5 2000 3000 1router-3(config-cos-queue)# queue low-latency strict-priorityFor Services from Sites A and B
At the physical interface level:
router-3(config)# interface pos3/1router-3(config-if)# tx-cos class0+5For Service from Site C
At the physical interface level:
router-3(config)# interface pos4/1router-3(config-if)# tx-cos class0+5Tunnel 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 cefrouter-5(config)# mpls traffic-eng tunnelsrouter-5(config)# router ospf 100router-5(config-router)# redistribute connectedrouter-5(config-router)# network 13.1.1.0 0.0.0.255 area 0router-5(config-router)# network 14.1.1.0 0.0.0.255 area 0router-5(config-router)# network 25.1.1.1 0.0.0.0 area 0router-5(config-router)# mpls traffic-eng router-id Loopback0router-5(config-router)# mpls traffic-eng area 0router-5(config-router)# exitAt the (internal) physical interface:
router-5(config)# interface Loopback0router-5(config-if)# ip address 25.1.1.1 255.255.255.255router-5(config-if)# no ip directed-broadcastrouter-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 60000router-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 60000router-5(config-if)# exitFor Service from Site C
At the device level, create a profile of QoS queuing:
router-5(config)# cos-queue-group class0+5router-5(config-cos-queue)# precedence 0 random-detect-label 0router-5(config-cos-queue)# precedence 5 queue low-latencyrouter-5(config-cos-queue)# precedence 5 random-detect-label 5router-5(config-cos-queue)# random-detect-label 0 100 200 1router-5(config-cos-queue)# random-detect-label 5 2000 3000 1router-5(config-cos-queue)# queue low-latency strict-priorityAt the physical interface level:
router-5(config)# interface pos2/1router-5(config-if)# tx-cos class0+5Tunnel Tail Configuration
The inbound interfaces on the tail router are configured identically to the inbound interfaces of the midpoint router (except, of course, for the ID of each particular interface):
Configuring the Pools and Tunnels
At the device level:
router-4(config)# ip cefrouter-4(config)# mpls traffic-eng tunnelsrouter-4(config)# router ospf 100router-4(config-router)# redistribute connectedrouter-4(config-router)# network 12.1.1.0 0.0.0.255 area 0router-4(config-router)# network 14.1.1.0 0.0.0.255 area 0



