Cisco IOS Software Releases 12.0 ST

Table Of Contents

Diff-Serv-aware Traffic Engineering (DS-TE)

Feature History

Background and Overview

Benefits

Related Features and Technologies

Related Documents

Platforms and Interfaces Supported

Supported Standards

Prerequisites

Configuration Tasks

New Commands

The ip rsvp bandwidth command

The tunnel mpls traffic-eng bandwidth command

The Configuration Procedure

Level 1: Configuring the Device

Level 2: Configuring the Physical Interface

Level 3: Configuring the Tunnel Interface

Verifying the Configurations

Configuration Examples

DS-TE Configuration on the 12000 GSR

Tunnel Head

Midpoint Devices

Tail-End Device

DS-TE Configuration on the Series 7500(VIP)

Tunnel Head

Guaranteed Bandwidth Service Configuration

Guaranteed Bandwidth Service Examples

Example with Single Destination Prefix

7500 Tunnel Head Configuration

12000 GSR Tunnel Head Configuration

Tunnel Midpoint Configuration [Mid-1]

Tunnel Midpoint Configuration [Mid-2]

Tunnel Tail Configuration

Example with Many Destination Prefixes

7500(VIP) Tunnel Head Configuration

12000 GSR Tunnel Head Configuration

Tunnel Midpoint Configuration [Mid-1]

Tunnel Midpoint Configuration [Mid-2]

Tunnel Tail Configuration

Command Reference

interface

ip cef

ip router isis

ip rsvp bandwidth

is-type

metric-style wide

mpls traffic-eng

mpls traffic-eng administrative-weight

mpls traffic-eng area

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

mpls traffic-eng router-id

mpls traffic-eng tunnels

mpls traffic-eng tunnels

net

passive-interface

router isis

router ospf

show interfaces tunnel

show ip ospf

show ip route

show ip rsvp host

show ip rsvp interface

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

show mpls traffic-eng tunnels

tunnel destination

tunnel mode mpls traffic-eng

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 Commands

debug mpls traffic-eng link-management preemption

Glossary

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.

Feature History

Release	Modification
12.0(11) ST	DS-TE feature introduced.
12.0(14) ST	Support added for Cisco Series 7500(VIP) platform. Support added for IS-IS Interior Gateway Protocol.
12.0(14) ST-1	Support added for guaranteed bandwidth service directed to many destination prefixes (for example, guaranteed bandwidth service destined to an autonomous system or to a BGP community).

The guide contains the following sections:

•Background and Overview, page 2

•Platforms and Interfaces Supported, page 3

•Prerequisites, page 4

•Configuration Tasks, page 4

•Configuration Examples, page 10

•Command Reference, page 40

•Debug Commands, page 128

•Glossary, page 130

---

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, 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:

•"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 IS-IS:

•"Configuring Integrated IS-IS" 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/1cdisis.htm

•"Integrated IS-IS Commands" in Cisco IOS Release 12.1 Cisco IOS IP and IP Routing Command Reference,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdisis.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.htm

For 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.htm

Platforms and Interfaces Supported

This release supports DS-TE together with QoS on the following platforms over the POS (Packet over Sonet) interface:

•Cisco 12000 Series Gigabit Switch Router (GSR), with Engine 0 on edge (access) interfaces and Engine 2 on core (backbone) interfaces

•Cisco 7500 Series Router (VIP)

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-tewg-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-01.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-ietf-ospf-diff-te-00.txt

•Extensions to ISIS 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-ietf-isis-diff-te-00.txt

As 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

•ISIS

•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 y

where 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 z

where 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 b

where 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 b

This indicates that the tunnel should use bandwidth from the sub-pool. Alternatively, you can enter

tunnel mpls traffic-eng bandwidth b

