01-29-2013 01:21 PM - edited 03-07-2019 11:23 AM
we are trying to mark traffic close to the source, by applying the configuration on the switch, as included in the attachment.
Object of this config in the switch is to mark with specific dscp values, to be used in giving prioritization across the WAN.
Example: incoming packets of fas 0/1 are destinted for IP address 10.180.9.16. Based on our acl for APP1, under extended ACL Critical_Data, we should mark this with dscp af31. The router QoS is setup to prioritize this traffic, during congested periods.
however, on the switch, when i apply the service policy inbound, i get this error msg:
QoS: class(CRITICAL) match ip can be used only with match protocol in a match-all class [FastEthernet0/1]
Not sure why this error is being caused, or how to correct it.
It would appear to be caused by the access-group line in the class map for critical and/or scavenger traffic.
Can you help provide a correct config sample that will work for this setup?
switch model and ios is:
Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 26 WS-C2960-24TC-L 12.2(55)SE5 C2960-LANBASEK9-M Switch Ports Model
thanks in advance
01-30-2013 02:09 AM
Hi,
In my view the error message addresses the fact you are breaking the rule for the "match" command within the "class-map":
"Only one match criterion per class map is supported, and only one ACL per class map is supported." - 12.2(55) Configuration Guide,
"To define packet classification on a physical-port basis, only one match command per class map is supported." - 12.2(55) Command Reference,
ie. you cannot classify the traffic by ip dscp value AND access-list at the same time (sorry to say that).
Best regards,
Antonin
01-30-2013 08:28 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Try:
class-map match-any CRITICAL
match access-group name CRITICAL_DATA
class-map match-any SCAVENGER
match access-group name SCAVENGER
ip access-list extended CRITICAL_DATA
permit ip any any dscp af31
.
.
ip access-list extended SCAVENGER
permit ip any any dscp cs1
.
.
01-30-2013 08:49 AM
Thanks to Joseph and Antonin for your replies.
Joseph, my question for you now is, if i do as you suggest, i've removed the specific destination networks that i indicated were part of either scavenger or critical data.
how does you method determine which incoming packets are to be marked AF31 or CS1?
thanks again for your response. hope i haven't misundertood your info.
regards,
Ed
01-30-2013 08:55 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Ed, I meant for you to move the DSCP match from the match-class to the ACL. I.e. you keep the current ACEs, just add the new ACE.
01-30-2013 09:35 AM
thanks again Joseph.
can i do this:
ip access-list extended CRITICAL_DATA
# traffic rules for APPS1
permit ip any 10.180.9.16 0.0.0.0 dscp af31
permit ip any 10.180.9.12 0.0.0.0 dscp af31
#traffic rules for APPS2
permit tcp any 206.108.40.29 0.0.0.0 eq 80 dscp af31
if i do the above, and then apply the service policy input on all user access ports, will traffic destined for above destinations be marked with af31?
the CRITICAL_DATA acl above is only a portion of what is in the actual acl, just as an fyi.
thanks again
Ed
01-30-2013 10:07 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Sure you can match on the DSCP on the other ACEs, although if your intent is to mark matched AF31 with AF31, you don't need to as they already are so marked.
01-30-2013 10:18 AM
i think i've confused the situation, or i am confused.
currently no traffic is being marked with af31. we would like to apply a rule on switch user access ports that says, for example, any traffic destined for desintation IP 10.180.9.16 be marked with dscp af31. Likewise for any traffic destined for destination IP 206.108.40.29 port 80.
here is how i understand what you were telling to do in your first reply:
ip access-list extended CRITICAL_DATA
# traffic rules for APPS1
permit ip any 10.180.9.16 0.0.0.0
permit ip any 10.180.9.12 0.0.0.0
#traffic rules for APPS2
permit tcp any 206.108.40.29 0.0.0.0 eq 80
permit ip any any dscp af31
Exit
But if the above is correct, then to me, everything coming into a user access port will be marked af31. Hence why i changed to adding dscp af31 at the end of current permit lines. i thought that maybe that would do what we wanted.
what have i misunderstood. I'm very sorry for troubling you, but appreciate your help.
regards,
Ed
01-30-2013 04:44 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Well I'm confused.
You're not troubling me.
From your original class-maps it appears you wanted traffic that matched the ACL to get a specific marking or (the match-any) preserve traffic with that same marking. (BTW, this makes sense, unless you want to restrict the DSCP marking to traffic only matching the prior ACL.)
If the issue is the 2960 won't allow a class-map with multiple match statements, what I'm suggesting is moving the one class-map match statement, for the DSCP value, to an ACE. Your last posted ACL is what I intended by my first post. I listed the ACE first, but last ACE is fine too.
01-30-2013 05:37 PM
Lol, thanks Joseph. You are patient
you are correct in saying that we wanted to incoming traffic that matched the ACL to be marked, i.e. if incoming packet matched an ACE in the CRITICAL_DATA, it is to be marked dscp af31, if it matched an ACE from the SCAVENGER ACL, it should be marked with dscp cs1. And if the incoming packet didn't match any ACL, it's dscp value remains as it is.
so having said that, and done a little reading, wonder if this is what i should be doing:
policy-map Outbound-QOS
class CRITICAL
set dscp af31
class SCAVENGER
set
dscp cs1
class-map match-any CRITICAL
match access-group name CRITICAL_DATA
class-map match-any SCAVENGER
match access-group name SCAVENGER
and the ACL remains as the original ACL shown in my attachment. By doing it this way, do you feel i have the correct setting to mark incoming traffic with af31, if it matches ACL CRITICAL_DATA, or with dscp cs1 if it matches ACL SCAVENGER?
and all other incoming packets make no changes to thier dscp value, i.e. remain as they are.
thanks again. you've really provided some very good information and i'm grateful for your help
regards,
Ed
01-31-2013 02:44 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Oops! I just noticed in your attachment, your inbound policy and outbound policy are named the same. I.e:
policy-map Outbound-QOS
class VOICE
set precedence 5
.
.
interface FastEthernet0/1
service-policy input Outbound-QOS
policy-map Outbound-QOS
class VOICE
priority percent 25
.
.
interface Serial0/0/0
service-policy output Outbound-QOS
I assume your ingress policy was meant/is Inbound-QOS?
Yes, you can additionally set DSCP markings in an outbound policy (if I remember correctly, a feature added in later CBWFQ; although not recently). If you can and do do this, you then often don't need an ingress policy to mark.
Also if you do this, to preserve original markings, you wouldn't want to mark in egress default class because then already marked traffic like AF31 and CS1 would also be processed through the default class. So, again, if you specific ACLs match both specific IP addresses/ports or markings of the class, you should be good.
In other words, to recap, you eliminate your ingress policy, add set DSCP statements to your egress policy and use the DSCP ACEs in your ACLs (as previouslly discussed).
I often recommend against using WRED (as in your egress default-class) except for TCP like traffic, and even then, only with a real understanding how to use it (as the default values are often far from optimal).
With all that said, I don't believe 2960s actually support egress service-policies. For most small switches, you need an ingress policy to mark packets if necessary and then map markings to hardware egress queues which have their own set of configuration options. There might also be some additional limitations because of the IOS feature set you're using, LANBASE.
Sorry I didn't notice this earier, I focused too much on CBWFQ features rather than the platform features.
02-01-2013 11:39 AM
Hi Joseph,
Sorry delay in replying. Agreed, and confirmed that the C2960 does not appear to allow egress service policy settings. At least not with the code we are running.
Also, it's my fault about the confusion in using service policy with name 'Outbound' when i am actually applying it for inbound traffic on the switch.
I've attached a visio with some details to help better explain. I believe you have helped in answering my questions though. My main objective was to find a way to mark traffic we deemed as critical with dscp af31, or traffic we deemed as scavenger with dscp cs1. All other traffic should traverse as marked coming into the switch. FYI for voice, the user pc group policy setup marks Lync voice traffic and control, at the pc. Video is included only as for future requirements, but not actually in use today.
if you believe i've achieved this with the config samples in this visio attachment, let me know.
ideally, i'd love to ensure that the switch deals with forwarding voice and critical data packets to the router before best effort (or def) and scavenger traffic, on the uplink between sw and router. Not sure if that is achieved in this config or not.
Very much appreciate your help and guidance.
regards,
Ed
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide