Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 54 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
54
Dung lượng
251,01 KB
Nội dung
Configuring Advanced QoS Solutions in this chapter: ■ Enabling, Verifying, and Troubleshooting RSVP ■ Enabling, Verifying, and Troubleshooting CBWFQ ■ Configuring, Verifying, and Troubleshooting LLQ ■ Configuring, Verifying, and Troubleshooting WRED ■ Configuring and Verifying GTS and FRTS ■ Understanding Distributed Technologies ■ Configuring, Verifying, and Troubleshooting Link Fragmentation and Interleaving ■ Configuring, Verifying, and Troubleshooting RTP Header Compression Chapter 9 321 110_QoS_09 2/13/01 11:50 AM Page 321 322 Chapter 9 • Configuring Advanced QoS Introduction This chapter demonstrates how to properly configure the advanced technologies introduced in chapter 8. It will become a great reference tool to use when you are ready to configure these technologies on your network, and thus, as far as possible, every effort has been made to afford complete coverage of advanced technologies configurations. It is not feasible, however, to show all of the options available with these mechanisms. In the last chapter, we introduced these advanced mechanisms and mentioned that they are typically far more versatile when used in combination with other QoS techniques. In this chapter, we show you how these mechanisms can be used alone, as well as how powerful they can be when combined with other techniques. There will be things that you want to do with these QoS mechanisms that we do not show you.Thus, you should become familiar with Cisco’s Web site (www.cisco.com).The pages of CCO (Cisco Connection Online) contain more information than any book could ever hope to have, and this resource is kept up to date with the most cutting edge technologies and uses for existing technologies. Enabling, Verifying, and Troubleshooting Resource Reservation Protocol (RSVP) In Chapter 8, we learned that RSVP guarantees QoS to applications by reserving resources on the router. Specifically, two types of services can be guaranteed.To provide controlled-load service to applications, RSVP uses WRED on the output interface in the downstream direction of the reservation.To provide guaranteed-rate service, RSVP uses WFQ on the output interface in the downstream direction of the reservation.WRED helps to emulate an unloaded network by making sure that congestion never really starts.WFQ gives a rate guarantee and low packet drop rate to applications by giving the RSVP session priority over other flows. It is important to remember that RSVP works in one direction only (sim- plex). If a two-way (full duplex) reservation is needed, RSVP reservations must be made in each direction independently. Figure 9.1 shows how reservations for the RSVP session are enforced on the output interfaces of the routers in the direction of the session stream.Though the router keeps a stateful database of all reservations, it is at these interfaces that WFQ,WRED, or both act to implement the reservation. www.syngress.com 110_QoS_09 2/13/01 11:50 AM Page 322 www.syngress.com We also saw in Chapter 8 that RSVP is transparent to non-RSVP enabled nodes so that they can tunnel over non-RSVP aware networks (as shown in the Figure). However, notice that no reservations are made in the cloud or at its egress; therefore, there can be no bandwidth guarantees here. Enabling RSVP is much easier than trying to explain the mechanics of how it works. However, even though it is simple to enable, do not be tempted to enable it carelessly on all interfaces in your router network. It does take planning to ensure that RSVP reservations do not run rampant and take bandwidth from other applications. You will want to refer to Figure 9.1 throughout this section.We will refer- ence it in relation to enabling RSVP, and to illustrate particular show commands. Configuring Advanced QoS • Chapter 9 323 Figure 9.1 RSVP on the Network Client A (Sender) 10.0.6.2 Client B (Receiver) 10.0.1.2 Reservations are enforced on these interfaces in direction of flow. Non-RSVP aware IP Network Downstream 10.0.6.0/24 10.0.1.0/24 Router 1 Router 2 Router 3 Router 4 e2/0 10.0.6.1 s5/0:0 10.0.101.6 s4/0/0:0 10.0.101.5 110_QoS_09 2/13/01 11:50 AM Page 323 324 Chapter 9 • Configuring Advanced QoS Enabling RSVP Because WRED and WFQ act to implement RSVP reservations on the output interfaces of routers, RSVP must be enabled on a per interface basis.To do this, use the ip rsvp bandwidth command in the interface configuration context: Router1 #config t Enter configuration commands, one per line. End with CNTL/Z. Router1 (config)#int s5:0/0 Router1 (config-if)#bandwidth 1152 Router1 (config-if)#ip rsvp bandwidth 768 128 The first argument on the ip rsvp bandwidth command is the total amount of bandwidth that can be reserved on the interface.The second argument is the maximum bandwidth of a single reservation.Thus, the interface can set aside no more than 768 Kbps for RSVP reservations, with each reservation being no larger than 128 Kbps. Notice that the bandwidth command was entered first to tell the router the value of the total link speed. Many serial interfaces will default to 1544 Kbps unless otherwise specified.This is important since RSVP uses the bandwidth of the serial interface to calculate how much of the total can be reserved. RSVP will not allow more than 75 per cent of the total bandwidth to be reserved. Remember that you have to enable RSVP on each interface that you would like to participate in RSVP. Specifically, enable it on interfaces on which you expect QoS implementation mechanisms like WRED and WFQ to act to deliver QoS. Verifying Your RSVP Configuration You can confirm that your RSVP configuration is entered properly with the show run command, but there are other commands that you will find useful to monitor the status of RSVP. With the show ip rsvp installed command, all the current reservations can be displayed for each interface: Router1#show ip rsvp installed RSVP: Ethernet2/0 has no installed reservations RSVP: Serial5/0:0 BPS To From Protoc DPort Sport Weight Conversation 128K 10.0.1.2 10.0.6.2 TCP 0 0 6 271 64K 10.0.1.3 10.0.6.3 TCP 0 0 12 272 www.syngress.com 110_QoS_09 2/13/01 11:50 AM Page 324 Configuring Advanced QoS • Chapter 9 325 In this example, there are two reservations going out Serial5/0:0 from the senders 10.0.1.2 and 10.0.1.3 to the receivers 10.0.6.2 and 10.0.6.3 (the second pair of senders and receivers are not shown in Figure 9.1).The first reservation is for 128 Kbps, and the second is for 64 Kbps.The weight listed is the weighting factor used by WFQ.The conversation is the number assigned to that flow.Take a look at Figure 9.1 again, and remember that since the session flow is towards Client B from Client A, and because WFQ and WRED work on output inter- faces, there is no reservation on the Ethernet 2/0, even though the session is flowing in to the router through this interface. To see interface specific information, such as how much total bandwidth has been set aside for RSVP (i/f max) and the amount currently being used (allo- cated), issue the show ip rsvp interface command: Router1#show ip rsvp interface interface allocated i/f max flow max pct UDP IP UDP_IP UDP M/C Et2/0 0M 7500K 7500K 0 0 2 0 0 Se5/0:0 192K 1152K 1152K 16 0 1 0 0 Sometimes it is helpful to see all neighboring nodes that are participating in RSVP.To do this, use the show ip rsvp neighbor command: Router1#show ip rsvp neighbor Interfac Neighbor Encapsulation Et2/0 10.0.6.3 RSVP Et2/0 10.0.6.2 RSVP Se5/0:0 10.0.101.5 RSVP This tells us that there are two RSVP neighbors out the Ethernet 2/0 inter- face and another one out the Se5/0:0 interface.These neighbors can be any nodes that are currently using RSVP.They could be end-stations (10.0.6.3 and 10.0.6.2) or RSVP participating router interfaces (10.0.101.5). To display RSVP information such as requests flowing upstream and receiver and sender information currently in the database, use the following commands, respectively: www.syngress.com 110_QoS_09 2/13/01 11:50 AM Page 325 326 Chapter 9 • Configuring Advanced QoS Router1#show ip rsvp request To From Pro DPort Sport Next Hop I/F Fi Serv BPS Bytes 10.0.1.2 10.0.6.2 TCP 0 0 10.0.6.2 Et2/0 FF LOAD 128K 64K 10.0.1.3 10.0.6.3 TCP 0 0 10.0.6.3 Et2/0 FF RATE 64K 1K Router1#show ip rsvp reservation To From Pro DPort Sport Next Hop I/F Fi Serv BPS Bytes 10.0.1.2 10.0.6.2 TCP 0 0 10.0.101.5 Se5/0 FF LOAD 128K 64K 10.0.1.3 10.0.6.3 TCP 0 0 10.0.101.5 Se5/0 FF RATE 64K 1K Router1#show ip rsvp sender To From Pro DPort Sport Prev Hop I/F BPS Bytes 10.0.1.2 10.0.6.2 TCP 0 0 10.0.6.2 Et2/0 128K 1K 10.0.1.3 10.0.6.3 TCP 0 0 10.0.6.3 Et2/0 64K 1K The request and reservation show commands also indicate the type of service desired, either controlled-load (LOAD) or guaranteed-rate (RATE). www.syngress.com To capture the outputs shown above, a network similar to the one in Figure 9.1 can be set up in the lab. Because of the lack of RSVP-enabled clients, a feature called RSVP proxy is used to generate the Send and Resv messages. RSVP proxy is available on Cisco routers and allows the manual configuration of reservations. These are statically entered and remain in place until removed. Because they are not dynamic, it is not recommended that they be used for anything but testing, since the bandwidth remains “nailed-up” and cannot be used by packets outside of the reservation. Nonetheless, with these reservations up, QoS can be provided to packets matching the criteria set up with the proxy com- mands. For reference, here are the necessary commands. Router1: ip rsvp sender 10.0.1.2 10.0.6.2 TCP 0 0 10.0.6.2 Ethernet2/0 128 1 ip rsvp sender 10.0.1.3 10.0.6.3 TCP 0 0 10.0.6.3 Ethernet2/0 64 1 RSVP Proxy Continued 110_QoS_09 2/13/01 11:50 AM Page 326 Configuring Advanced QoS • Chapter 9 327 Troubleshooting RSVP The first step in troubleshooting an RSVP configuration is to use the show com- mands discussed. A good understanding of the session start-up process is required in order to determine where things might be going wrong.To help figure it out, you can use debugging commands.To turn on RSVP debugging, issue the debug ip rsvp command from the privileged exec command mode (enable mode). After enabling debugging, check your log with the show log command. Alternatively, you can enable terminal monitoring (if you are using Telnet) with terminal monitor to copy debug commands to the terminal window. WARNING Debugging is a privileged command that can be frustrating at times. If there is a lot of output from the debugging, you could swamp the pro- cessor and your terminal session, essentially locking you out of the router. If you expect large amounts of output, consider debugging with an access list. For example, use debug ip rsvp 100 detail, where 100 is an access list to select the addresses or protocols you are interested in. www.syngress.com Router4: ip rsvp reservation 10.0.1.2 10.0.6.2 TCP 0 0 10.0.1.2 Ethernet0/1 FF LOAD 128 64 ip rsvp reservation 10.0.1.3 10.0.6.3 TCP 0 0 10.0.1.3 Ethernet0/1 FF RATE 64 1 The ip rsvp sender command emulates a sender and generates RSVP Path packets. The ip rsvp reservation command emulates a receiver and generates RSVP Resv packets. Refer to Chapter 8 for a refresher on how these two packet types work to make a reservation, and see the Cisco documentation for the exact syntax of these com- mands if you want to use them to test your RSVP network. 110_QoS_09 2/13/01 11:50 AM Page 327 328 Chapter 9 • Configuring Advanced QoS Enabling, Verifying, and Troubleshooting Class-Based Weighted Fair Queuing (CBWFQ) CBWFQ allows the guarantee of bandwidth to classes defined by criteria such as protocol, Access Control Lists (ACLs), IP precedence, or input interfaces. CBWFQ is available on most Cisco router platforms, starting with IOS code ver- sion 12.0(5)T. To get up and running with CBWFQ, you first have to determine how many classes you need in order to categorize all your traffic.You also need to know what criteria you are going to use to map traffic into those classes, and what bandwidth guarantees you will give to each class. If you have already classified your traffic at the edge of the network, IP precedence may the only criterion you need. If you are configuring a more modest, point-to-point implementation of CBWFQ, you will probably use extended ACLs to categorize incoming traffic into classes. Enabling CBWFQ There are three major steps in configuring CBWFQ: 1. Defining class maps 2. Creating policy maps 3. Attaching policies to interfaces Class maps determine what traffic goes into what class and can be used in one or more policy maps. Policy maps determine how that traffic is handled. But no QoS is delivered until the policy map is applied to the interfaces. Let us see how this is done. Defining Class Maps The class-map statements in the router configuration determine how traffic is classified.The configured class must have a name that you can reference later. Within the class map, you set your match criteria. Consider this example: router1#config t Enter configuration commands, one per line. End with CNTL/Z. router1(config)#class-map Gold router1(config-cmap)#match access-group name Gold www.syngress.com 110_QoS_09 2/13/01 11:50 AM Page 328 Configuring Advanced QoS • Chapter 9 329 In this example, we created a class map with the name Gold.This could be a premium service offered to applications that guarantees a certain bandwidth. Furthermore, while in the class-map (config-cmap) command mode, we entered a match criterion, namely, the ACL named Gold.Thus, all traffic that matches the ACL will be part of the Gold class map.We have used the same name, Gold, for both the class map and the ACL name for consistency. It is neces- sary to configure the ACLs if you want the class maps to use them. In this case, the ACL might be configured like this: router1(config)#ip access-list extended Gold router1(config-ext-nacl)#permit ip any any precedence flash-override An extended access list is used so we can specify a match for any IP packet with a precedence of 4 (the fourth level of precedence is traditionally given the name flash-override). If it could not be expected that packets were marked at the edge of the network with IP precedence, then you would probably use an ACL that classifies traffic based on criteria like protocol and port number. If you are not already familiar with Access Control Lists, you should take some time to learn more about them.They are used frequently in many Cisco router features and are essential if you want fine control over what kinds of traffic end up in your QoS classes. NOTE In the previous example, we used an access list to specify the traffic. But if your match criteria are a little simpler, you may be able to match all your traffic with commands in the class map alone. With IOS 12.0(5)T, you can match all packets corresponding to a particular protocol with the match protocol command, or all packets arriving on a particular interface with the match input-interface command. With more recent versions of IOS, you can match according to criteria such as source address, destination address, protocol, IP precedence, and DSCP levels— all without using ACLs. Furthermore, you can place logical “AND” or “OR” statements between each of these criteria by specifying the class map with the class-map match-all or class-map match-any commands, respectively. www.syngress.com 110_QoS_09 2/13/01 11:50 AM Page 329 330 Chapter 9 • Configuring Advanced QoS Now that the Gold class has been configured, we can configure more class maps the same way: router1(config)#class-map Silver router1(config-cmap)#match access-group name Silver router1(config-cmap)#class-map Bronze router1(config-cmap)#match access-group name Bronze The extended access lists would be defined as follows: router1(config)#ip access-list extended Bronze router1(config-ext-nacl)#permit ip any any precedence immediate router1(config-ext-nacl)#ip access-list extended Silver router1(config-ext-nacl)#permit ip any any precedence flash This gives us three classes, Gold, Bronze, and Silver, mapped to the IP prece- dence levels 4, 3, and 2, respectively. Creating Policies Now that we have defined class maps, we can continue on to the second step to create the policy maps that specify the QoS the classes will ultimately have. Let us configure the policy for the Gold class configured in the last example: router1(config)#policy-map PPP-T1 router1(config-pmap)#class Gold router1(config-pmap-c)#bandwidth 216 We have given the name “PPP-T1” to the policy-map.You should use a name that will be descriptive, such as what kind of circuit bandwidth it was meant to run on.This leads us into the policy map command context (config-pmap).We now enter the class that we want to specify parameters for, in this case, Gold. Under this new context (config-pmap-c), we specify the bandwidth reserved for this class in Kbps.You can enter the following commands to configure the QoS the class will be given: ■ bandwidth Bandwidth (in Kbps) ■ queue-limit Maximum queue threshold for tail drop ■ random-detect Enable WRED as drop policy www.syngress.com 110_QoS_09 2/13/01 11:50 AM Page 330 [...]... configuration: class-map Gold match access-group Gold class-map Bronze match access-group Bronze class-map Silver match access-group Silver ! policy-map PPP-T1 class Gold bandwidth 216 class Silver bandwidth 1 69 class Bronze bandwidth 108 class class-default bandwidth 31 ! ! ip access-list extended Gold permit ip any any precedence flash-override ip access-list extended Bronze permit ip any any precedence... parameters router1(config)#map-class frame-relay Data router1(config-map-class)#frame-relay traffic-rate 256000 router1(config-map-class)#frame-relay adaptive-shaping becn router1(config-map-class)#frame-relay mincir 128000 After defining the name of the class map, Data, we use the frame-relay traffic-rate command to set the CIR parameter.The syntax of the command is like this: frame-relay traffic-rate average [peak]... the VIP-based RSP platform for DWRED by using the show interfaces [interface-type interfacenumber] random-detect command: router3#show queueing random-detect Current random-detect configuration: www.syngress.com 343 110 _QoS_ 09 344 2/13/01 11:50 AM Page 344 Chapter 9 • Configuring Advanced QoS Serial4/0/0:0 Queueing strategy: fifo Packet drop strategy: VIP-based random early detection (DWRED) Exp-weight-constant:... 95 418/84680 Class Silver www.syngress.com 110 _QoS_ 09 2/13/01 11:50 AM Page 3 39 Configuring Advanced QoS • Chapter 9 Output Queue: Conversation 266 Bandwidth 1 69 (kbps) Packets Matched 248305 Max Threshold 64 (packets) (discards/tail drops) 1 195 58/1 098 29 Class Bronze Output Queue: Conversation 267 Bandwidth 108 (kbps) Packets Matched 248 292 Max Threshold 64 (packets) (discards/tail drops) 156 598 /14 895 6... pkts/bytes pkts/bytes threshold threshold probability 0 491 4/560382 1 896 4/2161 896 20 40 1/10 1 4786/545604 18834/2147076 22 40 1/10 2 4705/536370 18853/21 492 42 24 40 1/10 3 4700/535800 1 893 8/215 893 2 26 40 1/10 4 4612/525768 18830/2146620 28 40 1/10 5 4543/51 790 2 18857/21 496 98 31 40 1/10 6 4 494 /512282 1 892 8/2157622 33 40 1/10 7 4380/ 499 320 18851/21 490 14 35 40 1/10 rsvp 0/0 0/0 37 40 1/10 This provides... Exp-weight-constant: 9 (1/512) Mean queue depth: 192 Queue size: 194 Maximum available buffers: 384 Output packets: 150838 Class WRED drops: 10434 No buffer: 0 Random Tail Minimum Maximum Mark Output drop drop threshold threshold probability Packets 0 1067 543 96 192 1/10 21456 1 0 0 108 192 1/10 0 2 1054 546 120 192 1/10 21412 3 10 49 535 132 192 1/10 21428 4 1042 530 144 192 1/10 214 39 5 836 517 156 192 1/10 21658... 29 42 1/10 0 5 0 0 31 42 1/10 0 6 0 0 33 42 1/10 0 7 0 1 35 42 1/10 22417 class-map: Internet (match-all) 22751 packets, 11375500 bytes 30 second offered rate 203000 bps, drop rate 0 bps match: access-group name Internet queue size 0, queue limit 69 packets output 22 099 , packet drops 3 19 tail/random drops 3 19, no buffer drops 0, other drops 0 bandwidth: kbps 277, weight 24 random-detect: Exp-weight-constant:... Maximum DWRED Threshold Values Minimum Maximum 0 1 2 3 4 5 6 7 RSVP 20 22 24 26 28 31 33 35 37 95 106 117 128 1 39 150 161 172 N/A 40 40 40 40 40 40 40 40 40 190 190 190 190 190 190 190 190 N/A Table 9. 1 shows the default values of the minimum and maximum thresholds for each precedence.The minimum threshold for IP precedence 0 is one half the maximum.The value of the minimum threshold for the remaining... www.syngress.com 345 110 _QoS_ 09 346 2/13/01 11:50 AM Page 346 Chapter 9 • Configuring Advanced QoS Class Random Tail Minimum Maximum Mark Output drop drop threshold threshold probability packets 0 0 0 17 34 1/10 0 1 0 0 19 34 1/10 0 2 0 0 21 34 1/10 0 3 0 0 23 34 1/10 0 4 0 0 25 34 1/10 0 5 0 0 27 34 1/10 0 6 18 22 29 34 1/10 22 099 7 0 0 31 34 1/10 0 class-map: Platinum (match-all) 22751 packets, 11375500... 14 27 1/10 0 2 0 0 15 27 1/10 0 3 0 0 16 27 1/10 0 4 95 121 17 27 1/10 214 29 www.syngress.com 110 _QoS_ 09 2/13/01 11:50 AM Page 347 Configuring Advanced QoS • Chapter 9 5 0 0 18 27 1/10 0 6 0 0 19 27 1/10 0 7 0 0 20 27 1/10 0 class-map: Silver (match-all) 22751 packets, 11375500 bytes 30 second offered rate 203000 bps, drop rate 37000 bps match: access-group name Silver queue size 42, queue limit 42 packets . follows: router1(config) #ip access-list extended Bronze router1(config-ext-nacl)#permit ip any any precedence immediate router1(config-ext-nacl) #ip access-list extended Silver router1(config-ext-nacl)#permit ip any. class map with the class-map match-all or class-map match-any commands, respectively. www.syngress.com 110 _QoS_ 09 2/13/01 11:50 AM Page 3 29 330 Chapter 9 • Configuring Advanced QoS Now that the Gold. CNTL/Z. router1(config)#class-map Gold router1(config-cmap)#match access-group name Gold www.syngress.com 110 _QoS_ 09 2/13/01 11:50 AM Page 328 Configuring Advanced QoS • Chapter 9 3 29 In this example, we