This 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 (router or switch router) to use accelerated packet-forwarding (known as Cisco Express Forwarding or CEF), MultiProtocol Label Switching (MPLS), traffic-engineering tunneling, and either the OSPF or IS-IS routing algorithm (Open Shortest Path First or Intermediate System to Intermediate System). 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	Purpose
Step 1	Router(config)# ip cef [distributed]	Enables CEF—which accelerates the flow of packets through the device. (More on page 46.) On the Cisco 7500 (VIP) router, you must enter the keyword distributed; on the Cisco 12000 switch-router, do not enter that keyword.
Step 2	Router(config)# mpls traffic-eng tunnels	Enables MPLS, and specifically its traffic engineering tunnel capability. (More on page 65.)
Step 3	Router(config)# router ospf [or] Router(config)# router isis	Invokes the OSPF routing process for IP and puts the device into router configuration mode. (More on page 72.) Proceed now to Steps 9 and 10. Alternatively, you may invoke the ISIS routing process with this command (more on page 70), and continue with Step 4.
Step 4	Router (config-router)# net network-entity-title	Specifies the IS-IS network entity title (NET) for the routing process. (More on page 67.)
Step 5	Router (config-router)# metric-style wide	Enables the router to generate and accept IS-IS new-style TLVs (type, length, and value objects). (More on page 52.)
Step 6	Router (config-router)# is-type level-n	Configures the router to learn about destinations inside its own area or "IS-IS level". (More on page 51.)
Step 7	Router (config-router)# mpls traffic-eng level-n	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. (More on page 54).
Step 8	Router (config-router)# passive-interface loopback0	Instructs IS-IS to advertise the IP address of the loopback interface without actually running IS-IS on that interface. (More on page 68.) Continue with Step 9 but don't do Step 10—because Step 10 refers to OSPF.
Step 9	Router(config-router)# mpls traffic-eng router-id loopback0	Specifies that the traffic engineering router identifier is the IP address associated with the loopback0 interface. (More on page 64.)
Step 10	Router(config-router)# mpls traffic-eng area num	Turns on MPLS traffic engineering for a particular OSPF area. (More on page 56.)

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—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:

	Command	Purpose
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. (More on page 42.)
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 49.)
Step 3	Router(config-if)# mpls traffic-eng tunnels	Enables the MPLS traffic engineering tunnel feature on this interface. (More on page 66.)
Step 4	Router(config-if)# ip router isis	Enables the IS-IS routing protocol on this interface. (More on page 48.) 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).

The only command which was modified at this level for DS-TE is tunnel mpls traffic-eng bandwidth (described in detail on page 122).

You enter the following commands:

	Command	Purpose
Step 1	Router(config)# interface tunnel1	Creates a tunnel interface (named in this example tunnel1) and enters interface configuration mode. (More on page 42.)
Step 2	Router(config-if)# tunnel destination A.B.C.D	Specifies the IP address of the tunnel tail device. (More on page 116.)
Step 3	Router(config-if)# tunnel mode mpls traffic-eng	Sets the tunnel's encapsulation mode to MPLS traffic engineering. (More on page 118.)
Step 4	Router(config-if)# tunnel mpls traffic-eng bandwidth {sub-pool | [global]} bandwidth	Configures the tunnel's bandwidth and assigns it either to the sub-pool or the global pool. (More on page 122).
Step 5	Router(config-if)# tunnel mpls traffic-eng priority	Sets the priority to be used when system determines which existing tunnels are eligible to be preempted. (More on page 126).
Step 6	Router(config-if)# tunnel mpls traffic-eng path-option	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). (More on page 124).

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 73 for show interfaces tunnel and page 87 for show ip rsvp interface.

GSR1#show interfaces tunnel 4

Tunnel4 is up, line protocol is down

  Hardware is Routing Tunnel

  MTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255

  Encapsulation TUNNEL, loopback not set, keepalive set (10 sec)

  Tunnel source 0.0.0.0, destination 0.0.0.0

  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled

  Last input never, output never, output hang never

  Last clearing of "show interface" counters never

  Output queue 0/0, 0 drops; input queue 0/75, 0 drops

  Five minute input rate 0 bits/sec, 0 packets/sec

  Five minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets, 0 restarts    

GSR1#show ip rsvp interface pos4/0

