2821: incrementing packets issues within class-map

Unanswered Question
Apr 27th, 2010
User Badges:

Hello There,


I got an issue with a cisco 2821 router using the IOS c2800nm-spservicesk9-mz.124-15.T7.bin.


I sent several pings at the same time with MTU 1500 and TOS 72 with for destination a remote LAN, hoping to see this traffic in my class-map:


Class-map: ADVANCED (match-any)
          7 packets, 474 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip dscp af21 (18)
            7 packets, 474 bytes
            5 minute rate 0 bps
          Match: ip dscp af22 (20)
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: ip dscp af23 (22)
            0 packets, 0 bytes
            5 minute rate 0 bps
          Queueing
            Output Queue: Conversation 137
            Bandwidth 900 (kbps)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
             exponential weight: 9
             mean queue depth: 0


   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       7/474             0/0              0/0           32      40  1/10


Type of pings sent:


p
Protocol [ip]:
Target IP address: X.X.X.X
Repeat count [5]: 260000000
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: GigabitEthernet0/0 ---> That s my LAN interface
Type of service [0]: 72


ce152a-uk-kohler-000-INPNQ#p
Protocol [ip]:
Target IP address: X.X.X.X
Repeat count [5]: 2147483647
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: GigabitEthernet0/0
Type of service [0]: 72


ce152a-uk-kohler-000-INPNQ#p
Protocol [ip]:
Target IP address: 10.50.0.2
Repeat count [5]: X.X.X.X
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: GigabitEthernet0/0
Type of service [0]: 72



The live traffic seems not appearing under the class-map. I looked at IOS bug, but cannot find anything related to this type of issue. Any help, suggestion are more than welcome.


I am thinking uploading the IOS version c2800nm-adventerprisek9-mz.124-16a.bin to see if there is still this issue.


Thanks


Mel

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
melaniemaillet Tue, 04/27/2010 - 05:43
User Badges:

Hi Krisztian,


policy-map CLASSIFY-LEGACY
class ADVANCED-CLASSIFY
  set ip dscp af21
class CRITICAL-CLASSIFY
  set ip dscp af31
class class-default
  set ip dscp af11




policy-map CE-LEGACY-WAN-OUT
class ADVANCED
  bandwidth 900
  random-detect dscp-based
   police cir 900000
     conform-action set-dscp-transmit af21
     exceed-action set-dscp-transmit af23
class CRITICAL
  bandwidth 900
  random-detect dscp-based
   police cir 900000
     conform-action set-dscp-transmit af31
     exceed-action set-dscp-transmit af33
class MANAGEMENT
  bandwidth 64
  set ip dscp cs5
class ROUTING
  bandwidth 64
  set ip dscp cs6
class class-default
  bandwidth 3952
  random-detect dscp-based
  set ip dscp default


policy-map SHAPE-CE-WAN-OUT
class class-default
  shape average 6000000
  service-policy CE-LEGACY-WAN-OUT


interface GigabitEthernet0/0

service-policy input CLASSIFY-LEGACY


interface GigabitEthernet0/1

max-reserved-bandwidth 98
service-policy output SHAPE-CE-WAN-OUT




Thanks

Mel

melaniemaillet Tue, 04/27/2010 - 05:49
User Badges:

oops sorry


class-map match-any CRITICAL
match ip dscp af31
match ip dscp af32
match ip dscp af33
match ip dscp cs3
class-map match-any MANAGEMENT
match ip dscp cs5
match access-group name MANAGEMENT-CLASSIFY
class-map match-any ADVANCED
match ip dscp af21
match ip dscp af22
match ip dscp af23
class-map match-any ADVANCED-CLASSIFY
match access-group name ADVANCED-CLASSIFY
match ip dscp af23
match ip dscp af22
match ip dscp af21
class-map match-any CRITICAL-CLASSIFY
match access-group name CRITICAL-CLASSIFY
match protocol citrix
class-map match-any ROUTING
match ip dscp cs6
match access-group name ROUTING-CLASSIFY
!

Hi Mel,


Config looks OK.

Can you check the following:


1. show policy-map inteface gig 0/1


paste the output


2. do the ping test


3. paste the same command output.


We should see the difference between the first and second.


Concerning the real traffic:

1. Are the acls are correctly covering the traffic to be matched?

2. If the classification is to be done based on existing marking are you sure the traffic comes with correct marking?


Hope it helps,

Krisztian

melaniemaillet Thu, 04/29/2010 - 09:09
User Badges:

Hi Krisztian,


Yeah I did these tests at the fisrt time and basically  the amount of packets change in the interface as we will hope but unfortunately under the policy map the amount of packet is not changing as fast as on the interface...:'(


I will get the IOS change just in case.


Thanks for your help

Mel

Edison Ortiz Wed, 04/28/2010 - 07:51
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

You are sending the wrong TOS values in your ping


TOS 72  in binary is 1110010 which is DSCP 28


If you want to send for AF21 (010010) you must use TOS 48, AF22 (010100) TOS 50 and AF23 (010110) TOS 58


Regards


Edison

Edison Ortiz Wed, 04/28/2010 - 12:50
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Hi Krisztian,


I did the same and you are right, 72 matches DSCP AF21 but my calculator says different.


72 is a hex value which converts to the binary value I posted.

I even double check on a web calculator such as this one:


http://www.easycalculation.com/hex-converter.php


BTW, as you noted, my binary conversion for AF21 was the same as yours, we differ on the TOS 72.

Edison Ortiz Wed, 04/28/2010 - 12:55
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

I see the confusion.


The router is taking the TOS value as decimal, not Hex.

I'm used to pinging with Hex value, specially 0xB8 for DSCP 46.


Disregard my previous post about using the wrong TOS, the router will take the TOS without 0x as decimal and performs the binary conversion from decimal to binary. I was doing hex to binary.


By the way, here is a pinging with Hex 48


Rack1SW1#ping
Protocol [ip]:
Target IP address: 10.12.1.1
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 0x48
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.12.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/17 ms
Rack1SW1#
Rack7Pod1>1
[Resuming connection 1 to r1 ... ]


Rack1R1#sh policy-map interface
FastEthernet0/0


  Service-policy input: QOS


    Class-map: AF21 (match-all)
      105 packets, 11970 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  dscp af21 (18)
      police:
          cir 2000000 bps, bc 62500 bytes
        conformed 105 packets, 11970 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps


    Class-map: class-default (match-any)
      263 packets, 23662 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
Rack1R1#

Actions

This Discussion