|
|
Congestion Management (Queuing)This section covers PQ and CQ configuration, as well as distributed WFQ (dWFQ) and MDRR configuration. PQ ConfigurationPQ configuration resembles access-control list (ACL) configuration, except the result is to queue a packet rather than discarding it. Global commands are used to define the logic for classifying packets by matching header fields, and an interface subcommand is used to enable PQ on an interface. Example configurations for PQ follow Tables B-10 and B-11, which list the configuration and exec commands related to PQ, respectively.
To understand the core PQ configuration commands, examine Example B-14. In this example, R3 uses PQ on its S0/0 interface. The engineer configuring R3 decided that voice traffic could benefit from being placed into the High queue, so a simple QoS policy has been devised:
Figure B-14 shows the network in which the configuration is applied, and Example B-14 shows the configuration and the commands used. Note that all IP addresses in the example start with 192.168. Figure B-14. Network Used with PQ Configuration Examples
Example B-14. Priority Queuing, VoIP in High Queue, All Else in Normal Queue
R3#show running-config
Building configuration...
! Portions omitted for brevity
interface Ethernet0/0
description connected to SW2, where Server1 is connected
ip address 192.168.3.253 255.255.255.0
load-interval 30
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
load-interval 30
priority-group 5
clockrate 64000
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (R1)
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
!
access-list 120 permit udp any range 16384 32767 any range 16384 32767
!
priority-list 5 protocol ip high list 120
R3#show queue serial 0/0
Output queue for Serial0/0 is 26/60
Packet 1, linktype: ip, length: 1404, flags: 0x88
source: 192.168.3.100, destination: 192.168.1.100, id: 0xF560, ttl: 127,
TOS: 0 prot: 6, source port 2831, destination port 1668
data: 0x0B0F 0x0684 0x79EB 0x0D2A 0x05B4 0x0FF5 0x5010
0x4510 0x5BF8 0x0000 0x6076 0xEEFD 0xFBB6 0xCC72
Packet 2, linktype: ip, length: 724, flags: 0x88
source: 192.168.3.100, destination: 192.168.1.100, id: 0xF561, ttl: 127,
TOS: 0 prot: 6, source port 80, destination port 1667
data: 0x0050 0x0683 0x79C1 0x0930 0x05B3 0xE88E 0x5010
0x41C5 0x276E 0x0000 0xDA9B 0x48F7 0x7F64 0x7313
Packet 3, linktype: ip, length: 724, flags: 0x88
source: 192.168.3.100, destination: 192.168.1.100, id: 0xF562, ttl: 127,
TOS: 0 prot: 6, source port 80, destination port 1666
data: 0x0050 0x0682 0x79BC 0xE875 0x05B3 0xE2C6 0x5010
0x441A 0xA5A2 0x0000 0x8071 0x4239 0x5906 0xD18C
! Several lines omitted for brevity
R3#show queueing interface serial 0/0
Interface Serial0/0 queueing strategy: priority
Output queue utilization (queue/count)
high/13593 medium/0 normal/206 low/0
R3#show queueing priority
Current DLCI priority queue configuration:
Current priority queue configuration:
List Queue Args
5 high protocol ip list 120
R3#show int s 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description: connected to FRS port S0. Single PVC to R1.
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 9/255, rxload 8/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 79, LMI stat recvd 70, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 165/2, interface broadcasts 149
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:13:25
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2
Queueing strategy: priority-list 5
Output queue (queue priority: size/max/drops):
high: 4/20/2, medium: 0/40/0, normal: 20/60/0, low: 0/80/0
!
! Lines omitted for brevity.
Example B-14 uses only one priority-list command in this case, putting voice traffic into the High queue and letting the rest of the traffic be placed in the Normal queue by default. The priority-list 5 protocol ip high list 120 command matches all IP packets that are permitted by ACL 120, which matches all VoIP User Datagram Protocol (UDP) ports. The priority-group 5 interface subcommand enables PQ on S0/0, linking PQ list 5 with the interface. Two similar commands display some limited information about PQ. First, the show queue command lists brief information about packets currently in the queue. Notice that some information is listed for each packet in the queue; in Example B-14, a packet that was sent by the web server (source port 80) is highlighted. Also note that none of the stanzas describing the packets in the queue shows a voice packet, with UDP ports between 16384 and 32767. Because PQ always serves the High queue first, you would need to have more voice traffic being sent into the network than the speed of the interface before packets would ever actually back up into the High queue. Therefore, it is rare to see queue entries for packets in the High queue. The show queueing interface command lists configuration information about PQ and statistical information about how many packets have been placed into each queue. Note that no packets have been placed into the Medium or Low queues, because priority-list 5 matches VoIP packets, placing them in the High queue, with all other packets defaulting to the Normal queue. The show queueing priority command lists information about the configuration of PQ. Finally, the output of the show interfaces command states that PQ is in use, along with statistics about each queue. The current number of packets in each queue, the maximum length of each queue, and the cumulative number of tail drops is listed for each of the four queues. Good QoS design calls for the marking of packets close to the source of the packet. The next example (Example B-15) accomplishes the same queuing goals as the preceding example, but in this case, PQ relies on the fact that the packets have been marked before reaching R3's S0/0 interface. In a real network, the packets could be marked on one of the LAN switches, or in an IP Phone, or by the computers in the network. This example shows the packets being marked upon entering R3's E0/0 interface. Example B-15 shows the revised configuration based on the following criteria:
Example B-15. Priority Queuing, DSCP EF in High Queue, All Else in Normal Queue
R3#show running-config
! Portions omitted for brevity
! Next several lines are CB Marking configuration, not PQ configuration
class-map match-all all-else
match any
class-map match-all voip-rtp
match ip rtp 16384 16383
!
policy-map voip-and-be
class voip-rtp
set ip dscp 46
class class-default
set ip dscp 0
!
!
interface Ethernet0/0
description connected to SW2, where Server1 is connected
ip address 192.168.3.253 255.255.255.0
load-interval 30
service-policy input voip-and-be
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
load-interval 30
priority-group 6
clockrate 128000
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (R1)
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
!
! Portions omitted for brevity
!
access-list 121 permit ip any any dscp ef
!
priority-list 6 protocol ip high list 121
!
! Portions omitted for brevity
R3#show queueing priority
Current DLCI priority queue configuration:
Current priority queue configuration:
List Queue Args
6 high protocol ip list 121
R3#show interface s 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description: connected to FRS port S0. Single PVC to R1.
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 20/255, rxload 6/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 29, LMI stat recvd 29, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 68/0, interface broadcasts 63
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:04:50
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 751
Queueing strategy: priority-list 6
Output queue (queue priority: size/max/drops):
high: 0/20/0, medium: 0/40/0, normal: 4/60/751, low: 0/80/0
!
!Portions omitted for brevity.
In Example B-15, priority-list 6 contains a single entry, referring to ACL 121, which matches all IP packets with DSCP EF. The priority-group 6 command enables PQ on S0/0. Before the PQ configuration can actually do what the requirements suggest, the packets must be marked. The policy-map voip-and-be command matches VoIP packets based on their UDP port numbers, and marks them on ingress to interface e0/0. Note that unlike the preceding example, when an ACL matched all UDP ports between 16384 and 32767, this example matches only even- numbered ports, which are the ports actually used for VoIP payload. (The odd-numbered ports are used for voice signaling.) The match ip rtp 16384 16383 command matches the same range of port numbers as ACL 120, except it only matches the even (payload) ports. PQ can only support four different classifications of packets, because it only has four queues. Example B-16 shows all four queues being used. The following criteria is used for queuing packets on R3's S0/0 interface:
The same network used in the preceding example, as shown in Figure B-14, is used for this example, too. Example B-16. PQ Example: VoIP in High, NetMeeting in Medium, HTTP in Normal, and All Else in Low Queueaccess-list 150 permit udp host 192.168.1.100 range 16384 32767 192.168.3.0 0.0.0.255 range 16384 32767 ! access-list 151 permit udp any range 16384 32768 any range 16384 32768 ! access-list 152 permit tcp any eq www any access-list 152 permit tcp any any eq www ! priority-list 8 protocol ip medium list 150 priority-list 8 protocol ip high list 151 priority-list 8 protocol ip normal list 152 priority-list 8 default low ! interface serial 0/0 priority-group 8 Note a couple of points from the example. First, there is no need to match the traffic that goes into the Low queue, because the priority-list 8 default low command makes the Low queue the default queue for unmatched packets. Second, note that ACL 152 matches web traffic from web servers, as well as to web servers. In this limited example, you only needed to check for packets from the web server when performing queuing on output of R3's S0/0 interface. Because one day you might have traffic going to a web server exiting R3's S0/0 interface, however, you might want to go ahead and match all web traffic as shown in the ACL. Finally, one last example shows the equivalent configuration as shown in Example B-16, but with the assumption that the traffic had been marked before reaching R3's S0/0 interface. Again, the packets are marked upon entering R3's E0/0, using CB marking. The criteria used for the final example, whose configuration is shown in Example B-17, is as follows:
Example B-17. PQ Example: DSCP EF in High, DSCP AF41 in Medium, DSCP AF22 in Normal, and All Else in Low Queue
R3#show running-config
! Portions omitted for brevity
class-map match-all http-all
match protocol http
class-map match-all voip-rtp
match ip rtp 16384 16383
class-map match-all NetMeet
match access-group NetMeet-ACL
class-map match-all all-else
match any
!
policy-map laundry-list
class voip-rtp
set ip dscp 46
class NetMeet
set ip dscp 34
class http-all
set ip dscp 20
class class-default
set ip dscp 0
!
interface Ethernet0/0
description connected to SW2, where Server1 is connected
ip address 192.168.3.253 255.255.255.0
ip nbar protocol-discovery
load-interval 30
service-policy input laundry-list
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
load-interval 30
priority-group 7
clockrate 128000
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (R1)
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
!
ip access-list extended NetMeet-ACL
permit udp host 192.168.3.100 range 16384 32768192.168.1.0 0.0.0.255 range 16384 32768
!
access-list 130 permit ip any any dscp ef
access-list 131 permit ip any any dscp af41
access-list 132 permit ip any any dscp af22
access-list 133 permit ip any any dscp default
!
priority-list 7 protocol ip high list 130
priority-list 7 protocol ip medium list 131
priority-list 7 protocol ip normal list 132
priority-list 7 protocol ip low list 133
priority-list 7 default low
R3#show queueing int s 0/0
Interface Serial0/0 queueing strategy: priority
Output queue utilization (queue/count)
high/42092 medium/1182 normal/52 low/3242
As seen in Example B-17, if the packets have already been marked, PQ can simply match the DSCP field. Routers that forward these packets later can also just configure PQ, and match the DSCP field. Note that PQ needs to refer to an ACL to match the DSCP field, whereas some other queuing tools can refer directly to the DSCP field without using an ACL. Another interesting point to note in this configuration is that the CB marking configuration used network-based application recognition (NBAR) with the match protocol http command to match all web traffic, and then set those packets with DSCP 20. Example B-16 showed why you might want to match all web traffic, but the configuration used two entries to match all web traffic (ACL 152). With NBAR, you can match all web traffic, regardless of whether it is coming from or going to a web server. CQ ConfigurationCQ configuration resembles PQ configuration. Global commands are used to define the logic for classifying packets by matching header fields, and an interface subcommand is used to enable CQ on an interface. Example configurations for CQ follow Tables B-12 and B-13, which list the configuration and exec commands related to CQ, respectively.
To understand the core CQ configuration commands, examine Example B-18. (This example is identical to Example B-14, shown in the "PQ Configuration" section earlier in this chapter, except that CQ is used rather than PQ.) In this example, R3 uses CQ on its S0/0 interface. The engineer configuring R3 decided that voice traffic could benefit from being given preferential queuing treatment, so a simple QoS policy has been devised, as noted in the following:
Figure B-15 shows the network in which the configuration is applied, and Example B-18 shows the configuration and show commands: Figure B-15. Network Used with CQ Configuration Examples
Example B-18. Custom Queuing: VoIP in High Queue, All Else in Normal Queue
R3(config)#queue-list 1 protocol ip 1 ?
fragments Prioritize fragmented IP packets
gt Classify packets greater than a specified size
list To specify an access list
lt Classify packets less than a specified size
tcp Prioritize TCP packets 'to' or 'from' the specified port
udp Prioritize UDP packets 'to' or 'from' the specified port
<cr>
R3(config)#^Z
R3#show running-config
access-list 120 permit udp any range 16383 32767 any range 16383 32767
!
queue-list 5 protocol ip 2 list 120
queue-list 5 queue 2 byte-count 5000
queue-list 5 queue 1 byte-count 2500
queue-list 5 queue 2 limit 30
!
interface serial0/0
custom-queue-list 5
!
R3#show queueing custom
Current custom queue configuration:
List Queue Args
5 2 protocol ip list 120
5 1 byte-count 2500
5 2 byte-count 5000 limit 30
R3#show queueing int s 0/0
Interface Serial0/0 queueing strategy: custom
Output queue utilization (queue/count)
0/15 1/91 2/3549 3/0 4/0 5/0 6/0 7/0 8/0
9/0 10/0 11/0 12/0 13/0 14/0 15/0 16/0
R3#show int s 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description: connected to FRS port S0. Single PVC to R1.
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 9/255, rxload 8/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 1, LMI stat recvd 1, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 4/0, interface broadcasts 3
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:00:12
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 282
Queueing strategy: custom-list 5
Output queues: (queue #: size/max/drops)
0: 0/20/0 1: 6/20/0 2: 28/30/282 3: 0/20/0 4: 0/20/0
5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0
15: 0/20/0 16: 0/20/0
5 minute input rate 52000 bits/sec, 102 packets/sec
5 minute output rate 60000 bits/sec, 73 packets/sec
1394 packets input, 89409 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1085 packets output, 102851 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
The configuration for this scenario only requires a few commands. The queue-list 5 protocol ip 2 list 120 command causes CQ to match all packets permitted by ACL 120 and to place these packets into Queue 2. CQ uses Queue 1 for unmatched packets, so no other classification commands are required. The byte count for each queue defaults to 1500 bytes; in this case, the criteria specified that CQ should give about 2/3 of the bandwidth to the VoIP traffic, so queue 2 was assigned a byte count of 5000, and Queue 1 a byte count of 2500. At a 64-kbps clock rate, each complete cycle takes a little less than a second. Finally, to enable CQ list 5, the custom- queue interface subcommand was used. IOS uses the same show commands to display information about CQ as it does for PQ. The show queue command lists brief information about packets in the queue at the present time (not shown in the example). The show queueing interface command lists configuration information about CQ and statistical information about how many packets have been placed into each queue. In the example, Queue 2 has had a total of 3549 packets pass through it. Also note that no packets have been placed into Queues 3 through 16, because CQ list 5 does not classify packets into Queues 3 through 16. The show queueing custom command lists information about the configuration of CQ. The output of the show interfaces command states that CQ is in use, along with statistics about each queue. The current number of packets in each queue, the maximum length of each queue, and the cumulative number of tail drops are listed for each of the 16 queues. You may have noticed that Queue 0 shows up in a couple of commands. CQ uses a special queue, Queue 0, which is used for important high-priority packets generated by the router. Routing protocol updates are considered high priority, for instance, so these packets are placed into Queue 0. CQ treats Queue 0 as a priority queuethat is, when packets are waiting in Queue 0, CQ interrupts its normal scheduling logic, takes the packet from Queue 0 next, and then resumes the scheduling process. CQ does not allow packets to be explicitly classified into Queue 0. Stepping back from the configuration for a moment, consider the time required to service 2500 bytes from Queue 1, and then 5000 bytes from Queue 2, at 64 kbps. It requires roughly .875 seconds total, with roughly 310 ms to service Queue 1, and the rest to service Queue 2. So, if Queue 1 has many packets, the voice packet in Queue 2 that is the next packet to get serviced, after Queue 1 gets to send its 2500 bytes, has to wait an extra 310 ms! So, this example, although giving voice 2/3 of the bandwidth, does not actually give voice very good performance. Good QoS design calls for the marking of packets close to the source of the packet. The next example accomplishes the same queuing goals as the preceding example, but CQ relies on the fact that the packets have been marked before reaching R3's S0/0 interface. In a real network, the packets could be marked on one of the LAN switches; for review, however, this example shows the packets being marked upon entering R3's E0/0 interface. Example B-19 shows the revised configuration based on the following criteria:
Example B-19. Custom Queuing: DSCP EF in Queue 1, All Else in Queue 2
ip cef
!
class-map match-all class-default
match any
class-map match-all voip-rtp
match ip rtp 16384 16383
!
!
policy-map voip-and-be
class voip-rtp
set ip dscp 46
class all-else
set ip dscp 0
!
interface Ethernet0/0
service-policy input voip-and-be
!
interface Serial0/0
custom-queue-list 6
clockrate 64000
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (R1)
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
!
! Portions omitted for brevity
!
access-list 121 permit ip any any dscp ef
!
queue-list 6 protocol ip 1 list 121
queue-list 6 queue 1 byte-count 5000
queue-list 6 queue 2 byte-count 2500
queue-list 6 default 2
R3#sh queueing int s 0/0
Interface Serial0/0 queueing strategy: custom
Output queue utilization (queue/count)
0/5 1/1012 2/30 3/0 4/0 5/0 6/0 7/0 8/0
9/0 10/0 11/0 12/0 13/0 14/0 15/0 16/0
R3#show queueing custom
Current custom queue configuration:
List Queue Args
6 2 default
6 1 protocol ip list 121
6 1 byte-count 5000
6 2 byte-count 2500
R3#show int s 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description: connected to FRS port S0. Single PVC to R1.
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 10/255, rxload 8/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 4, LMI stat recvd 4, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 7/0, interface broadcasts 7
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:00:33
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 718
Queueing strategy: custom-list 6
Output queues: (queue #: size/max/drops)
0: 0/20/0 1: 16/20/718 2: 19/20/0 3: 0/20/0 4: 0/20/0
5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0
15: 0/20/0 16: 0/20/0
5 minute input rate 52000 bits/sec, 102 packets/sec
5 minute output rate 61000 bits/sec, 81 packets/sec
3533 packets input, 226737 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
2788 packets output, 260972 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
In Example B-19, queue-list 6 refers to ACL 121, which matches all IP packets with DSCP EF, and places these packets into Queue 1. The default queue is now Queue 2, based on the queue- list 6 default 2 command. The byte counts for the first two queues have been set to 5000 and 2500, respectively. The new CQ configuration is enabled on S0/0 with the custom-queue 6 command. Example B-20 shows CQ with four queues, with classification as follows:
The same network used in the preceding example, as shown in Figure B-15, is used for this example as well. Example B-20. 0CQ Example: VoIP in Queue 1, NetMeeting in Queue 2, HTTP in Queue 3, and All Else in Queue 4access-list 150 permit udp host 192.168.1.100 range 16384 32767 192.168.3.0 0.0.0.255 range 16384 32767 ! access-list 151 permit udp any range 16384 32768 any range 16384 32768 ! access-list 152 permit tcp any eq www any access-list 152 permit tcp any any eq www ! queue-list 8 protocol ip 2 list 150 queue-list 8 protocol ip 1 list 151 queue-list 8 protocol ip 3 list 152 queue-list 8 queue 1 byte-count 2500 queue-list 8 queue 2 byte-count 2500 queue-list 8 queue 3 byte-count 2500 queue-list 8 queue 4 byte-count 2500 queue-list 8 default 4 ! interface serial 0/0 custom-queue 8 Distributed Weighted Fair Queuing (dWFQ)IOS provides three streamlined WFQ options specifically designed for the Cisco 7500 series hardware architecture: distributed WFQ (dWFQ), ToS-based WFQ, and QoS groupbased WFQ. The 7500 architecture includes distributed processing on line cards called Versatile Interface Processors (VIPs). Many functions that the general-purpose processor on the Route Switch Processor (RSP) card would normally perform by can instead be distributed to the processor on the VIPs. Distributing the processing can prove very helpful in typical 7500 series configurations that use a large number of line cards and interfaces, relieving processing burden from the general-purpose RSP processor. You can use WFQ on 7500s without distributing the processing to the VIPs. To do so, just configure WFQ as described in the preceding section. However, Cisco created these other three distributed WFQ options specifically for 7500s, to address some specific needs. In particular, because 7500s tend to have faster WAN interfaces, Cisco created WFQ tools that run more efficiently in a higher-speed environment. One of the key goals of queuing is to reduce delay for the appropriate traffic; these distributed queuing tools are streamlined so that, even on the higher-speed interfaces on the 7500, the queuing process does not artificially delay any packets. The three distributed WFQ options are as follows:
All three tools require distributed CEF (dCEF) processing to be enabled globally, and on the interface on which distributed WFQ is enabled. The following three sections outline the basic similarities and differences among the three distributed WFQ options, respectively. WFQ terminology can be confusing at best. Table B-14 lists some of the fundamental terms and their respective definitions. Note that some terms can have more than one meaning.
Flow-Based dWFQFlow-Based dWFQ classifies packets based on the flow, examining the source and destination IP address and port and the protocol type. All of the other main features of dWFQ differ slightly when compared to WFQ. Table B-15 lists several points for comparison.
The first big difference between WFQ and dWFQ involves the tail-drop policy. dWFQ has to answer two simple questions when it determines whether to drop a packet:
If either of these questions is true (the aggregate packet limit or the individual queue limit has been exceeded), the new packet is discarded. Unlike WFQ, dWFQ cannot enqueue a packet, only to discard it later because its sequence number (SN) is larger than a new packet's SN. dWFQ uses the terms "aggregate limit" and "individual limit" to describe the limit over all queues and the limit per queue, respectively. Unlike WFQ, dWFQ ignores the IP precedence value when calculating the SN of a packet. In other words, dWFQ does not actually weight the packet, totally ignoring the contents of the ToS byte. In effect, all packets are weighted equally, so dWFQ always prefers lower-volume flows in comparison to higher-volume flows. Another difference between the two is that dWFQ does allow for the maximum queue length to be changed, but the number of queues remains constant at 512. Finally, one other difference between WFQ and dWFQ has to do with how dWFQ works internally. dWFQ uses a mechanism called a calendar queue to sort all the packets waiting in a dWFQ queue. WFQ uses a simple sorted linked list. The effect is the sameboth schedulers select the packet with the lowest SN as the next packet to be forwarded to the TX Queue/TX Ring. By using a calendar queue, however, dWFQ actually performs the final scheduling function more efficiently, which is particularly useful on higher-speed interfaces. (Note that the internals of calendar queues is not important for the QoS exam; if you want to read more, however, refer to Inside Cisco IOS Software Architecture.) dWFQ ConfigurationdWFQ configuration, like WFQ, takes little effort. The fair-queue interface subcommand enables flow-based dWFQ on the interface. If you want to change the aggregate or individual queue limits, you use the fair-queue aggregate-limit and fair-queue individual-limit commands, respectively. You can use the same familiar show commands to examine the status of dWFQ. Tables B-16 and B-17 list the configuration commands and exec commands for Flow-Based dWFQ.
Coincidentally, in some cases, a valid configuration for WFQ can be identical to a valid configuration for dWFQ. For instance, the fair-queue subcommand is used to enable both WFQ and dWFQ on an interface. Example B-21 shows a configuration on the familiar R3, which has now been upgraded to a 7500 series router with VIP2-50 line cards: Example B-21. dWFQ Configurationip cef ! interface serial 0/0/1 encapsulation ppp description Serial interface on VIP2-50 fair-queue In the example, CEF has been enabled globally, and the fair-queue command has been added to the serial interface. If the serial interface were not on a VIP at all, WFQ would be performed. With a VIP2-50 installed, dWFQ would be performed. Figure B-16 summarizes the sequencing and main features of dWFQ. Figure B-16. Flow-Based dWFQ: Summary of Main Features
ToS-Based dWFQToS-Based dWFQ uses a totally different classification method and a totally different scheduler as compared with WFQ. After reading this section, you may wonder why Cisco calls this tool WFQ at all, because it does not resemble WFQ in very many ways! ToS-Based WFQ classifies based on the 2 low-order bits in the IP Precedence fieldin other words, the second and third bits of the Precedence field. It places packets into one of four queues based on these values. It does not consider the flow at all; it is a class-based tool, as opposed to a flow-based tool. Classification is based on the 2 low-order bits in the IP Precedence field, as opposed to WFQ's flow-based classification. Although the details are not published, ToS-Based dWFQ does use a fair-queuing scheduler, with the weighting based on the bandwidth percentages configured in each case. If only 2 queues were used, and one queue were given 75 percent of the bandwidth, and the other queue were given 25 percent, for example, internally, IOS calculates weights for the 2 queues with a ratio of 3:1. That's why it's called WFQ, although ToS-Based dWFQ differs significantly from WFQ. Table B-18 lists points for comparison, which are illustrated in Figure B-17.
Figure B-17. ToS-Based dWFQ: Summary of Main Features
The classification function cannot be changed for ToS-Based WFQ. It always places packets into one of four queues, based on the 2 low-order bits in the IP Precedence field. In other words, precedence 0 and 4 go into Queue 0, because decimal 0 converts to 000, and decimal 4 converts to 100so the 2 low-order bits are equal. Likewise, precedence 1 and 5 end up in Queue 1, precedence 2 and 6 in Queue 2, and precedence 3 and 7 in Queue 3. The drop policy is just like dWFQ, using an aggregate limit and individual queue limit method to set the value. The scheduler provides a percentage of bandwidth for each queue. Cisco does not publish the scheduler logic, but it works like WFQ, using SNs. IOS derives the weights for each queue based on the configured bandwidth percentages. Interestingly, the parameter is actually called weight, although it is interpreted as a percentage of bandwidth. The percentages default to 10 percent, 20 percent, 30 percent, and 40 percent, for Queues 0 through 3, respectively. You can configure the percentages for Queues 1 through 3, with the rest being assigned to Queue 0. ToS-Based WFQ ConfigurationThe configuration for ToS-Based dWFQ is simple. Tables B-19 and B-20 list the generic commands, and an example follows these tables.
Configuring the fair-queue tos subcommand on an interface enables ToS-Based dWFQ. For this command to work, distributed CEF (dCEF) must be enabled, and the interface must really be on a VIP2-xx, where xx is 40 or higher. Example B-22 shows a sample configuration, along with changes to the bandwidth percentages given to Queues 1, 2, and 3. In this case, Queue 0 gets 39 percent of the link bandwidth, because 61 percent has been assigned using configuration commands. Example B-22. ToS-Based dWFQ Configurationip cef ! interface serial 0/0/1 encapsulation ppp description Serial interface on VIP2-50 fair-queue tos fair-queue tos 1 weight 30 fair-queue tos 2 weight 30 fair-queue tos 3 weight 1 Distributed QoS GroupBased WFQQoS GroupBased dWFQ behaves almost identically to ToS-Based WFQ. The classification feature of each is similar, but with QoS GroupBased dWFQ, the classification is based on the QoS group value assigned to the packet. The QoS group is a value between 0 and 99, inclusive, which is assigned to the packet as it passes through a single router. QoS GroupBased dWFQ classifies a packet into 1 of 100 queues, numbered 0 through 99, matching the QOS group assigned to the packet. (Queue 0 is the default queue.) The drop policy and scheduler work just like ToS-Based dWFQ as well. The bandwidth percentages can be spread among as many as 100 queues. Table B-21 lists the familiar points for comparison, this time highlighting QoS GroupBased dWFQ, and Figure B-18 depicts the general sequence of events when using QoS GroupBased dWFQ.
Figure B-18. QoS GroupBased dWFQ: Summary of Main Features
QoS GroupBased WFQ ConfigurationThe configuration for QoS GroupBased dWFQ is simple. Tables B-22 and B-23 lists the generic commands.
Configuring the fair-queue qos-group subcommand on an interface enables QoS GroupBased dWFQ. For this command to work, dCEF must be enabled, and the interface must really be on a VIP2-xx, where xx is 40 or higher. Example B-23 shows a sample configuration, along with changes to the bandwidth percentages given to Queues 1, 2, and 3. In this case, queue 0 gets 39 percent of the link bandwidth, because 61 percent has been assigned using configuration commands. Example B-23. QoS GroupBased dWFQ Configurationip cef ! interface serial 0/0/1 encapsulation ppp description Serial interface on VIP2-50 fair-queue qos-group fair-queue qos-group 1 weight 30 fair-queue qos-group 2 weight 30 fair-queue qos-group 3 weight 1 Example B-23 lists the same basic parameters as Example B-13, but with QoS GroupBased dWFQ in this case. Of course, more queues could be used, with different weights (bandwidth percentages) for each queue. Summary: dWFQ OptionsOf the three dWFQ options, useful on the 7500 series routers only, dWFQ (also called Flow- Based dWFQ) is most similar to WFQ. It is flow based, uses a similar (although slightly different) drop policy, and uses the same scheduling logic. However, the other differences are significant: dWFQ does not consider the IP precedence when assigning SNs, and it only allows 512 queues. The other two dWFQ options, ToS-Based dWFQ and QoS GroupBased dWFQ, stand out in their lack of similarity to WFQ. Neither are flow based, the number of queues is predetermined, and the scheduler assigns weights based on bandwidth percentages, which is more like CQ or CBWFQ. Like dWFQ, these two options are available only on 7500 series routers. ToS-Based dWFQ classifies based on the 2 low-order bits in the IP Precedence field, which may require you to rethink your QoS classification and marking strategy. For instance, Cisco recommends that you mark video payload with AF41, and the least-important data with DSCP BE. The video needs high bandwidth, low delay, and low jitter. The unimportant data can get the leftover bandwidth, with no significant delay requirements. With DSCP AF41's binary code being 100010, however, and DSCP BE being 000000, ToS-Based dWFQ would work poorly. (The low-order 2 bits of the IP Precedence field are in bold, and in both cases, the value is binary 00.) Similarly, DSCP EF traffic and DSCP AF11, AF12, and AF13 would all be placed in the same queue with ToS-Based dWFQ. Therefore, you would need to reconsider the QoS policy for marking before using this tool. From an exam-preparation perspective, try to focus on the details of WFQ and the comparisons between the tools that Table B-24 outlines.
Modified Deficit Round-RobinCisco designed Modified Deficit Round-Robin (MDRR) specifically for the Gigabit Switch Router (GSR) models of Internet routers. In fact, MDRR is supported only on the GSR 12000 series routers, and the other queuing tools (WFQ, CBWFQ, PQ, CQ, and so on) are not supported on the GSRs. Many of the features of MDRR will be familiar. Like all queuing tools, it needs to perform classification and make drop decisions, scheduling decisions, and so on. Figure B-19 depicts the major parts of the queuing puzzle of MDRR, followed by some comments about each step. Figure B-19. MDRR: Summary of Main Features
MDRR classifies packets only based on the IP Precedence field. Not surprisingly, MDRR supports eight classes, and therefore eight queues, because there are eight precedence values. The queues are numbered 0 through 7, and the precedence values (decimal) are also 0 through 7but MDRR does map the values one to one. MDRR enables you to configure each precedence value to map to any of the queues, so more than one precedence value could map to the same queue. Like CBWFQ, MDRR supports either tail drop or Weighted Random Early Detection (WRED) for the drop policy, per queue. Like most other tools, inside each queue, first-in, first-out (FIFO) logic is used. In addition, as expected, the most interesting part relates to the logic used by the scheduler, which is where MDRR gets its name. MDRR schedules traffic by making a round-robin pass through the configured queues. (For the time being, assume that the optional PQ [LLQ] feature has not been configured.) MDRR removes packets from a queue, until the quantum value (QV) for that queue has been removed. The QV quantifies a number of bytes, and is used much like the byte count is used by the CQ scheduler. MDRR repeats the process for every queue, in order from 0 through 7, and then repeats this round-robin process. The end result is that each queue gets some percentage bandwidth of the link. The CQ scheduler has a problem with trying closely to provide a particular percentage bandwidth. MDRR overcomes this same problem, but it is useful to recall an example of the problem first. Repeating an earlier example about CQ, suppose a router uses CQ on an interface, with 3 queues, with the byte counts configured to 1500, 1500, and 1500. Now suppose that all the packets in the queues are 1500 bytes. (This is not going to happen in real life, but it is useful for making the point.) CQ takes a 1500-byte packet, notices that it has met the byte count, and moves to the next queue. In effect, CQ takes one packet from each queue, and each queue gets 1/3 of the link bandwidth. Now suppose that Queue 3 has been configured to send 1501 bytes per queue service, and all the packets in all queues are still 1500 bytes long. CQ takes 1 packet from Queue 1, 1 from Queue 2, and then 2 packets from Queue 3! CQ does not fragment the packet. In effect, Queue 3 sends 2 packets for every 1 packet sent from Queues 1 and 2, effectively giving 25 percent of the bandwidth each to Queues 1 and 2, and 50 percent of the link bandwidth to Queue 3. MDRR deals with this problem by treating any "extra" bytes sent during a cycle as a "deficit." Next time around through the queues, the number of "extra" bytes sent by MDRR is subtracted from the QV. In Figure B-20, MDRR is using only two queues, with QVs of 1500 and 3000, respectively, and with all packets at 1000 bytes in length. Figure B-20. MDRR: Making Up Deficits
First, some extra information on how to interpret the figure may help. The figure shows the action during the first round-robin pass in the top half of the figure, and the action during the second pass in the lower half of the figure. The example begins with six packets (labeled P1 through P6) in Queue 1, and six packets (labeled P7 through P12) in Queue 2. Each arrowed line, attached to the right sides of the queues, and pointing to the right, represents the choice by MDRR to send a single packet. When a queue first fills, the queue's deficit counter is set to the QV for that queue, which is 1500 for Queue 1, and 3000 for Queue 2. In the figure, MDRR begins by taking 1 packet from Queue 1, decrementing the DC to 500, and deciding that the DC has not been decremented to 0 (or less). MDRR takes a second packet from Queue 1, decrementing the DC to 500. MDRR then moves on to Queue 2, taking three packets, after which the DC for Queue 2 has decremented to 0. That concludes the first pass through the queues. MDRR has taken 2000 bytes from Queue 1, and 3000 from Queue 2, giving the queues 40 percent and 60 percent of link bandwidth, respectively. In the second round-robin pass, shown in the lower half of the figure, the process begins by MDRR adding the QV for each queue to the DC for each queue. Queue 1's DC becomes 1500 + 500, or 1000, to begin the second pass. During this pass, MDRR takes P3 from Queue 1, decrements DC to 0, and then moves on to Queue 2. After taking three more packets from Queue 3, decrementing Queue 2's DC to 0, MDRR completes the second pass. Over these two round-robin passes, MDRR has taken 3000 bytes from Queue 1, and 6000 from Queue 2which is the same ratio as the ratio between the QVs. With the deficit feature of MDRR, over time each queue receives a guaranteed bandwidth based on the following formula:
Note For additional examples of the operation of the MDRR deficit feature, refer to http://www.cisco.com/warp/public/63/toc_18841.html. Alternatively, you can go to www.cisco.com and search for "Understanding and Configuring MDRR and WRED on the Cisco 12000 Series Internet Router." MDRR also allows one queue to be used as a PQ, but with two variations on how the PQ is scheduled. One scheduling option, called strict scheduling, acts just like PQ's treatment of the High queue, which is also how Low Latency Queuing (LLQ) and IP RTP Priority scheduling works. Whenever the scheduler decides to remove another packet from any queue, it first checks the strict PQ, and takes a packet if one is in the queue. With strict treatment, MDRR does not need to assign a QV to the low-latency queue, because there is no concept of taking a QV of bytes per pass through the queuethe low-latency queue gets strict service whenever it needs it. MDRR offers a less strict algorithm for servicing the low-latency queue called alternate service. With alternate service, the low-latency queue is assigned a QV, just like the other queues. MDRR takes QV bytes from the low-latency queue, and then take bytes from a non-low-latency queue. MDRR then goes back to the low-latency queue, taking QV bytes, and then to another queue. If Queues 0 through 2 are Normal queues, and Queue 7 is the low-latency queue, for instance, MDRR serves the queues in this order: 7, 0, 7, 1, 7, 2, and repeats this sequence. Because the low-latency queue gets serviced on every alternate attempt, it can get a disproportionate amount of bandwidth. However, with alternate service, MDRR does prevent the low- latency queue from taking over the link. Strict and alternate priority affect delay and jitter differently. With alternate priority, packets experience longer delay and more jitter, as compared with strict scheduling. Alternate priority gives the other queues a little more service, however, which improves their performance. Table B-25 summarizes some of the key features of MDRR.
MDRR ConfigurationMDRR configuration requires you to understand GSR architecture to a small degree. MDRR configuration also introduces some new terminology. Table B-26 lists the configuration commands related to MDRR, and following the tables is an explanation of the new terminology, the formula used to calculate the QV per queue, and an explanation of the flow of the configuration commands.
After you understand the basic concepts, you just need to understand a few facts about how the configuration commands work before being able to configure basic MDRR. First, the low- latency queue is always Queue 7, and instead of being referred to as Queue 7, the low-latency queue is referred to with the low-latency keyword. The next thing to note is that the QoS configuration details are configured as subcommands of the cos-queue-group command. In other words, the classification details, choosing QVs by using the weight keyword, and selecting strict or alternate LLQ scheduling, are configured as subcommands of the cos-queue- group command. MDRR configuration does not enable you to specify the QV for each queue, but rather you configure a value called weight. The QV is then calculated from the weight using the following formula:
Here, MTU is the maximum transmission unit configured for the interface. Weight values can be configured between 1 and 2048, but Cisco recommends using low valuesin fact, for the lowest-weight queue, use a value of 1. Finally, like LAN switches, GSR routers benefit from having both input and output queuing. MDRR can be applied to an interface for input packets using the rx-cos command, and for output packets using the tx-cos command. The following criteria is used in the upcoming example configuration:
Example B-24 shows the configuration and show commands. Example B-24. MDRR: VoIP in High Queue, All Else in Normal Queueinterface pos 3/0 Rx-cos my-sample Interface pos 3/1 Tx-cos my-sample ! cos-queue-group my-sample precedence 0 queue 0 precedence 0 random-detect-label 0 precedence 1 queue 0 precedence 1 random-detect-label 0 precedence 2 queue 1 precedence 2 random-detect-label 0 precedence 3 queue 1 precedence 3 random-detect-label 0 precedence 4 queue 1 precedence 4 random-detect-label 0 precedence 5 queue low-latency precedence 6 queue 1 precedence 6 random-detect-label 0 precedence 7 queue 1 precedence 7 random-detect-label 0 ! precedence 0 random-detect-label 0 ! queue 0 1 queue 1 3 queue low-latency strict ! random-detect-label 0 Most of the commands in the sample are configuration subcommands under the cos-queue- group my-sample command. For instance, the precedence 0 queue 0 command maps precedence 0 packets to Queue 0; a similar command maps the appropriate precedence values to queues, as stated in the policy before the example. Similarly, WRED parameters apply per precedence, so the precedence 0 random-detect-label 0 command links precedence 0 packets to a set of WRED parameters with a WRED label of 0. At the end of the example, the random- detect-label 0 command creates a WRED label 0, with no specific parameterseven if you want to take default WRED parameters, you still need to create the label, and refer to it with a command such as precedence 0 random-detect-label 0 to enable WRED for those packets. The weights are configured with the queue command seen toward the end of the configuration. The queue 0 1 command assigns a weight of 1 to Queue 0, and the queue 1 3 command assigns a weight of 3 to Queue 1. The queue low-latency strict command defines that Queue 7, the low-latency queue, should use strict scheduling. Finally, at the top of the configuration, the rx-cos my-sample command enables cos-queue-list my-sample for packets entering interface pos 3/0. Similarly, the tx-cos my-sample interface subcommand enables MDRR for packets exiting pos 3/1. MDRR provides queuing services on GSR 12000 series routers. It assigns a percentage bandwidth through the use of the weight keyword, with the percentages being much more exact than CQ through the deficit feature of the MDRR scheduler. MDRR allows two options for treatment of the low-latency queue, strict and alternate, which gives the engineer more flexibility in how to deal with delay- and jitter-sensitive traffic. The classification feature of MDRR only supports IP precedence, which can be seen as a negative. Because most networks deploy GSRs in the core of the network, however, a good QoS design, with classification and marking at the edge of the network, can work very well with the precedence-based classification of MDRR. Shaping and PolicingThis section covers GTS, DTS, FRTS, and CAR (as a policing tool). Generic Traffic-Shaping ConfigurationGTS performs traffic shaping using the same logic and features discussed in the introductory section of this chapter. It can be enabled on a large variety of interfaces. It can also adapt the rate based on BECN signals, and reflect BECNs on a VC after receiving a FECN. It supports a single queuing tool for the shaping queues: Weighted Fair Queuing (WFQ). It can also classify traffic, performing shaping on a subset of the traffic on an interface by classifying packets based on access control lists (ACLs). The only feature of GTS not already covered to some depth, other than configuration, is the concept of shaping a subset of the traffic on an interface or subinterface. GTS can classify traffic with an ACL; traffic permitted by the ACL is shaped based on the parameters specified on the same command. For instance, you could shape all FTP traffic to 32 kbps, and web traffic to 64 kbps. Other than the material already covered, the only other thing really left to think about with GTS is how to configure it. Tables B-27 and B-28 list the configuration and show commands pertinent to GTS.
The examples in this section use a familiar network diagram, as shown in Figure B-21. The configuration shows R3, with a 128-kbps access rate, and a 64-kbps Frame Relay VC connecting to R1. Traffic from R3 to R1 is Shaped using the following criteria:
Figure B-21. Sample Network Used for GTS Configuration Examples
In each example, the client downloads one web page, which has two frames inside the page. The web page uses two separate TCP connections to download two separate large JPG files that are shown in each of the two frames inside the browser window. The client also downloads a file using FTP. Additionally, a VoIP call is placed between extension 302 and 102. Example B-25 shows the configuration and some sample show commands. Example B-25. CB Shaping on R3, 64-kbps Shape Rate
interface serial0/0
bandwidth 64
load-interval 30
fair-queue
interface serial0/0.1
traffic-shape 64000
R3#show traffic-shape
Interface Se0/0.1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 64000 2000 8000 8000 125 1000 -
R3#show traffic-shape statistics
Access Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Se0/0.1 65 4285 687360 4248 680272 yes
R3#show traffic-shape statistics serial 0/0.1
Access Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Se0/0.1 41 4720 752636 4683 745548 yes
R3#show queue serial 0/0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4227
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/7/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
R3#show traffic-shape queue serial 0/0.1
Traffic queued in shaping queue on Serial0/0.1
Queueing strategy: weighted fair
Queueing Stats: 64/1000/64/768 (size/max total/threshold/drops)
Conversations 3/4/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 64 kilobits/sec
! Next one is a web connection
(depth/weight/total drops/no-buffer drops/interleaves) 61/32384/734/0/0
Conversation 14, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0xAA21, ttl: 127,
TOS: 0 prot: 6, source port 80, destination port 3041
! Next one is VoIP
(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/0/0/0
Conversation 0, linktype: ip, length: 188
source: 192.168.3.254, destination: 192.168.2.251, id: 0x0060, ttl: 254,
TOS: 0 prot: 17, source port 19273, destination port 17641
! Next one is Passive FTP, not requiring port 20 on either side
(depth/weight/total drops/no-buffer drops/interleaves) 2/32384/35/0/0
Conversation 11, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0xAA24, ttl: 127,
TOS: 0 prot: 6, source port 4904, destination port 3043
The configuration itself is rather simple. You can configure GTS on the subinterface, or on the main interface in this case, because only one VC runs out of the interface. Because most installations tend to enable GTS on subinterfaces, the traffic-shape rate 64000 command was added to interface s0/0.1 to enable GTS for a shaping rate of 64 kbps. GTS only allows WFQ on the shaping queues, so no other configuration command is needed to enable WFQ. The fair- queue command on the physical interface enables WFQ just for the interface output queues. Three show commands list information about GTS. First, immediately after the configuration, the show traffic-shape command lists basic configuration information, and the derived values for Bc and Be of 8000 bits each. Bc was derived by IOS using the formula Bc = Tc * CIR, which is just a variation on the Tc = Bc/CIR formula. The Tc value defaults to 125 ms, but interestingly, GTS can use different default Tc values, based on the configuration settings you use. GTS uses WFQ for the shaping queues; the next command in the example, show traffic-shape queue, supplies the same output that the show queue command does for WFQ on an interface. Finally, the show traffic-shape statistics command lists basic statistics about GTS. The last column of output is particularly interesting, because it tells you whether shaping is currently active. IOS does not need to shape all the time, so this column just lists the current state when the command was issued. Shaping activates for three reasons:
Queuing occurs on the physical interface when the traffic load exceeds the interface clock rate, and shaping queues form when the traffic load exceeds the shaping rate. In this case, with a single VC, shaped at 64 kbps, and a 128-kbps clock rate on the physical interface, no queues should form on the physical interface. The offered load on the physical link should not exceed 64 kbps, because that is how much traffic the GTS will allow to pass through the only subinterface in the example. The output of the show queue and show traffic-shape queue commands in the example support these facts. The show queue command lists information about WFQ on the physical interface; it does not list any flows, because no congestion is occurring there. However, the show traffic-shape queue command lists information about WFQ's performance with the shaping queues. In this case, it lists information about a VoIP call, and one FTP download. This particular example reminds us of the importance of the queuing methods supported by the shaping tool. Because GTS only supports WFQ in conjunction with shaping, there is no low- latency option, such as LLQ. The VoIP call in this particular example had a completely unusable quality level. A second GTS configuration example is shown next. For the second configuration, imagine that the Frame Relay provider actually polices the VC from R3 to R1 at 96 kbps. You engineer the network to support a single G.729 VoIP call, which takes about 28 kbps. You decide that you want to be very careful about packet drops, latency, and jitter for this voice traffic, so you decide to shape all traffic except voice. To avoid drops inside the cloud, you shape the rest of the traffic to a rate of 64 kbps (so that the combined single VoIP call, and the shaped rate of 64 kbps, do not exceed the policing rate in the Frame Relay network). The next example shows the configuration, and the criteria for the configuration is as follows:
The traffic generated for this second example is the same type of traffic generated for the firsta single VoIP call, one web page downloaded with two frames inside the page (causing two TCP connections), and an FTP get. Example B-26 shows the configuration and some sample show commands. Example B-26. GTS on R3, 64 kbps for Non-Voice Traffic, Tc = 50 ms
interface serial0/0
bandwidth 64
load-interval 30
fair-queue
interface serial0/0.1
traffic-shape group 101 64000 3200
!
access-list 101 deny udp any range 16384 32767 any range 16384 32767
access-list 101 permit ip any any
R3#show traffic-shape
Interface Se0/0.1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 101 64000 800 3200 3200 50 400 -
R3#show traffic-shape statistics
Access Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Se0/0.1 101 0 94 120156 59 77376 no
R3#show traffic-shape queue
Traffic queued in shaping queue on Serial0/0.1
Traffic shape group: 101
Queueing strategy: weighted fair
Queueing Stats: 3/1000/64/0 (size/max total/threshold/drops)
Conversations 1/2/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 64 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 3/32384/0/0/0
Conversation 11, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0xB077, ttl: 127,
TOS: 0 prot: 6, source port 4904, destination port 3043
R3#show access-lists
Extended IP access list 101
deny udp any range 16384 32767 any range 16384 32767 (18638 matches)
permit ip any any (1257 matches)
The configuration enables GTS by using the traffic-shape group 101 64000 3200 command. This command refers to ACL 101, which permits all traffic except VoIP traffic, implying that shaping occurs for all traffic except VoIP. The shaped rate of 64 kbps implies that the traffic permitted by the ACL will be shaped to 64 kbps. Also note that, according to the traffic-shape command, the Bc value was set to 3200, which should give a Tc of 3200/64,000, or 50 ms. The show traffic-shape command confirms the calculated Tc value, listing it as 50 ms. Also note that the Be value was set to 3200, because GTS defaults Be to be equal to Bc. Note All IOS shapers use bits as the unit when setting Bc and Be; both policers use bytes as the unit. The show access-lists command lists the number of packets permitted and denied by ACL 101. Because ACL 101 is used for matching by GTS, this also tells us how many packets were shaped by GTS, and how many were not. GTS supports several useful traffic-shaping features. It can be used on many types of interfaces, and it can shape a subset of the traffic by referencing ACLs. It can also adapt to BECNs, and reflect FECNs. However, GTS does have several drawbacks. It only supports WFQ in the shaping queues, and it cannot support FRF.12 fragmentation on Frame Relay subinterfaces. Table B-29 summaries the key points for comparison between the various traffic-shaping tools, and lists whether GTS supports each.
Distributed Traffic Shaping (DTS) ConfigurationDTS shapes traffic identically to CB shaping, but with processing distributed to VIPs in a 7500 series router. In fact, DTS and CB shaping configurations are very similar, but with a few extra requirements. Distributed CEF must be configured for the interfaces on which DTS should operate. DTS also has a few idiosyncrasies that are not mentioned in either of the QoS courses, so they are unlikely to be on the exam. Note If you want to read further about DTS, look for the "Cisco AVVID Enterprise Quality of Service Infrastructure Quality of Service Design" document at www.cisco.com/warp/customer/771/srnd/qos_srnd.pdf. On pages 4 through 18 of that document, the text outlines some of the unique requirements for DTS that are beyond the scope of the QoS exams, but important in real networks. This document is a very good reference for QoS design recommendations across all QoS functions and Cisco product lines. To configure DTS, just complete these listed tasks:
Table B-30 lists the comparison features for the shaping tools, with DTS highlighted.
Frame Relay Traffic Shaping (FRTS) ConfigurationFrame Relay traffic shaping (FRTS) differs from the other three shaping tools in several significant ways. The most obvious difference is the most importantFRTS applies to Frame Relay only. But the basic shaping function is the same, with the same parametersa shaped rate, which is often set to CIR; a Tc interval, which defaults to 125 ms; and the Bc value is either set, or calculated based on the Tc = Bc/CIR formula. The first big difference between FRTS and the other shapers has to do with queuing tool support. FRTS does not allow any IOS queuing tool to be used on the physical interface when FRTS is configured for VCs on the interface. Even if a queuing tool has already been configured, IOS removes the configuration from the physical interface when FRTS is enabled. FRTS does supply the largest list of options for queuing tools for the shaping queue: FIFO, PQ, CQ, CBWFQ, LLQ, and WFQ are all available. For you exam takers, be aware that at the time this book went to press the Cisco QoS course book incorrectly claims that FRTS supports WFQ on the physical interface; the DQOS course book does not say anything about queuing on the physical interface with FRTS. The next important difference is that FRTS supports concurrent Frame Relay fragmentation (FRF) using Frame Relay Forum Implementation Agreement 12, also known as FRF.12. With FRF.12, large packets are fragmented, with "large" being defined with configuration commands. Small packets are interleaved, so that a small packet does not have to wait on the long serialization delay associated with the longer original packets. Interestingly, to perform the interleaving feature, FRF uses two queues on the physical interface, with one of the queues holding small, unfragmented packets, and the other holding the fragments of large packets. The queue holding the unfragmented packets is treated like a low-latency queue, always being serviced first. Therefore, although FRTS does not allow any queuing tools on the physical interface, FRF.12 supplies the added benefit of at least a two-queue system, called dual-FIFO, to the physical interface. FRTS, unlike the other shaping tools, cannot shape a subset of the traffic on an interface. Each of the other three shapers can be configured on one subinterface, and not the other, essentially enabling shaping on only some of the traffic leaving an interface. The other three shapers can also configure classification parameters, and shape only part of the traffic on a subinterface. Unlike the other shapers, when FRTS is enabled on the physical interface, all traffic on the interface is shaped in some way. In fact, with FRTS enabled, each VC is shaped separately. However, you cannot enable FRTS for only a subset of the VCs on an interface, nor for a subset of the traffic exiting a single VC. FRTS shapes all VCs on an interface after it has been enabled on that interface. To enable FRTS, add the frame-relay traffic-shape command under the physical interface. If you add no other configuration commands, FRTS uses default settings and shapes each individual VC. If you include additional configuration per VC, FRTS uses those parameters rather than the defaults. In any case, FRTS always shapes each VC separately after it has been enabled on the physical interface. Unlike the other three shapers, FRTS can dynamically learn the CIR, Bc, and Be values configured per VC at the Frame Relay switch and use those settings for shaping. Cisco's WAN switching products (from the Stratacom acquisition in the mid-1990s) use an Enhanced LMI (ELMI) feature, which IOS understands. Using ELMI, the switch just announces the CIR, Bc, and Be for each VC to the router. So, if you want to use FRTS only to shape to CIR, and the Frame Relay network uses Cisco switches, you can just enable FRTS and ELMI on the interface, and the rest (Bc, CIR, and so on) will be learned dynamically for each VC. Finally, the biggest difference relates to FRTS configuration. The commands used differ totally from the other three tools. Tables B-31 and B-32 list the configuration and show commands pertinent to FRTS, respectively.
For the sake of comparison, the first FRTS example follows the same requirements as the first GTS and CB shaping examples. The configuration shows R3, with a 128-kbps access rate, and a 64-kbps Frame Relay VC connecting to R1. The criteria for the configuration is as follows:
In each example, the client downloads one web page, which has two frames inside the page. The web page uses two separate TCP connections to download two separate large JPG files. The PC also downloads a file using FTP get. In addition, a VoIP call is placed between extension 302 and 102. Example B-27 shows the configuration and some sample show commands. Example B-27. FRTS Configuration, 64 kbps, with Mostly Defaults
!
! Portions of Configuration omitted for Brevity
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
no fair-queue
clockrate 128000
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (
R1)
ip address 192.168.2.253 255.255.255.0
frame-relay class shape-all-64
frame-relay interface-dlci 101
!
map-class frame-relay shape-all-64
frame-relay traffic-rate 64000 64000
R3#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 135486 output pkts 129093 in bytes 8648302
out bytes 17252015 dropped pkts 5102 in pkts dropped 0
out pkts dropped 7876 out bytes dropped 1227684
late-dropped out pkts 7876 late-dropped out bytes 1227684
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 1441 out bcast bytes 117294
pvc create time 01:45:46, last time pvc status changed 01:30:01
R3#show frame-relay pvc 101
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 135152 output pkts 128787 in bytes 8626938
out bytes 17210463 dropped pkts 5060 in pkts dropped 0
out pkts dropped 7834 out bytes dropped 1212912
late-dropped out pkts 7834 late-dropped out bytes 1212912
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 1440 out bcast bytes 117230
pvc create time 01:45:40, last time pvc status changed 01:29:54
cir 64000 bc 64000 be 0 byte limit 1000 interval 125
mincir 32000 byte increment 1000 Adaptive Shaping none
pkts 96272 bytes 11677007 pkts delayed 58459 bytes delayed 9188174
shaping active
traffic shaping drops 2774
Queueing strategy: fifo
Output queue 3/40, 678 drop, 3777 dequeued
R3#show traffic-shape
Interface Se0/0.1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
101 64000 1000 64000 0 125 1000 -
R3#show traffic-shape statistics
Access Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Se0/0.1 39 97123 11816731 59238 9317918 yes
R3#show traffic-shape statistics serial 0/0.1
Access Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Se0/0.1 6 97584 11884637 59643 9379560 yes
R3#show traffic-shape queue
Traffic queued in shaping queue on Serial0/0.1 dlci 101
Queueing strategy: fcfs
Queueing Stats: 23/40/959 (size/max total/drops)
Packet 1, linktype: ip, length: 64, flags: 0x10000088
source: 192.168.3.254, destination: 192.168.2.251, id: 0x0384, ttl: 253,
TOS: 0 prot: 17, source port 16704, destination port 19472
data: 0x4140 0x4C10 0x0028 0x0000 0x8012 0x16FD 0x4D91
0x0E64 0x22FC 0x03FE 0x1E90 0xC796 0x387A 0x5193
Packet 2, linktype: ip, length: 64, flags: 0x10000088
source: 192.168.3.254, destination: 192.168.2.251, id: 0x0384, ttl: 253,
TOS: 0 prot: 17, source port 16704, destination port 19472
data: 0x4140 0x4C10 0x0028 0x0000 0x8012 0x16FE 0x4D91
0x0F04 0x22FC 0x03FE 0x144B 0x2EE8 0xC8C2 0x1483
Packet 3, linktype: ip, length: 64, flags: 0x10000088
source: 192.168.3.254, destination: 192.168.2.251, id: 0x0384, ttl: 253,
TOS: 0 prot: 17, source port 16704, destination port 19472
data: 0x4140 0x4C10 0x0028 0x0000 0x8012 0x16FF 0x4D91
0x0FA4 0x22FC 0x03FE 0xDCEA 0xB529 0x916A 0x5254
!
! Many lines omitted for brevity
!
FRTS configuration typically involves three separate steps, although only the first step is actually required.
All three steps were used in Example B-27. The frame-relay traffic-shape interface subcommand, under serial 0/0, enables FRTS. Next, the frame-relay class shape-all-64 subinterface subcommand tells the router to use the shaping parameters in the map-class called shape-all-64. Finally, the map-class frame-relay shape-all-64 command creates a map class, with the frame-relay traffic-rate 64000 64000 command specifying the shaping rate of 64,000 bps. From the first 64000 parameter, FRTS calculates the Bc and Tc values. The second 64000 in the command sets the excess information rate (EIR), from which the Be is calculated; to have a burst greater than zero, the excess rate must be larger than the shaping rate. The show frame-relay pvc command, which follows the configuration in the example, lists statistics about each Frame Relay permanent virtual circuit (PVC). However, the show frame- relay pvc 101 command, with a specific VC listed, gives some basic information about FRTS operation on the VC. In this case, the output shows that shaping is active, which means that FRTS was actively shaping packets when this command was issued. (As with other shapers, FRTS shaping is active when packets are in the shaping queues, or as soon as a packet exceeds the traffic contract so that it should be placed in the queues.) The command also lists that the default queuing type of FIFO is used, along with some statistics about the number of packets tail dropped from the shaping queue. The same show traffic-shape commands used with GTS also provide useful information for FRTS. The show traffic-shape command output shown in Example B-27 lists the basic shaping settings. Remember, the frame-relay traffic-rate 64000 64000 command did not explicitly set Bc, Be, or Tc, but Bc and Be are shown in the show traffic-shape command output. The logic to derive the values works like this, with CIR representing the configured shaping rate:
In this example, the shaping parameters are set as follows:
For each Tc of 125 ms, FRTS allows 8000 bits, so the overall rate becomes 64,000 bps. Those of you who are thoroughly reading the command output may have noticed that the show traffic-shape command actually lists Bc as 64,000, not the 8000 bits suggested previously. Interestingly, when using the frame-relay traffic-rate command, the show traffic-shape "Sustained Bits/interval" heading lists the bits per second. Internally, a 125-ms Tc value is really used, and a Bc of 8000 is really usedbut the output of the command lists the number of bits that can be sent in a full second. The value of 1000 bytes under the heading "Increment (Bytes)" accurately lists the real Bc value used. (I did not believe it either; check out http:\\www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_r/frcmds/wrffr3.htm#xtocid24, and look for the frame-relay traffic-rate command, for some confirming comments.) The show traffic-shape statistics and the show traffic-shape queue commands list the same basic information for FRTS as they did for GTS. One piece of terminology not seen with GTS, however, is that the default queuing type of FRTS shaping tools is called "FCFS" in the show command output. FCFS stands for first-come, first-served, which is just another term for FIFO. You can configure basic FRTS shaping parameters in two ways. The first example, Example B-27, used the traffic-shape rate command. Alternatively, you can use the frame-relay cir, frame- relay Bc, and frame-relay Be commands to set FRTS shaping parameters inside an FRTS map class. In fact, if you want to manipulate Tc down to a smaller value, which you typically should do to support voice and video traffic, you must use these alternative commands. Remember, Tc = Bc/shaped rate, or Tc = Bc/CIR if you are shaping at the CIR. Example B-28 lists two examples that use these additional FRTS commands, with show commands listing the changed Tc and Bc values. The commands are applied to R3, the same router as in Example B-27. Example B-28. FRTS Configuration by Setting CIR, Bc to Manipulate Tc
R3#show running-config
!
! Portions of Configuration omitted for Brevity
!
map-class frame-relay shape-all-64-long
frame-relay cir 64000
frame-relay bc 8000
! Portions of the configuration omitted for brevity
!
R3#
R3(config)#interface serial 0/0.1
R3(config-subif)#frame class shape-all-64-long
R3(config-subif)#^Z
R3#show traffic-shape
Interface Se0/0.1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
101 64000 1000 8000 0 125 1000 -
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
!
R3(config)#map-class frame-relay shape-all-64-shortTC
R3(config-map-class)#frame-relay cir 64000
R3(config-map-class)#frame-relay bc 640
R3(config-map-class)#int s 0/0.1
R3(config-subif)#frame-relay class shape-all-64-shortTC
R3(config-subif)#^Z
R3#show traffic-shape
Interface Se0/0.1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
101 64000 80 640 0 10 80 -
Example B-28 lists two configurations, with show command output listed after each configuration. In each case, the configuration commands enable you to explicitly set CIR, Bc, and Be, with Tc being calculated with the familiar Tc = Bc/CIR. In map-class frame-relay shape-all- 64-long, CIR and Bc are set to the same values as in the first FRTS configuration shown in Example B-27. After the configuration section at the beginning of Example B-28, this map class is enabled on interface S0/0.1; the show traffic-shape command now accurately lists the Bc value of 8000, and the shaping rate (as set by the frame-relay cir command) of 64,000 bps. The second configuration in Example B-28 uses the map-class frame-relay shape-all-64- shortTC command to set Bc to 1/100 of the CIR value, which yields a Tc = 640/64,000, or 10 ms. This map class shows how you would set values to lower Tc, which is particularly useful to reduce the delay waiting for the next Tc if you have multiservice traffic. The example shows the configuration being changed to use map-class shape-all-64-shortTC by adding the frame- relay class shape-all-64-shortTC command. The show traffic-shape command follows, listing a Tc value of 10 ms. In Example B-29, the lab network has a new remote site added, with a PC named Kris, and a router (R2) with a 64-kbps CIR VC to R3. Suppose that the Frame Relay provider actually polices each VC at 96 kbps. The criteria for the configuration is summarized as follows:
In this case, traffic to site R1 consists of a single VoIP call, and one web connection with two frames inside the page. At site R2, PC Kris FTP transfers a large file from the FTP server near R3. Figure B-22 shows the network, and Example B-29 shows the configuration and some sample show command output. Figure B-22. Example Network with VCs from R3 to Two Remote Sites
Example B-29. R3 FRTS Configuration on Two Different VCs, with Identical Settings
!
! Many lines omitted for brevity
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
load-interval 30
no fair-queue
clockrate 128000
frame-relay class shape-all-96
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (
R1)
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
!
interface Serial0/0.2 point-to-point
description point-to-point subint connected to DLCI 102 (R2)
ip address 192.168.23.253 255.255.255.0
frame-relay interface-dlci 102
!
map-class frame-relay shape-all-96
frame-relay traffic-rate 96000 112000
no frame-relay adaptive-shaping
!
! Lines omitted for brevity
!
R3#show frame pvc 101
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 251070 output pkts 239522 in bytes 16004601
out bytes 34597106 dropped pkts 15567 in pkts dropped 0
out pkts dropped 15567 out bytes dropped 3005588
late-dropped out pkts 15567 late-dropped out bytes 3005588
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 1951 out bcast bytes 158000
pvc create time 02:22:11, last time pvc status changed 02:06:26
cir 96000 bc 96000 be 16000 byte limit 3500 interval 125
mincir 48000 byte increment 1500 Adaptive Shaping none
pkts 33292 bytes 4753889 pkts delayed 19315 bytes delayed 3460327
shaping inactive
traffic shaping drops 0
Queueing strategy: fifo
Output queue 0/40, 747 drop, 18449 dequeued
R3#show frame pvc 102
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.2
input pkts 4063 output pkts 3820 in bytes 250312
out bytes 3863342 dropped pkts 1206 in pkts dropped 1206
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 587 out bcast bytes 50380
pvc create time 02:22:13, last time pvc status changed 02:05:29
cir 96000 bc 96000 be 16000 byte limit 3500 interval 125
mincir 48000 byte increment 1500 Adaptive Shaping none
pkts 2916 bytes 3802088 pkts delayed 1120 bytes delayed 1468724
shaping active
traffic shaping drops 0
Queueing strategy: fifo
Output queue 0/40, 0 drop, 1120 dequeued
R3#show traffic-shape
Interface Se0/0.1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
101 96000 3500 96000 16000 125 1500 -
Interface Se0/0.2
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
102 96000 3500 96000 16000 125 1500 -
R3#show traffic-shape statistics
Access Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Se0/0.1 18 34730 4920740 19737 3510580 yes
Se0/0.2 0 3103 4065016 1191 1563968 yes
The FRTS configuration in this example sets FRTS parameters in a map class, which is then enabled on a physical interface. FRTS always performs shaping on each VC separately; therefore, in this case, the shaping parameters per VC will be picked up from the map class that has been enabled on the physical interface. Notice that a new map class, map-class shape-all-96, is configured with a frame-relay traffic-rate 96000 112000 command to set the CIR and EIR values. The frame-relay class shape-all-96 command has been added to the physical interface, and not to the individual subinterfaces. FRTS includes a feature that I call the inheritance feature, which just means that if a subinterface does not have a frame-relay class command, it uses the frame-relay class configured on the physical interface. Similarly, on multipoint subinterfaces, if a map class has not been configured on a particular DLCI, it inherits the FRTS parameters from the map class configured on the subinterface. The first two show commands after the configuration ( show frame pvc 101 and show frame pvc 102) list both shaping parameters and operational statistics. The parameters are the same, because each subinterface picked up its parameters from the map class (shape-all-96) that was enabled on the physical interface. However, the operational statistics differ, because FRTS shapes each VC separately. The show traffic-shape commands that follow confirm the same settings are used on each of the two subinterfaces as well. And in case you still think that FRTS may be shaping all the subinterfaces together, the show traffic-shape statistics command lists the varying statistics for shaping on each VC at the end of the example. FRTS uses a default setting of CIR = 56 kbps, and Tc = 125 ms, if the frame-relay class command does not appear on the interface. In other words, if you enable FRTS on the physical interface with the frame-relay traffic-shape command, but do not enable a map class, FRTS still shapes each VC individuallybut it does so with default parameters. So, be carefulpick a good set of default settings, put them in a map class, and enable it on the physical interface as in Example B-29, just to be safe. In Example B-29, the G.729 voice call between R1 and R3 suffered, mainly due to the fact that shaping increases delay, and no effort was made to service the voice traffic more quickly. Suppose that the network engineer notices that IOS supports LLQ as an option for queuing in the shaping queues for FRTS. Therefore, he wants to solve the problem of poor voice quality by putting the voice call into a low-latency queue. With a shaping rate of 96 kbps, and with a single G.729 call, the voice call quality should improve. The criteria for the configuration is summarized as follows:
In this case, traffic to site R1 consists of a single VoIP call, and one web connection with two frames inside the page. At site R2, PC Kris FTP transfers a large file from the FTP server near R3. Example B-30 shows the configuration and some sample show commands. Example B-30. FRTS to Two Sites, with LLQ Used in the Shaping Queue to Site 1
R3#show running-config
!
! Many lines omitted for brevity
!
class-map match-all voip-rtp
match ip rtp 16384 16383
!
policy-map voip-and-allelse
class voip-rtp
priority 30
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
load-interval 30
no fair-queue
clockrate 128000
frame-relay class shape-all-96
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (
R1)
ip address 192.168.2.253 255.255.255.0
frame-relay class shape-with-LLQ
frame-relay interface-dlci 101
!
interface Serial0/0.2 point-to-point
description point-to-point subint connected to DLCI 102 (R2)
ip address 192.168.23.253 255.255.255.0
frame-relay interface-dlci 102
!
! Note No frame-relay class command on previous VC!
!
!
map-class frame-relay shape-all-96
frame-relay cir 96000
frame-relay bc 960
frame-relay be 0
!
map-class frame-relay shape-with-LLQ
frame-relay cir 96000
frame-relay bc 960
frame-relay be 0
service-policy output voip-and-allelse
!
R3#show frame-relay pvc 101
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 18487 output pkts 17749 in bytes 1184282
out bytes 2639555 dropped pkts 863 in pkts dropped 0
out pkts dropped 863 out bytes dropped 115649
late-dropped out pkts 863 late-dropped out bytes 115649
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 364 out bcast bytes 30272
pvc create time 00:26:08, last time pvc status changed 00:24:49
cir 96000 bc 96000 be 16000 byte limit 3500 interval 125
mincir 48000 byte increment 1500 Adaptive Shaping none
pkts 17718 bytes 2621259 pkts delayed 15671 bytes delayed 2238337
shaping active
traffic shaping drops 0
service policy voip-and-allelse
Serial0/0.1: DLCI 101 -
Service-policy output: voip-and-allelse
Class-map: voip-rtp (match-all)
5101 packets, 326464 bytes
30 second offered rate 25000 bps, drop rate 0 bps
Match: ip rtp 16384 16383
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 24
Bandwidth 30 (kbps) Burst 750 (Bytes)
(pkts matched/bytes matched) 4468/285952
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
386 packets, 412201 bytes
30 second offered rate 31000 bps, drop rate 0 bps
Match: any
Output queue size 42/max total 600/drops 0
R3#show traffic-shape queue serial 0/0.1
Traffic queued in shaping queue on Serial0/0.1 dlci 101
Queueing strategy: weighted fair
Queueing Stats: 15/600/64/0 (size/max total/threshold/drops)
Conversations 4/8/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 18 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 5/0/0/0/0
Conversation 24, linktype: ip, length: 64
source: 192.168.3.254, destination: 192.168.2.251, id: 0x012F, ttl: 253,
TOS: 0 prot: 17, source port 19018, destination port 17766
(depth/weight/total drops/no-buffer drops/interleaves) 3/32384/0/0/0
Conversation 2, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0x177B, ttl: 127,
TOS: 0 prot: 6, source port 80, destination port 1148
(depth/weight/total drops/no-buffer drops/interleaves) 2/32384/0/0/0
Conversation 1, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0x1775, ttl: 127,
TOS: 0 prot: 6, source port 80, destination port 1147
(depth/weight/total drops/no-buffer drops/interleaves) 5/32384/0/0/0
Conversation 12, linktype: ip, length: 1244
source: 192.168.3.100, destination: 192.168.1.100, id: 0x1758, ttl: 127,
TOS: 0 prot: 6, source port 1176, destination port 1146
R3#sh traffic-shape queue s 0/0.2
Traffic queued in shaping queue on Serial0/0.2 dlci 102
Queueing strategy: fcfs
Example B-30 begins with the new FRTS and LLQ configuration. The policy-map voip-and-allelse command defines a policy map that puts all even RTP ports into a low-latency queue, with 32 kbps maximum, and all other traffic into the class-default class. LLQ is enabled inside a new FRTS map-class shape-with-LLQ command, with the service-policy output voip-and- allelse command enabling LLQ inside the map class. Any VC that uses the shape-with-LLQ map class will use the settings in that map class, including the LLQ configuration. In this case, the single VC on subinterface s 0/0.1 uses LLQ for the shaping queue because of the frame- relay class shape-with-LLQ command. The VC on subinterface S0/0.2 does not use map-class voip-and-allelse. Because no frame- relay class command is configured on subinterface 0/0.2, FRTS uses the shaping parameters from map-class shape-all-64, because it is configured on physical interface s 0/0. Immediately following the configuration, the show frame-relay pvc 101 command lists a large amount of new information. Essentially, IOS lists the same kinds of information normally seen with the show policy-map interface command in the show frame-relay pvc 101 command. Information about the MQC classes defined, and statistics about the packets in each class, is listed. Also note that the show traffic-shape queue s 0/0.2 at the end of the example reminds us that FCFS is used on the other subinterface. If you take a step back from the configuration and show commands for a moment, it may be obvious that the two VCs, shaped at 96 kbps each, oversubscribe R3's access link, which is clocked at 128 kbps. Because FRTS only supports FIFO Queuing on the physical interface, congestion still occurs there. Although adding LLQ to subinterface S0/0.1 helped the quality of the voice call, call quality still suffered due to drops and jitter caused by the oversubscribed FIFO output queue on the physical interface s 0/0. The final solution to the voice quality problem in this case is to take advantage of the queuing feature introduced by FRF.12 fragmentation. Frame Relay fragmentation (FRF) can be used with FRTS. FRF actually creates a set of two queues on the physical interface, called dual-FIFO queues. Packets that are larger than the fragmentation size are fragmented and placed into one queue. Packets that are equal to, or smaller than, the fragmentation size are not fragmented, and placed into the other queue. IOS treats the nonfragmented frame queue as a priority queuein other words, it is always serviced first. Therefore, if you want to give great service to small packets such as VoIP, FRF can provide the traditional benefits of fragmentation, and provide a priority queue for all small packets, including VoIP. Figure B-23 outlines the basic idea, with FRTS on two subinterfaces. Figure B-23. Interaction Between Shaping Queues, and Frame Relay Fragmentation Queues
Using FRF to create a two-queue PQ system works well with voice traffic, because the packets are generally small. However, video traffic includes too many larger packets to benefit substantially from FRF's queuing feature, because the larger packets are fragmented and placed in the lower-priority queue. Chapter 8, "Link Efficiency Tools," shows the configuration for adding FRF to this network. Other FRTS configuration items that might be on the exam include how to configure adaptive shaping, and how to enable FRTS parameters on a VC on a multipoint subinterface. Example B-31 lists a simple map class configuration that enables adaptive shaping, with the configuration added to DLCI 101, but not DLCI 102, on multipoint subinterface S0/0.33. Example B-31. FRTS Adaptive Shaping and per-DLCI ConfigurationR3#show running-config ! ! Many lines omitted for brevity ! interface Serial0/0 description connected to FRS port S0. Single PVC to R1. no ip address encapsulation frame-relay load-interval 30 no fair-queue clockrate 128000 frame-relay class shape-all-96 frame-relay traffic-shaping ! interface Serial0/0.33 multipoint description multipoint subint, w/ DLCIs 101 and 102 ip address 192.168.2.253 255.255.255.0 frame-relay interface-dlci 101 class my-adapt-shape-class frame-relay interface-dlci 102 ! map-class frame-relay shape-all-96 frame-relay traffic-rate 96000 112000 ! map-class frame-relay my-adapt-shape-class frame-relay traffic-rate 96000 112000 frame-relay adaptive-shaping becn frame-relay mincir 64000 The map-class frame-relay my-adapt-shape-class command creates a new map class with adaptive FRTS enabled. With adaptive shaping, FRTS uses the shape rate as the maximum rate, and the rate configured on the frame-relay mincir command as the minimum rate. The new map-class my-adapt-shape-class command enables adaptive shaping with the frame-relay adaptive-shaping becn command, and sets the mincir with the frame-relay mincir 64000 command. The map class is enabled on DLCI 101, but not DLCI 102, on subinterface s0/0.33. The example also shows how to enable a map class for a single DLCI. To enable an FRTS map class per DLCI, first enter subinterface configuration mode, and then issue the frame-relay interface-dlci command. This command places you into DLCI configuration mode, where the class my-adapt-shape-class command enables map class my-adapt-shape-class just for this DLCI. Note that after the frame-relay interface-dlci 102 command, there is no class command. So, on DLCI 102, the FRTS parameters in class shape-all-96, as configured on the physical interface, are used. Table B-33 summarizes the key points for comparison between the various traffic-shaping tools, highlighting FRTS.
Committed Access Rate (CAR) ConfigurationCAR has more similarities than differences when compared to CB policing. Both perform policing on all traffic on either an interface or subinterface. Both can classify traffic to police a subset of traffic as well. Both use the same units when configuring policing parametersbits per second for the policing rate, bytes for the normal and Be values, with the configured Be value actually representing Bc + Be. CAR differs from CB policing regarding four main features. The most obvious is that CAR uses the rate-limit command, which is not part of the MQC set of commands. CAR also uses only two categories for actionsconform and exceedas opposed to the three categories (conform, exceed, and violate) supported by CB policing. The most significant difference is that CAR has a feature called cascaded or nested rate-limit commands. Finally, CAR does not use MQC for configuration. Each of these differing features are covered in the example configurations. Most QoS tools that classify packets operate with logic similar to ACLs in that, when a packet is matched, the action(s) related to that matched statement are taken. With all MQC features, such as CB marking, CBWFQ, CB policing, and CB shaping, after a particular class has been matched, the action associated with that class inside the policy map is performed. For instance, all MQC policy maps end with the class-default class, which matches all packets; however, packets may have matched an earlier class, so that a packet would never fall through to the class-default class. With CAR, a single packet can match multiple statements. By doing so, you can actually police progressively more specific subsets of the traffic on the interface or subinterface. For example, you can create logic such as the following:
In other words, you can police a larger group of traffic, but also prevent one particular subset of that group from taking over all the available bandwidth. For example, CAR can be configured so thatweb traffic can only take 400 kbps of the traffic, but the overall rate can be 500 kbps. This section ends with a configuration example that polices a larger set of traffic, and subsets of the larger set. Table B-34 lists the configuration commands used with CAR, and Table B-35 lists the options for the actions to be taken when CAR decides a packet either conforms to or exceeds the traffic contract. Table B-36 lists the CAR show commands.
Like CB policing, you can use CAR to police all traffic entering or exiting an interface. In Example B-32, router ISP-edge polices ingress traffic from an enterprise network. The criteria for the first CB policing example is as follows:
Figure B-24 shows the network in which the configuration is applied, and Example B-32 shows the configuration. Figure B-24. Example network for Policing Examples
Example B-32. CB Policing at 96 kbps at ISP-edge Router
ISP-edge#show running-config
!
!Lines omitted for brevity
!
interface Serial1/0
description connected to FRS port S1. Single PVC to R3.
no ip address
encapsulation frame-relay
load-interval 30
no fair-queue
clockrate 1300000
!
interface Serial1/0.1 point-to-point
description point-point subint global DLCI 101, connected via PVC to DLCI 103 (R3)
ip address 192.168.2.251 255.255.255.0
! note: the rate-limit command wraps around to a second line.
rate-limit input 96000 12000 18000 conform-action set-prec-transmit 0
exceed-action drop
frame-relay interface-dlci 103
!
!Lines omitted for brevity
!
ISP-edge#show interfaces s 1/0.1 rate-limit
Serial1/0.1 point-point subint global DLCI 101, connected via PVC to DLCI 103 (R3)
Input
matches: all traffic
params: 96000 bps, 12000 limit, 18000 extended limit
conformed 2290 packets, 430018 bytes; action: set-prec-transmit 0
exceeded 230 packets, 67681 bytes; action: drop
last packet: 0ms ago, current burst: 13428 bytes
last cleared 00:02:16 ago, conformed 25000 bps, exceeded 3000 bps
ISP-edge#
The configuration requires a single rate-limit command under serial 1/0.1 on router ISP-edge. All the parameters are typed in the single command line: rate-limit input 96000 12000 18000 conform-action set-prec-transmit 0 exceed-action drop. The rate of 96 kbps is listed with a Bc of 12,000 bytes, and a Be of 6000 bytes. (Remember, the burst-excess parameter of 18,000 is actually Bc + Be.) The show interfaces s1/0.1 rate-limit command lists the operational statistics, including numbers of bytes and packets that conformed and exceeded the contract. Interestingly, the two measured rates (conform and exceed) over time do not total more than the policing rate; it appears that the preemptive discarding of packets with the debt process during Be processing is having some good effect. In this particular network, only three concurrent TCP connections were used to create traffic, so just a few packets lost would reduce the TCP windows, and reduce traffic quickly. Example B-33 exhibits how to classify traffic with CAR using rate-limit ACLs, and how to use CAR with cascaded rate-limit commands. To classify traffic, CAR requires the use of either a normal ACL, or a rate-limit ACL. A rate-limit ACL can match MPLS Experimental bits, IP precedence, or MAC address. For CAR to match other IP header fields, you must use an IP ACL. In Example B-33, the CAR configuration meets the requirements of the example for cascaded statements mentioned in the introduction to this section, repeated in the following list.
Example B-33 shows the configuration. Example B-33. Cascaded CAR rate-limit Commands, with Subclassifications! ! Next ACL matches all web traffic ! Access-list 101 permit tcp any eq www any Access-list 101 permit tcp any any eq www ! ! Next ACL matches all FTP traffic ! access-list 102 permit tcp any eq ftp any access-list 102 permit tcp any any eq ftp access-list 102 permit tcp any eq ftp-data any access-list 102 permit tcp any any eq ftp-data ! ! Next ACL matches all VoIP traffic ! access-list 103 permit udp any range 16384 32767 any range 16384 32767 ! interface s 0/0 rate-limit input 496000 62000 62000 conform-action continue exceed-action drop rate-limit input access-group 101 400000 50000 50000 conform-action transmit exceed- action drop rate-limit input access-group 102 160000 20000 20000 conform-action transmit exceed- action drop rate-limit input access-group 103 200000 25000 25000 conform-action transmit exceed- action drop The CAR configuration needs to refer to IP ACLs to classify the traffic, using three different IP ACLs in this case. ACL 101 matches all web traffic, ACL 102 matches all FTP traffic, and ACL 103 matches all VoIP traffic. Under subinterface S1/0.1, four rate-limit commands are used. The first sets the rate for all traffic, dropping traffic that exceeds 496 kbps. However, the conform action is listed as "continue". This means that packets conforming to this statement are now compared to the next rate-limit statements, and when matching a statement, some other action is taken. For instance, web traffic matches the second rate-limit command, with a resulting action of either transmit or drop. VoIP traffic is actually compared with the next three rate-limit commands before matching the last rate-limit command. The following list characterizes the types of traffic, and which rate-limit commands they match, in the example.
You also may have noticed that the policing rates used in this example did not exactly match the values in the original problem statement at the beginning of this section. For instance, originally the requirement stated 500 kbps for all traffic; the configuration uses 496 kbps. CAR requires that the policing rate be a multiple of 8000, so the requirements were adjusted accordingly. Table B-37 summarizes the CAR features, comparing them with CB policing.
Congestion AvoidanceThis section covers Flow-Based Random Early Detection (FRED). FREDFRED configuration requires only slightly more effort than does WRED configuration, as long as default configuration values are acceptable. This section shows two FRED configuration examples that involve the same basic scenarios as the first two WRED examples in the previous section. FRED configuration and show commands are listed in Tables B-38 and B-39.
In the first example, R3 enables FRED on its S0/0 interface. FRED classifies the packets into flows and then decides which flows are currently considered to be robust, fragile, and nonadaptive. Based on the category, FRED decides whether new packets should be discarded. This example continues the tradition of marking packets at ingress on R3's E0/0 interface. The marking logic performed by CB marking is as follows:
To generate traffic in this network, two voice calls will be made between the analog phones attached to R1 and R4. Multiple web browsers will load the standard page used in this book, with two TCP connections created by each browserone to get a file with the word "important" in it, and the other getting a file with "not-so" in it. An FTP download of a large file will also be initiated from the Server to Client1. Example B-34 shows the basic configuration and show command output. The example uses the familiar network diagram in Figure B-25, with the configuration being added to R3. Figure B-25. Sample Network for All FRED ExamplesConfiguration on R3
Example B-34. FRED Example Using All Default Values, R3 S0/0
R3#show running-config
Building configuration...
!
! Some lines omitted for brevity
!
ip cef
!
! The following class-maps will be used for CB marking policy
! used at ingress to E0/0
!
class-map match-all http-impo
match protocol http url "*important*"
class-map match-all http-not
match protocol http url "*not-so*"
class-map match-all class-default
match any
class-map match-all voip-rtp
match ip rtp 16384 16383
!
! The following policy-map will be used for CB marking
!
policy-map laundry-list
class voip-rtp
set ip dscp ef
class http-impo
set ip dscp af21
class http-not
set ip dscp af23
class class-default
set ip dscp default
!
call rsvp-sync
!
interface Ethernet0/0
description connected to SW2, where Server1 is connected
ip address 192.168.3.253 255.255.255.0
ip nbar protocol-discovery
half-duplex
service-policy input laundry-list
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
load-interval 30
random-detect
random-detect flow
clockrate 128000
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (
R1)
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
!
!
! Some lines omitted for brevity
!
R3#show queueing random-detect
Current random-detect configuration:
Serial0/0
Queueing strategy: random early detection (WRED)
Exp-weight-constant: 9 (1/512)
Mean queue depth: 36
Max flow count: 256 Average depth factor: 4
Flows (active/max active/max): 2/8/256
class Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes thresh thresh prob
0 25/12280 12/5651 20 40 1/10
1 0/0 0/0 22 40 1/10
2 103/125056 133/146549 24 40 1/10
3 0/0 0/0 26 40 1/10
4 0/0 0/0 28 40 1/10
5 641/41024 1475/94400 31 40 1/10
6 0/0 0/0 33 40 1/10
7 0/0 0/0 35 40 1/10
rsvp 0/0 0/0 37 40 1/10
The FRED part of the configuration is again quite short. The configuration lists the random- detect interface subcommand under serial 0/0, which enables precedence-based WRED on the interface. Because FRED is actually a superset of WRED, you also need to add the random- detect flow command to the interface. Interestingly, IOS adds the random-detect command to the interface if you only type the random-detect flow command. The rest of the detailed configuration in this example is just like the first WRED example configuration, repeating the CB marking configuration that marks the VoIP, FTP, and two different types of HTTP traffic. (For more information about CB marking, see Chapter 3.) The only command that lists any new information, as compared with WRED, is the show queueing random-detect interface serial 0/0 command. Most of the output looks familiar: It includes the various IP precedence values, with statistics. Just like with WRED, the command lists per-precedence default values for minimum threshold and maximum threshold. FRED still uses these values when determining the percentage of packets to discard. Specifically new for FRED, the command output lists two values used by the FRED algorithm when deciding to discard packets, namely the maximum flow count and average depth factor. The maximum flow count is the maximum number of unique active flows tracked by FRED. The average depth factor describes the scaling factor as described in the FRED concepts section, used when calculating the maximum per-flow queue size. Although FRED does track and act on flow information, listing statistics per flow would be cumbersome, because the flows may well be short lived. The show queueing command still lists statistics, but it groups the statistics based on the precedence value (or DSCP value if DSCP-based FRED is used). The second FRED configuration example uses FRED on the interface again, but this time with DSCP FRED, and a few defaults changed. In fact, Example B-35 just shows the changed configuration, with most of the configuration staying the same. The same CB marking configuration is used to mark the traffic, for instance, so the details are not repeated in the example. The example uses the familiar network diagram used in Figure B-25. Example B-35. DSCP-Based FRED on R3 S0/0
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#interface serial 0/0
R3(config-if)#random-detect flow ?
average-depth-factor Average depth multiplier (1, 2, 4, 8 or 16)
count max number of dynamic flows
<cr>
R3(config-if)#random-detect flow average-depth-factor 2
R3(config-if)#random-detect flow count 19
Number of WRED flows must be a power of 2 (16, 32, 64, 128, 256, 512, 1024
2048, 4096, 8192, 16384 or 32768)
R3(config-if)#random-detect flow count 64
R3(config-if)#^Z
R3#
R3#show queueing random-detect
Current random-detect configuration:
Serial0/0
Queueing strategy: random early detection (WRED)
Exp-weight-constant: 9 (1/512)
Mean queue depth: 39
Max flow count: 64 Average depth factor: 2
Flows (active/max active/max): 13/13/64
dscp Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes thresh thresh prob
af11 0/0 0/0 33 40 1/10
af12 0/0 0/0 28 40 1/10
af13 0/0 0/0 24 40 1/10
af21 19/23334 1/1404 33 40 1/10
af22 0/0 0/0 28 40 1/10
af23 11/14116 0/0 24 40 1/10
af31 0/0 0/0 33 40 1/10
af32 0/0 0/0 28 40 1/10
af33 0/0 0/0 24 40 1/10
af41 0/0 0/0 33 40 1/10
af42 0/0 0/0 28 40 1/10
af43 0/0 0/0 24 40 1/10
cs1 0/0 0/0 22 40 1/10
cs2 0/0 0/0 24 40 1/10
cs3 0/0 0/0 26 40 1/10
cs4 0/0 0/0 28 40 1/10
cs5 0/0 0/0 31 40 1/10
cs6 0/0 0/0 33 40 1/10
cs7 0/0 0/0 35 40 1/10
ef 11/704 2658/170112 37 40 1/10
rsvp 0/0 0/0 37 40 1/10
default 7/7396 16/14275 20 40 1/10
The configuration begins with a change from precedence-based FRED to DSCP-based FRED using the random-detect dscp-based interface subcommand. (The configuration already contained the random-detect flow command to enable flow-based WRED.) Two FRED options can be set with the random-detect flow command, as seen in the example. The average depth factor defines the multiple of the average queue space per flow that can be allocated to a single flow before FRED decides to start discarding packets. (Formula: average depth factor * maximum queue depth/number of active flows) The flow count, set to 64 in this example, just sets the maximum number of unique flows tracked by FRED. Just like with WFQ, the setting of the number of flows must be set to a power of 2. Just like with DSCP-based WRED, the command output for DSCP-based FRED does not differ from the earlier precedence-based FRED example in too many ways. The changes to the default values have been highlighted in the example. The show queueing command contains the only notable difference between the command outputs in the first two examples, now listing information about all the DSCP values recommended in the DSCP RFCs. Notice that the counters point out drops for both AF21 and AF23, which were previously both treated as precedence 2 by precedence-based FRED. Also note that FRED has discarded some voice traffic (DSCP EF) in this example. Because FRED operates on all traffic in the interface FIFO queue, it cannot avoid the possibility of discarding voice traffic. Table B-40 summarizes many of the key concepts when comparing WRED and FRED.
Link Efficiency ToolsThis section covers Payload Compression configuration, RTP and TCP header compression configuration (without MQC), and a comparison of FRF.11-C and FRF.12 fragmentation. Payload Compression ConfigurationPayload compression requires little configuration. You must enable compression on both ends of a point-to-point serial link, or on both ends of a Frame Relay VC for Frame Relay. The compress command enables compression on point-to-point links, with the frame-relay payload-compression command enabling compression over Frame Relay. Table B-41 lists the various configuration and show commands used with payload compression, followed by example configurations.
You can use the show compress command to verify that compression has been enabled on the interface and to display statistics about the compression behavior. The first example uses the network described in Figure B-26, with a PPP link between R1 and R3. The example uses the same familiar web browsing sessions, each of which downloads two JPGs. An FTP get transfers a file from the server to the client, and two voice calls between R1 and R4 are used. Figure B-26. The Network Used in PPP Payload Compression Examples
Example B-36 shows the Stacker compression between R1 and R3. Example B-36. Stacker Payload Compression Between R1 and R3 (Output from R3)
R3#show running-config
Building configuration...
!
! Lines omitted for brevity
!
interface Serial0/1
bandwidth 128
ip address 192.168.12.253 255.255.255.0
encapsulation ppp
compress stacker
clockrate 128000
!
! Portions omitted for brevity
!
r3#show compress
Serial0/1
Software compression enabled
uncompressed bytes xmt/rcv 323994/5494
compressed bytes xmt/rcv 0/0
1 min avg ratio xmt/rcv 1.023/1.422
5 min avg ratio xmt/rcv 1.023/1.422
10 min avg ratio xmt/rcv 1.023/1.422
no bufs xmt 0 no bufs rcv 0
resyncs 2
The configuration requires only one interface subcommand, compress stacker. You must enter this command on both ends of the serial link before compression will work. The show compress command lists statistics about how well compression is working. For instance, the 1-, 5-, and 10-minute compression ratios for both transmitted and received traffic are listed, which gives you a good idea of how much less bandwidth is being used because of compression. You can easily configure the other two payload compression tools. Instead of the compress stacker command as in Example B-36, just use the compress mppc or compress predictor command. Example B-37 shows FRF.9 payload compression. The configuration uses a point-to-point subinterface and the familiar network used on most of the other configuration examples in the book, as shown in Figure B-27. Figure B-27. The Network Used in FRF.9 Payload Compression Example
Example B-37. FRF.9 Payload Compression Between R1 and R3 (Output from R3)
R3#show running-config
Building configuration...
!
! Lines omitted for brevity
!
interface Serial0/0
description Single PVC to R1.
no ip address
encapsulation frame-relay IETF
no ip mroute-cache
load-interval 30
clockrate 128000
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (R1)
ip address 192.168.2.253 255.255.255.0
no ip mroute-cache
frame-relay interface-dlci 101 IETF
frame-relay payload-compression FRF9 stac
!
! Portions omitted for brevity
!
R3#show compress
Serial0/0 - DLCI: 101
Software compression enabled
uncompressed bytes xmt/rcv 6480/1892637
compressed bytes xmt/rcv 1537/1384881
1 min avg ratio xmt/rcv 0.021/1.352
5 min avg ratio xmt/rcv 0.097/1.543
10 min avg ratio xmt/rcv 0.097/1.543
no bufs xmt 0 no bufs rcv 0
resyncs 1
Additional Stacker Stats:
Transmit bytes: Uncompressed = 0 Compressed = 584
Received bytes: Compressed = 959636 Uncompressed = 0
Frame Relay payload compression takes a little more thought, although it may not be apparent from the example. On point-to-point subinterfaces, the frame-relay payload-compression FRF9 stac command enables FRF.9 compression on the VC associated with the subinterface. If a multipoint subinterface is used, or if no subinterfaces are used, however, you must enable compression as parameters on the frame-relay map command. TCP and RTP Header Compression ConfigurationUnlike payload compression, Cisco IOS Software does not have different variations on the compression algorithms for TCP and RTP header compression. To enable TCP or RTP compression, you just enable it on both sides of a point-to-point link, or on both sides of a Frame Relay VC. Note that when enabling compression, it is best practice to enable the remote side of the WAN link before enabling the local side of the WAN link. This enables the administrator to retain control of WAN connectivity. If the local side of the WAN link is configured first, an out-of-band access must exist to access the remote side. When configuring Frame Relay TCP or RTP header compression, the style of configuration differs based on whether you use point-to-point subinterfaces. On point-to-point subinterfaces, the frame-relay ip tcp or frame-relay ip rtp commands are used. If you use multipoint subinterfaces, or use the physical interface, you must configure the same parameters on frame-relay map commands. Regardless of the type of data-link protocol in use, TCP and RTP compression commands allow the use of the passive keyword. The passive keyword means that the router attempts to perform compression only if the router on the other side of the link or VC compresses the traffic. The passive keyword enables you to deploy configurations on remote routers with the passive keyword, and then later add the compression configuration on the local router, at which time compression begins. The TCP and RTP header compression configuration process, as mentioned, is very simple. Table B-42 and Table B-43 list the configuration and show commands, which are followed by a few example configurations.
The first example uses the same point-to-point link used in the payload compression section, as shown earlier in Figure B-26. In each example, the same familiar web browsing sessions are used, each downloading two JPGs. An FTP get transfers a file from the server to the client, and two voice calls between R1 and R4 are used. Example B-38 shows TCP header compression on R3. Example B-38. TCP Header Compression on R3
R3#show running-config
Building configuration...
!
! Lines omitted for brevity
!
interface Serial0/1
bandwidth 128
ip address 192.168.12.253 255.255.255.0
encapsulation ppp
ip tcp header-compression
clockrate 128000
!
! Portions omitted for brevity
!
R3#show ip tcp header-compression
TCP/IP header compression statistics:
Interface Serial0/1:
Rcvd: 252 total, 246 compressed, 0 errors
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 371 total, 365 compressed,
12995 bytes saved, 425880 bytes sent
1.3 efficiency improvement factor
Connect: 16 rx slots, 16 tx slots,
218 long searches, 6 misses 0 collisions, 0 negative cache hits
98% hit ratio, five minute miss rate 0 misses/sec, 1 max
To enable TCP header compression, the ip tcp header-compression command was added to both serial interfaces on R1 and R3. The show ip tcp header-compression command lists statistics about how well TCP compression is working. For instance, 365 out of 371 packets sent were compressed, with a savings of 12,995 bytes. Interestingly, to find the average number of bytes saved for each of the compressed packets, divide the number of bytes saved (12,995) by the number of packets compressed (365), which tells you the average number of bytes saved per packet was 35.6. For comparison, remember that TCP header compression reduces the 40 bytes of IP and TCP header down to between 3 and 5 bytes, meaning that TCP header compression should save between 35 and 37 bytes per packet, as is reflected by the output of the show ip tcp header-compression command. To configure RTP header compression on point-to-point links, you perform a similar exercise as you did for TCP in Example B-38, except you use the rtp keyword rather than the tcp keyword to enable RTP header compression. For a little variety, however, the next example shows RTP header compression, as enabled on a Frame Relay link between R3 and R1. The network used in this example matches Figure B-27, shown in the Frame Relay payload compression example. Example B-39 shows the configuration and statistics. Example B-39. Frame Relay RTP Header Compression on R3
R3#show running-config
Building configuration...
!
! Lines omitted for brevity
!
interface Serial0/0
description connected to FRS port S0. Single PVC to R1.
no ip address
encapsulation frame-relay
load-interval 30
clockrate 128000
!
interface Serial0/0.1 point-to-point
description point-point subint global DLCI 103, connected via PVC to DLCI 101 (R1)
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
frame-relay ip rtp header-compression
!
! Portions omitted for brevity
!
R3#show frame-relay ip rtp header-compression
DLCI 101 Link/Destination info: point-to-point dlci
Interface Serial0/0:
Rcvd: 18733 total, 18731 compressed, 2 errors
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 16994 total, 16992 compressed,
645645 bytes saved, 373875 bytes sent
2.72 efficiency improvement factor
Connect: 256 rx slots, 256 tx slots,
0 long searches, 2 misses 0 collisions, 0 negative cache hits
99% hit ratio, five minute miss rate 0 misses/sec, 0 max
To enable RTP header compression, the frame-relay ip rtp header-compression command was added to both serial subinterfaces on R1 and R3. (If a multipoint subinterface had been used instead, the same parameters could have been configured on a frame-relay map command.) The show frame-relay ip rtp header-compression command lists statistics about how well cRTP is working. You might recall that cRTP reduces the 40 bytes of IP, UDP, and RTP header to between 2 and 4 bytes, saving between 36 and 38 bytes per packet. In the output in the example, with 16,992 packets compressed, a savings of 645,645 bytes is realized, which is an average per-packet savings of 37.99 bytes. The show frame-relay ip rtp header-compression command output also lists an efficiency improvement factor, which is the compression ratio. It is calculated as the number of bytes that would have been sent without compression, divided by the actual number of bytes sent. From the shaded lines at the end of the preceding example, 645,645 + 373,875 bytes would have been sent (the number of bytes saved, plus actual number sent), for a total of 1,019,520 bytes that would have been sent. Dividing that total by the actual number sent (373,875) gives you the improvement factor of 2.72. For perspective, if you divide the packet size of a G.729 VoIP packet (60 bytes), by the compressed size of 22 bytes (which implies you saved 38 of the 40 bytes in the header), the ratio also calculates to 2.72. Therefore, the empirical ratio from the show command matches the theoretical ratio between bytes that would have been sent, and bytes that are actually sent, with cRTP. Comparing FRF.12 and FRF.11-CMost of the coverage of LFI over Frame Relay has focused on FRF.12. However, IOS offers another Frame Relay LFI service called FRF.11-C. You can use each of these two LFI options only when you use particular types of Frame Relay VCs. To appreciate how the two options differ, you first need to understand these two types of VCs. The Frame Relay Forum (FRF) created data VCs originally to carry multiprotocol data traffic, as defined in the FRF.3 Implementation Agreements. Service providers around the world offer Frame Relay FRF.3 data VCs. Later, with the advent of packetized voice, the Frame Relay Forum decided to create a new type of VC that would allow for better treatment of voice traffic. The FRF created the FRF.11 Implementation Agreement, which defines Voice over Frame Relay (VoFR) VCs. These VCs still pass data traffic, but they also pass voice traffic. Therefore, if a Frame Relay switch knows that one frame is data, and another is voice, for example, the switch can implement some form of queuing to give the voice frame low latency. FRF.11 headers include a field that identifies the frame as voice or data, making it possible for the cloud to perform QoS for the voice traffic. The key to understanding the difference between the two basic types of VCs is to look at the headers used when the frames cross the Frame Relay network. It helps to understand when VoFR VCs can be useful, and when they cannot. Figure B-28 shows the framing when FRF.3 and FRF.11 are used, both for IP telephony traffic and for local voice gateway traffic. Figure B-28. Framing of Voice Traffic with FRF.3 and FRF.11 VCs
In all cases in the figure, G.729 codecs are used. With FRF.3 VCs, the IP Phone and voice gateway traffic sits inside IP/UDP/RTP headers. In other words, the IP Phones encapsulate the G.729 payload using VoIP, and the routers do the same for the analog and digital voice trunks. Although the packets traverse the Frame Relay network, all the voice traffic is considered to be VoIP traffic when you use FRF.3 data VCs. With FRF.11 VCs, some voice traffic can be VoIP, and some can be VoFR traffic. The traffic to and from the directly attached analog and digital voice links can be encapsulated using VoFR, as shown in the lowest of the four example frames. The IP telephony traffic, however, still must be encapsulated first in IP, because the traffic must pass across other links besides this single Frame Relay cloud. The VoFR encapsulation requires far less overhead, because the IP, RTP, and UDP headers are not needed. However, VoFR you can use encapsulation only when the Frame Relayattached routers are the endpoints for the packets holding the voice payload. Because the larger percentage of packetized voice over time will be from IP Phones and the like, VoFR services are not typically offered by Frame Relay providers. FRF.11-C provides for LFI over VoFR VCs, similarly to how FRF.12 provides LFI services for FRF.3 data VCs. Just like FRF.12, FRF.11-C uses Dual FIFO interface output queues, with PQ logic applied to the two queues. However, FRF.11-C uses a different classification logic, as follows:
In the preceding figure, the VoFR frames created for the voice gateway would be placed in the High queue, but the IP Phone packets would be placed into the Normal queue, because they would be considered to be data. The other main difference between FRF.11-C and FRF.12 has to do with how the tools decide what to fragment, and what not to fragment. FRF.12 fragments all packets over a certain length. FRF.11-C, however, never fragments VoFR frames, even if they are larger than the fragment size. FRF.11-C fragments data frames only, and only if they are larger than the fragment size. Table B-44 summarizes some of the key comparison points about FRF.12 and FRF.11-C.
|
|
|