interface    allocated  i/f max  flow max sub max 

PO4/0        300K       466500K  466500K  0M 

To 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 114):

GSR1#show mpls traffic-eng tunnels brief

Signalling Summary:

LSP Tunnels Process:           running

RSVP Process:                  running

Forwarding:                    enabled

Periodic reoptimization:       every 3600 seconds, next in 3029 seconds

TUNNEL NAME 	DESTINATION      UP IF     DOWN IF   STATE/PROT

GSR1_t0 	192.168.1.13     -         SR3/0     up/up     

GSR1_t1 	192.168.1.13     -         SR3/0     up/up     

GSR1_t2 	192.168.1.13     -         PO4/0     up/up     

Displayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails

When 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 brief

Signalling Summary:

    LSP Tunnels Process:           running

    RSVP Process:                  running

    Forwarding:                    enabled

    Periodic reoptimization:       every 3600 seconds, next in 2279 seconds

TUNNEL NAME 	DESTINATION      UP IF     DOWN IF   STATE/PROT

GSR1_t0 	192.168.1.13     -         SR3/0     up/down 

GSR1_t1 	192.168.1.13     -         SR3/0     up/down 

GSR1_t2 	192.168.1.13     -         PO4/0     up/up 

Displayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails

To 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_t0 

Name:GSR1_t0                            (Tunnel0) Destination:192.168.1.13

  Status:

    Admin:up         Oper:down 	Path: not valid       Signalling:connected

If, 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 111.)

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 98)
	Preemptions along the tunnel path	debug mpls traffic-eng link-management preemption (described on 129)
	Available TE link band- width on all head routers	show mpls traffic-eng topology (described on page 111)
Router	Status of all tunnels cur- rently signalled by this router	show mpls traffic-eng link-management admission-control (described on page 96)
	Tunnels configured on midpoint routers	show mpls traffic-eng link-management summary (described on page 109)
Physical interface	Detailed information on current bandwidth pools	show mpls traffic-eng link-management bandwidth-allocation [interface-name] (described on page 101)
	TE RSVP bookkeeping	show mpls traffic-eng link-management interfaces (described on page 107)
	Entire configuration of one interface	show run interface

Configuration Examples

This section presents a separate example for each of two platforms that may carry the tunnel, the 12000 Gigabit Switch Router and the Series 7500 (VIP) router.

At first the 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.

DS-TE Configuration on the 12000 GSR

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 terminal

gsr-68-1(config)# ip cef

gsr-68-1(config)# mpls traffic-eng tunnels

[now one uses either the IS-IS commands on the left or the OSPF commands on the right]

gsr-68-1(config)# router isis	router ospf 100
gsr-68-1(config-router)# net 49.0000.1000.0000.0011.00	redistribute connected
gsr-68-1(config-router)# metric-style wide	network 11.1.1.0 0.0.0.255 area 0
gsr-68-1(config-router)# is-type level-1	network 23.1.1.1 0.0.0.0 area 0
gsr-68-1(config-router)# mpls traffic-eng level-1	mpls traffic-eng area 0
gsr-68-1(config-router)# passive-interface Loopback0

:

[now one resumes the common command set]:

gsr-68-1(config-router)# mpls traffic-eng router-id Loopback0

gsr-68-1(config-router)# exit

gsr-68-1(config)# interface Loopback0

At the physical interface level (internal):

gsr-68-1(config-if)# ip address 23.1.1.1 255.255.255.255

gsr-68-1(config-if)# no ip directed-broadcast

gsr-68-1(config-if)# exit

At the device level:

gsr-68-1(config)# interface POS3/0

At the physical interface level (egress):

gsr-68-1(config-if)# ip address 11.1.1.1 255.255.255.0

gsr-68-1(config-if)# mpls traffic-eng tunnels

