|
|
本帖最后由 kkingkill 于 2010-4-21 17:05 编辑
Understanding the “shape peak” command
By Petr Lapukhov, CCIE #16379
Note: The following post is an excerpt ** the full QoS section of IEWB-RS VOL1 version 5.
Peak shaping may look confusing at first sight; however, its function becomes clear once you think of oversubscription. As we discussed before, oversubscription means selling customers more bandwidth than a network can supply, hoping that not all connections would use their maximum sending rate at the same time. With oversubscription, traffic contract usually specifies three parameters: PIR, CIR and Tc – peak rate, committed rate and averaging time interval for rate measurements. The SP allows customers to send traffic at rates up to PIR, but only guarantees CIR rate in case of network congestion. Inside the network SP uses any of the max-min scheduling procedures to implement bandwidth sharing in such manner that oversubscribed traffic has lower preference than conforming traffic. Additionally, the SP generally assumes that customers respond to notifications of traffic congestion in the network (either explicit, such as FECN/BECN/TCP ECN or implicit such as packet drops in TCP) by slowing down sending rate.
Commonly, customers implement traffic shaping to conform to traffic contract, and provider uses traffic policing to enforce the contract. If a contract specifies PIR, then it makes sense for customer to shape traffic at PIR rate. However, this makes difficult to deduce CIR value just by looking at the router configuration. In some circumstances, like with Frame-Relay networks, a secondary parameter, known as minCIR, may help to understand the configuration quickly. In general, it would benefit to see CIR and PIR in the shaping configuration at the same time. This is exactly the idea behind shape peak. When you configure
shape peak <CIR> <Bc> <Be>
the actual maximum sending rate is limited to:
PIR = CIR*(1+Be/Bc).
K注：所以，默认情况下，如果你不配置Be, 那么Be值=Bc,所以 PIR=2CIR.
That is, each time interval Tc=Bc/CIR the shaper allows sending up to Bc+Be bits of data. By default, if you omit the value for Be, it equals to Bc and thus PIR=2*CIR by default. However, due to some IOS show output discrepancy, this is NOT reflected in “show” command output, unless you explicitly specify the Be value in command line. With shape peak configured this way, you can see both CIR as the “average rate” and PIR as the “target rate” when issuing “show policy-map” command.
Rack1R6#show policy-map interface fastEthernet 0/0.146
FastEthernet0/0.146
Service-policy output: POLICY_VLAN146_OUT
Class-map: HTTP (match-all)
6846 packets, 4065413 bytes
5 minute offered rate 63000 bps, drop rate 0 bps
Match: access-group 180
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/64000 1600 6400 6400 100 1600
K注：average rate=CIR
target rate=PIR
...
All other shaping functions remain the same as with the classic GTS - shape peak is just more suited for use with oversubscription scenarios. Also, in Frame-Relay networks you may want to use configuration similar to the following to respond to congestion notifications:
shape peak <CIR> <Bc> <Be> K注：所说，不要认为 peak后面的是PIR， PIR是通过间接算出来的，不是直接配上去的。
shape adaptive <CIR>
To illustrate the use of shape peak, let’s look at the following scenario. Here, R4 serves two customers (R1 and R6) sending their traffic across one serial link of 128Kbps between R4 and R5. The fictive ISP sells 128Kbps (PIR) to each of the customers, guaranteeing only 64Kbps (CIR). Let’s assume the measurement interval of 100ms for this configuration. The serial link, which is the oversubscribed resource, uses WFQ for fair bandwidth sharing between two flows.
R1:
access-list 180 permit tcp any eq 80 any
!
class-map HTTP
match access-group 180
!
policy-map POLICY_VLAN146_OUT
class HTTP
shape peak 64000 6400 6400
!
interface FastEthernet 0/0
service-policy output POLICY_VLAN146_OUT
R6:
access-list 180 permit tcp any eq 80 any
!
class-map HTTP
match access-group 180
!
policy-map POLICY_VLAN146_OUT
class HTTP
shape peak 64000 6400 6400
!
interface FastEthernet 0/0.146
service-policy output POLICY_VLAN146_OUT
R4:
!
! All HTTP traffic
!
ip access-list extended HTTP
permit tcp any eq 80 any
!
class-map HTTP
match access-group name HTTP
!
! Traffic ** R1 and R6 respectively
!
ip access-list extended **_R1
permit ip host 155.1.146.1 any
!
ip access-list extended **_R6
permit ip host 155.1.146.6 any
!
!
!
class-map **_R1
match access-group name **_R1
!
class-map **_R6
match access-group name **_R6
!
! Subrate policers
!
policy-map SUBRATE_POLICER
class **_R1
police cir 64000 bc 3200 pir 128000 be 6400
conform-action set-prec-transmit 1
exceed-action set-prec-transmit 0
violate-action drop
class **_R6
police cir 64000 bc 3200 pir 128000 be 6400
conform-action set-prec-transmit 1
exceed-action set-prec-transmit 0
violate-action drop
!
! Policer configuration using MQC syntax.
!
policy-map POLICE_VLAN146
class HTTP
service-policy SUBRATE_POLICER
!
interface FastEthernet 0/1
service-policy input POLICE_VLAN146
The idea is to allow R1 and R6 send up to 128Kbps if there is enough bandwidth on the serial link. However, if both of the sources start streaming at the same time, the SP may only guarantee up to 64Kbps to each of sending routers. The implementation meters each flow against 64Kbps and 128Kbps meters, and marks all conforming traffic with IP precedence of 1. All exceeding traffic is marked with IP precedence of 0. Since the serial link uses WFQ, we conclude that traffic marked with IP precedence of zero has lower scheduling weight. Thus, if IP precedence 1 traffic exist on the link, it is given preference over low-priority traffic (precedence 0).
To verify our configuration in action, start downloading a large file ** R1 across R4 and see the statistics on R1 and R4:
Rack1R4#show policy-map interface fastEthernet 0/1
FastEthernet0/1
Service-policy input: POLICE_VLAN146
Class-map: HTTP (match-all)
20451 packets, 12066090 bytes
30 second offered rate 126000 bps, drop rate 0 bps
Match: access-group name HTTP
Service-policy : SUBRATE_POLICER
Class-map: **_R1 (match-all)
20451 packets, 12066090 bytes
30 second offered rate 126000 bps, drop rate 0 bps
Match: access-group name **_R1
police:
cir 64000 bps, bc 3200 bytes
pir 128000 bps, be 6400 bytes
conformed 11113 packets, 6556670 bytes; actions:
set-prec-transmit 1
exceeded 9338 packets, 5509420 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 64000 bps, exceed 62000 bps, violate 0 bps
Class-map: **_R6 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group name **_R6
police:
cir 64000 bps, bc 3200 bytes
pir 128000 bps, be 6400 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 1
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps
Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
K注：从policy-map看到，R1使用了所有可用Bandwidth,因为R6未发包.
!
! The above statistics demonstrate that R1 uses almost all available bandwidth
! ** the output below we can see that R1 is set to CIR 64Kbps and PIR 128Kbs.
! We may also notice that shaper was active for some time, delaying hundreds of
! exceeding packets. This usually happens in the beginning of TCP session when
! sendger aggressively increases sending rate.
!
Rack1R1#show policy-map interface fastEthernet 0/0
FastEthernet0/0
Service-policy output: POLICY_VLAN146_OUT
Class-map: HTTP (match-all)
3225 packets, 1897929 bytes
30 second offered rate 124000 bps, drop rate 0 bps
Match: access-group 180
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/64000 1600 6400 6400 100 1600
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 3225 1897929 348 205320 no
Class-map: class-default (match-any)
29 packets, 4378 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
Now start another file transfer, this time ** R6 down to a host behind, R5 across the serial link. This will make both flows compete for the link bandwidth, and result in fair sharing of the link bandwidth. Now verify the policer statistics once again:
Rack1R4#show policy-map interface fastEthernet 0/1
FastEthernet0/1
Service-policy input: POLICE_VLAN146
Class-map: HTTP (match-all)
35113 packets, 20715559 bytes
30 second offered rate 126000 bps, drop rate 0 bps
Match: access-group name HTTP
Service-policy : SUBRATE_POLICER
Class-map: **_R1 (match-all)
29986 packets, 17691740 bytes
30 second offered rate 63000 bps, drop rate 0 bps
Match: access-group name **_R1
police:
cir 64000 bps, bc 3200 bytes
pir 128000 bps, be 6400 bytes
conformed 18466 packets, 10894940 bytes; actions:
set-prec-transmit 1
exceeded 11520 packets, 6796800 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 63000 bps, exceed 0 bps, violate 0 bps
Class-map: **_R6 (match-all)
5127 packets, 3023819 bytes
30 second offered rate 63000 bps, drop rate 0 bps
Match: access-group name **_R6
police:
cir 64000 bps, bc 3200 bytes
pir 128000 bps, be 6400 bytes
conformed 5124 packets, 3022049 bytes; actions:
set-prec-transmit 1
exceeded 3 packets, 1770 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 63000 bps, exceed 0 bps, violate 0 bps
Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
!
! Verify statistics for both traffic shapers on R1 and R6. Both are set for PIR=128Kbps.
! However, metered rate is close to CIR, and the shaping is inactive. The sending rate
! went down thanks to TCP implicit congestion management procedure, that makes protocol
! sending rate adaptive to congestion in networks.
!
Rack1R6#show policy-map interface fastEthernet 0/0.146
FastEthernet0/0.146
Service-policy output: POLICY_VLAN146_OUT
Class-map: HTTP (match-all)
6846 packets, 4065413 bytes
5 minute offered rate 63000 bps, drop rate 0 bps
Match: access-group 180
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/64000 1600 6400 6400 100 1600
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 6846 4065413 3 1782 no
Class-map: class-default (match-any)
191 packets, 43930 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Rack1R1#show policy-map interface fastEthernet 0/0
FastEthernet0/0
Service-policy output: POLICY_VLAN146_OUT
Class-map: HTTP (match-all)
33062 packets, 19505469 bytes
30 second offered rate 63000 bps, drop rate 0 bps
Match: access-group 180
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/64000 1600 6400 6400 100 1600
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 33062 19505469 2632 1552858 no
Class-map: class-default (match-any)
7641 packets, 7385752 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
Now let’s confirm that WFQ is actually working on the serial interface between R4 and R5 and provides truly fair division of the bandwidth:
Rack1R4#show queueing interface serial 0/1
Interface Serial0/1 queueing strategy: fair
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 12/1000/64/0 (size/max total/threshold/drops)
Conversations 2/3/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 96 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 6/16192/0/0/0
Conversation 134, linktype: ip, length: 580
source: 155.1.146.1, destination: 155.1.58.8, id: 0xEB41, ttl: 254,
TOS: 32 prot: 6, source port 80, destination port 11001
(depth/weight/total drops/no-buffer drops/interleaves) 6/16192/0/0/0
Conversation 192, linktype: ip, length: 580
source: 155.1.146.6, destination: 155.1.108.10, id: 0x70CA, ttl: 254,
TOS: 32 prot: 6, source port 80, destination port 11002
K注：红色部分为两条流
To summarize, shape peak is a special form of shaping specifically adapted to configure oversubscription scenarios. All other properties of GTS remains the same. |
|
[复制链接]
|熊猫同学技术论坛|小黑屋|
网络工程师论坛
( 沪ICP备09076391 )
发表于 2010-4-21 16:54:10
提升卡
置顶卡
变色卡
显身卡
楼主
看着头晕哇~~~
看看