Counter not incrementing

  • 0
  • 1
  • Question
  • Updated 3 years ago
  • Answered
Hi everybody
I am new to QOS on Extreme platform. I will appreciate if you help me understand why the counters are not incrementing :


TRAFFIC_GENERATOR---P6- EXSW-P2--ACCEDIAN LOOPBACK.


Above , traffic generator is generating three streams :
DSCP 0
DSCP 8
DSCP 32


Upon entry on P6, they are first policed , counted, and placed in proper queue  on egress on port 2:

DSCP0-->QP1
DSCP8--> QP2
DSCP32->QP5

######################################
Vi SNID4.pol
entry AGGEGATE_METER { 
if  { 

}
then {
    meter AGGREGATE ;
    count AGGREGATE ;    
}


entry REALTIME_DSCP_32 { 
if match any { 
dscp 32 ;
}
then {
    meter METER_REALTIME_QP5_SNID ;
    qosprofile QP5 ;
    count REALTIME ;
}




entry MED_DSCP_8 { 
if match any { 
dscp 8 ;
}
then {
    meter METER_MED_QP2_SNID ;
    qosprofile QP2 ;
    count MED ;
}
}


entry STD_DSCP_REST { 
if match any { 

}
then {
    meter METER_STD_QP1_SNID ;
    qosprofile QP1 ;
    count STD ;
}
}

##############################


 X450a-24t.70 # enable diffserv examination ports 6
* X450a-24t.71 # disable dot1p examination ports 6

I can see traffic are placed in right queue on egress on port 2:


* X450a-24t.72 # show port 2 qosmonitorQos Monitor Req Summary                          Sat May 30 04:19:41 2015
Port   QP1      QP2      QP3      QP4      QP5      QP6      QP7      QP8
       Pkt      Pkt      Pkt      Pkt      Pkt      Pkt      Pkt      Pkt
       Xmts     Xmts     Xmts     Xmts     Xmts     Xmts     Xmts     Xmts
===============================================================================
2      20327590 27064071 0        0        26423347 0        0        36


ISSUE:

I do not see the counters are incrementing when the traffic enters port 6:


* X450a-24t.74 # show access-list counter ports 6

Policy Name       Vlan Name        Port   Direction
    Counter Name                   Packet Count         Byte Count
==================================================================
SNID4             *                6      ingress
    AGGREGATE                      38081875
    MED                            0
    REALTIME                       0
    STD                            0



Have a great weekend!!
Photo of zeeshan qadir

zeeshan qadir

  • 266 Points 250 badge 2x thumb

Posted 3 years ago

  • 0
  • 1
Photo of Andrew Maldonado

Andrew Maldonado, Extreme Alumnus

  • 2,302 Points 2k badge 2x thumb
Zeeshan,

The first entry within the policy does not appear to display a match condition. With no match condition specified all traffic will match on the first entry. To test the other counters the first entry can be either commented out using a "#" in front of each line of the first entry or moved to the bottom of the policy.

-Andrew
Photo of zeeshan qadir

zeeshan qadir

  • 266 Points 250 badge 2x thumb
Hi Andrew

I am sorry i did not get it when you said:

"To test the other counters the first entry can be either commented out using a "#" in front of each line of the first entry"



could you please illustrate this ? For example, how would you write the first rule with #" as you suggested above.

Vi SNID4.pol
entry AGGEGATE_METER { 
if  { 

}
then {
    meter AGGREGATE ;
    count AGGREGATE ;    
}



thanks
Photo of OscarK

OscarK, ESE

  • 7,702 Points 5k badge 2x thumb
An ACL needs to be written in a certain order. If a packet matches an if statemeent the ACL will not continue and stop processing other rules. So you have to put the most specific rules on top and the catch-all (empty if) on the bottom. As you have put a catch-all rule as first the other rules will never apply to a packet. In fact you have 2 catch-all rules which does not make sense.

The correct order should be something like below (I removed the first catch-all).

Vi SNID4.polentry REALTIME_DSCP_32 { 
if match any { 
dscp 32 ;
}
then {
    meter METER_REALTIME_QP5_SNID ;
    qosprofile QP5 ;
    count REALTIME ;
}

entry MED_DSCP_8 { 
if match any { 
dscp 8 ;
}
then {
    meter METER_MED_QP2_SNID ;
    qosprofile QP2 ;
    count MED ;
}
}
entry STD_DSCP_REST { 
if match any { 
}
then {
    meter METER_STD_QP1_SNID ;
    qosprofile QP1 ;
    count STD ;
}
}
Photo of zeeshan qadir

zeeshan qadir

  • 266 Points 250 badge 2x thumb
Thanks Koot.

This is my thought process:

All traffic entering must be subject to aggregate meter. All offending traffic will be dropped, all conforming is then classified and subject to their respective meter.

I can see all my traffic are classified correctly and are placed in correct queues which indeed corroborates the Concept guide.

Concept guide says following:


Rule EvaluationWhen there are multiple rule entries applied to an interface, evaluation proceeds as follows:
• A packet is compared to all the rule entry match conditions at the same time.


For each rule where the packet matches all the match conditions, the action and any actionmodifiers in the then statement are taken. If there are any actions or action modifiers that conflict
(deny vs. permit, etc), only the one with higher precedence is taken.
• If a packet matches no rule entries in the ACL, it is permitted

##################################################

Much appreciated!!
Photo of OscarK

OscarK, ESE

  • 7,702 Points 5k badge 2x thumb
I think this can be explained in a few ways but from my point of view this is not how an ACL is evaluated. When an rule is hit that action is executed. I would suggest changing the ACL to have the most specific rules on the top and the catch-all rules on the end.