Downloads |
Table Of Contents
Diff-Serv-aware MPLS 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 Network Interface
Level 3: Configuring the Tunnel Interface
Guaranteed Bandwidth Service Configuration
Guaranteed Bandwidth Service Examples
Example with Single Destination Prefix
Tunnel Midpoint Configuration [Mid-2]
Example with Many Destination Prefixes
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 MPLS 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
CautionThe Fast Reroute feature of traffic engineering is not supported on ATM interfaces.
The guide contains the following sections:
•
•
•
Note
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:
•
•
•
•
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:
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1cdospf.htm•
For IS-IS:
•
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdisis.htmFor RSVP:
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt5/qcdrsvp.htm•
For QoS:
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/index.htm•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/index.htmFor MPLS Traffic Engineering:
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/traffeng.htm•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/switch_c/xcprt4•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/switch_r/xrdscmd3.htmFor ATM-PVC:
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/wcfatm.htmPlatforms and Interfaces Supported
This release supports DS-TE together with QoS on the POS and ATM-PVC interfaces on the Cisco 7200 Series Router.
To check for changes in platform support since the publication of this document, access Feature Navigator at http://www.cisco.com/go/fn . You must have an account on Cisco.com . Qualified users can establish an account by following directions at http://www.cisco.com/register.
If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered, and account details with a new random password will then be e-mailed to you.
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:
•
http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-01.txt•
http://search.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-ext-01.txt•
http://search.ietf.org/internet-drafts/draft-ietf-ospf-diff-te-00.txt•
http://search.ietf.org/internet-drafts/draft-ietf-isis-diff-te-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:
•
•
•
•
•
•
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 11), 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:
•
•
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:
•
•
•
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:
Step 1
Enables CEF—which accelerates the flow of packets through the device. (More on page 55.)
Step 2
Enables MPLS, and specifically its traffic engineering tunnel capability. (More on page 74.)
Step 3
Invokes the OSPF routing process for IP and puts the device into router configuration mode. (More on page 81.) Proceed now to Steps 9 and 10.
Alternatively, you may invoke the ISIS routing process with this command (more on page 79), and continue with Step 4.
Step 4
Specifies the IS-IS network entity title (NET) for the routing process. (More on page 76.)
Step 5
Enables the router to generate and accept IS-IS new-style TLVs (type, length, and value objects). (More on page 61.)
Step 6
Configures the router to learn about destinations inside its own area or "IS-IS level". (More on page 60.)
Step 7
Specifies the IS-IS level (which must be the same level as in the preceding step) to which the router will flood MPLS traffic- engineering link information. (More on page 63).
Step 8
Instructs IS-IS to advertise the IP address of the loopback interface without actually running IS-IS on that interface. (More on page 77.) Continue with Step 9 but don't do Step 10—because Step 10 refers to OSPF.
Step 9
Specifies that the traffic engineering router identifier is the IP address associated with the loopback0 interface. (More on page 73.)
Step 10
Turns on MPLS traffic engineering for a particular OSPF area. (More on page 65.)
Level 2: Configuring the Network 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). 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 network interface—and if you will be relying on the IS-IS routing protocol, you enable that as well. (In the case of ATM-PVC interfaces you must enable MPLS and IS-IS on both the interface and the sub-interface level.)
To accomplish these tasks, you enter the following commands:
Step 1
Router(config)# interface interface-id
Moves configuration to the interface level, directing subsequent configuration commands to the specific interface identified by the interface-id. (More on page 51.)
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 58.)
Step 3
Enables the MPLS traffic engineering tunnel feature on this interface. (More on page 75.) If the tunnel will go through an ATM-PVC interface, continue on through Steps 4 through 10. However, if the tunnel will go through the POS interface, skip immediately to Step 10.
Step 4
Moves configuration to the sub-interface level, directing subsequent configuration commands to the specific sub-interface identified by the interface-id.sub-int. Needed when the tunnel will traverse an ATM-PVC interface. (More on page 51.)
Step 5
Enables RSVP on the sub-interface and limits the amount of bandwidth RSVP can reserve on the sub-interface. The sum of bandwidth used by all tunnels on this sub-interface cannot exceed interface-kbps, and the sum of bandwidth used by all sub-pool tunnels cannot exceed sub-pool kbps. (More on page 58.)
Step 6
Enables the MPLS traffic engineering tunnel feature on this sub-interface. (More on page 75.)
Step 7
Sets the ATM PVC descriptor, path identifier, and channel identifier. Also sets the encapsulation as AAL5SNAP.
Step 8
Enables the IS-IS routing protocol on the sub-interface. (More on page 57.) Do not enter this command if you are configuring for OSPF.
Step 9
Exits the sub-interface level, returning to the interface level.
Step 10
Enables IS-IS routing protocol on the interface. (More on page 57.) 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 network 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 132).
You enter the following commands:
Step 1
Creates a tunnel interface (named in this example tunnel1) and enters interface configuration mode. (More on page 51.)
Step 2
Specifies the IP address of the tunnel tail device. (More on page 126.)
Step 3
Sets the tunnel's encapsulation mode to MPLS traffic engineering. (More on page 128.)
Step 4
Configures the tunnel's bandwidth and assigns it either to the sub-pool or the global pool. (More on page 132).
Step 5
Sets the priority to be used when system determines which existing tunnels are eligible to be preempted. (More on page 136).
Step 6
Configures the paths (hops) a tunnel should use. The user can enter an explicit path (can specify the IP addresses of the hops) or can specify a dynamic path (the router figures out the best set of hops). (More on page 134).
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 network interface (and also, in the case of an ATM-PVC interface, the name or number of the sub-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 82 for show interfaces tunnel and page 96 for show ip rsvp interface.
RTR1#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 restartsRTR1#show ip rsvp interface pos4/0interface allocated i/f max flow max sub maxPO4/0 300K 466500K 466500K 0MRTR1#show ip rsvp interface atm3/0RTR1#show ip rsvp interface atm3/0.5interface allocated i/f max flow max sub maxAT3/0.5 110M 130M 130M 100To 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 124):
RTR1#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/PROTRTR1_t0 192.168.1.13 - SR3/0 up/upRTR1_t1 192.168.1.13 - SR3/0 up/upRTR1_t2 192.168.1.13 - PO4/0 up/up[[RTR1_t3 192.168.1.13 - AT3/0.5 up/up]]Displayed 4(of 4) heads, 0 (of 0) midpoints, 0 (of 0) tailsWhen one or more tunnels are 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).
RTR1#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/PROTRTR1_t0 192.168.1.13 - SR3/0 up/downRTR1_t1 192.168.1.13 - SR3/0 up/downRTR1_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:
RTR1#show mpls traffic-eng tunnels name RTR1_t0Name:RTR1_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 121.)
Additionally, you can use any of the following show commands to inspect particular aspects of the network, router, or interface concerned:
Network
Advertised bandwidth allocation information
show mpls traffic-eng link-management advertisements (described on page 108)
Preemptions along the tunnel path
debug mpls traffic-eng link-management preemption (described on 139)
Available TE link band- width on all head routers
show mpls traffic-eng topology (described on page 121)
Router
Status of all tunnels cur- rently signalled by this router
show mpls traffic-eng link-management admission-control (described on page 106)
Tunnels configured on midpoint routers
show mpls traffic-eng link-management summary
(described on page 119)Interface
Detailed information on current bandwidth pools
show mpls traffic-eng link-management bandwidth-allocation [interface-name]
(described on page 111)TE RSVP bookkeeping
show mpls traffic-eng link-management interfaces
(described on page 117)Entire configuration of one interface
show run interface
Configuration Examples
First this section presents the DS-TE configurations needed to create the sub-pool tunnel. Then it presents the more comprehensive design for building end-to-end guaranteed bandwidth service, which involves configuring Quality of Service as well.
As shown in Figure 1, the tunnel configuration involves at least three devices—tunnel head, midpoint, and tail. On each of those devices one or two network interfaces must be configured, for traffic ingress and egress.
Figure 1 Sample Tunnel Topology using POS Interfaces
Sample topologies when the tunnel will run over ATM-PVCs are shown in Figure 2 (full mesh) and Figure 3 (partial mesh).
Figure 2 Sample Tunnel across ATM-PVC Interfaces -- Full Mesh Topology
The full mesh topology shows no Midpoint device because the sub-pool tunnel can be routed along a direct PVC connecting the Head and Tail devices. However, if that particular PVC does not contain enough bandwidth, the tunnel can pass through alternate PVCs which may connect one or more PE routers. In that case the alternate PE router(s) will function as tunnel midpoint(s), and must be configured as shown in the Midpoint sections of the following configuration examples.
Figure 3 Sample Tunnel across ATM-PVC Interfaces -- Partial Mesh Topology
Tunnel Head
At the device level:
router-1# configure terminalEnter configuration commands, one per line. End with CNTL/Z.router-1(config)# ip cefrouter-1(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-1(config-router)# mpls traffic-eng router-id Loopback0router-1(config-router)# exitrouter-1(config)# interface Loopback0At the virtual interface level:
router-1(config-if)# ip address 22.1.1.1 255.255.255.255router-1(config-if)# no ip directed-broadcastrouter-1(config-if)# exitAt the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[continuing each case at the network interface level (egress)]
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitAt the device level:
router-1(config)# interface Tunnel1At the tunnel interface level:
router-1(config-if)# bandwidth 110000router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 24.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamicrouter-1(config-if)# exitrouter-1(config)#Midpoint Devices
At the device level:
router-2# configure terminalrouter-2(config)# ip cefrouter-2(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-2(config-router)# mpls traffic-eng router-id Loopback0router-2(config-router)# exitrouter-2(config)# interface Loopback0At the virtual interface level:
router-2(config-if)# ip address 25.1.1.1 255.255.255.255router-2(config-if)# no ip directed-broadcastrouter-2(config-if)# exitAt the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[continuing each case at the network interface level (ingress)]
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitAt the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[continuing each case at the network interface level (egress)]
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-2(config-if)# ip router isis[and in all cases]:router-2(config-if)# exitNote that there is no configuring of tunnel interfaces at the mid-point devices, only network interfaces, sub-interfaces, and the device globally.
Tail-End Device
At the device level:
router-3# configure terminalrouter-3(config)# ip cefrouter-3(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-3(config-router)# mpls traffic-eng router-id Loopback0router-3(config-router)# exitrouter-3(config)# interface Loopback0At the virtual interface level:
router-3(config-if)# ip address 24.1.1.1 255.255.255.255router-3(config-if)# no ip directed-broadcast[and if using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[continuing each case at the network interface level (ingress)]
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitGuaranteed Bandwidth Service Configuration
Having configured two bandwidth pools, you now can
•
•
Having a separate pool for traffic requiring strict guarantees allows you to limit the amount of such traffic admitted on any given link. Often, it is possible to achieve strict QoS guarantees only if the amount of guaranteed traffic is limited to a portion of the total link bandwidth.
Having a separate pool for other traffic (best-effort or diffserv traffic) allows you to have a separate limit for the amount of such traffic admitted on any given link. This is useful because it allows you to fill up links with best-effort/diffserv traffic, thereby achieving a greater utilization of those links.
Providing Strict QoS Guarantees Using DS-TE Sub-pool Tunnels
A tunnel using sub-pool bandwidth can satisfy the stricter requirements if you do all of the following:
1.
If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue (EF PHB) is used. On the Cisco 7200 it is the "priority" queue. You must configure the bandwidth of the queue to be at least equal to the bandwidth of the sub-pool.
If only bandwidth guarantees are sought, the diffserv Assured Forwarding PHB (AF PHB) is used. On the Cisco 7200 you use one of the existing Class-Based Weighted Fair Queuing (CBWFQ) queues.
2.
You do this by marking the traffic that enters the tunnel with a unique value in the mpls exp bits field, and steering only traffic with that marking into the GB queue.
3.
You do this by rate-limiting the guaranteed traffic before it enters the sub-pool tunnel. The aggregate rate of all traffic entering the sub-pool tunnel should be less than or equal to the bandwidth capacity of the sub-pool tunnel. Excess traffic can be dropped (in the case of delay/jitter guarantees) or can be marked differently for preferential discard (in the case of bandwidth guarantees).
4.
You do this by setting the sub-pool bandwidth of each outbound link to the appropriate percentage of the total link bandwidth (that is, by adjusting the z parameter of the ip rsvp bandwidth command).
Providing Differentiated Service Using DS-TE Global Pool Tunnels
You can configure a tunnel using global pool bandwidth to carry best-effort as well as several other classes of traffic. Traffic from each class can receive differentiated service if you do all of the following:
1.
2.
3.
To control the amount of diffserv tunnel traffic you intend to support on a given link, adjust the size of the global pool on that link.
Providing Strict Guarantees and Differentiated Service in the Same Network
Because DS-TE allows simultaneous constraint-based routing of sub-pool and global pool tunnels, strict guarantees and diffserv can be supported simultaneously in a given network.
Guaranteed Bandwidth Service Examples
Given the many topologies in which Guaranteed Bandwidth Services can be applied, there is space here only to present two examples. They illustrate opposite ends of the spectrum of possibilities.
In the first example, the guaranteed bandwidth tunnel can be easily specified by its destination. So the forwarding criteria refer to a single destination prefix.
In the second example, there can be many final destinations for the guaranteed bandwidth traffic, including a dynamically changing number of destination prefixes. So the forwarding criteria are specified by Border Gateway Protocol (BGP) policies.
Example with Single Destination Prefix
Figure 4 and Figure 5 illustrate topologies for guaranteed bandwidth services whose destination is specified by a single prefix. In Figure 4 the interfaces to be configured are POS (Packet over SONET), while in Figure 5 the interfaces are ATM-PVC (Asynchronous Transfer Mode - Permanent Virtual Circuit). In both illustrations, the destination for the guaranteed bandwidth service is either a single host (like a voice gateway, here designated "Site D" and bearing prefix 26.1.1.1) or a subnet (like a web farm, here called "Province" and bearing prefix 26.1.1.0). Three services are offered:
•
•
•
Figure 4 Sample Topology for Guaranteed Bandwidth Services (traversing POS interfaces) to a Single Destination Prefix
Figure 5 Sample Topology for Guaranteed Bandwidth Services (traversing ATM-PVC interfaces) to a Single Destination Prefix
These three services run through two sub-pool tunnels:
•
•
Both tunnels use the same tail router, though they have different heads. (In Figure 4 one midpoint router is shared by both tunnels. In the real world there could of course be many more midpoints.)
All POS and ATM-PVC interfaces in this example are OC3, whose capacity is 155 Mbps.
Configuring Tunnel Head-1
First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier on page 11). Then we present the QoS commands that guarantee end-to-end service on the subpool tunnel. With the 7200 router, Modular QoS CLI is used.
Configuring the Pools and Tunnel
At the device level:
router-1(config)# ip cefrouter-1(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-1(config-router)# mpls traffic-eng router-id Loopback0router-1(config-router)# exitCreate a virtual interface:
router-1(config)# interface Loopback0router-1(config-if)# ip address 23.1.1.1 255.255.255.255router-1(config-if)# no ip directed-broadcastrouter-1(config-if)# exitFor the outgoing network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitAt the tunnel interface:
router-1(config)# interface Tunnel1router-1(config-if)# bandwidth 110000router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 27.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamicTo ensure that packets destined to host 26.1.1.1 and subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static route. At the device level:
router-1(config)# ip route 26.1.1.0 255.255.255.0 Tunnel1router-1(config)# exitAnd in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down this tunnel, we disable autoroute announce:
router-1(config)# no tunnel mpls traffic-eng autoroute announceFor Service from Site A to Site D
At the inbound physical interface (FE4/0):
1.
class-map match-all sla-1-classmatch access-group 1002.
access-list 100 permit ip any host 26.1.1.13.
a.
- a rate of 8 million bits per second
- a normal burst of 1 million bytes
- a maximum burst of 2 million bytes
b.
c.
d.
policy-map sla-1-input-policyclass sla-1-classpolice 8000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 \ exceed-action dropclass class-defaultset-mpls-exp-transmit 04.
interface FastEthernet4/0service-policy input sla-1-input-policyFor Service from Site B to Subnet "Province"
At the inbound physical interface (FE4/1):
1.
class-map match-all sla-2-classmatch access-group 1202.
access-list 120 permit ip any 26.1.1.0 0.0.0.2553.
a.
- a rate of 32 million bits per second
- a normal burst of 1 million bytes
- a maximum burst of 2 million bytes
b.
c.
d.
policy-map sla-2-input-policyclass sla-2-classpolice 32000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 \ exceed-action dropclass class-defaultset-mpls-exp-transmit 04.
interface FastEthernet4/1service-policy input sla-2-input-policyFor Both Services
The outbound interface (POS4/0 or ATM2/0.4) is configured as follows:
1.
class-map match-all exp-5-trafficmatch mpls experimental 52.
policy-map output-interface-policyclass exp-5-trafficpriority 623.
:
The result of the above configuration lines is that packets entering the router via interface FE4/0 destined to host 26.1.1.1, or entering the router via interface FE4/1 destined to subnet 26.1.1.0, will have their MPLS experimental bit set to 5. We assume that no other packets entering the router (on any interface) are using this value. (If this cannot be assumed, an additional configuration must be added to mark all such packets to another experimental value.) Packets marked with experimental bit 5, when exiting the router via interface POS4/0 or subinterface ATM2/0.4, will be placed into the priority queue.
Configuring Tunnel Head-2
First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier on page 13). Then we present the QoS commands that guarantee end-to-end service on the subpool tunnel. With the 7200 router, Modular QoS CLI is used.
Configuring the Pools and Tunnel
At the device level:
router-2(config)# ip cefrouter-2(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-2(config-router)# mpls traffic-eng router-id Loopback0router-2(config-router)# exitCreate a virtual interface:
router-2(config)# interface Loopback0router-2(config-if)# ip address 22.1.1.1 255.255.255.255router-2(config-if)# no ip directed-broadcastrouter-2(config-if)# exitFor the outgoing network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
]:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-2(config-if)# ip router isis[and in all cases]:router-2(config-if)# exitAt the tunnel interface:
router-2(config)# interface Tunnel2router-2(config-if)# ip unnumbered Loopback0router-2(config-if)# tunnel destination 27.1.1.1router-2(config-if)# tunnel mode mpls traffic-engrouter-2(config-if)# tunnel mpls traffic-eng priority 0 0router-2(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000router-2(config-if)# tunnel mpls traffic-eng path-option 1 dynamicTo 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)# 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-2(config)# no tunnel mpls traffic-eng autoroute announceFor Service from Site C to Subnet "Province"
At the inbound physical interface (FE2/1):
1.
class-map match-all sla-3-classmatch access-group 1302.
access-list 130 permit ip any 26.1.1.0 0.0.0.2553.
a.
- a rate of 30 million bits per second
- a normal burst of 1 million bytes
- a maximum burst of 2 million bytes
b.
c.
d.
policy-map sla-3-input-policyclass sla-3-classpolice 30000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 \ exceed-action dropclass class-defaultset-mpls-exp-transmit 04.
interface FastEthernet2/1service-policy input sla-3-input-policyThe outbound interface (POS0/0 or ATM3/0.2) is configured as follows:
1.
class-map match-all exp-5-trafficmatch mpls experimental 52.
policy-map output-interface-policyclass exp-5-trafficpriority 323.
:
The result of the above configuration lines is that packets entering the router via interface FE2/1 destined to subnet 26.1.1.0, will have their MPLS experimental bit set to 5. We assume that no other packets entering the router (on any interface) are using this value. (If this cannot be assumed, an additional configuration must be added to mark all such packets to another experimental value.) Packets marked with experimental bit 5, when exiting the router via interface POS0/0 or subinterface ATM3/0.2, will be placed into the priority queue.
Tunnel Midpoint Configuration
All four interfaces on the 7200 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 tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-3(config-router)# mpls traffic-eng router-id Loopback0router-3(config-router)# exitCreate a virtual interface:
router-3(config)# interface Loopback0router-3(config-if)# ip address 24.1.1.1 255.255.255.255router-3(config-if)# exitFor one incoming network interface, first at the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
]:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitFor the other incoming network interface, first at the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continuing each case at the network interface level
]:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitFor one outgoing network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
]:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitFor the other outgoing network interface, first at the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[then, continuing each case at the network interface level
]:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitTunnel Midpoint Configuration [Mid-2]
[For the sake of simplicity, only the POS example (Figure 4) is illustrated with a second midpoint router.] Both interfaces on this 7200 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 tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-5(config-router)# mpls traffic-eng router-id Loopback0router-5(config-router)# exitCreate a virtual interface:
router-5(config)# interface Loopback0router-5(config-if)# ip address 25.1.1.1 255.255.255.255router-5(config-if)# exitAt the incoming network interface level:
router-5(config)# interface pos1/1router-5(config-if)# ip address 13.1.1.2 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitAt the outgoing network interface level:
router-5(config)# interface pos2/1router-5(config-if)# ip address 14.1.1.1 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitTunnel Tail Configuration
The inbound interfaces on the 7200 tail router are configured identically to the inbound interfaces of the midpoint routers (except, of course, for the ID of each particular interface):
Configuring the Pools and Tunnels
At the device level:
router-4(config)# ip cefrouter-4(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-4(config-router)# mpls traffic-eng router-id Loopback0router-4(config-router)# exitCreate a virtual interface:
router-4(config)# interface Loopback0router-4(config-if)# ip address 27.1.1.1 255.255.255.255router-4(config-if)# exitFor one incoming network interface, first at the device level:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
]:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitFor the other incoming network interface, first at the device level:
ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
]:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitBecause the tunnel ends on the tail (does not include any outbound interfaces of the tail router), no outbound QoS configuration is used.
Example with Many Destination Prefixes
Figure 6 and Figure 7 illustrate topologies for guaranteed bandwidth services whose destinations are a set of prefixes. In Figure 6 the interfaces to be configured are POS (Packet over SONET), while in Figure 7 the interfaces are ATM-PVC (Asynchronous Transfer Mode - Permanent Virtual Circuit). In both illustrations, the destinations' prefixes usually share some common properties such as belonging to the same Autonomous System (AS) or transiting through the same AS. Although the individual prefixes may change dynamically because of route flaps in the downstream autonomous systems, the properties the prefixes share will not change. Policies addressing the destination prefix set are enforced through Border Gateway Protocol (BGP), which is described in the following documents:
•
•
•
In this example, three guaranteed bandwidth services are offered:
•
•
•
Figure 6 Sample Topology for Guaranteed Bandwidth Service (traversing POS interfaces) to Many Destination Prefixes
Figure 7 Sample Topology for Guaranteed Bandwidth Service (traversing ATM-PVC interfaces) to Many Destination Prefixes
The applicability of guaranteed bandwidth service is not limited to the three types of multiple destination scenarios described above. There is not room in this document to present all possible scenarios. These three were chosen as representative of the wide range of possible deployments.
The guaranteed bandwidth services run through two sub-pool tunnels:
•
•
In addition, a global pool tunnel has been configured from each head end, to carry best-effort traffic to the same destinations. All four tunnels use the same tail router, even though they have different heads and differ in their passage through the midpoint(s). (Of course in the real world there would likely be many more midpoints than just the one or two shown here.)
All POS and ATM-PVC interfaces in this example are OC3, whose capacity is 155 Mbps.
Configuring a multi-destination guaranteed bandwidth service involves:
a.
b.
c.
d.
All of these tasks are included in the following example.
Tunnel Head Configuration [Head-1]
First we recapitulate commands that establish a sub-pool tunnel (commands presented earlier on page 11) and now we also configure a global pool tunnel. Additionally, we present QoS and BGP commands that guarantee end-to-end service on the sub-pool tunnel. (With the 7200 router, Modular QoS CLI is used).
Configuring the Pools and Tunnels
At the device level:
router-1(config)# ip cefrouter-1(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-1(config-router)# mpls traffic-eng router-id Loopback0router-1(config-router)# exitCreate a virtual interface:
router-1(config)# interface Loopback0router-1(config-if)# ip address 23.1.1.1 255.255.255.255router-1(config-if)# exitFor the outgoing network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-1(config-if)# ip router isis[and in all cases]:router-1(config-if)# exitAt one tunnel interface, create a sub-pool tunnel:
router-1(config)# interface Tunnel1router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 27.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path1router-1(config-if)# exitand at a second tunnel interface, create a global pool tunnel:
router-1(config)# interface Tunnel2router-1(config-if)# ip unnumbered Loopback0router-1(config-if)# tunnel destination 27.1.1.1router-1(config-if)# tunnel mode mpls traffic-engrouter-1(config-if)# tunnel mpls traffic-eng priority 0 0router-1(config-if)# tunnel mpls traffic-eng bandwidth 80000router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \ best-effort-path1router-1(config-if)# exitIn this example explicit paths are used instead of dynamic, to ensure that best-effort traffic and guaranteed bandwidth traffic will travel along different paths.
At the device level:
router-1(config)# ip explicit-path name gbs-path1router-1(config-ip-expl-path)# next-address 24.1.1.1router-1(config-ip-expl-path)# next-address 27.1.1.1router-1(config-ip-expl-path)# exitrouter-1(config)# ip explicit-path name best-effort-path1router-1(config-ip-expl-path)# next-address 24.1.1.1router-1(config-ip-expl-path)# next-address 25.1.1.1router-1(config-ip-expl-path)# next-address 27.1.1.1router-1(config-ip-expl-path)# exitNote that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other traffic down these tunnels.
Configuring DiffServ QoS
At the inbound physical interface (in Figure 6 and Figure 7 this is FE4/0), packets received are rate-limited to:
a.
b.
c.
Packets that are mapped to qos-group 6 and that conform to the rate-limit are marked with experimental value 5 and the BGP destination community string, and are forwarded; packets that do not conform (exceed action) are dropped:
router-1(config)# interface FastEthernet4/0router-1(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \ conform-action set-mpls-exp-transmit 5 exceed-action droprouter-1(config-if)# bgp-policy destination ip-qos-maprouter-1(config-if)# exitAt the device level create a class of traffic called "exp5-class" that has MPLS experimental bit set to 5:
router-1(config)# class-map match-all exp5-classrouter-1(config-cmap)# match mpls experimental 5router-1(config-cmap)# exitCreate a policy that creates a priority queue for "exp5-class":
router-1(config)# policy-map core-out-policyrouter-1(config-pmap)# class exp5-classrouter-1(config-pmap-c)# priority 100000router-1(config-pmap-c)# exitrouter-1(config-pmap)# class class-defaultrouter-1(config-pmap-c)# bandwidth 55000router-1(config-pmap-c)# exitrouter-1(config-pmap)# exitThe policy is applied to packets exiting subinterface ATM2/0.4 (left side) or interface POS4/0 (right side)
:
Configuring QoS Policy Propagation via BGP
For All GB Services
Create a table map under BGP to map (tie) the prefixes to a qos-group. At the device level:
router-1(config)# router bgp 2router-1(config-router)# no synchronizationrouter-1(config-router)# table-map set-qos-grouprouter-1(config-router)# bgp log-neighbor-changesrouter-1(config-router)# neighbor 27.1.1.1 remote-as 2router-1(config-router)# neighbor 27.1.1.1 update-source Loopback0router-1(config-router)# no auto-summaryrouter-1(config-router)# exitFor GB Service Destined to AS5
Create a distinct route map for this service. This includes setting the next-hop of packets matching 29.1.1.1 (a virtual loopback configured in the tail router; see page 48) so they will be mapped onto Tunnel #1 (the guaranteed bandwidth service tunnel). At the device level:
router-1(config)# route-map set-qos-group permit 10router-1(config-route-map)# match as-path 100router-1(config-route-map)# set ip qos-group 6router-1(config-route-map)# set ip next-hop 29.1.1.1router-1(config-route-map)# exitrouter-1(config)# ip as-path access-list 100 permit ^5$For GB Service Transiting through AS5
Create a distinct route map for this service. (Its traffic will go to AS6 and AS7).
At the device level:
router-1(config)# route-map set-qos-group permit 10router-1(config-route-map)# match as-path 101router-1(config-route-map)# set ip qos-group 6router-1(config-route-map)# set ip next-hop 29.1.1.1router-1(config-route-map)# exitrouter-1(config)# ip as-path access-list 101 permit _5_For GB Service Destined to Community 100:1
Create a distinct route map for all traffic destined to prefixes that have community value 100:1. This traffic will go to AS3, AS5, and AS8.
At the device level:
router-1(config)# route-map set-qos-group permit 10router-1(config-route-map)# match community 20router-1(config-route-map)# set ip qos-group 6router-1(config-route-map)# set ip next-hop 29.1.1.1router-1(config-route-map)# exitrouter-1(config)# ip community-list 20 permit 100:1Mapping Traffic onto the Tunnels
Map all guaranteed bandwidth traffic onto Tunnel #1:
router-1(config)# ip route 29.1.1.1 255.255.255.255 Tunnel1Map all best-effort traffic (traveling toward another virtual loopback interface, 30.1.1.1, configured in the tail router) onto Tunnel #2:
router-1(config)# ip route 30.1.1.1 255.255.255.255 Tunnel2Tunnel Head Configuration [Head-2]
As with the Head-1 device and interfaces, the following Head-2 configuration first presents commands that establish a sub-pool tunnel (commands presented earlier on page 11) and then also configures a global pool tunnel. After that it presents QoS and BGP commands that guarantee end-to-end service on the sub-pool tunnel. (Because this is a 7200 router, Modular QoS CLI is used).
Configuring the Pools and Tunnels
At the device level:
router-2(config)# ip cefrouter-2(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-2(config-router)# mpls traffic-eng router-id Loopback0router-2(config-router)# exitCreate a virtual interface:
router-2(config)# interface Loopback0router-2(config-if)# ip address 22.1.1.1 255.255.255.255router-2(config-if)# exitFor the outgoing network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-2(config-if)# ip router isis[and in all cases]:router-2(config-if)# exitAt one tunnel interface, create a sub-pool tunnel:
router-2(config)# interface Tunnel3router-2(config-if)# ip unnumbered Loopback0router-2(config-if)# tunnel destination 27.1.1.1router-2(config-if)# tunnel mode mpls traffic-engrouter-2(config-if)# tunnel mpls traffic-eng priority 0 0router-2(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path2router-2(config-if)# exitand at a second tunnel interface, create a global pool tunnel:
router-2(config)# interface Tunnel4router-2(config-if)# ip unnumbered Loopback0router-2(config-if)# tunnel destination 27.1.1.1router-2(config-if)# tunnel mode mpls traffic-engrouter-2(config-if)# tunnel mpls traffic-eng priority 0 0router-2(config-if)# tunnel mpls traffic-eng bandwidth 70000router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \ best-effort-path2router-2(config-if)# exitIn this example explicit paths are used instead of dynamic, to ensure that best-effort traffic and guaranteed bandwidth traffic will travel along different paths.
At the device level:
router-2(config)# ip explicit-path name gbs-path2router-2(config-ip-expl-path)# next-address 24.1.1.1router-2(config-ip-expl-path)# next-address 27.1.1.1router-2(config-ip-expl-path)# exitrouter-2(config)# ip explicit-path name best-effort-path2router-2(config-ip-expl-path)# next-address 24.1.1.1router-2(config-ip-expl-path)# next-address 25.1.1.1router-2(config-ip-expl-path)# next-address 27.1.1.1router-2(config-ip-expl-path)# exitNote that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other traffic down these tunnels.
Configuring DiffServ QoS
At the inbound physical interface (in Figure 6 and Figure 7 this is FE2/1), packets received are rate-limited to:
a.
b.
c.
Packets that are mapped to qos-group 6 and that conform to the rate-limit are marked with experimental value 5 and the BGP destination community string, and are forwarded; packets that do not conform (exceed action) are dropped:
router-2(config)# interface FastEthernet2/1router-2(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \ conform-action set-mpls-exp-transmit 5 exceed-action droprouter-2(config-if)# bgp-policy destination ip-qos-maprouter-2(config-if)# exitAt the device level create a class of traffic called "exp5-class" that has MPLS experimental bit set to 5:
router-2(config)# class-map match-all exp5-classrouter-2(config-cmap)# match mpls experimental 5router-2(config-cmap)# exitCreate a policy that creates a priority queue for "exp5-class":
router-2(config)# policy-map core-out-policyrouter-2(config-pmap)# class exp5-classrouter-2(config-pmap-c)# priority 100000router-2(config-pmap-c)# exitrouter-2(config-pmap)# class class-defaultrouter-2(config-pmap-c)# bandwidth 55000router-2(config-pmap-c)# exitrouter-2(config-pmap)# exitThe policy is applied to packets exiting subinterface ATM3/0.2 (left side) or interface POS0/0 (right side)
:
Configuring QoS Policy Propagation via BGP
For All GB Services
Create a table map under BGP to map (tie) the prefixes to a qos-group. At the device level:
router-2(config)# router bgp 2router-2(config-router)# no synchronizationrouter-2(config-router)# table-map set-qos-grouprouter-2(config-router)# bgp log-neighbor-changesrouter-2(config-router)# neighbor 27.1.1.1 remote-as 2router-2(config-router)# neighbor 27.1.1.1 update-source Loopback0router-2(config-router)# no auto-summaryrouter-2(config-router)# exitFor GB Service Destined to AS5
Create a distinct route map for this service. This includes setting the next-hop of packets matching 29.1.1.1 (a virtual loopback configured in the tail router; see page 48) so they will be mapped onto Tunnel #3 (th e guaranteed bandwidth service tunnel). At the device level:
router-2(config)# route-map set-qos-group permit 10router-2(config-route-map)# match as-path 100router-2(config-route-map)# set ip qos-group 6router-2(config-route-map)# set ip next-hop 29.1.1.1router-2(config-route-map)# exitrouter-2(config)# ip as-path access-list 100 permit ^5$For GB Service Transiting through AS5
Create a distinct route map for this service. (Its traffic will go to AS6 and AS7).
At the device level:
router-2(config)# route-map set-qos-group permit 10router-2(config-route-map)# match as-path 101router-2(config-route-map)# set ip qos-group 6router-2(config-route-map)# set ip next-hop 29.1.1.1router-2(config-route-map)# exitrouter-2(config)# ip as-path access-list 101 permit _5_For GB Service Destined to Community 100:1
Create a distinct route map for all traffic destined to prefixes that have community value 100:1. This traffic will go to AS3, AS5, and AS8.
At the device level:
router-2(config)# route-map set-qos-group permit 10router-2(config-route-map)# match community 20router-2(config-route-map)# set ip qos-group 6router-2(config-route-map)# set ip next-hop 29.1.1.1router-2(config-route-map)# exitrouter-2(config)# ip community-list 20 permit 100:1Mapping Traffic onto the Tunnels
Map all guaranteed bandwidth traffic onto Tunnel #3:
router-2(config)# ip route 29.1.1.1 255.255.255.255 Tunnel3Map all best-effort traffic onto Tunnel #4 (traveling toward another virtual loopback interface, 30.1.1.1, configured in the tail router):
router-2(config)# ip route 30.1.1.1 255.255.255.255 Tunnel4Tunnel Midpoint Configuration [Mid-1]
All four interfaces on the midpoint router are configured very much like the outbound interface of the head router. The strategy is to have all mid-point routers in this Autonomous System ready to carry future as well as presently configured sub-pool and global pool tunnels.
Configuring the Pools and Tunnels
At the device level:
router-3(config)# ip cefrouter-3(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-3(config-router)# mpls traffic-eng router-id Loopback0router-3(config-router)# exitCreate a virtual interface:
router-3(config)# interface Loopback0router-3(config-if)# ip address 24.1.1.1 255.255.255.255router-3(config-if)# exitAt one incoming network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the other incoming network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the outgoing network interface through which two sub-pool tunnels currently exit:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitAt the outgoing network interface through which two global pool tunnels currently exit:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-3(config-if)# ip router isis[and in all cases]:router-3(config-if)# exitTunnel Midpoint Configuration [Mid-2]
[For the sake of simplicity, only the POS example (Figure 6) is illustrated with a second midpoint router.] Both interfaces on this midpoint router are configured like the outbound interfaces of the Mid-1 router.
Configuring the Pools and Tunnels
At the device level:
router-5(config)# ip cefrouter-5(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right]
:
[now one resumes the common command set]:
router-5(config-router)# mpls traffic-eng router-id Loopback0router-5(config-router)# exitCreate a virtual interface:
router-5(config)# interface Loopback0router-5(config-if)# ip address 25.1.1.1 255.255.255.255router-5(config-if)# exitAt the incoming network interface:
router-5(config)# interface pos1/1router-5(config-if)# ip address 13.1.1.2 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitAt the outgoing network interface:
router-5(config)# interface pos2/1router-5(config-if)# ip address 14.1.1.1 255.0.0.0router-5(config-if)# mpls traffic-eng tunnelsrouter-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 70000[and if using IS-IS instead of OSPF]:router-5(config-if)# ip router isis[and in all cases]:router-5(config-if)# exitTunnel Tail Configuration
The inbound interfaces on the tail router are configured much like the outbound interfaces of the midpoint routers:
Configuring the Pools and Tunnels
At the device level:
router-4(config)# ip cefrouter-4(config)# mpls traffic-eng tunnels[now one uses either the IS-IS commands on the left or the OSPF commands on the right. In the case of OSPF, one must advertise two new loopback interfaces—29.1.1.1 and 30.1.1.1 in our example—which are defined in the QoS Policy Propagation section, further along on this page]
:
[now one resumes the common command set, taking care to include the two additional loopback interfaces]:
router-4(config-router)# mpls traffic-eng router-id Loopback0router-4(config-router)# mpls traffic-eng router-id Loopback1router-4(config-router)# mpls traffic-eng router-id Loopback2router-4(config-router)# exitCreate a virtual interface:
router-4(config)# interface Loopback0router-4(config-if)# ip address 27.1.1.1 255.255.255.255router-4(config-if)# exitAt one incoming network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitAt the other incoming network interface:
[ATM-PVC case appears on the left; POS case on the right]
:
[then continue each case at the network interface level
:
Continuing at the network interface level, regardless of interface type:
[If using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitConfiguring QoS Policy Propagation
On the tail device, one must configure a separate virtual loopback IP address for each class-of-service terminating here. The headend routers need these addresses to map traffic into the proper tunnels. In the current example, four tunnels terminate on the same tail device but they represent only two service classes, so only two additional loopback addresses are needed:
Create two virtual interfaces:
router-4(config)# interface Loopback1router-4(config-if)# ip address 29.1.1.1 255.255.255.255[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitrouter-4(config)# interface Loopback2router-4(config-if)# ip address 30.1.1.1 255.255.255.255[and if using IS-IS instead of OSPF]:router-4(config-if)# ip router isis[and in all cases]:router-4(config-if)# exitAt the device level, configure BGP to send the community to each tunnel head:
router-4(config)# router bgp 2router-4(config-router)# neighbor 23.1.1.1 send-communityrouter-4(config-router)# neighbor 22.1.1.1 send-communityrouter-4(config-router)# exitCommand Reference
This section documents commands that configure guaranteed bandwidth services using Diff-Serv-aware Traffic Engineering tunnels. Besides the fundamental commands that were presented in the Configuration Tasks and Configuration Examples sections, we have included here advanced commands that enable you to fine-tune the behavior of traffic engineering tunnels.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
interface
To configure an interface type and enter interface configuration mode, use the interface global configuration command.
interface type number [name-tag]
Cisco 7200 Series and Cisco 7500 Series with a Packet over SONET Interface Processor
interface type slot/port
Cisco 7500 Series with Ports on VIP Cards
interface type slot/port-adapter/port [ethernet | serial]
Cisco 7500 Series with Channelized T1 or E1
interface serial slot/port:channel-group
Cisco 4000 Series with Channelized T1 or E1 and the Cisco MC3810
interface serial number:channel-group
To configure a subinterface, use this form of the interface global configuration commands:
Cisco 7500 Series with Ports on VIP Cards
interface type slot/port-adapter/port.subinterface-number [multipoint | point-to-point]
Cisco 7200 Series
interface type slot/port.subinterface-number [multipoint | point-to-point]
Cisco 7500 Series
interface type slot/port-adapter.subinterface-number [multipoint | point-to-point]
Syntax Description
type
Type of interface to be configured. See Table 1.
number
Port, connector, or interface card number. On a Cisco 4000 series router, specifies the NPM number. The numbers are assigned at the factory at the time of installation or when added to a system, and can be displayed with the show interfaces command.
name-tag
(Optional) Specifies the logic name to identify the server configuration so that multiple entries of server configuration can be entered.
This optional argument is for use with the RLM feature.
slot
Number of the slot being configured. Refer to the appropriate hardware manual for slot and port information.
port
Number of the port being configured. Refer to the appropriate hardware manual for slot and port information.
port-adapter
Number of the port-adapter being configured. Refer to the appropriate hardware manual for information about port adapter compatibility.
ethernet
Ethernet IEEE 802.3 interface.
serial
Serial interface.
:channel-group
Cisco 4000 series routers specify the T1 channel group number in the range of 0 to 23 defined with the channel-group controller configuration command. On a dual port card, it is possible to run channelized on one port and primary rate on the other port.
Cisco MC3810 specifies the T1/E1 channel group number in the range of 0 to 23 defined with the channel-group controller configuration command.
.subinterface-number
Subinterface number in the range 1 to 4294967293. The number that precedes the period (.) must match the number to which this subinterface belongs.
multipoint | point-to-point
(Optional) Specifies a multipoint or point-to-point subinterface. There is no default.
Defaults
No interface types are configured.
Command Modes
Global configuration
Note
Command History
Usage Guidelines
Subinterfaces can be configured to support partially meshed Frame Relay networks. Refer to the "Configuring Serial Interfaces" chapter in the Cisco IOS Interface Configuration Guide.
There is no correlation between the number of the physical serial interface and the number of the logical LAN Extender interface. These interfaces can have the same or different numbers.
There is not a no form of this command.
Examples
The following example configures serial interface 0 with PPP encapsulation:
Router(config)# interface serial 0Router(config-if)# encapsulation pppThe following example enables loopback mode and assigns an IP network address and network mask to the interface. The loopback interface established here will always appear to be up:
Router(config)# interface loopback 0Router(config-if)# ip address 131.108.1.1 255.255.255.0The following example for the Cisco 7500 series router shows the interface configuration command for Ethernet port 4 on the EIP that is installed in (or recently removed from) slot 2:
Router(config)# interface ethernet 2/4The following example begins configuration on the Token Ring interface processor in slot 1 on port 0 of a Cisco 7500 series routers:
Router(config)# interface tokenring 1/0The following example shows how a partially meshed Frame Relay network can be configured. In this example, subinterface serial 0.1 is configured as a multipoint subinterface with three Frame Relay PVCs associated, and subinterface serial 0.2 is configured as a point-to-point subinterface.
Router(config)# interface serial 0Router(config-if)# encapsulation frame-relayRouter(config)# interface serial 0.1 multipointRouter(config-if)# ip address 131.108.10.1 255.255.255.0Router(config-if)# frame-relay interface-dlci 42 broadcastRouter(config-if)# frame-relay interface-dlci 53 broadcastRouter(config)# interface serial 0.2 point-to-pointRouter(config-if)# ip address 131.108.11.1 255.255.0Router(config-if)# frame-relay interface-dlci 59 broadcastThe following example configures circuit 0 of a T1 link for Point-to-Point Protocol (PPP) encapsulation:
Router(config)# controller t1 4/1Router(config-controller)# circuit 0 1Router(config)# interface serial 4/1:0Router(config-if)# ip address 131.108.13.1 255.255.255.0Router(config-if)# encapsulation pppThe following example configures LAN Extender interface 0:
Router(config)# interface lex 0Related Commands
ip cef
To enable Cisco Express Forwarding (CEF) on the route processor card, use the ip cef global configuration command. To disable CEF, use the no form of this command.
ip cef [distributed]
no ip cef [distributed]
Syntax Description
distributed
(Optional) Enables distributed CEF (dCEF) operation. Distributes CEF information to line cards. Line cards perform express forwarding.
Defaults
Command Modes
Global configuration
Command History
Usage Guidelines
This command is not available on the Cisco 12000 series GSR because that router series operates only in distributed CEF mode.
CEF is advanced Layer 3 IP switching technology. CEF optimizes network performance and scalability for networks with dynamic, topologically dispersed traffic patterns, such as those associated with Web-based applications and interactive sessions.
Examples
The following example enables standard CEF operation:
ip cefThe following example enables dCEF operation:
ip cef distributedRelated Commands
ip router isis
To configure an IS-IS routing process for IP on an interface, use the ip router isis interface configuration command. To disable IS-IS for IP, use the no form of this command.
ip router isis [tag]
no ip router isis [tag]
Syntax Description
Defaults
No routing processes are specified.
Command Modes
Interface configuration
Command History
Usage Guidelines
Before the IS-IS router process is useful, a NET must be assigned with the net command and some interfaces must be enabled with IS-IS.
If you have IS-IS running and at least one ISO-IGRP process, the IS-IS process and the ISO-IGRP process cannot both be configured without a tag. The null tag can be used by only one process. Therefore, if you do not use ISO-IGRP, the IS-IS tag should be null. If you run ISO-IGRP and IS-IS, a null tag can still be used for IS-IS, but not for ISO-IGRP at the same time.
Examples
The following example specifies IS-IS as an IP routing protocol for a process named Finance, and specifies that the Finance process will be routed on interfaces Ethernet 0 and serial 0:
router isis Financenet 49.0001.aaaa.aaaa.aaaa.00interface Ethernet 0ip router isis Financeinterface serial 0ip router isis FinanceRelated Commands
Configures an IS-IS network entity title (NET) for the routing process.
Enables the IS-IS routing protocol.
ip rsvp bandwidth
To enable Resource Reservation Protocol (RSVP) for IP on an interface, use the ip rsvp bandwidth interface configuration command. To disable RSVP completely, use the no form of this command. To eliminate only the sub-pool portion of the bandwidth, use the no form of this command with the keyword sub-pool.
ip rsvp bandwidth interface-kbps single-flow-kbps [sub-pool kbps]
no ip rsvp bandwidth interface-kbps single-flow-kbps [sub-pool kbps]
Syntax Description
Defaults
RSVP is disabled if this command is not entered. When enabled without the optional arguments, RSVP is enabled and 75 percent of the link bandwidth is reserved for it.
Command Modes
Interface configuration
Command History
Usage Guidelines
RSVP cannot be configured with VIP-distributed Cisco Express Forwarding (dCEF).
RSVP is disabled by default to allow backward compatibility with systems that do not implement RSVP.
Weighted Random Early Detection (WRED) or fair queueing must be enabled first.
Related Commands
is-type
To configure the IS-IS level at which the Cisco IOS software operates, use the is-type router configuration command. To reset the default value, use the no form of this command.
is-type {level-1 | level-1-2 | level-2-only}
no is-type {level-1 | level-1-2 | level-2-only}
Syntax Description
Defaults
Router acts as both a station router and an area router.
Command Modes
Router configuration
Command History
Usage Guidelines
It is highly recommended that you configure the type of an IS-IS router.
If there is only one area, there is no need to run two copies of the same algorithm. You have the option to run L1-only or L2-only everywhere. If IS-IS is used for CLNS routing, L1-only must be used everywhere. If IS-IS is used for IP routing, only, it is slightly preferred to run L2-only everywhere, as this allows easy addition of other areas later.
Examples
The following example specifies an area router:
router isisis-type level-2-onlymetric-style wide
To configure a router running IS-IS so that it generates and accepts only new-style type, length, and value objects (TLVs), use the metric-style wide router configuration command. Use the no form of this command to disable this feature.
metric-style wide [ transition ] [ { level-1 | level-2 | level-1-2 } ]
no metric-style wide [ transition ] [ { level-1 | level-2 | level-1-2 } ]
Syntax Description
Defaults
The MPLS traffic engineering image generates only old-style TLVs. To do MPLS traffic engineering, a router must generate new-style TLVs that have wider metric fields.
Command Modes
Router configuration
Command History
Usage Guidelines
If you enter the metric-style wide command, a router generates and accepts only new-style TLVs. Therefore, the router uses less memory and other resources than it would if it generated both old-style and new-style TLVs.
This style is appropriate for enabling MPLS traffic engineering across an entire network.
Note
Examples
In the following example, a router is configured to generate and accept only new-style TLVs on level 1:
Router(config-router)# metric-style wide level-1Related Commands
Configures a router to generate and accept old-style TLVs.
Configures a router to generate and accept both old-style and new-style TLVs.
mpls traffic-eng
To configure a router running IS-IS so that it floods MPLS traffic engineering link information into the indicated IS-IS level, use the mpls traffic-eng router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng { level-1 | level-2 }
no mpls traffic-eng { level-1 | level-2 }
Syntax Description
level-1
Floods MPLS traffic engineering link information into IS-IS level 1.
level-2
Floods MPLS traffic engineering link information into IS-IS level 2.
Defaults
Flooding is disabled.
Command Modes
Router configuration
Command History
Usage Guidelines
This command, which is part of the routing protocol tree, causes link resource information (such as available bandwidth) for appropriately configured links to be flooded in the IS-IS link state database.
Examples
In the following example, MPLS traffic engineering is turned on for IS-IS level 1:
Router(config-router)# mpls traffic-eng level-1Related Commands
Specifies that the traffic engineering router identifier for the node is the IP address associated with a given interface.
mpls traffic-eng administrative-weight
To override the Interior Gateway Protocol's (IGPs) administrative weight (cost) of the link, use the mpls traffic-eng administrative-weight interface configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng administrative-weight weight
no mpls traffic-eng administrative-weight
Syntax Description
Defaults
IGP cost of the link.
Command Modes
Interface configuration
Command History
Examples
The following example overrides the IGP's cost of the link and sets the cost to 20:
Router(config-if)# mpls traffic-eng administrative-weight 20Related Commands
mpls traffic-eng attribute-flags
Sets the user-specified attribute flags for an interface.
mpls traffic-eng area
To configure a router running OSPF MPLS so that it floods traffic engineering for the indicated OSPF area, use the mpls traffic-eng area router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng area num
no mpls traffic-eng area num
Syntax Description
Defaults
No default behavior or values.
Command Modes
Router configuration
Command History
Usage Guidelines
This command is in the routing protocol configuration tree, and is supported for both OSPF and IS-IS. The command affects the operation of MPLS traffic engineering only if MPLS traffic engineering is enabled for that routing protocol instance. Currently, only a single level can be enabled for traffic engineering.
Examples
The following example configures a router running OSPF MPLS to flood traffic engineering for OSPF 0:
Router(config-router)# mpls traffic-eng area 0Related Commands
mpls traffic-eng attribute-flags
To set the user-specified attribute flags for the interface, use the mpls traffic-eng attribute-flags interface configuration command. The interface is flooded globally so that it can be used as a tunnel head-end path selection criterion. Use the no form of this command to disable this feature.
mpls traffic-eng attribute-flags attributes
no mpls traffic-eng attribute-flags
Syntax Description
Defaults
0x0.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command assigns attributes to a link so that tunnels with matching attributes (represented by their affinity bits) prefer this link instead of others that do not match.
Examples
The following example sets the attribute flags to 0x0101:
Router(config-if)# mpls traffic-eng attribute-flags 0x0101Related Commands
mpls traffic-eng backup-path tunnel
To configure the interface to use a backup tunnel in the event of a detected failure on the interface, use the mpls traffic-eng backup tunnel interface command.
mpls traffic-eng backup-path tunnel interface
Syntax Description
Defaults
No default behavior or values.
Command Modes
Interface
Command History
Examples
The following example shows you how to specify the traffic engineering backup tunnel with the ID of 1000:
Router(config_if)# mpls traffic-eng backup-path Tunnel1000Related Commands
mpls traffic-eng flooding thresholds
To set a link's reserved bandwidth thresholds, use the mpls traffic-eng flooding thresholds interface configuration command. Use the no form of this command to return to the default settings.
mpls traffic-eng flooding thresholds {down | up} percent [percent...]
no mpls traffic-eng flooding thresholds {down | up}
Syntax Description
Defaults
The default for down is 100, 99, 98, 97, 96, 95, 90, 85, 80, 75, 60, 45, 30, 15.
The default for up is 15, 30, 45, 60, 75, 80, 85, 90, 95, 97, 98, 99, 100.
Command Modes
Interface configuration
Command History
Usage Guidelines
When a threshold is crossed, MPLS traffic engineering link management advertises updated link information. If no thresholds are crossed, changes may be flooded periodically unless periodic flooding was disabled.
Examples
The following example sets the link's reserved bandwidth for decreased resource availability (down) and for increased resource availability (up) thresholds:
Router(config-if)# mpls traffic-eng flooding thresholds down 100 75 25Router(config-if)# mpls traffic-eng flooding thresholds up 25 50 100Related Commands
mpls traffic-eng link timers bandwidth-hold
To set the length of time that bandwidth is "held" for an RSVP PATH (Set Up) message while waiting for the corresponding RSVP RESV message to come back, use the mpls traffic-eng link timers bandwidth-hold command
mpls traffic-eng link timers bandwidth-hold hold-time
Syntax Description
Defaults
15 seconds
Command Modes
Configuration
Command History
Examples
The following example sets the length of time that bandwidth is held to 10 seconds.
Router(config)# mpls traffic-eng link-management timers bandwidth-hold 10
Table 16 lists the fields displayed in this example.
Related Commands
show mpls traffic-eng link-management bandwidth-allocation
Shows current local link information.
mpls traffic-eng link timers periodic-flooding
To set the length of the interval used for periodic flooding, use the mpls traffic-eng link timers periodic-flooding command.
mpls traffic-eng link timers periodic-flooding interval
Syntax Description
Defaults
3 minutes
Command Modes
Configuration
Command History
Usage Guidelines
Use this command to set the length of the interval used for periodic flooding to advertise link state information changes that do not trigger immediate action (for example, a change to the amount of bandwidth allocated that does not cross a threshold).
Examples
The following example sets the interval length for periodic flooding to advertise flooding changes to 120 seconds.
Router(config)# mpls traffic-eng timers periodic-flooding 120Related Commands
mpls traffic-eng flooding thresholds
Sets a link's reserved bandwidth threshold.
mpls traffic-eng reoptimize timers frequency
To control the frequency at which tunnels with established LSPs are checked for better LSPs, use the mpls traffic-eng reoptimize timers frequency command.
mpls traffic-eng reoptimize timers frequency seconds
Syntax Description
Defaults
3600 seconds (1 hour) with a range of 0 to 604800 seconds (1 week).
Command Modes
Configuration
Command History
Usage Guidelines
A device with traffic engineering tunnels periodically examines tunnels with established LSPs to see if better LSPs are available. If a better LSP seems to be available, the device attempts to signal the better LSP and, if successful, replaces the old and inferior LSP with the new and better LSP.
Examples
The following example sets the reoptimization frequency to one day.
Router(config)# mpls traffic-eng reoptimize timers frequency 86400Related Commands
mpls traffic-eng reoptimize (exec)
Does a reoptimization check now.
tunnel mpls traffic-eng lockdown
Does not do a reoptimization check on this tunnel.
mpls traffic-eng router-id
To specify that the traffic engineering router identifier for the node is the IP address associated with a given interface, use the mpls traffic-eng router-id router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng router-id interface-name
no traffic-eng router-id
Syntax Description
Defaults
No default behavior or values.
Command Modes
Router configuration
Command History
Usage Guidelines
This router identifier acts as a stable IP address for the traffic engineering configuration. This stable IP address is flooded to all nodes. For all traffic engineering tunnels originating at other nodes and ending at this node, the tunnel destination must be set to the destination node's traffic engineering router identifier, since that is the address the traffic engineering topology database at the tunnel head uses for its path calculation.
Examples
The following example specifies that the traffic engineering router identifier is the IP address associated with interface Loopback0:
Router(config-router)# mpls traffic-eng router-id Loopback0Related Commands
mpls traffic-eng
Turns on flooding of MPLS traffic engineering link information into the indicated IGP level/area.
mpls traffic-eng tunnels
(global configuration mode)
To enable MPLS traffic engineering tunnel signalling on a device, use the mpls traffic-eng tunnels configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng tunnels
no mpls traffic-eng tunnels
Syntax Description
This command has no arguments or keywords.
Defaults
The feature is disabled.
Command Modes
Configuration
Command History
Usage Guidelines
This command enables MPLS traffic engineering on a device. To use the feature, MPLS traffic engineering must also be enabled on the desired interfaces.
Examples
The following example turns on the MPLS traffic engineering feature for a device:
Router(config)# mpls traffic-eng tunnelsRelated Commands
mpls traffic-eng tunnels (interface)
Enables MPLS traffic engineering tunnel signalling on an interface.
mpls traffic-eng tunnels
(interface configuration mode)
To enable MPLS traffic engineering tunnel signalling on an interface, assuming it is enabled already for the device, use the mpls traffic-eng tunnels interface configuration command. Use the no form of this command to disable this feature on the interface.
mpls traffic-eng tunnels
no mpls traffic-eng tunnels
Syntax Description
This command has no arguments or keywords.
Defaults
The feature is disabled on all interfaces.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command enables MPLS traffic engineering on the interface. MPLS traffic engineering must also be enabled on the device. An enabled interface has its resource information flooded into the appropriate IGP link state database, and accepts traffic engineering tunnel signalling requests.
Examples
The following example turns on MPLS traffic engineering on interface Ethernet0/0:
Router(config)# interface Ethernet0/0Router(config-if)# mpls traffic-eng tunnelsRelated Commands
mpls traffic-eng tunnels (configuration)
Enables MPLS traffic engineering tunnel signalling on a device.
net
To configure an IS-IS network entity title (NET) for the routing process, use the net router configuration command. To remove a NET, use the no form of this command.
net network-entity-title
no net network-entity-title
Syntax Description
network-entity-title
NET that specifies the area address and the system ID for an IS-IS routing process. This argument can be either an address or a name.
Defaults
No NET is configured and the IS-IS process will not start. A NET is mandatory.
Command Modes
Router configuration
Command History
Usage Guidelines
Under most circumstances, one and only one NET must be configured.
A NET is an NSAP where the last byte is always zero. On a Cisco router running IS-IS, a NET can be 8 to 20 bytes. The last byte is always the n-selector and must be zero.
The six bytes in front of the n-selector are the system ID. The system ID length is a fixed size and cannot be changed. The system ID must be unique throughout each area (L1) and throughout the backbone (L2).
All bytes in front of the system ID are the area ID.
Even when IS-IS is used to do IP routing only (no CLNS routing enabled), a NET must still be configured. This is needed to instruct the router about its system ID and area ID.
Multiple NETs per router are allowed, with a maximum of three. In rare circumstances, it is possible to configure two or three NETs. In such a case, the area this router is in will have three area addresses. There will still be only one area, but it will have more area addresses.
Configuring multiple NETs can be temporarily useful in the case of network reconfiguration where multiple areas are merged, or where one area is in the process of being split into more areas. Multiple area addresses enable you to renumber an area slowly, without the need of a flag day.
Examples
The following example configures a router with system ID 0000.0c11.11 and area ID 47.0004.004d.0001:
router isis Pieintheskynet 47.0004.004d.0001.0000.0c11.1111.00passive-interface
To disable sending routing updates on an interface, use the passive-interface router configuration command. To reenable the sending of routing updates, use the no form of this command.
passive-interface type number
no passive-interface type number
Syntax Description
Defaults
Routing updates are sent on the interface.
Command Modes
Router configuration
Command History
Usage Guidelines
If you disable the sending of routing updates on an interface, the particular subnet will continue to be advertised to other interfaces, and updates from other routers on that interface continue to be received and processed.
For OSPF, OSPF routing information is neither sent nor received through the specified router interface. The specified interface address appears as a stub network in the OSPF domain.
For IS-IS, this command instructs IS-IS to advertise the IP addresses for the specified interface without actually running IS-IS on that interface. The no form of this command for IS-IS disables advertising IP addresses for the specified address.
Enhanced IGRP is disabled on an interface that is configured as passive although it advertises the route.
Examples
The following example sends IGRP updates to all interfaces on network 131.108.0.0 except Ethernet interface 1:
router igrp 109network 131.108.0.0passive-interface ethernet 1The following configuration enables IS-IS on interfaces Ethernet 1 and serial 0 and advertises the IP addresses of Ethernet 0 in its Link State PDUs:
router isis Financepassive-interface Ethernet 0interface Ethernet 1ip router isis Financeinterface serial 0ip router isis Financerouter isis
To enable the IS-IS routing protocol and to specify an IS-IS process, use the router isis global configuration command. To disable IS-IS routing, use the no form of this command.
router isis [tag]
no router isis [tag]
Syntax Description
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
This command is needed to configure a NET and configure an interface with clns router isis or ip router isis.
You can specify only one IS-IS process per router. Only one IS-IS process is allowed whether you run it in integrated mode, ISO CLNS only, or IP only.
Examples
The following example configures IS-IS for IP routing, with system ID 0000.0000.0002 and area ID 01.0001, and enables IS-IS to form adjacencies on Ethernet 0 and serial 0 interfaces. The IP prefix assigned to Ethernet 0 will be advertised to other IS-IS routers:
router isis net 01.0001.0000.0000.0002.00is-type level-1!interface ethernet 0ip address 10.1.1.1 255.255.255.0ip router isis!interface serial 0ip unnumbered ethernet0ip router isisRelated Commands
router ospf
To configure an OSPF routing process, use the router ospf global configuration command. To terminate an OSPF routing process, use the no form of this command.
router ospf process-id
no router ospf process-id
Syntax Description
process-id
Internally used identification parameter for an OSPF routing process. It is locally assigned and can be any positive integer. A unique value is assigned for each OSPF routing process.
Defaults
No OSPF routing process is defined.
Command Modes
Global configuration
Command History
Usage Guidelines
You can specify multiple OSPF routing processes in each router.
Examples
The following example configures an OSPF routing process and assign a process number of 109:
router ospf 109Related Commands
Defines the interfaces on which OSPF runs and defines the area ID for those interfaces.
show interfaces tunnel
To list tunnel interface information, use the show interfaces tunnel privileged EXEC command.
show interfaces tunnel number [accounting]
Syntax Description
number
Port line number.
accounting
(Optional) Displays the number of packets of each protocol type that have been sent through the interface.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the show interfaces tunnel command:
Router# show interfaces tunnel 1Tunnel1 is up, line protocol is upHardware is TunnelInterface is unnumbered. Using address of Loopback0 (23.1.1.1)MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255Encapsulation TUNNEL, loopback not setKeepalive set (10 sec)Tunnel source 23.1.1.1, destination 24.1.1.1Tunnel protocol/transport Label Switching, key disabled, sequencing disabledChecksumming of packets disabled, fast tunneling enabledLast input never, output 00:00:06, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/0, 8 drops; input queue 0/75, 0 drops, 0 flushes5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec0 packets input, 0 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort92596 packets output, 8278258 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets0 output buffer failures, 0 output buffers swapped outTable 2 describes significant fields shown in the display.
Related Commands
Displays statistics for all interfaces configured on the router or access server.
show ip route
Displays the current state of the routing table.
show ip ospf
To display general information about OSPF routing processes, use the show ip ospf EXEC command.
show ip ospf [process-id]
Syntax Description
process-id
(Optional) Process ID. If this argument is included, only information for the specified routing process is included.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show ip ospf command when entered without a specific OSPF process ID:
Router# show ip ospfRouting Process "ospf 201" with ID 192.42.110.200Supports only single TOS(TOS0) routeIt is an area border and autonomous system boundary routerRedistributing External Routes from,igrp 200 with metric mapped to 2, includes subnets in redistributionrip with metric mapped to 2igrp 2 with metric mapped to 100igrp 32 with metric mapped to 1Number of areas in this router is 3Area 192.42.110.0Number of interfaces in this area is 1Area has simple password authenticationSPF algorithm executed 6 timesTable 3 describes significant fields shown in the display.
The following is sample output from the show ip ospf command when entered on a router configured for Diff-Serv-aware Traffic Engineering:
router-2# show ip ospfRouting Process "ospf 100" with ID 24.1.1.1Supports only single TOS(TOS0) routesSupports opaque LSASPF schedule delay 5 secs, Hold time between two SPFs 10 secsMinimum LSA interval 5 secs. Minimum LSA arrival 1 secsNumber of external LSA 0. Checksum Sum 0x0Number of opaque AS LSA 0. Checksum Sum 0x0Number of DCbitless external and opaque AS LSA 0Number of DoNotAge external and opaque AS LSA 0Number of areas in this router is 1. 1 normal 0 stub 0 nssaExternal flood list length 0Area BACKBONE(0) (Inactive)Number of interfaces in this area is 2Area has RRR enabledArea has no authenticationSPF algorithm executed 4 timesArea ranges areNumber of LSA 3. Checksum Sum 0x14D81Number of opaque link LSA 0. Checksum Sum 0x0Number of DCbitless LSA 0Number of indication LSA 0Number of DoNotAge LSA 0Flood list length 0show ip route
Use the show ip route EXEC command to display the current state of the routing table.
show ip route [address [mask] [longer-prefixes]] | [protocol [process-id]]
Syntax Description
Command Modes
EXEC
Examples
Command History
Examples
The following is sample output from the show ip route command when entered without an address:
Router# show ip routeCodes: I - IGRP derived, R - RIP derived, O - OSPF derivedC - connected, S - static, E - EGP derived, B - BGP derived* - candidate default route, IA - OSPF inter area routeE1 - OSPF external type 1 route, E2 - OSPF external type 2 routeGateway of last resort is 131.119.254.240 to network 129.140.0.0O E2 150.150.0.0 [160/5] via 131.119.254.6, 0:01:00, Ethernet2E 192.67.131.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2O E2 192.68.132.0 [160/5] via 131.119.254.6, 0:00:59, Ethernet2O E2 130.130.0.0 [160/5] via 131.119.254.6, 0:00:59, Ethernet2E 128.128.0.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2E 129.129.0.0 [200/129] via 131.119.254.240, 0:02:22, Ethernet2E 192.65.129.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2E 131.131.0.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2E 192.75.139.0 [200/129] via 131.119.254.240, 0:02:23, Ethernet2E 192.16.208.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2E 192.84.148.0 [200/129] via 131.119.254.240, 0:02:23, Ethernet2E 192.31.223.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2E 192.44.236.0 [200/129] via 131.119.254.240, 0:02:23, Ethernet2E 140.141.0.0 [200/129] via 131.119.254.240, 0:02:22, Ethernet2E 141.140.0.0 [200/129] via 131.119.254.240, 0:02:23, Ethernet2The following is sample output that includes some IS-IS Level 2 routes learned:
Router# show ip routeCodes: I - IGRP derived, R - RIP derived, O - OSPF derivedC - connected, S - static, E - EGP derived, B - BGP derivedi - IS-IS derived* - candidate default route, IA - OSPF inter area routeE1 - OSPF external type 1 route, E2 - OSPF external type 2 routeL1 - IS-IS level-1 route, L2 - IS-IS level-2 routeGateway of last resort is not set160.89.0.0 is subnetted (mask is 255.255.255.0), 3 subnetsC 160.89.64.0 255.255.255.0 is possibly down,routing via 0.0.0.0, Ethernet0i L2 160.89.67.0 [115/20] via 160.89.64.240, 0:00:12, Ethernet0i L2 160.89.66.0 [115/20] via 160.89.64.240, 0:00:12, Ethernet0Table 4 describes significant fields shown in these two displays.
When you specify that you want information about a specific network displayed, more detailed statistics are shown. The following is sample output from the show ip route command when entered with the address 131.119.0.0.
Router# show ip route 131.119.0.0Routing entry for 131.119.0.0 (mask 255.255.0.0)Known via "igrp 109", distance 100, metric 10989Tag 0Redistributing via igrp 109Last update from 131.108.35.13 on TokenRing0, 0:00:58 agoRouting Descriptor Blocks:* 131.108.35.13, from 131.108.35.13, 0:00:58 ago, via TokenRing0Route metric is 10989, traffic share count is 1Total delay is 45130 microseconds, minimum bandwidth is 1544 KbitReliability 255/255, minimum MTU 1500 bytesLoading 2/255, Hops 4When an IS-IS router advertises its link state information, it includes one of its own IP addresses to be used as the originator IP address. When other routers calculate IP routes, they can store the originator IP address with each route in the routing table.
The following example shows the output from the show ip route command when looking at an IP route generated by IS-IS. Each path that is shown under the Routing Descriptor Blocks report displays two IP addresses. The first address (10.22.22.2) is the next hop address, the second is the originator IP address from the advertising IS-IS router. This address helps you determine where a particular IP route has originated in your network. In the example the route to 10.0.0.1/32 was originated by a router with IP address 223.191.255.247.
Router# show ip route 10.0.0.1Routing entry for 10.0.0.1/32Known via "isis", distance 115, metric 20, type level-1Redistributing via isisLast update from 223.191.255.251 on Fddi1/0, 00:00:13 agoRouting Descriptor Blocks:* 10.22.22.2, from 223.191.255.247, via Serial2/3Route metric is 20, traffic share count is 1223.191.255.251, from 223.191.255.247, via Fddi1/0Route metric is 20, traffic share count is 1Compare the report above using the show ip route command with an IP address to the following report using the show ip route isis command:
Router# show ip route isis10.0.0.0/8 is variably subnetted, 2 subnets, 2 masksi L1 10.0.0.1/32 [115/20] via 10.22.22.2, Serial2/3[115/20] via 223.191.255.251, Fddi1/022.0.0.0/24 is subnetted, 2 subnetsi L1 22.22.23.0 [115/20] via 223.191.255.252, Fddi1/0Table 4 describes significant fields shown in this last display. Table 5 describes significant fields shown when using the show ip route command with an IP address (previous displays).
