Cisconinja’s Blog

Classification, Marking, and Policing Order of Operations

Posted by Andy on February 3, 2009

Continuing from my previous policing tests, this post will take a look at another difference between class-based policing and CAR.  R1 will be configured to police traffic and R2 will be configured to measure incoming traffic.  The network topology and configurations are shown below:

policing2-topology

R1:
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 load-interval 30
 speed 100
 full-duplex
 no keepalive
 no mop enabled
!
interface Serial0/0
 ip address 10.1.12.1 255.255.255.0
 load-interval 30
 no keepalive
!
no cdp run

R2:
interface Serial0/0
 ip address 10.1.12.2 255.255.255.0
 load-interval 30
 no keepalive
!
no cdp run

R1 will be configured with a hierarchical class-based policing policy in order to test how the order of marking and policing on the parent and child policy maps take place.  As we saw in the last set of policing tests, the policing on the parent policy takes place first and the results are offered to the child policy.  The way that the marking takes place is also important to know because it can lead to a very different end result than what is expected.  Consider the following configuration:

R1:
class-map match-all Prec0
 match precedence 0
class-map match-all Prec2
 match precedence 2
!
policy-map child-policer
 class Prec2
  police cir 96000 bc 6000
   conform-action set-prec-transmit 3
   exceed-action drop
 class Prec0
  police cir 96000 bc 6000
   conform-action set-prec-transmit 1
   exceed-action drop
policy-map policer
 class class-default
  police cir 192000 bc 12000
   conform-action set-prec-transmit 2
   exceed-action drop
 service-policy child-policer
!
interface Serial0/0
 service-policy output policer

R2:
class-map match-all Prec1
 match precedence 1
class-map match-all Prec2
 match precedence 2
class-map match-all Prec3
 match precedence 3
!
policy-map Prec-Traffic-Meter
 class Prec3
 class Prec2
 class Prec1
!
interface Serial0/0
 service-policy input Prec-Traffic-Meter

Policy map ‘policer’ has been configured to police traffic to 192,000 bps, set the IP precedence to 2, and offer the results to ‘child-policer’.  All other exceeding traffic is dropped.  Policy-map ‘child-policer’ has been configured with 2 class maps, one to match IP precedence 2 traffic and one to match IP precedence 0 traffic.  The policer on the ‘Prec2’ class specifies that conforming traffic should be remarked as IP precedence 3 and transmitted, while the policer on the ‘Prec0’ class specifies that conforming traffic should be remarked as IP precedence 1 and transmitted.  R2 has been configured to measure incoming traffic by precedence value.  We will have PC generate 32 packets/second at 1496 bytes each for a total offered rate of approximately 384,000 bps on the serial link (1500 * 8 * 32):

flood.pl --port=53 --size=1496 --delay=31 10.1.12.2

show interfaces verifies that approximately 384,000 bps is being received on the FastEthernet interface and approximately 96,000 bps is being sent across the serial link: 

1-policing2-r1f0

1-policing2-r1s0

1-policing2-r2s0

Next look at the policy-map statistics on R1:

1-policing2-r1-pmap

The policing statistics on the parent policy look as expected – the offered rate is close to 384,000 bps and 192,000 bps has conformed, with the rest exceeding and being dropped.  The child policy policing statistics, however, may be a surprise.  Even though the parent policing takes place first and we configured the conform action to set IP precedence to 2 before transmitting, no packets have matched the class ‘Prec2’ on the child policy.  The class ‘Prec0’ on the other hand has matched as many packets as the parent policy has and also shows an offered rate close to 384,000 bps.  It also shows that 96,000 bps have conformed and 96,000 bps exceeded, which matches the rate being offered after policing on the parent policy has taken place.  R2 also confirms that all packets being sent are IP precedence 1:

1-policing2-r2-pmap

Based on this information, we can conclude that:

1. Classification into both the parent and child classes happens before policing occurs.  If it were the other way around, we would only see about 192,000 bps as the offered rate to the class ‘Prec0’.

2. Policing on the parent happens before policing on the child.  This was shown in earlier tests as well, and again we can see it is true because the conforming + exceeding packet counter on the child class ‘Prec0’ equals the conforming packet counter on the parent.

3. Classification into both the parent and child classes happens before any marking from the policers occur.  This is shown by the fact that all traffic on the child policy is being classified into ‘Prec0’, which is the default IP precedence of the traffic stream before any marking has occured, rather than class ‘Prec2’ which it would have been if the parent policer had marked it before offering it to the child.

 

Next, we will modify the configuration slightly by changing the conform action on the child policy class ‘Prec0’.  Instead of marking conforming traffic as precedence 1 and transmitting, it will transmit conforming traffic unchanged.  The rest of the configuration will remain the same.  Here is the new policy map configuration for reference:

R1:
policy-map child-policer
 class Prec2
  police cir 96000 bc 6000
   conform-action set-prec-transmit 3
   exceed-action drop
 class Prec0
  police cir 96000 bc 6000
   conform-action transmit
   exceed-action drop
policy-map policer
 class class-default
  police cir 192000 bc 12000
   conform-action set-prec-transmit 2
   exceed-action drop
 service-policy child-policer

The results of R1’s policing and R2’s traffic measurments are shown below:

2-policing2-r1-pmap

2-policing2-r2-pmap

