![]() |
Asynchronous Transfer Mode Configuration Guide, Cisco IOS Release 12.4T
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MPLS Diff-Serv-aware Traffic Engineering over ATM
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Contents
MPLS Diff-Serv-aware Traffic Engineering over ATMLast Updated: December 5, 2011
This guide presents extensions made to Multiprotocol Label Switching Traffic Engineering (MPLS TE) that make it Diff-Serv aware and applicable across ATM networks. 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.
Finding Feature InformationYour software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Feature History
Background and OverviewMPLS 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. BenefitsDiff-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 TechnologiesThe 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 DocumentsFor OSPF:
For IS-IS:
For RSVP:
For QoS:
For MPLS Traffic Engineering:
For ATM:
Platforms and Interfaces SupportedThis release supports DS-TE together with QoS on the POS, ATM-PVC, and LC-ATM interfaces of the Cisco 7200 and 7500 Series Routers. To carry DS-TE tunnels through an MPLS ATM cloud, an ATM-LSR should contain a Cisco 7200 router (functioning as its Label Switch Controller) and any one of the following ATM switches: 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 StandardsStandardization 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:
As the IETF work is still in progress, details are still under definition and subject to change, so DS-TE should be considered as a pre-standard implementation of IETF DiffServ-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). PrerequisitesYour network must support the following Cisco IOS features in order to support guaranteed bandwidth services based on Diff-Serv-aware Traffic Engineering:
Configuration TasksThis 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 14), presents these same commands in context and shows how, by combining them with QoS commands, you can build guaranteed bandwidth services. New CommandsDS-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 commandThe old command was ip rsvp bandwidth x y where x = the size of the only possible pool, and y = the size of a single traffic flow (ignored by traffic engineering) Now the extended command is ip rsvp bandwidth x y sub-pool z where x = the size of the global pool, and z = the size of the sub-pool. (Remember, the sub-pool's bandwidth is less than--because it is part of--the global pool's bandwidth.) The tunnel mpls traffic-eng bandwidth commandThe old command was tunnel mpls traffic-eng bandwidth b where b = the amount of bandwidth this tunnel requires. Now you specify from which pool (global or sub) the tunnel's bandwidth is to come. You can enter tunnel mpls traffic-eng bandwidth sub-pool b This indicates that the tunnel should use bandwidth from the sub-pool. Alternatively, you can enter tunnel mpls traffic-eng bandwidth b This indicates that the tunnel should use bandwidth from the global pool (the default). The Configuration ProcedureTo establish a sub-pool TE tunnel, you must enter configurations at three levels:
On the first two levels, you activate traffic engineering (and certain ATM settings if the tunnel will cross an ATM cloud). 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 DeviceAt 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. You enter the following commands: DETAILED STEPS
Level 2: Configuring the Network InterfaceHaving 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 and LC-ATM interfaces you must enable IS-IS on a sub -interface level, and you must enable MPLS on both the interface and the sub-interface levels.) To accomplish these tasks, you enter the following commands. (Step 7 or 8 is entered only when the interface you are configuring is either an ATM-PVC - Step 7 - or an LC-ATM - Step 8). DETAILED STEPS
Level 3: Configuring the Tunnel InterfaceNow 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 at this level which was affected to create DS-TE is tunnel mpls traffic-eng bandwidth (described in detail on page 145). You enter the following commands: DETAILED STEPS
ATM-LSR Special CaseBecause of the joint nature of the ATM-LSR device--being both a router running Cisco IOS and an ATM switch running its own, different operating system--distinct configuration tasks are required to have this device convey DS-TE tunnels across itself as a tunnel midpoint. (The ATM-LSR device cannot be the head nor tail of a DS-TE tunnel, only a midpoint). Configuring the ATM-LSR midpoint device thus involves four tasks:
Establishing a link between the router and the switch control portSUMMARY STEPS
DETAILED STEPS
Mapping pools to classes of serviceSUMMARY STEPS
DETAILED STEPS
Mapping switch ports and configuring XTag-ATM interfacesSUMMARY STEPS
DETAILED STEPS
Configuring resources within the switch(Reminder--the following commands are entered directly into the switch. They are not part of the router portion's Cisco IOS software.) DETAILED STEPS
Verifying the ConfigurationsTo 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 or LC-ATM 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 95 for show interfaces tunnel and page 109 for show ip rsvp interface. RTR1#show interfaces tunnel 4 Tunnel4 is up, line protocol is down Hardware is Routing Tunnel MTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 Encapsulation TUNNEL, loopback not set, keepalive set (10 sec) Tunnel source 0.0.0.0, destination 0.0.0.0 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Last input never, output never, output hang never Last clearing of "show interface" counters never Output queue 0/0, 0 drops; input queue 0/75, 0 drops Five minute input rate 0 bits/sec, 0 packets/sec Five minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets, 0 restarts RTR1#show ip rsvp interface pos4/0 interface allocated i/f max flow max sub max PO4/0 300K 466500K 466500K 0M RTR1#show ip rsvp interface atm3/0 RTR1#show ip rsvp interface atm3/0.5 interface allocated i/f max flow max sub max AT3/0.5 110M 130M 130M 100 To view all tunnels at once on the router you have configured, enter show mpls traffic-eng tunnels brief. The information displayed when tunnels are functioning properly looks like this (a table explaining the display fields begins on page 136):
RTR1#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3029 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
RTR1_t0 192.168.1.13 - SR3/0 up/up
RTR1_t1 192.168.1.13 - SR3/0 up/up
RTR1_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) tails
When 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 brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 2279 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
RTR1_t0 192.168.1.13 - SR3/0 up/down
RTR1_t1 192.168.1.13 - SR3/0 up/down
RTR1_t2 192.168.1.13 - PO4/0 up/up
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails
To find out why a tunnel is down, insert its name into this same command, after adding the keyword name and omitting the keyword brief. For example:
RTR1#show mpls traffic-eng tunnels name RTR1_t0
Name:RTR1_t0 (Tunnel0) Destination:192.168.1.13
Status:
Admin:up Oper:down Path: not valid Signalling:connected
If, as in this example, the Path is displayed as not valid, use the show mpls traffic-eng topology commandto make sure the router has received the needed updates. (That command is described on page 133.) Additionally, you can use any of the following show commands to inspect particular aspects of the network, router, or interface concerned:
Configuration ExamplesFirst 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 the figure below, 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. Sample topologies when the tunnel will run over ATM-PVCs are shown in the next two figures below. 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. As shown in the figure below, DS-TE tunnels that travel through an MPLS ATM cloud can start either at a device outside the cloud or at one located on the edge of the cloud. Likewise, these tunnels can end either at a device on the edge of the cloud or one that is wholly outside the cloud. However, DS-TE tunnels cannot begin or end inside an MPLS ATM cloud. On the edge of the cloud, the interface conveying the tunnel is an LC-ATM. Within the cloud, it is an XTag-ATM, residing on an ATM-LSR device. A sample topology for tunnels that traverse LC-ATM interfaces is shown in the figure below The following example refers to all three figures. Where the language is specific to only one type of interface, that fact is indicated.
Tunnel HeadAt the device level: router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)# ip cef router(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(config-router)# mpls traffic-eng router-id Loopback0 router(config-router)# exit router(config)# interface Loopback0 At the virtual interface level: router(config-if)# ip address 22.1.1.1 255.255.255.255 router(config-if)# no ip directed-broadcast router(config-if)# exit At the device level: [ATM cases appear 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:
router(config-if)# exit
At the device level:
router(config)# interface Tunnel1
At the tunnel interface level: router(config-if)# bandwidth 110000 router(config-if)# ip unnumbered Loopback0 router(config-if)# tunnel destination 24.1.1.1 router(config-if)# tunnel mode mpls traffic-eng router(config-if)# tunnel mpls traffic-eng priority 0 0 router(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000 router(config-if)# tunnel mpls traffic-eng path-option 1 dynamic router(config-if)# exit router(config)# Midpoint DevicesAt the device level: router# configure terminal router(config)# ip cef router(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(config-router)# mpls traffic-eng router-id Loopback0 router(config-router)# exit router(config)# interface Loopback0 At the virtual interface level: router(config-if)# ip address 25.1.1.1 255.255.255.255 router(config-if)# no ip directed-broadcast router(config-if)# exit [And if the device is an ATM-LSR: router(config)#interface atm9/0 0/0/0 router(config-if)# label-control-protocol vsi router(config-if)# exit router(config)#mpls traffic-eng atm cos sub-pool ] On all devices, for the ingress interface: [ATM-LSR appears on the left; ATM-PVC and LC-ATM cases in the middle; POS on the right] [continuing each case at the network interface level]
Continuing at the network interface level, regardless of interface type:
router(config-if)# exit
At the device level, for the egress interface: [ATM-LSR appears on the left; ATM-PVC and LC-ATM cases in the middle; POS on the right] [continuing each case at the network interface level]
Continuing at the network interface level, regardless of interface type:
router(config-if)# exit
Note that there is no configuring of tunnel interfaces at the mid-point devices, only network interfaces, sub-interfaces, and the device globally. When the midpoint device is an ATM-LSR, the following commands are also required. They are entered directly into the switch device, bypassing Cisco IOS: BPX-12# uptrk 1.1 BPX-12# addshelf 1.1 v l.1 BPX-12# cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000 BPX-12# uptrk 2.2 BPX-12# cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000 BPX-12# uptrk 3.3 BPX-12# cnfrsrc 3.3 256 252207 y 1 e 512 4096 2 5 26000 100000 BPX-12# uptrk 4.4 BPX-12# cnfrsrc 4.4 256 252207 y 1 e 512 4096 2 5 26000 100000 BPX-12# uptrk 5.5 BPX-12# cnfrsrc 5.5 256 252207 y 1 e 512 4096 2 5 26000 100000 Tail-End DeviceAt the device level: router# configure terminal router(config)# ip cef router(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(config-router)# mpls traffic-eng router-id Loopback0 router(config-router)# exit router(config)# interface Loopback0 At the virtual interface level: router(config-if)# ip address 24.1.1.1 255.255.255.255 router(config-if)# no ip directed-broadcast [and if using IS-IS instead of OSPF]: router(config-if)# ip router isis [and in all cases]: router(config-if)# exit At the device level: [ATM cases appear 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:
router(config-if)# exit
Guaranteed Bandwidth Service ConfigurationHaving 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 TunnelsA tunnel using sub-pool bandwidth can satisfy the stricter requirements if you do all of the following:
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.
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.
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).
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 TunnelsYou 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:
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. Guaranteed Bandwidth Service ExamplesGiven 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 PrefixThe three figures below illustrate topologies for guaranteed bandwidth services whose destination is specified by a single prefix. In the first figure below, the interfaces to be configured are POS (Packet over SONET), while in second figure below the interfaces are ATM-PVC (Asynchronous Transfer Mode - Permanent Virtual Circuit), and in the third figure below, they are LC-ATM (Label Controlled - Asynchronous Transfer Mode) and, within the MPLS ATM cloud, XTag-ATM. In all three 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 in each sample topology:
These three services run through two sub-pool tunnels:
In the POS and ATM-PVC examples, both tunnels use the same tail router, though they have different heads. This is to illustrate that many combinations are possible. (In Figure 5 one midpoint router is shared by both tunnels. In the real world there could of course be many more midpoints.) All POS, ATM-PVC, LC-ATM, and XTagATM interfaces in this example are OC3, whose capacity is 155 Mbps.
Configuring Tunnel Head-1First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier on page 14). 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 TunnelAt the device level: router-1(config)# ip cef router-1(config)# mpls traffic-eng tunnels [now one uses either the IS-IS commands on the left or the OSPF commands on the right]:
[now one resumes the common command set]: router-1(config-router)# mpls traffic-eng router-id Loopback0 router-1(config-router)# exit Create a virtual interface: router-1(config)# interface Loopback0 router-1(config-if)# ip address 23.1.1.1 255.255.255.255 router-1(config-if)# no ip directed-broadcast router-1(config-if)# exit For 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:
router-1(config-if)# exit
At the tunnel interface: router-1(config)# interface Tunnel1 router-1(config-if)# bandwidth 110000 router-1(config-if)# ip unnumbered Loopback0 router-1(config-if)# tunnel destination 27.1.1.1 router-1(config-if)# tunnel mode mpls traffic-eng router-1(config-if)# tunnel mpls traffic-eng priority 0 0 router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000 router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic To ensure that packets destined to host 26.1.1.1 and subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static route. At the device level: router-1(config)# ip route 26.1.1.0 255.255.255.0 Tunnel1 router-1(config)# exit And in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down this tunnel, we disable autoroute announce:
router-1(config)# no tunnel mpls traffic-eng autoroute announce
For Service from Site A to Site D
SUMMARY STEPS
DETAILED STEPS For Service from Site B to Subnet Province
SUMMARY STEPS
DETAILED STEPS For Both ServicesThe outbound interface (POS4/0 in Figure 5 and Figure 7, and ATM2/0.4 in Figure 6) is configured as follows: DETAILED STEPS
Configuring Tunnel Head-2First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier on page 16). 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. [And because this router is on the edge of the MPLS ATM cloud in Figure 7, an LC-ATM interface is configured in that example.] Configuring the Pools and TunnelAt the device level: router-2(config)# ip cef router-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 Loopback0 router-2(config-router)# exit Create a virtual interface: router-2(config)# interface Loopback0 router-2(config-if)# ip address 22.1.1.1 255.255.255.255 router-2(config-if)# no ip directed-broadcast router-2(config-if)# exit For the outgoing network interface: [ATM cases appear 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:
router-2(config-if)# exit
At the tunnel interface: router-2(config)# interface Tunnel2 router-2(config-if)# ip unnumbered Loopback0 router-2(config-if)# tunnel destination 27.1.1.1 [though in Figure 7: tunnel destination 28.1.1.1 ] router-2(config-if)# tunnel mode mpls traffic-eng router-2(config-if)# tunnel mpls traffic-eng priority 0 0 router-2(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000 router-2(config-if)# tunnel mpls traffic-eng path-option 1 dynamic To ensure that packets destined to subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static route. At the device level: router-2(config)# ip route 26.1.1.0 255.255.255.0 Tunnel2 router-2(config)# exit And in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down this tunnel, we disable autoroute announce:
router-2(config)# no tunnel mpls traffic-eng autoroute announce
For Service from Site C to Subnet Province
SUMMARY STEPS
DETAILED STEPS Tunnel Midpoint ConfigurationsAll four interfaces on the 7200 midpoint router ("Mid-1" in Figure 5, "Midpoint" in Figure 6) are configured identically to the outbound interface of the head router (except, of course, for the IDs of the individual interfaces). When an ATM-LSR serves as a midpoint (as in Figure 7), its XTagATM interfaces and BPX or IGX switching resources must be configured. Also, two new MPLS commands are used. The details of this configuration are presented in the ATM-LSR section which begins on page 38. The LC-ATM midpoint configuration (on the left edge of the ATM cloud in Figure 7) is presented on page 35. LC-ATM at a midpoint on the right edge of the cloud in Figure 7 is presented on page 39. Configuring the Pools and TunnelsAt the device level: router-3(config)# ip cef router-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 Loopback0 router-3(config-router)# exit Create a virtual interface: router-3(config)# interface Loopback0 router-3(config-if)# ip address 22.1.1.1 255.255.255.255 router-3(config-if)# exit For 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:
router-3(config-if)# exit
For 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:
router-3(config-if)# exit
For 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:
router-3(config-if)# exit
For 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:
router-3(config-if)# exit
Tunnel Midpoint Configuration POS ingress and LC-ATM egressConfiguring the Pools and TunnelsAt the device level: router-2(config)# ip cef router-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 Loopback0 router-2(config-router)# exit Create a virtual interface: router-2(config)# interface Loopback0 router-2(config-if)# ip address 22.1.1.1 255.255.255.255 router-2(config-if)# exit For the incoming network interface, first at the device level:
router-2(config)# interface POS2/1
[then continuing at the network interface level]: router-2(config-if)# ip address 11.1.1.2 255.0.0.0 router-2(config-if)# mpls traffic-eng tunnels router-2(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000 [If using IS-IS instead of OSPF]: router-2(config-if)# ip router isis [and in both cases]: router-2(config-if)# exit For the outgoing network interface: router-2(config)# interface atm6/1 router-2(config-if)# mpls traffic-eng tunnels router-2(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000 router-2(config-if)# interface atm6/1.3 mpls router-2(config-subif)# ip address 11.1.1.2 255.0.0.0 router-2(config-subif)#ip rsvp bandwidth 140000 140000 sub-pool 60000 router-2(config-subif)# mpls traffic-eng tunnels router-2(config-subif)# mpls atm vpi 2-15 [if using IS-IS instead of OSPF]: router-2(config-subif)# ip router isis router-2(config-subif)# exit [and in bothcases]: router-2(config-if)# exit Tunnel Midpoint Configuration all POS[For the sake of simplicity, the ATM-PVC example (Figure 6) was illustrated with only one midpoint router.] Both interfaces on the second 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 TunnelAt the device level: router-5(config)# ip cef router-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 Loopback0 router-5(config-router)# exit Create a virtual interface: router-5(config)# interface Loopback0 router-5(config-if)# ip address 25.1.1.1 255.255.255.255 router-5(config-if)# exit At the incoming network interface level: router-5(config)# interface pos1/1 router-5(config-if)# ip address 13.1.1.2 255.0.0.0 router-5(config-if)# mpls traffic-eng tunnels router-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)# exit At the outgoing network interface level: router-5(config)# interface pos2/1 router-5(config-if)# ip address 14.1.1.1 255.0.0.0 router-5(config-if)# mpls traffic-eng tunnels router-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)# exit Tunnel Midpoint Configurationz all XTag-ATMWhen an ATM-LSR serves as a midpoint, its Virtual Switch Interface, XTagATM interfaces, and BPX or IGX switching resources must be configured. Also, one or two new MPLS commands are used on the ATM-LSR (namely, mpls traffic-eng atm cos sub-pool and mpls traffic-eng atm cos global-pool), to transfer traffic from priority queues into class-of-service (since the cell-based switch cannot examine packets). Configuring the Pools and TunnelAt the device level: router-6(config)# ip cef router-6(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-6(config-router)# mpls traffic-eng router-id Loopback0 router-6(config-router)# exit Create a virtual interface: router-6(config)# interface Loopback0 router-6(config-if)# ip address 25.1.1.1 255.255.255.255 router-6(config-if)# exit At the device level, to coordinate traffic across the router and switch portions of the device: router-6(config)# interface atm9/0 0/0/0 router-6(config-if)# label-control-protocol vsi router-6(config-if)# exit router-6(config)# mpls traffic-eng atm cos sub-pool router-6(config)# mpls traffic-eng atm cos global-pool premiun For one incoming network interface:
router-6(config)# interface Xtagatm22
router-6(config-if)# extended-port atm9/0 bpx2.2 router-6(config-if)# ip address 10.1.1.2 255.0.0.0 router-6(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000 router-6(config-if)# mpls traffic-eng tunnels router-6(config-if)# mpls atm vpi 2-15 [If using IS-IS instead of OSPF]: router-6(config-if)# ip router isis [and in either case]: router-6(config-if)# exit For the other incoming network interface: router-6(config)# interface xtagatm55 router-6(config-if)# extended-port atm9/0 bpx5.5 router-6(config-if)# ip address 11.1.1.2 255.0.0.0 router-6(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000 router-6(config-if)# mpls traffic-eng tunnels router-6(config-if)# mpls atm vpi 2-15 [If using IS-IS instead of OSPF]: router-6(config-if)# ip router isis [and in either case]: router-6(config-if)# exit For one outgoing network interface: router-6(config)# interface Xtagatm33 router-6(config-if)# extended-port atm9/0 bpx3.3 router-6(config-if)# ip address 11.1.1.2 255.0.0.0 router-6(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000 router-6(config-if)# mpls traffic-eng tunnels router-6(config-if)# mpls atm vpi 2-15 [If using IS-IS instead of OSPF]: router-6(config-if)# ip router isis [and in either case]: router-6(config-if)# exit For the other outgoing network interface: router-6(config)# interface Xtagatm44 router-6(config-if)# extended-port atm9/0 bpx4.4 router-6(config-if)# ip address 12.1.1.1 255.0.0.0 router-6(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000 router-6(config-if)# mpls traffic-eng tunnels router-6(config-if)# mpls atm vpi 2-15 [If using IS-IS instead of OSPF]: router-6(config-if)# ip router isis [and in either case]: router-6(config-if)# exit Tunnel Midpoint Configuration LC-ATM IngressThis 7200 midpoint router sits at the right-side edge of the MPLS ATM cloud in Figure 7. Therefore its ingress interface is LC-ATM and its egress can be either POS or ACM-PVC. Configuring the Pools and TunnelsAt the device level: router-8(config)# ip cef router-8(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-8(config-router)# mpls traffic-eng router-id Loopback0 router-8(config-router)# exit Create a virtual interface: router-8(config)# interface Loopback0 router-8(config-if)# ip address 27.1.1.1 255.255.255.255 router-8(config-if)# exit At the incoming network interface level: router-8(config)# interface atm8/2 router-8(config-if)# mpls traffic-eng tunnels router-8(config-if)# ip rsvp bandwidth 140000 140000\ sub-pool 60000 router-8(config-if)# interface atm8/2.0 mpls router-8(config-subif)# ip address 13.1.1.2 255.0.0.0 router-8(config-subif)# ip rsvp bandwidth 140000 140000 sub-pool 60000 router-8(config-subif)# mpls traffic-eng tunnels router-8(config-subif)# mpls atm vpi 2-15 [if using IS-IS instead of OSPF]: router-8(config-subif)# ip router isis router-8(config-subif)# exit And in all cases:
router-8(config-if)# exit
For 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:
router-8(config-if)# exit
Tunnel Tail ConfigurationThe 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 TunnelsAt the device level: router-4-8-or-7(config)# ip cef router-4-8-or-7(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-8-or-7(config-router)# mpls traffic-eng router-id Loopback0 router-4-8-or-7(config-router)# exit Create a virtual interface: router-4-8-or-7(config)# interface Loopback0 router-4-8-or-7(config-if)# ip address 27.1.1.1 255.255.255.255 [but on router-7 in Figure 7 use ip address 28.1.1.1 255.255.255.255 ] router-4-8-or-7(config-if)# exit For the incoming network interface, first at the device level: [LC-ATM 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:
router-4-8-or-7(config-if)# exit
Because 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 PrefixesThe two figures below illustrate topologies for guaranteed bandwidth services whose destinations are a set of prefixes. In the first figure below the interfaces to be configured are POS (Packet over SONET), while in second figure below 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:
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:
All of these tasks are included in the following example.
Tunnel Head Configuration Head-1First we recapitulate commands that establish a sub-pool tunnel (commands presented earlier on page 9) 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 TunnelsAt the device level: router-1(config)# ip cef router-1(config)# mpls traffic-eng tunnels [now one uses either the IS-IS commands on the left or the OSPF commands on the right]:
[now one resumes the common command set]: router-1(config-router)# mpls traffic-eng router-id Loopback0 router-1(config-router)# exit Create a virtual interface: router-1(config)# interface Loopback0 router-1(config-if)# ip address 23.1.1.1 255.255.255.255 router-1(config-if)# exit For 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)# exit At one tunnel interface, create a sub-pool tunnel: router-1(config)# interface Tunnel1 router-1(config-if)# ip unnumbered Loopback0 router-1(config-if)# tunnel destination 27.1.1.1 router-1(config-if)# tunnel mode mpls traffic-eng router-1(config-if)# tunnel mpls traffic-eng priority 0 0 router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000 router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path1 router-1(config-if)# exit and at a second tunnel interface, create a global pool tunnel: router-1(config)# interface Tunnel2 router-1(config-if)# ip unnumbered Loopback0 router-1(config-if)# tunnel destination 27.1.1.1 router-1(config-if)# tunnel mode mpls traffic-eng router-1(config-if)# tunnel mpls traffic-eng priority 0 0 router-1(config-if)# tunnel mpls traffic-eng bandwidth 80000 router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \ best-effort-path1 router-1(config-if)# exit In 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-path1 router-1(config-ip-expl-path)# next-address 24.1.1.1 router-1(config-ip-expl-path)# next-address 27.1.1.1 router-1(config-ip-expl-path)# exit router-1(config)# ip explicit-path name best-effort-path1 router-1(config-ip-expl-path)# next-address 24.1.1.1 router-1(config-ip-expl-path)# next-address 25.1.1.1 router-1(config-ip-expl-path)# next-address 27.1.1.1 router-1(config-ip-expl-path)# exit Note that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other traffic down these tunnels. Configuring DiffServ QoSAt the inbound network interface (in Figure 8 and Figure 9 this is FE4/0), packets received are rate-limited to:
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/0 router-1(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \ conform-action set-mpls-exp-transmit 5 exceed-action drop router-1(config-if)# bgp-policy destination ip-qos-map router-1(config-if)# exit At 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-class router-1(config-cmap)# match mpls experimental 5 router-1(config-cmap)# exit Create a policy that creates a priority queue for "exp5-class": router-1(config)# policy-map core-out-policy router-1(config-pmap)# class exp5-class router-1(config-pmap-c)# priority 100000 router-1(config-pmap-c)# exit router-1(config-pmap)# class class-default router-1(config-pmap-c)# bandwidth 55000 router-1(config-pmap-c)# exit router-1(config-pmap)# exit The policy is applied to packets exiting subinterface ATM2/0.4 (first example) or interface POS4/0 (second example)?: interface atm2/0 interface atm2/0.4 service-policy output core-out-policy interface POS4/0 service-policy output\ core-out-policy For All GB ServicesCreate a table map under BGP to map (tie) the prefixes to a qos-group. At the device level: router-1(config)# router bgp 2 router-1(config-router)# no synchronization router-1(config-router)# table-map set-qos-group router-1(config-router)# bgp log-neighbor-changes router-1(config-router)# neighbor 27.1.1.1 remote-as 2 router-1(config-router)# neighbor 27.1.1.1 update-source Loopback0 router-1(config-router)# no auto-summary router-1(config-router)# exit For GB Service Destined to AS5Create 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 57) 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 10 router-1(config-route-map)# match as-path 100 router-1(config-route-map)# set ip qos-group 6 router-1(config-route-map)# set ip next-hop 29.1.1.1 router-1(config-route-map)# exit router-1(config)# ip as-path access-list 100 permit ^5$ For GB Service Transiting through AS5Create 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 10 router-1(config-route-map)# match as-path 101 router-1(config-route-map)# set ip qos-group 6 router-1(config-route-map)# set ip next-hop 29.1.1.1 router-1(config-route-map)# exit router-1(config)# ip as-path access-list 101 permit _5_ For GB Service Destined to Community 100:1Create 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 10 router-1(config-route-map)# match community 20 router-1(config-route-map)# set ip qos-group 6 router-1(config-route-map)# set ip next-hop 29.1.1.1 router-1(config-route-map)# exit router-1(config)# ip community-list 20 permit 100:1 Mapping Traffic onto the TunnelsMap all guaranteed bandwidth traffic onto Tunnel #1:
router-1(config)# ip route 29.1.1.1 255.255.255.255 Tunnel1
Map 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 Tunnel2
Tunnel Head Configuration Head-2As 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 9) 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 TunnelsAt the device level: router-2(config)# ip cef router-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 Loopback0 router-2(config-router)# exit Create a virtual interface: router-2(config)# interface Loopback0 router-2(config-if)# ip address 22.1.1.1 255.255.255.255 router-2(config-if)# exit For 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)# exit At one tunnel interface, create a sub-pool tunnel: router-2(config)# interface Tunnel3 router-2(config-if)# ip unnumbered Loopback0 router-2(config-if)# tunnel destination 27.1.1.1 router-2(config-if)# tunnel mode mpls traffic-eng router-2(config-if)# tunnel mpls traffic-eng priority 0 0 router-2(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000 router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path2 router-2(config-if)# exit and at a second tunnel interface, create a global pool tunnel: router-2(config)# interface Tunnel4 router-2(config-if)# ip unnumbered Loopback0 router-2(config-if)# tunnel destination 27.1.1.1 router-2(config-if)# tunnel mode mpls traffic-eng router-2(config-if)# tunnel mpls traffic-eng priority 0 0 router-2(config-if)# tunnel mpls traffic-eng bandwidth 70000 router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \ best-effort-path2 router-2(config-if)# exit In 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-path2 router-2(config-ip-expl-path)# next-address 24.1.1.1 router-2(config-ip-expl-path)# next-address 27.1.1.1 router-2(config-ip-expl-path)# exit router-2(config)# ip explicit-path name best-effort-path2 router-2(config-ip-expl-path)# next-address 24.1.1.1 router-2(config-ip-expl-path)# next-address 25.1.1.1 router-2(config-ip-expl-path)# next-address 27.1.1.1 router-2(config-ip-expl-path)# exit Note that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other traffic down these tunnels. Configuring DiffServ QoSAt the inbound network interface (in Figure 8 and Figure 9 this is FE2/1), packets received are rate-limited to: 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/1 router-2(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \ conform-action set-mpls-exp-transmit 5 exceed-action drop router-2(config-if)# bgp-policy destination ip-qos-map router-2(config-if)# exit At 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-class router-2(config-cmap)# match mpls experimental 5 router-2(config-cmap)# exit Create a policy that creates a priority queue for "exp5-class": router-2(config)# policy-map core-out-policy router-2(config-pmap)# class exp5-class router-2(config-pmap-c)# priority 100000 router-2(config-pmap-c)# exit router-2(config-pmap)# class class-default router-2(config-pmap-c)# bandwidth 55000 router-2(config-pmap-c)# exit router-2(config-pmap)# exit The policy is applied to packets exiting subinterface ATM3/0.2 (left side) or interface POS0/0 (right side):
For All GB ServicesCreate a table map under BGP to map (tie) the prefixes to a qos-group. At the device level: router-2(config)# router bgp 2 router-2(config-router)# no synchronization router-2(config-router)# table-map set-qos-group router-2(config-router)# bgp log-neighbor-changes router-2(config-router)# neighbor 27.1.1.1 remote-as 2 router-2(config-router)# neighbor 27.1.1.1 update-source Loopback0 router-2(config-router)# no auto-summary router-2(config-router)# exit For GB Service Destined to AS5Create 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 57) 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 10 router-2(config-route-map)# match as-path 100 router-2(config-route-map)# set ip qos-group 6 router-2(config-route-map)# set ip next-hop 29.1.1.1 router-2(config-route-map)# exit router-2(config)# ip as-path access-list 100 permit ^5$ For GB Service Transiting through AS5Create 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 10 router-2(config-route-map)# match as-path 101 router-2(config-route-map)# set ip qos-group 6 router-2(config-route-map)# set ip next-hop 29.1.1.1 router-2(config-route-map)# exit router-2(config)# ip as-path access-list 101 permit _5_ For GB Service Destined to Community 100:1Create 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 10 router-2(config-route-map)# match community 20 router-2(config-route-map)# set ip qos-group 6 router-2(config-route-map)# set ip next-hop 29.1.1.1 router-2(config-route-map)# exit router-2(config)# ip community-list 20 permit 100:1 Mapping Traffic onto the TunnelsMap all guaranteed bandwidth traffic onto Tunnel #3:
router-2(config)# ip route 29.1.1.1 255.255.255.255 Tunnel3
Map 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 Tunnel4
Tunnel Midpoint Configuration Mid-1All 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 TunnelsAt the device level: router-3(config)# ip cef router-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 Loopback0 router-3(config-router)# exit Create a virtual interface: router-3(config)# interface Loopback0 router-3(config-if)# ip address 24.1.1.1 255.255.255.255 router-3(config-if)# exit At 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)# exit At 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)# exit At 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)# exit At 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)# exit Tunnel Midpoint Configuration Mid-2[For the sake of simplicity, only the POS example (Figure 8) 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 TunnelsAt the device level: router-5(config)# ip cef router-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 Loopback0 router-5(config-router)# exit Create a virtual interface: router-5(config)# interface Loopback0 router-5(config-if)# ip address 25.1.1.1 255.255.255.255 router-5(config-if)# exit At the incoming network interface: router-5(config)# interface pos1/1 router-5(config-if)# ip address 13.1.1.2 255.0.0.0 router-5(config-if)# mpls traffic-eng tunnels router-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)# exit At the outgoing network interface: router-5(config)# interface pos2/1 router-5(config-if)# ip address 14.1.1.1 255.0.0.0 router-5(config-if)# mpls traffic-eng tunnels router-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)# exit Tunnel Tail ConfigurationThe inbound interfaces on the tail router are configured much like the outbound interfaces of the midpoint routers: Configuring the Pools and TunnelsAt the device level: router-4(config)# ip cef router-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 Loopback0 router-4(config-router)# mpls traffic-eng router-id Loopback1 router-4(config-router)# mpls traffic-eng router-id Loopback2 router-4(config-router)# exit Create a virtual interface: router-4(config)# interface Loopback0 router-4(config-if)# ip address 27.1.1.1 255.255.255.255 router-4(config-if)# exit At 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)# exit At 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)# exit Configuring QoS Policy PropagationOn 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 Loopback1 router-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)# exit router-4(config)# interface Loopback2 router-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)# exit At the device level, configure BGP to send the community to each tunnel head: router-4(config)# router bgp 2 router-4(config-router)# neighbor 23.1.1.1 send-community router-4(config-router)# neighbor 22.1.1.1 send-community router-4(config-router)# exit Command ReferenceThe following commands are introduced or modified in the feature or features documented in this module. For information about these commands, see the Cisco IOS Asynchronous Transfer Mode Command Reference. For information about all Cisco IOS commands, go to the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or to the Cisco IOS Master Commands List.
GlossaryThis section defines acronyms and words that may not be readily understood. AS --Autonomous System. A collection of networks under a common administration, sharing a common routing strategy and identified by a unique 16-bit number (assigned by the Internet Assigned Numbers Authority). ATM --Asynchronous Transfer Mode. The international standard for cell relay in which several service types (such as voice, video or data) are conveyed in fixed-length (53-byte) cells. Fixed-length cells allow cell processing to occur in hardware, thereby reducing transit delays. ATM is designed to take advantage of high-speed transmission media, such as E3, SONET, and T3. BGP --Border Gateway Protocol. The predominant interdomain routing protocol. It is defined by RFC 1163. Version 4 uses route aggregation mechanisms to reduce the size of routing tables. BPX --A Cisco standards-based ATM switch that supports broadband, narrowband, and IP services. CBR--Constraint Based Routing. The computation of traffic paths that simultaneously satisfy label-switched path attributes and current network resource limitations. CEF --Cisco Express Forwarding. A means for accelerating the forwarding of packets within a router, by storing route lookup information in several data structures instead of in a route cache. CLI--Command Line Interface. Cisco's interface for configuring and managing its routers. DS-TE --Diff Serv-aware Traffic Engineering. The capability to configure two bandwidth pools on each link, a global pool and a sub-pool. MPLS traffic engineering tunnels using the sub-pool bandwidth can be configured with Quality of Service mechanisms to deliver guaranteed bandwidth services end-to-end across the network. Simultaneously, tunnels using the global pool can convey diff-serv traffic. flooding --A traffic passing technique used by switches and bridges in which traffic received on an interface is sent out through all of the interfaces of that device except the interface on which the information was originally received. GB queue --Guaranteed Bandwidth queue. A per-hop behavior (PHB) used exclusively by the strict guarantee traffic. If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue (EF PHB) is used. If only bandwidth guarantees are sought, the diffserv Assured Forwarding PHB (AF PHB) is used. Global Pool --The total bandwidth allocated to an MPLS traffic engineering link. IGP --Interior Gateway Protocol. An internet protocol used to exchange routing information within an autonomous system. Examples of common internet IGPs include IGRP, OSPF, and RIP. label-switched path (LSP) tunnel --A configured connection between two routers, using label switching to carry the packets. IS-IS --Intermediate System-to-Intermediate System. A link-state hierarchical routing protocol, based on DECnet Phase V routing, whereby nodes exchange routing information based on a single metric, to determine network topology. LCAC --Link-level (per-hop) call admission control. LC-ATM --Label switching Controlled ATM. The assignment of values into the VPI/VCI field of ATM cells by MPLS rather than by ATM control procedures. LSP --Label-switched path (see above).Also Link-state packet--A broadcast packet used by link-state protocols that contains information about neighbors and path costs. LSPs are used by the receiving routers to maintain their routing tables. Also called link-state advertisement (LSA). MPLS --Multi-Protocol Label Switching (formerly known as Tag Switching). A method for directing packets primarily through Layer 2 switching rather than Layer 3 routing, by assigning the packets short fixed-length labels at the ingress to an MPLS cloud, using the concept of forwarding equivalence classes. Within the MPLS domain, the labels are used to make forwarding decisions mostly without recourse to the original packet headers. MPLS TE --MPLS Traffic Engineering (formerly known as "RRR" or Resource Reservation Routing). The use of label switching to improve traffic performance along with an efficient use of network resources. OSPF --Open Shortest Path First. A link-state, hierarchical IGP routing algorithm, derived from the IS-IS protocol. OSPF features include least-cost routing, multipath routing, and load balancing. POS --Packet over SONET (Synchronous Optical Network). PVC --Permanent Virtual Connection. A circuit or channel through an ATM network provisioned by a carrier between two end points; used for dedicated long-term information transport between locations. PVCs save bandwidth associated with circuit establishment and tear down in situations where certain virtual circuits must exist all the time. RSVP --Resource reSerVation Protocol. An IETF protocol used for signaling requests (to set aside internet services) by a customer before that customer is permitted to transmit data over that portion of the network. Sub-pool --The more restrictive bandwidth in an MPLS traffic engineering link. The sub-pool is a portion of the link's overall global pool bandwidth. TE --Traffic engineering. The application of scientific principles and technology to measure, model, and control internet traffic in order to simultaneously optimize traffic performance and network resource utilization. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2011 Cisco Systems, Inc. All rights reserved.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|