QoS mark management traffic sent by Catalyst switch.

[d.alsn-nilsson]

Hi,

I've noticed that Catalyst switches seem to DSCP mark some management traffic that they send, but not all.

For example, SYSLOG and SNMP Traps are not DSCP marked, while Telnet and SSH does get proper DSCP markings when originated from the switch.

This can of course cause problems if the switch tries to send out SYSLOG/SNMP through a congested interface. If they were marked, they could be assigned a queue, drop threshold etc to guarantee that they won't get dropped.

Someone knows how to get around this issue?

(Please note that classifying and marking on ingress won't help, because this is about traffic that originates from the switch itself.)

Thanks,

David

[Daniel Hood · Accepted solution]

Can you share your config?

[d.alsn-nilsson]

Hi,danielhoodt!

By mistake I marked your reply as a "Correct Answer".

Sorry about that. Don't know how to undo it.

Anywhay, as you can see in my reply to rajeevsh, it's not an issue of the QoS config on the local switch.

When it comes to SYSLOG and SNMP Traps, it's basically standard configured, and there are no options I can find to force SYSLOG and SNMP to be sent marked.

It's actually that I'm looking for; How to make the SYSLOG and SNMP traffic from the local switch to be DSCP tagged.

/David

[Rajeev Sharma]

Hey David,

You may use PBR for marking the traffic and then apply it locally. Something like this:

! Use ACL to specify what you want to have marked
#access-list 166 permit ......

#route-map local-qos permit 10
#match ip address 166
#set ip precedence x

! In the global config mode

#ip local policy route-map local-qos

HTH.

Regards,

RS.

[Rajeev Sharma]

Hey David,

Check your QoS configuration and look for any marking or classification for traffic destined to your SNMP or SYSLOG server.

HTH.

Regards,

RS.

[d.alsn-nilsson]

Hi,

Thanks for suggestion.

However, any classification and marking can only be done on ingress. In other words, it cannot classify or mark any traffic sent by the actual switch in question. (SYSLOG/SNMP traffic from local switch originates from it's CPU, and does not come from outside via an ingress interface.)

The next switch on the path to the SYSLOG/SNMP destination can easily classify/mark/queue etc the traffic sent by the switch in question. No problem. But then it might be too late, if the switch we are looking at is trying to send out unmarked SYSLOG/SNMP  through congested interface.

Has anyone managed to make a Catalyst switch mark it's own SYSLOG/SNMP traffic with something other than DSCP=0?

Hope I'm clear enough on the actual issue.

Thanks again,

David

[Joseph W. Doherty]

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

It would be Rube Goldberg, but if you have extra ports, you could loop traffic back through the same switch.  You would then be able to see your egress as ingress before it become egress again.  I.e. you could mark your original egress on the looped ingress and then let go as egress again.