Odd behavior with CBWFQ QOS Configuration

[charter]

I've got an odd issue with a QOS configuration.  I currently have a ticket open with Cisco on the issue but haven't gotten anywhere with it.  I was hoping someone has seen the same issue.  Here's the deal....

At our main corporate site, we have a T3 into AT&T's private IP network.  It's not Frame-Relay, just point-to-point connectivity.  At our remote locations, we have mostly T-1's and some bonded T-1's.  We need to shape the traffic outbound from our main site to match the egress port speed to these locations.  We also need to mark it so that AT&T can apply the appropriate traffic prioritization.  Below is our configuration, albeit, simplified to 3 total locations to make the point.  So we have 3 locations, the main location that has a T3, one location that has a T-1, and one location that has 2 T-1's bonded together to form a 3Mbps pipe.  The below configuration is on our main WAN router where the T-3 is located.  What is happening is that when I apply the service policy outbound to the T3 interface at our main site, the first class in the service policy matches ALL of the traffic.  The class is defined by an access-list and I have verified that the Access-List is correct and is only suppossed to match traffic to the defined networks.  I have tried moving a class up in the service-policy and the problem remains, it just switches to whatever the first class is.  For some reason the ACL is not working correctly.  So when the policy below named OUTBOUND_COS is applied to my outgoing interface at our main site, every single packet gets matched in the match_location1 class, even packets that do not match that object-group.  Note that I am using object-group's to make my access-lists smaller.  This causes all of the traffic outbound on the interface to be shaped to 1 T-1 which is not good.  Has anyone seen this before?

policy-map OUTBOUND_COS

  class match_location1

     shape average 1526000

    service-policy mark_location1

  class match_location2

     shape average 3072000

    service-policy mark_location2

class-map match-all match_location1

  match access-group name match_location1

class-map match-all match_location2

  match access-group name match_location2

policy-map mark_location1

  class location1_gold

    set ip dscp af31

  class location1_silver

    set ip dscp af21

  class class-default

policy-map mark_location2

  class location2_gold

     set ip dscp af31

  class location2_silver

     set ip dscp af21

  class class-default

class-map match-all location1_gold

  match access-group name location1_gold

class-map match all location1_silver

  match access-group name location1_silver

class-map match-all location2_gold

  match access-group name location2_gold

class-map match-all location2_silver

  match access-group name location2_silver

object-group network location1

172.16.1.0 255.255.255.0

172.16.2.0 255.255.255.0

object-group network location2

  172.16.3.0 255.255.255.0

  172.16.4.0 255.255.255.0

ip access-list extended match_location1

  permit ip any object-group location1

ip access-list extended match_location2

  permit ip any object-group location2

ip access-list extended location1_gold

  permit tcp any eq 1494 object-group location1

ip access-list extended location1_silver

  permit tcp any range 3200-3399 object-group location1

ip access-list extended location2_gold

  permit tcp any eq 1494 object-group location2

ip access-list extended location2_silver

  permit tcp any range 3200 3399 object-group location2

[Peter Paluch]

Hello,

It is possible that the object groups are not supported for this type of usage. If you try to modify your configuration so that no object groups are used, only plain extended ACLs, would the QoS configuration then work correctly?

Also please what exact device are you using, and what IOS version?

Thank you!

Best regards,

Peter

[charter]

I have tried using plain text ACL's as well to no avail.  This is on a Cisco 7200VXR.  Version is 12.4-24.T2

[Peter Paluch]

Hello,

I've just found something.

class-map match-all match_location1

  match access-group name match_location1

class-map match-all match_location2

  match access-group name match_location2

The highlighted names should refer to ACL names - but such ACLs do not exist at all. These are names of the classes themselves. Now, referencing a non-existent ACL on IOS usually means a "permit any" action. This may be why your QoS policy is not working. Correctly, you should be using the ACL names mark_location1 and mark_location2 - isn't that so?

Try correcting your class definitions in this sense.

In general, it is not recommended to have the same class names as ACLs etc. because it is then confusing to a casual reader what does the name refer to - an ACL, class name, object name, policy-map name etc. At least, I suggest prefixing the names with a non-ambiguous discriminator of the type, say,

• acl_... for ACLs
• cm_... for class-maps
• pm_... for policy-maps

etc.

Best regards,

Peter

[charter]

Peter,

It was a typo in my  example.  I went back and looked at my original configuration and verfied that I indeed was pointing to an ACL that exists and that is the case.  Unfortunately my problem still remains.

I have wondered if having my class-map and acl named the same is causing problems.  I know it's probably not best practice but it does make it easier when you have lots of class-map statements and trying to keep track of the ACL's that go with them.

Thanks for the reply.  I may test in my lab with different ACL names to see if that makes a difference.

Thanks,

Chad

[Peter Paluch]

Hello Chad,

I see. My suggestion: try, at least for now, creating numbered ACLs instead of named ACLs, and perhaps try it with and without referencing object groups.

With the numbered ACLs, I am seeking a particular point: perhaps there is a problem with that IOS when referring to ACLs, especially to ACLs with longer names. Using numbered ACLs should prevent that problem from occuring - if that is what's really happening.

Best regards,

Peter

[Marwan ALshawi]

Can you try to specify a source ip in your acl rather than any

Also use numbered acl instead of named ( not object )

Sent from Cisco Technical Support iPhone App

[charter]

I guess that I could but my access lists will be HUGE.  The whole point of object-groups is to make the ACL's more manageable so not using them would make it pretty tough.

[charter]

Why would it matter if I'm using any as the source?  It should be matching on destination regardless of the source.

[Peter Paluch · Accepted solution]

Chad,

Personally, I do not object against using the any in your ACLs. However, bypassing the object groups, at least for a while, is probably inevitable, considering the fact that numbered ACLs do not support object group references.

Alternatively, try for now using unique but short ACL names (see the rationale in my previous post).

Best regards,

Peter

[Marwan ALshawi]

hi

i know it dose not make sense if its any or specific source or numbered vs named

however because your router not behaving normally and it might be a big for testing you can try these and see if there is any difference

[Peter Paluch]

Hello Marwan,

Allright. I agree that the router is behaving curiously, and it may be anything subtle - either an ACL name, number or the entry format - that can make the policy work again. I guess Chad has now quite a large battery of tests to perform

Best regards,

Peter

[charter]

After working with Cisco this afternoon, we confirmed that the use of object-groups in the ACL being used to match the traffic for traffic-shaping is causing the issue.  Using a regular access-list exhibited the correct behavior.  Oddly enough, the nested service-policy we are using to mark and police the traffic is working correctly when using object-groups.  I'm going to make the appropriate changes and I'll report back with my findings.  Either way, it's a nice discovery and hopefully will help someone dealing with the same issue.