The traffic is now being received on R2 as IPP 2, which is what we configured the parent policy to mark conforming traffic as.  Therefore, we can conclude that marking with class-based policing occurs first on the parent policy, and then on the child policy.  If the child policy policer has not been configured to remark traffic, then it will be transmitted as marked by the parent policer.

 

Next we will add class-based marking to both the parent and child policy maps, in addition to marking with class-based policing.  The parent policy will be configured with class-based marking to set IPP to 5.  The child policy class ‘Prec0’ will be configured with class-based marking to set IPP to 4.  The child policy will also be configured as it was initially, so that traffic conforming to the policer on class ‘Prec0’ is marked with IPP 1.  Additional classes will also be added to the traffic meter on R2 to test for incoming IPP values of 4 or 5.  The configuration is:

R1:
policy-map child-policer
 class Prec2
  police cir 96000 bc 6000
   conform-action set-prec-transmit 3
   exceed-action drop
 class Prec0
  set precedence 4
  police cir 96000 bc 6000
   conform-action set-prec-transmit 1
   exceed-action drop
policy-map policer
 class class-default
  police cir 192000 bc 12000
   conform-action set-prec-transmit 2
   exceed-action drop
  set precedence 5
  service-policy child-policer

R2:
class-map match-all Prec4
 match precedence 4
class-map match-all Prec5
 match precedence 5
!
policy-map Prec-Traffic-Meter
 class Prec1
 class Prec2
 class Prec3
 class Prec4
 class Prec5

The results of R1’s marking and policing and R2’s traffic measurments are shown below:

3-policing2-r1-pmap

3-policing2-r2-pmap

The policy map statistics on R1 show that class-based marking has marked 6103 packets as IPP 5 on the parent and as IPP 4 on the child, the same number of total packets before any policing occured – so we know that class-based marking occurs before policing does.  R2 shows that all packets being received are IPP 1, which is what the child policer has been configured to remark conforming traffic as – so we also know that of the 4 methods of marking being used, marking by the child policer takes place last.

 

Now let’s modify the conform action on the child policer class ‘Prec0’ again so that it does not remark traffic.  Only the conform action needs to be changed, but the whole policy map configuration on R1 is shown for reference:

R1:
policy-map child-policer
 class Prec2
  police cir 96000 bc 6000
   conform-action set-prec-transmit 3
   exceed-action drop
 class Prec0
  set precedence 4
  police cir 96000 bc 6000
   conform-action transmit
   exceed-action drop
policy-map policer
 class class-default
  police cir 192000 bc 12000
   conform-action set-prec-transmit 2
   exceed-action drop
  set precedence 5
  service-policy child-policer

The results of R1’s marking and policing and R2’s traffic measurments are shown below:

4-policing2-r1-pmap1

4-policing2-r2-pmap

All traffic being received by R2 is IPP 2, as configured on the parent policer.  Therefore we can determine that marking by the parent policer also takes place after class-based marking by either the child or parent policys.

 

Next we will modify the action for conforming traffic on the parent policer as well, so that both policers transmit conforming traffic unmodified.  This will allow us to see which occurs last of the class-based marking configured on the parent and child policys.  The new policy map configuration is:

R1:
policy-map child-policer
 class Prec2
  police cir 96000 bc 6000
   conform-action set-prec-transmit 3
   exceed-action drop
 class Prec0
  set precedence 4
  police cir 96000 bc 6000
   conform-action transmit
   exceed-action drop
policy-map policer
 class class-default
  police cir 192000 bc 12000
   conform-action transmit
   exceed-action drop
  set precedence 5
  service-policy child-policer

The results of R1’s marking and policing and R2’s traffic measurments are shown below:

5-policing2-r1-pmap

5-policing2-r2-pmap

All traffic received is IPP 4, which was configured with class-based marking on the child policy.  We can determine that class-based marking on the child policy takes place after class-based marking on the parent policy.

 

Now let’s remove class-based marking from the child policy just to verify that class-based marking on the parent policy takes place as expected in the absence of all other marking methods.  The policy map configuration is:

R1:
policy-map child-policer
 class Prec2
  police cir 96000 bc 6000
   conform-action set-prec-transmit 3
   exceed-action drop
 class Prec0
  police cir 96000 bc 6000
   conform-action transmit
   exceed-action drop
policy-map policer
 class class-default
  police cir 192000 bc 12000
   conform-action transmit
   exceed-action drop
  set precedence 5
  service-policy child-policer

The results of R1’s marking and policing and R2’s traffic measurments are shown below:

6-policing2-r1-pmap

6-policing2-r2-pmap

Our traffic is now being marked as IPP 5 as specified by the class-based marker on the parent policy after all other types of marking were removed.  Identical tests were performed for inbound classification, marking, and policing and the results were the same.  Based on this series of tests, we can conclude that the order of operation for classification, class-based marking, and class-based policing is:

1. Inbound classification for both parent and child policy maps.  This same classification will be used for determining which class traffic is placed into in Step #2 – 5, regardless of any changes made to the markings along the way.

2. Inbound class-based marking on the parent policy

3. Inbound class-based marking on the child policy.

4. Inbound class-based policing and marking on the parent policy.

5. Inbound class-based policing and marking on the child policy.

6. Outbound classification for both parent and child policy maps.  This same classification will be used for determining which class traffic is placed into in Step #7 – 10, regardless of any changes made to the markings along the way.