gsr-68-1(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000

[and if using IS-IS instead of OSPF]:

gsr-68-1(config-if)# ip router isis

[and in all cases]:

gsr-68-1(config-if)# exit

At the device level:

gsr-68-1(config)# interface Tunnel1

At the tunnel interface level:

gsr-68-1(config-if)# ip unnumbered Loopback0

gsr-68-1(config-if)# tunnel destination 24.1.1.1

gsr-68-1(config-if)# tunnel mode mpls traffic-eng

gsr-68-1(config-if)# tunnel mpls traffic-eng priority 0 0

gsr-68-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000

gsr-68-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic

gsr-68-1(config-if)# exit

gsr-68-1(config)# 

Midpoint Devices

At the device level:

gsr-68-2# configure terminal

gsr-68-2(config)# ip cef

gsr-68-2(config)# mpls traffic-eng tunnels

[now one uses either the IS-IS commands on the left or the OSPF commands on the right]

gsr-68-2(config)# router isis	router ospf 100
gsr-68-2(config-router)# net 49.0000.1000.0000.0012.00	redistribute connected
gsr-68-2(config-router)# metric-style wide	network 11.1.1.0 0.0.0.255 area 0
gsr-68-2(config-router)# is-type level-1	network 12.1.1.0 0.0.0.255 area 0
gsr-68-2(config-router)# mpls traffic-eng level-1	network 25.1.1.1 0.0.0.0 area 0
gsr-68-2(config-router)# passive-interface Loopback0	mpls traffic-eng area 0

:

[now one resumes the common command set]:

gsr-68-2(config-router)# mpls traffic-eng router-id Loopback0

gsr-68-2(config-router)# exit

gsr-68-2(config)# interface Loopback0

At the virtual interface level:

gsr-68-2(config-if)# ip address 25.1.1.1 255.255.255.255

gsr-68-2(config-if)# no ip directed-broadcast

gsr-68-2(config-if)# exit

At the device level:

gsr-68-2(config)# interface POS4/0

At the physical interface level (ingress):

gsr-68-2(config-if)# ip address 11.1.1.2 255.255.255.0

gsr-68-2(config-if)# mpls traffic-eng tunnels

gsr-68-2(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000

[and if using IS-IS instead of OSPF]:

gsr-68-2(config-if)# ip router isis

[and in all cases:

gsr-68-2(config-if)# exit

At the device level:

gsr-68-2(config)# interface POS4/1

At the physical interface level (egress):

gsr-68-2(config-if)# ip address 12.1.1.2 255.255.255.0

gsr-68-2(config-if)# mpls traffic-eng tunnels

gsr-68-2(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000

[and if using IS-IS instead of OSPF]:

gsr-68-2(config-if)# ip router isis

[and in all cases:

gsr-68-2(config-if)# exit

Note 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 terminal

gsr-69-1(config)# ip cef

gsr-69-1(config)# mpls traffic-eng tunnels

[now one uses either the IS-IS commands on the left or the OSPF commands on the right]

gsr-69-1(config)# router isis	router ospf 100
gsr-69-1(config-router)# net 49.0000.1000.0000.0013.00	redistribute connected
gsr-69-1(config-router)# metric-style wide	network 12.1.1.0 0.0.0.255 area 0
gsr-69-1(config-router)# is-type level-1	network 24.1.1.1 0.0.0.0 area 0
gsr-69-1(config-router)# mpls traffic-eng level-1	mpls traffic-eng area 0
gsr-69-1(config-router)# passive-interface Loopback0

:

[now one resumes the common command set]:

gsr-69-1(config-router)# mpls traffic-eng router-id Loopback0

gsr-69-1(config-router)# exit

gsr-69-1(config)# interface Loopback0

At the virtual interface level:

gsr-69-1(config-if)# ip address 24.1.1.1 255.255.255.255

gsr-69-1(config-if)# no ip directed-broadcast

[and if using IS-IS instead of OSPF]:

gsr-69-1(config-if)# ip router isis

[and in all cases]:

gsr-69-1(config-if)# exit

At the device level:

gsr-69-1(config)# interface POS2/0

At the physical interface level (ingress):

gsr-69-1(config-if)# ip address 12.1.1.3 255.255.255.0

gsr-69-1(config-if)# mpls traffic-eng tunnels

[and if using IS-IS instead of OSPF]:

gsr-69-1(config-if)# ip router isis

[and in all cases]:

gsr-69-1(config-if)# exit

DS-TE Configuration on the Series 7500(VIP)

If the tunnel-head device is a Cisco Series 7500(VIP) router instead of the 12000 Series Gigabit Switch Router, the sub-pool configuration command set differs only in two aspects:

•the Cisco Express Forwarding command, ip cef, must include the keyword distributed

•a bandwidth specification is made for the tunnel interface and not for the loopback interface; the opposite was true with the 12000 GSR

Commands on the midpoint and tail-end routers in this topology are the same as they were in the previous example, because at those locations the devices are also 12000 Series GSRs, not Series 7500 (VIP) routers.

Figure 2 Sample Tunnel Topology with 7500 as Tunnel Head

Tunnel Head

At the device level:

rsp-41-3# configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

rsp-41-3(config)# ip cef distributed

rsp-41-3(config)# mpls traffic-eng tunnels

[now one uses either the IS-IS commands on the left or the OSPF commands on the right]

rsp-41-3(config)# router isis	router ospf 100
rsp-41-3(config-router)# net 49.0000.1000.0000.0010.00	redistribute connected
rsp-41-3(config-router)# metric-style wide	network 10.1.1.0 0.0.0.255 area 0
rsp-41-3(config-router)# is-type level-1	network 22.1.1.1 0.0.0.0 area 0
rsp-41-3(config-router)# mpls traffic-eng level-1	mpls traffic-eng area 0
rsp-41-3(config-router)# passive-interface Loopback0

:

[now one resumes the common command set]:

rsp-41-3(config-router)# mpls traffic-eng router-id Loopback0

rsp-41-3(config-router)# exit

rsp-41-3(config)# interface Loopback0

At the virtual interface level:

rsp-41-3(config-if)# ip address 22.1.1.1 255.255.255.255

rsp-41-3(config-if)# no ip directed-broadcast

rsp-41-3(config-if)# exit

At the device level:

rsp-41-3(config)# interface POS2/0/0

At the physical interface level (egress):

rsp-41-3(config-if)# ip address 10.1.1.1 255.255.255.0

rsp-41-3(config-if)# mpls traffic-eng tunnels

rsp-41-3(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000

[and if using IS-IS instead of OSPF]:

rsp-41-3(config-if)# ip router isis

[and in all cases]:

rsp-41-3(config-if)# exit

At the device level:

rsp-41-3(config)# interface Tunnel1

At the tunnel interface level:

rsp-41-3(config-if)# bandwidth 110000

rsp-41-3(config-if)# ip unnumbered Loopback0

rsp-41-3(config-if)# tunnel destination 24.1.1.1

rsp-41-3(config-if)# tunnel mode mpls traffic-eng

rsp-41-3(config-if)# tunnel mpls traffic-eng priority 0 0

rsp-41-3(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000

rsp-41-3(config-if)# tunnel mpls traffic-eng path-option 1 dynamic

rsp-41-3(config-if)# exit

rsp-41-3(config)# 

Guaranteed Bandwidth Service Configuration

Having configured two bandwidth 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. On the Cisco 7500(VIP) it is the "priority" queue. In both cases, 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. On the Cisco 7500 (VIP) you use one of the existing Class-Based Weighted Fair Queuing (CBWFQ) 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 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 3 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:

•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): 30 Mbps of guaranteed bandwidth with low loss

Figure 3 Sample Topology for Guaranteed Bandwidth Services to a Single Destination Prefix

These three services run through two sub-pool tunnels:

•From the 7500 head, 23.1.1.1, to the tail (a 12000 GSR)

•From the 12000 head, 22.1.1.1, to that same tail

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 Mbps.

7500 Tunnel Head Configuration

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 distributed

router-1(config)# mpls traffic-eng tunnels

[now one uses either the IS-IS commands on the left or the OSPF commands on the right]

router-1(config)# router isis	router ospf 100
router-1(config-router)# net 49.0000.1000.0000.0010.00	redistribute connected
router-1(config-router)# metric-style wide	network 10.1.1.0 0.0.0.255 area 0
router-1(config-router)# is-type level-1	network 23.1.1.1 0.0.0.0 area 0
router-1(config-router)# mpls traffic-eng level-1	mpls traffic-eng area 0
router-1(config-router)# passive-interface Loopback0

:

[now one resumes the common command set]:

router-1(config-router)# mpls traffic-eng router-id Loopback0

router-1(config-router)# exit

Create a virtual interface:

router-1(config)# interface Loopback0

router-1(config-if)# ip address 23.1.1.1 255.255.255.255

router-1(config-if)# no ip directed-broadcast

router-1(config-if)# exit

At the outgoing physical interface:

router-1(config)# interface pos4/0

router-1(config-if)# ip address 10.1.1.1 255.0.0.0

router-1(config-if)# mpls traffic-eng tunnels

router-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)# exit

At the tunnel interface:

router-1(config)# interface Tunnel1

router-1(config-if)# bandwidth 110000

router-1(config-if)# ip unnumbered Loopback0

router-1(config-if)# tunnel destination 27.1.1.1

router-1(config-if)# tunnel mode mpls traffic-eng

router-1(config-if)# tunnel mpls traffic-eng priority 0 0

router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000

router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic

To 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 Tunnel1

router-1(config)# exit

And 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 announce

For Service from Site A to Site D

At the inbound physical interface (FE4/1/0):

1. In global configuration mode, create a class of traffic matching ACL 100, called "sla-1-class":

class-map match-all sla-1-class

match access-group 100

2. 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.1

3. Create a policy named "sla-1-input-policy", and according to that policy:

a. Packets in the class called "sla-1-class" are rate-limited to:

- a rate of 8 million bits per second

- a normal burst of 1 million bytes

- a maximum burst of 2 million bytes

b. Packets which conform to this rate are marked with MPLS experimental bit 5 and are forwarded.

c. Packets which exceed this rate are dropped.

d. All other packets are marked with experimental bit 0 and are forwarded.

policy-map sla-1-input-policy

class sla-1-class

police 8000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 
exceed-action drop

class class-default

set-mpls-exp-transmit 0

4. The policy is applied to packets entering interface FE4/1/0.

interface FastEthernet4/1/0

service-policy input sla-1-input-policy

For Service from Site B to Subnet "Province"

At the inbound physical interface (FE4/1/1):

1. In global configuration mode, create a class of traffic matching ACL 120, called "sla-2-class":

class-map match-all sla-2-class

match access-group 120

2. 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 0.0.0.255

3. Create a policy named "sla-2-input-policy", and according to that policy:

a. Packets in the class called "sla-2-class" are rate-limited to:

- a rate of 32 million bits per second

- a normal burst of 1 million bytes

- a maximum burst of 2 million bytes

b. Packets which conform to this rate are marked with MPLS experimental bit 5 and are forwarded.

c. Packets which exceed this rate are dropped.

d. All other packets are marked with experimental bit 0 and are forwarded.

policy-map sla-2-input-policy

class sla-2-class

police 32000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 
exceed-action drop

class class-default

set-mpls-exp-transmit 0

4. The policy is applied to packets entering interface FE4/1/1.

interface FastEthernet4/1/1

service-policy input sla-2-input-policy

For Both Services

The outbound interface (POS4/0) is configured as follows:

1. In global configuration mode, create a class of traffic matching experimental bit 5, called "exp-5-traffic".

class-map match-all exp-5-traffic

match mpls experimental 5

2. Create a policy named "output-interface-policy". According to that policy, packets in the class "exp-5-traffic" are put in the priority queue (which is rate-limited to 62 kbits/sec).

policy-map output-interface-policy

class exp-5-traffic

priority 32

3. The policy is applied to packets exiting interface POS4/0.

		 interface POS4/0

service-policy output output-interface-policy

The result of the above configuration