NBAR class-map not marking packets

Answered Question
Dec 4th, 2009
User Badges:

Hi,


I have a WAN QoS policy that includes a nested service-policy, which includes a class-map for marking routing protocol traffic using NBAR. I cannot see any hit's on it. Can anyone tell me what I am doing wrong?


The IOS version is 12.4(22)T3

IP CEF is on

I have put on, and taken off the ip nbar protocol-discovery command, with no effect


Thanks


!

class-map match-all RealTime
description class used for VoIP
match access-group name VOIP_acl

!
class-map match-any BurstyLo
description VoIP Call Signaling & Management
match ip dscp af21
match access-group name VOIPControl_acl

!
class-map match-any BurstyHi
description Multicast and other [UDP] approved applications
match access-group name IPWAN_MULTICAST_ACL
match access-group name VTC-Codecs_acl
match access-group name VOIPControl_acl

!
class-map match-any ROUTING-PROTOCOLS
description prepare to separate BGP & EIGRP in BurstyHi
match protocol bgp
match protocol eigrp

!
!
policy-map MARK-ROUTING-PROTOCOLS
description Keep dscp markings for BGP & EIGRP
class ROUTING-PROTOCOLS
  set ip dscp cs6

!
policy-map IPWAN-COS
description add RT priority bw when needed
class RealTime
  set ip dscp ef
    priority 702
class BurstyHi
    bandwidth remaining percent 40
  set ip dscp af31
  service-policy MARK-ROUTING-PROTOCOLS
class BurstyLo
  set ip dscp af21
class class-default
    bandwidth remaining percent 60
     random-detect
  set ip dscp default


**********************************************************


service-policy output IPWAN-COS is placed on the Multilink1 interface


**********************************************************


!

sh policy-map int
Multilink1


  Service-policy output: IPWAN-COS


    queue stats for all priority classes:
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 708270/37005226


    Class-map: RealTime (match-all)
      708270 packets, 36966650 bytes
      5 minute offered rate 3000 bps, drop rate 0 bps
      Match: access-group name VOIP_acl
      QoS Set
        dscp ef
          Packets marked 708270
      Priority: 702 kbps, burst bytes 17550, b/w exceed drops: 0


    Class-map: BurstyHi (match-any)
      1071 packets, 66928 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name IPWAN_MULTICAST_ACL
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group name VTC-Codecs_acl
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group name VOIPControl_acl
        1071 packets, 66928 bytes
        5 minute rate 0 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 1071/66930
      bandwidth remaining 40% (948 kbps)
      QoS Set
        dscp af31
          Packets marked 1071


      Service-policy : MARK-ROUTING-PROTOCOLS


        Class-map: ROUTING-PROTOCOLS (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol bgp
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: protocol eigrp
            0 packets, 0 bytes
            5 minute rate 0 bps
          QoS Set
            dscp cs6
              Packets marked 0


        Class-map: class-default (match-any)
          1071 packets, 66928 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any


    Class-map: BurstyLo (match-any)
      14 packets, 737 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af21 (18)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group name VOIPControl_acl
        14 packets, 737 bytes
        5 minute rate 0 bps
      QoS Set
        dscp af21
          Packets marked 14


    Class-map: class-default (match-any)
      3489665 packets, 1200723572 bytes
      5 minute offered rate 387000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/1593/0
      (pkts output/bytes output) 3532671/1264911756
      bandwidth remaining 60% (1422 kbps)
        Exp-weight-constant: 9 (1/512)
        Mean queue depth: 0 packets
        class     Transmitted       Random drop      Tail drop          Minimum        Maximum     Mark
                  pkts/bytes     pkts/bytes       pkts/bytes          thresh         thresh     prob
       
        0         3536339/1265646110   1593/1609605        0/0                 20            40  1/10
        1               0/0               0/0              0/0                 22            40  1/10
        2              18/944             0/0              0/0                 24            40  1/10
        3               0/0               0/0              0/0                 26            40  1/10
        4               0/0               0/0              0/0                 28            40  1/10
        5               0/0               0/0              0/0                 30            40  1/10
        6               0/0               0/0              0/0                 32            40  1/10
        7               0/0               0/0              0/0                 34            40  1/10
      QoS Set
        dscp default
          Packets marked 3489665

Correct Answer by Giuseppe Larosa about 7 years 3 months ago

Hello,

routing protocols like BGP and EIGRP have already their packets marked with CS6 = ip precedence 6 you can verify this with a packet capture.


what can be important on some platforms that miss the hidden system queue is to provide BW resources for routing protocols.


if you are using an ISR or other sw based routers they have an hidden system queue for routing protocols messages so your "user" classes cannot match these packets. The hidden queue is the reason behind the default settings of max-reserved-bandwidth 75% that allows to allocate 75% of BW (as per bandwidth command administrative parameter) to user traffic leaving 25% for the system queue.


Hope to help

Giuseppe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Giuseppe Larosa Fri, 12/04/2009 - 11:45
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello,

routing protocols like BGP and EIGRP have already their packets marked with CS6 = ip precedence 6 you can verify this with a packet capture.


what can be important on some platforms that miss the hidden system queue is to provide BW resources for routing protocols.


if you are using an ISR or other sw based routers they have an hidden system queue for routing protocols messages so your "user" classes cannot match these packets. The hidden queue is the reason behind the default settings of max-reserved-bandwidth 75% that allows to allocate 75% of BW (as per bandwidth command administrative parameter) to user traffic leaving 25% for the system queue.


Hope to help

Giuseppe

Edison Ortiz Fri, 12/04/2009 - 18:36
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

giuslar wrote:


if you are using an ISR or other sw based routers they have an hidden system queue for routing protocols messages so your "user" classes cannot match these packets. The hidden queue is the reason behind the default settings of max-reserved-bandwidth 75% that allows to allocate 75% of BW (as per bandwidth command administrative parameter) to user traffic leaving 25% for the system queue.


Hope to help

Giuseppe


Caveat, this behavior has changed with 20T and later


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

Actions

This Discussion