7. Outbound class-based marking on the parent policy

8. Outbound class-based marking on the child policy.

9. Outbound class-based policing and marking on the parent policy.

10. Outbound class-based policing and marking on the child policy.

 

The only tricky part to remember is that the classification occurs only at the beginning, once in each direction – traffic is not reclassified based on an updated marking that occured in the middle.  For example, as we saw in the tests, when traffic reached the outbound child policer (Step #10), it was still classified as IPP 0 traffic even though it was remarked 3 different times in between (Step #7 – 9) to different IPP values.

 

CAR on the other hand behaves in a much more logical way.  If cascaded CAR statements are used, a new classification is performed at each one.  Therefore if a certain QoS value is remarked in the first CAR statement, future CAR statements can police based on that value.  Take a look at the following CAR configuration, after the class-based policing configuration has been removed:

R1:
access-list 100 permit ip any any precedence routine
access-list 101 permit ip any any precedence priority
access-list 102 permit ip any any precedence immediate
access-list 103 permit ip any any precedence flash
access-list 104 permit ip any any precedence flash-override
access-list 105 permit ip any any precedence critical
!
interface Serial0/0
 rate-limit output access-group 100 192000 12000 12000 conform-action set-prec-continue 1 exceed-action drop
 rate-limit output access-group 101 96000 6000 6000 conform-action set-prec-continue 2 exceed-action drop
 rate-limit output access-group 102 96000 6000 6000 conform-action set-prec-continue 3 exceed-action drop
 rate-limit output access-group 103 96000 6000 6000 conform-action transmit exceed-action drop

6 different ACLs have been configured, 1 to match each IPP value between 0 and 5.  CAR has also been configured with 4 cascaded policys, with the first policing traffic to 192,000 bps and the next 3 policing traffic to 96,000 bps.  All conforming traffic is marked to the next higher precedence value, and exceeding traffic is dropped.  Using the same traffic stream (approximately 384,000 bps of IPP 0 traffic), the results on R1 and R2 are shown below:

7-policing2-r1-car

7-policing2-r2-pmap

We can see that roughly 191,000 bps matched the first CAR policy, which was configured to match IPP 0 traffic.  Since the configured action was set-prec-continue 1, the conforming traffic is compared against the next statement.  The second CAR policy is configured to match only IPP 1 traffic, and we can see that it has matched 849 conforming and 850 exceeding packets, which equals the first CAR policy’s 1699 conforming packets.  Our traffic was reclassified when the second CAR policy was examined, resulting in a match on ACL 101 which was configured to match IPP 1 traffic – if it worked like class-based policing and was not reclassified, none of the last 3 CAR policies would have resulted in a match, and 192,000 bps of IPP 0 traffic would have been sent.  The third and fourth CAR policies remark the traffic to IPP 2 and 3 respectively, and since the CIR on both is the same as the second policy no additional traffic is dropped.  On R2, approximately 96,000 bps of IPP 3 traffic is arriving.

 

Next we will add class-based marking to the configuration.  We will configure the parent class-based marking policy to mark traffic as IPP 5 and the child to mark traffic as IPP 4, just as in the class-based policing tests.  We also add a couple additional CAR policies after the four configured previously.  The new config on R1 is:

R1:
policy-map child-marker
 class class-default
  set precedence 4
policy-map marker
 class class-default
  set precedence 5
  service-policy child-marker
!
interface Serial0/0
 rate-limit output access-group 104 96000 6000 6000 conform-action transmit exceed-action drop
 rate-limit output access-group 105 96000 6000 6000 conform-action transmit exceed-action drop
 service-policy output marker

We already know from previous tests that the class-based marking on the child will be applied after the parent, so after the two remarkings by class-based marking have taken place the traffic should be IPP 4; what we are trying to find out now is will the first CAR statement see the traffic as it was initially as IPP 0 or after it has been marked by class-based marking as IPP 4.  The results on R1 and R2 are shown below:

8-policing2-r1-car

8-policing2-r2-pmap

Only the fifth CAR statement (ACL 104) was matched, so CAR must have reclassified the traffic after class-based marking had marked it rather than using the initial classification of IPP 0.  R2 also confirms that it saw only IPP 4 traffic.  These tests show that the order of operation for classification, class-based marking, and CAR is:

1. Inbound classification for both parent and child policy maps.  This same classification will be used for determining which class traffic is placed into in Step #2 – 3, regardless of any changes made to the markings along the way.

2. Inbound class-based marking on the parent policy

3. Inbound class-based marking on the child policy.

4. Inbound re-classification by CAR.

5. Inbound policing and marking on the CAR policy.

6. Return to Step #4 for each additional cascaded CAR policy.

7. Outbound classification for both parent and child policy maps.  This same classification will be used for determining which class traffic is placed into in Step #8 – 9, regardless of any changes made to the markings along the way.

8. Outbound class-based marking on the parent policy

9. Outbound class-based marking on the child policy.

10. Outbound re-classification by CAR.

11. Outbound policing and marking on the CAR policy.

12. Return to Step #10 for each additional cascaded CAR policy.

Advertisements

8 Responses to “Classification, Marking, and Policing Order of Operations”

  1. Joyce said

    Hi Andy,

    I have question for you if you have tested that before. Based on Cisco Order of Operation in
    http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080160fc1.shtml#mark

    it says if “mark and apply QoS action in the same policy”, then “QoS action use the original value of the packet when it is commonly classified. The packet will carry the new value when it is transmitted, and the next router uses the new value.”

    I am particularly looking for an outbound only service policy applying on WAN outgoing interface along with WRED. Without any premarking in the LAN nor any Inbound service policy in the LAN interface to do any pre-marking with different dscp values. So that means assuming the LAN has different types of traffic and they are all dscp 0 with no premarking sending from LAN interface into this WAN router.

    Now I have ACL to classify say telnet traffic to be AF31 class, ftp traffic CS1 class, all rest goto default class as an example. So we have config:

    class-map match-any high_priority
    match access-group 10
    class-map match-any scavenger
    match access-group 20

    access-list 10 permit any any eq telnet
    access-list 10 permit any eq telnet any
    access-list 20 permit any any eq ftp
    access-list 20 permit any ftp any

    policy-map test
    class high_priority
    set ip dscp af31
    bandwidth remaining percent 50
    random-detect dscp-based
    random-detect dscp 26 32 64 10
    class scavenger
    set ip dscp cs1
    bandwidth remaining percent 5
    random-detect dscp-based
    random-detect dscp 8 22 64 10
    class class-default
    bandwidth remaining percent 45
    random-detect dscp-based
    random-detect dscp 0 20 64 10

    interface s0/0
    ip address x.x.x.x x.x.x.x
    service-policy output test

    Now here is my question, we know all the traffic coming into the router with dscp 0. We use ACL to match telnet traffic and manually set those traffic to be AF31 for example. So when any telnet traffic sends out of the serial port to the WAN, it will now get AF31 value. But my question is on WRED. If based on reading the Cisco document that when I do marking and policing in same policy, the QoS action won’t be used. So does WRED considers as the QoS action? So when I turn on WRED on class high_priority while I am doing “set ip dscp af31” in the same class policy, so when telnet traffic gets matches to the ACL and now being placed into the class high_priority, will WRED do the random drop based on the dscp 0 value or based on dscp af31 value??

    If I do “show policy-map int s0/0”, I can see class high_priority has packet matching on af31 counters and nothing on default counters in that class. So that just leads me to think the router is doing random drop based on AF31, but if that is the case, then it doesn’t match cisco document so that’s why I am little unsure which is correct.

    thanks,
    Joyce

  2. Andy said

    Hi Joyce,

    Interesting question and link. I just tested this out, and I had the same results as you. Here is my config:

    class-map match-all class1
    match any
    !
    policy-map test
    class class1
    set ip dscp af31
    bandwidth percent 75
    random-detect dscp-based
    random-detect dscp 0 30 40 10
    random-detect dscp 26 10 20 10
    policy-map shaper
    class class-default
    shape average 64000
    service-policy test
    !
    interface Serial0/0
    service-policy output shaper

    R1#sh policy-map int
    Serial0/0

    Service-policy output: shaper

    Class-map: class-default (match-any)
    954 packets, 1431000 bytes
    30 second offered rate 150000 bps, drop rate 90000 bps
    Match: any
    Traffic Shaping
    Target/Average Byte Sustain Excess Interval Increment
    Rate Limit bits/int bits/int (ms) (bytes)
    64000/64000 2000 8000 8000 125 1000

    Adapt Queue Packets Bytes Packets Bytes Shaping
    Active Depth Delayed Delayed Active
    – 20 497 745500 497 745500 yes

    Service-policy : test

    Class-map: class1 (match-all)
    954 packets, 1431000 bytes
    30 second offered rate 150000 bps, drop rate 90000 bps
    Match: any
    QoS Set
    dscp af31
    Packets marked 954
    Queueing
    Output Queue: Conversation 25
    Bandwidth 75 (%)
    Bandwidth 48 (kbps)
    (pkts matched/bytes matched) 954/1431000
    (depth/total drops/no-buffer drops) 20/460/0
    exponential weight: 9
    mean queue depth: 20

    dscp Transmitted Random drop Tail drop Minimum Maximum Mark
    pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
    af11 0/0 0/0 0/0 32 40 1/10
    af12 0/0 0/0 0/0 28 40 1/10
    af13 0/0 0/0 0/0 24 40 1/10
    af21 0/0 0/0 0/0 32 40 1/10
    af22 0/0 0/0 0/0 28 40 1/10
    af23 0/0 0/0 0/0 24 40 1/10
    af31 494/741000 190/285000 270/405000 10 20 1/10
    af32 0/0 0/0 0/0 28 40 1/10
    af33 0/0 0/0 0/0 24 40 1/10
    af41 0/0 0/0 0/0 32 40 1/10
    af42 0/0 0/0 0/0 28 40 1/10
    af43 0/0 0/0 0/0 24 40 1/10
    cs1 0/0 0/0 0/0 22 40 1/10
    cs2 0/0 0/0 0/0 24 40 1/10
    cs3 0/0 0/0 0/0 26 40 1/10
    cs4 0/0 0/0 0/0 28 40 1/10
    cs5 0/0 0/0 0/0 30 40 1/10
    cs6 0/0 0/0 0/0 32 40 1/10
    cs7 0/0 0/0 0/0 34 40 1/10
    ef 0/0 0/0 0/0 36 40 1/10
    rsvp 0/0 0/0 0/0 36 40 1/10
    default 0/0 0/0 0/0 30 40 1/10

    R1#sh traffic-shape que
    Traffic queued in shaping queue on Serial0/0
    Traffic shape class: class-default
    Queueing strategy: weighted fair
    Queueing Stats: 20/1000/64/399 (size/max total/threshold/drops)
    Conversations 1/1/16 (active/max active/max total)
    Reserved Conversations 1/1 (allocated/max allocated)
    Available Bandwidth 16 kilobits/sec

    (depth/weight/total drops/no-buffer drops/random/tail/interleaves) 20/86/399/0/0/0/0
    Conversation 25, linktype: ip, length: 1500
    source: 10.1.1.10, destination: 10.0.12.2, id: 0x8FE7, ttl: 127,
    TOS: 104 prot: 17, source port 21112, destination port 1000

    I have AF31 configured to use full drop after 20 packets are in the queue, and both outputs show 20 packets in the queue all the time.

    If I stop marking the traffic, WRED now shows only dscp 0 traffic being matched and the queue fills up to 40 which is the max I set for dscp 0:

    R1:
    no set ip dscp af31

    R1#sh policy-map int
    Serial0/0

    Service-policy output: shaper

    Class-map: class-default (match-any)
    855 packets, 1282500 bytes
    30 second offered rate 185000 bps, drop rate 129000 bps
    Match: any
    Traffic Shaping
    Target/Average Byte Sustain Excess Interval Increment
    Rate Limit bits/int bits/int (ms) (bytes)
    64000/64000 2000 8000 8000 125 1000

    Adapt Queue Packets Bytes Packets Bytes Shaping
    Active Depth Delayed Delayed Active
    – 40 293 439500 293 439500 yes

    Service-policy : test

    Class-map: class1 (match-all)
    855 packets, 1282500 bytes
    30 second offered rate 185000 bps, drop rate 129000 bps
    Match: any
    Queueing
    Output Queue: Conversation 25
    Bandwidth 75 (%)
    Bandwidth 48 (kbps)
    (pkts matched/bytes matched) 854/1281000
    (depth/total drops/no-buffer drops) 40/596/0
    exponential weight: 9
    mean queue depth: 48

    dscp Transmitted Random drop Tail drop Minimum Maximum Mark
    pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
    af11 0/0 0/0 0/0 32 40 1/10
    af12 0/0 0/0 0/0 28 40 1/10
    af13 0/0 0/0 0/0 24 40 1/10
    af21 0/0 0/0 0/0 32 40 1/10
    af22 0/0 0/0 0/0 28 40 1/10
    af23 0/0 0/0 0/0 24 40 1/10
    af31 0/0 0/0 0/0 10 20 1/10
    af32 0/0 0/0 0/0 28 40 1/10
    af33 0/0 0/0 0/0 24 40 1/10
    af41 0/0 0/0 0/0 32 40 1/10
    af42 0/0 0/0 0/0 28 40 1/10
    af43 0/0 0/0 0/0 24 40 1/10
    cs1 0/0 0/0 0/0 22 40 1/10
    cs2 0/0 0/0 0/0 24 40 1/10
    cs3 0/0 0/0 0/0 26 40 1/10
    cs4 0/0 0/0 0/0 28 40 1/10
    cs5 0/0 0/0 0/0 30 40 1/10
    cs6 0/0 0/0 0/0 32 40 1/10
    cs7 0/0 0/0 0/0 34 40 1/10
    ef 0/0 0/0 0/0 36 40 1/10
    rsvp 0/0 0/0 0/0 36 40 1/10
    default 258/387000 20/30000 576/864000 30 40 1/10

    R1#sh traff que
    Traffic queued in shaping queue on Serial0/0
    Traffic shape class: class-default
    Queueing strategy: weighted fair
    Queueing Stats: 40/1000/64/674 (size/max total/threshold/drops)
    Conversations 1/1/16 (active/max active/max total)
    Reserved Conversations 1/1 (allocated/max allocated)
    Available Bandwidth 16 kilobits/sec

    (depth/weight/total drops/no-buffer drops/random/tail/interleaves) 40/86/674/0/28/646/0
    Conversation 25, linktype: ip, length: 1500
    source: 10.1.1.10, destination: 10.0.12.2, id: 0x824E, ttl: 127,
    TOS: 0 prot: 17, source port 21112, destination port 1000

    I’m not sure exactly what cisco’s definition of ‘common classification’ that it talks about in the link is. If they are referring only to when it is classified into a specific class map, then I suppose it makes sense. With policing it is classified into a specific class at the beginning and the policing takes place based on what it was marked as when it was classified. But, class-based policing doesn’t have it’s own method of classifying traffic – it polices all traffic that was put into that class in the first place regardless of what value it was marked as. Class-based WRED has to look at the marking in 2 different places, first when it decides which class it is a part of and then again when it decides whether to drop it or queue it. For example you could have af31, af32, and af33 all put into the same class, and with policing they are all policed together because there is no other classification done by the policer itself, only by the class map. With CBWRED you could put af31, af32, and af33 into the same class and then have separate thresholds configured for each of them so CBWRED has to classify it again once it is in the class map. So I guess it makes sense if you think of it in that way and if cisco’s definition of ‘common classification’ only means classifying it into the class-map. The only other QoS tool I can think of that needs to classify again after the class-map classification is WFQ since it assigns weights based on IP precedence value and uses them to assign sequence numbers, and WFQ also is able to react to them, i.e. if you set IP precedence in the output policy, WFQ will queue them with the weight value of the new precedence value.

  3. Joyce said

    Hi Andy,

    Thank you very much for running the test for me so we have the same result. So it seems for a CBWFQ configuration with enabling WRED in one or more of the classes within the policy-map, our result shows WRED within that class is based on the “new” dscp value which is contradict from Cisco link about that section of “mark and apply QoS action in the same policy”.

    However, you are providing some explanation in the last paragraph of your response but I don’t really understand all the terminology of them. For example, I am not sure when you referred to “policing” vs “class-based policing” of what their difference are. Or when you referred to “classify again once it’s in the class map”. I mean we classify traffic via class-map via match access-group or match dscp or match protocol..etc. So that FIRST step of QoS will use the “original” value of dscp when it comes into the router from LAN as an example of match dscp xxxx when under class-map configuration. We are still use the same assumption that we only have 1 policy in this router and it’s applied on WAN interface outbound. So once the traffic are classified into the associated classes (so far this is just classification, we are not doing “marking” yet). Now under policy-map and under class xxxx, this is when we do “marking” of all the packets that belong to that class. So whatever the original dscp value maybe, it will get re-mark to AF31 in our example. Those traffic stays in that class no matter what dscp it has originally once it’s being considered belonging to this class and it stays in this class no matter what we re-mark this traffic to be. This traffic doesn’t really get “re-classify” to something else. So I am still somewhat confused to what cisco mean in their link.

    I tried to re-read your message again, I assume when you said “class-based policing doesn’t have its own method of classifying traffic- it policies all traffic that was put into that class in the first place regardless of what value it was marked as”. I am assuming you mean you are doing policy-map shaper where you put “all” traffic to do shape average 64000, then apply the child policy test1 in it. So then under the Parent policy, then for sure all traffic will get shaped at 64kbps regardless its value”. But then we don’t always need to do Parent and child policy when we do CBWFQ. Most of the time, I just have one policy (no parent/child). So in my example in the initial message, all traffic doesn’t have pre-marking, they come in to the router, then First Step, they are being classified into the Class High_priority, scavenger, default based on ACLs match. So Second step now all the Telnet traffic are now in High_priority are being “re-mark” to AF31. This class has Bandwidth 50% for it. And now we have WRED in this class. So in this Second step, the router is policing traffic to stay around 50% if there are congestion only. At the same time, WRED is enabled within this class, so all the Telnet packets should queue and do random drop/tail drop based on dscp 0 or dscp Af31? From our result, the telnet packets are being queued based on AF31 new value.

    Even if we do a totally different scenario:

    class-map match-any high_priority
    match dscp af31
    match dscp af32
    match dscp af33

    policy-map test2
    class high_priority
    random-detect dscp-based
    random-detect dscp 26 32 64 10
    random-detect dscp 28 30 40 10
    random-detect dscp 30 10 20 10
    bandwidth remaining percent 60
    class class-default
    bandwidth remaining percent 40
    random-detect dscp-based

    So in this example, our high_priority class within the policy map that we did not “re-mark” any dscp value from what it comes from LAN. This example we assume there are already all the correct marking dscp in the LAN already, so we just create a class map to match all the AF3x traffic into same class called high_priority. And then within this class, we honor the original dscp value and won’t re-mark them and we just set different min/max threshold drop probability to differentiate AF31, 32 and 33. But still, we are not really re-classify the traffic as all these traffic still belong to the same high_priority class.

    I value a lot on all your QoS-related posts and read them all :) I really appreciate your help to further clarify these doubts on the cisco link :)

    thanks,
    joyce

  4. Andy said

    Class-based policing just means doing policing within a policy-map, for example

    policy-map test
    class class1
    police 128000

    would be a class-based policer.

    What I meant by class-based policing not needing it’s own method of classification is that if you had a configuration like this:

    class-map match-all class1
    match ip dscp af31 af32 af33
    !
    policy-map test
    class class1
    police 128000

    the policer itself has no need to do any classification because it operates on all traffic within that class. So the only classification is done by the class-map, which puts af31, af32, and af33 into class1 and then the policer polices all of them combined.

    If you had a class-based WRED configuration like this:

    class-map match-all class1
    match ip dscp af31 af32 af33
    !
    policy-map test
    class class1
    bandwidth 50
    random-detect dscp-based
    random-detect dscp 26 20 50 10
    random-detect dscp 28 30 50 10
    random-detect dscp 30 40 50 10

    class-based WRED has to have it’s own method of classification, because it has different thresholds for different DSCP values within that class. It operates differently on each of the different DSCP values that end up in the class so just classifying it into ‘class1’ by the class-map classification isn’t enough with WRED.

    So I guess to put it simply class-based policing can’t treat traffic within a class differently, but class-based WRED can. That is why I think, based on the test that we both did, that class-based WRED performs it’s own classification and that it occurs after any remarking on the packet. The remarking won’t cause it to change classes because the class-map classification has already been done, but it will cause WRED to use the new DSCP value when it does it’s own classification. Cisco’s information on it isn’t very good so I am just trying to think through logically why it works this way. Hope that makes sense.

  5. Joyce said

    Andy,

    Thanks again and it’s very clear between the two types and totally agree with you.

    The Class-based WRED 2nd example, however, does not really have any “re-mark” “set” command, so pretty much we are just use the original value and then doing WRED based on original value since we are not re-marking any of those packets to any new value. So it doesn’t demonstrate the troubling concept in that Cisco URL of what they said. The URL actually has an example at the very bottom to show if we are doing shaping, the packets get “Match” with the original value instead of the new value. So I haven’t tried to run a lab test to expand that scenario little better to see the result.

    The funny thing is I opened a cisco tac case about something else and then at the end I asked about whether WRED within a class will use original or new value and that’s when I was pointed to that URL and the answer from Cisco is “original” value. So that I was puzzled as our output clearly showed the packets showed up in the “new” value row, and I asked them and I never get an answer back so far :)

    The strange thing I saw was the same scenario when I have no pre-marking and I match some traffic to a class to remark to AF31. The class map was just based on access-group. After running like few days, my output shows 99.9% of packets goes to AF31 under show policy-map int command but there is about 0.1% packets shows at “default” in that same class (not the Default class), I mean within the High_Priority class where I set AF31 and Enable WRED, the show policy-map int will show a display with all the dscp and 0.1% show up in default within that class. I asked finally they said it’s “junk” bug and it’s junk status so no plan to do anything about it. I was running 12.4.15T8 on ISR router.

    What I really noticed was that in my High_priority ACL, I have some SQL, SAP…and Telnet. And when I cleared the counter and I guess telnet few times to the router with multiple session, I saw there was like 1000+ packets at AF31, and just 5 packets at default in that class. Then when i do “show access-list high_priority”, I saw exactly 5 matches on the Telnet row…hm…so telnet traffic even though it’s being matched in the ACL, somehow they didn’t get “remark” to AF31…interesting…anyway, cisco just said “junk” and closed my case. HAHA

    Joyce

  6. Joyce said

    Hi Andy,

    On that same Cisco tac case, I have also asked a question to see if that makes sense to you.

    On WRED where you can adjust the min and max threshold. Default queue size is 64 packets. Let’s say if we want to change AF31 min to 100 and max to 200 as an example, so we will do:

    random-detect dscp af31 100 200 10

    this will show up under “show policy-map int s0” and I will see it change to 100 min and 200 max. So in “theory”, within that class for traffic that is AF31, I should expect I only starts random drop after reaching 100 packets and only starts tail drop after reaching 200. But Cisco said no, they said the queue size is 64 so it will start tail drop when it reach 64 even we change our min and max threshold. So apparently when we are running anything lower than 12.4.20T IOS, it is useless to enable WRED for anything exceeding 64. However Cisco said starting 12.4.20T, we can now change the Queue size + enable WRED “at the same time”. Previously, if you do “queue-limit 200” and then enable WRED, the queue-limit command will auto removed and vice versa. Pretty much queue-limit and WRED cannot co-exist in older IOS. But in 12.4.20T, Cisco said they can co-exist so now we can do Queue-limit 200 and also do random detect dscp af31 100 200 10 and it will do what we intend to do.

    Now the above was after 2+ months of back and forth emails with Cisco and they have been giving been conflicting answers so I am just not sure if I can trust 100% of it. My question is I run 12.4.15T8 and how can we “test” in a simulated case to see if the above is true in the sense that I want to know if we set random-detect dscp af31 100 200 10, is it really I start “tail drop” at 64 or do I really start tail drop at 200? Do you think you have any way to monitor the “dropping” to see if this is true or not?

    You are the expert to simulate the difference scenario so wonder if you have any idea?

    thanks a lot,
    Joyce

  7. Andy said

    Joyce,

    I think what Cisco told you about the queue size always being limited to 64 with WRED is wrong. Like you, I also have noticed before that configuring ‘queue-limit’ or ‘random-detect’ on a class causes the other one to be removed. Here’s a link to the 12.4 command reference for the random-detect command:

    http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_q1.html#wp1037276

    part way through the description it says:

    “WRED in a Policy Map

    You can configure WRED as part of the policy map for a standard class or the default class. The WRED random-detect command and the weighted fair queueing (WFQ) queue-limit command are mutually exclusive. If you configure WRED, its packet drop capability is used to manage the queue when packets exceeding the configured maximum count are enqueued. If you configure the WFQ queue-limit command, tail drop is used.”

    This makes it sound like if WRED is configured on the class, only the WRED thresholds are used for determining if a packet should be dropped and the default queue-limit of 64 does not matter. The results of testing it out also support this.

    policy-map test
    class class-default
    bandwidth 50
    !
    policy-map shaper
    class class-default
    shape average 64000
    service-policy test
    !
    interface Serial0/0
    ip address 10.0.12.1 255.255.255.0
    load-interval 30
    service-policy output shaper

    This is without WRED configured and default queue-limit of 64. As expected the queue fills up to 64 and starts tail dropping:

    R1#sh policy-map int
    Serial0/0

    Service-policy output: shaper

    Class-map: class-default (match-any)
    485 packets, 727500 bytes
    30 second offered rate 186000 bps, drop rate 122000 bps
    Match: any
    Traffic Shaping
    Target/Average Byte Sustain Excess Interval Increment
    Rate Limit bits/int bits/int (ms) (bytes)
    64000/64000 2000 8000 8000 125 1000

    Adapt Queue Packets Bytes Packets Bytes Shaping
    Active Depth Delayed Delayed Active
    – 64 168 252000 168 252000 yes

    Service-policy : test

    Class-map: class-default (match-any)
    485 packets, 727500 bytes
    30 second offered rate 186000 bps, drop rate 122000 bps
    Match: any
    Queueing
    Output Queue: Conversation 25
    Bandwidth 50 (kbps)Max Threshold 64 (packets)
    (pkts matched/bytes matched) 485/727500
    (depth/total drops/no-buffer drops) 64/317/0

    R1#sh traf q
    Traffic queued in shaping queue on Serial0/0
    Traffic shape class: class-default
    Queueing strategy: weighted fair
    Queueing Stats: 64/1000/64/375 (size/max total/threshold/drops)
    Conversations 1/1/16 (active/max active/max total)
    Reserved Conversations 1/1 (allocated/max allocated)
    Available Bandwidth 14 kilobits/sec

    (depth/weight/total drops/no-buffer drops/interleaves) 64/82/375/0/0
    Conversation 25, linktype: ip, length: 1500
    source: 10.1.1.10, destination: 10.0.12.2, id: 0xCC03, ttl: 127,
    TOS: 0 prot: 17, source port 3060, destination port 1000

    Next is with WRED configured with a min threshold of 100 and max of 200. The queue fills up to 200 packets:

    policy-map test
    class class-default
    bandwidth 50
    random-detect dscp-based
    random-detect dscp 0 100 200
    !
    policy-map shaper
    class class-default
    shape average 64000
    service-policy test
    !
    interface Serial0/0
    ip address 10.0.12.1 255.255.255.0
    load-interval 30
    service-policy output shaper

    R1#sh policy-map int
    Serial0/0

    Service-policy output: shaper

    Class-map: class-default (match-any)
    3434 packets, 5151000 bytes
    30 second offered rate 186000 bps, drop rate 122000 bps
    Match: any
    Traffic Shaping
    Target/Average Byte Sustain Excess Interval Increment
    Rate Limit bits/int bits/int (ms) (bytes)
    64000/64000 2000 8000 8000 125 1000

    Adapt Queue Packets Bytes Packets Bytes Shaping
    Active Depth Delayed Delayed Active
    – 201 1202 1803000 1202 1803000 yes

    Service-policy : test

    Class-map: class-default (match-any)
    3434 packets, 5151000 bytes
    30 second offered rate 186000 bps, drop rate 122000 bps
    Match: any
    Queueing
    Output Queue: Conversation 25
    Bandwidth 50 (kbps)
    (pkts matched/bytes matched) 3434/5151000
    (depth/total drops/no-buffer drops) 201/2225/0
    exponential weight: 9
    mean queue depth: 201

    dscp Transmitted Random drop Tail drop Minimum Maximum Mark
    pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
    af11 0/0 0/0 0/0 32 40 1/10
    af12 0/0 0/0 0/0 28 40 1/10
    af13 0/0 0/0 0/0 24 40 1/10
    af21 0/0 0/0 0/0 32 40 1/10
    af22 0/0 0/0 0/0 28 40 1/10
    af23 0/0 0/0 0/0 24 40 1/10
    af31 0/0 0/0 0/0 32 40 1/10
    af32 0/0 0/0 0/0 28 40 1/10
    af33 0/0 0/0 0/0 24 40 1/10
    af41 0/0 0/0 0/0 32 40 1/10
    af42 0/0 0/0 0/0 28 40 1/10
    af43 0/0 0/0 0/0 24 40 1/10
    cs1 0/0 0/0 0/0 22 40 1/10
    cs2 0/0 0/0 0/0 24 40 1/10
    cs3 0/0 0/0 0/0 26 40 1/10
    cs4 0/0 0/0 0/0 28 40 1/10
    cs5 0/0 0/0 0/0 30 40 1/10
    cs6 0/0 0/0 0/0 32 40 1/10
    cs7 0/0 0/0 0/0 34 40 1/10
    ef 0/0 0/0 0/0 36 40 1/10
    rsvp 0/0 0/0 0/0 36 40 1/10
    default 1209/1813500 281/421500 1944/2916000 100 200 1/10

    R1#sh traf q
    Traffic queued in shaping queue on Serial0/0
    Traffic shape class: class-default
    Queueing strategy: weighted fair
    Queueing Stats: 201/1000/64/2416 (size/max total/threshold/drops)
    Conversations 1/1/16 (active/max active/max total)
    Reserved Conversations 1/1 (allocated/max allocated)
    Available Bandwidth 14 kilobits/sec

    (depth/weight/total drops/no-buffer drops/random/tail/interleaves) 201/82/2416/0/289/2127/0
    Conversation 25, linktype: ip, length: 1500
    source: 10.1.1.10, destination: 10.0.12.2, id: 0x9052, ttl: 127,
    TOS: 0 prot: 17, source port 3060, destination port 1000

  8. Joyce said

    Andy,

    You are the QoS King!!! Thanks for your test result as that clearly shows I am once again got an wrong answer from Cisco one after another :)

    Nothing better than seeing the actual proof from the simulation!

    thanks again!!

    Joyce

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: